[squid-users] Squid 4.x: Intermediate certificates downloader

[Alex Rousskov]

On 01/23/2017 03:59 PM, Amos Jeffries wrote:
> On 24/01/2017 8:22 a.m., Yuri Voinov wrote:
>> 24.01.2017 0:06, Alex Rousskov пишет:
>>> FWIW, IMO, storing the generated fake certificates in the regular Squid
>>> cache would also be better than using an OpenSSL-administered database.

>> Exactly.

> There is one drawback to that suggestion though.

> The cert generated by Squid are pollution as far as TLS is concerned.

TLS has nothing to do with this decision though. Whether it is a good
idea to store something in a cache is determined primarily by two
factors: Reusability (i.e., the probability of a hit) and hit cost
(relative to a miss cost).


> Intended for use only by that proxy installation with the specific set
> of details involved with the origin certificate on that connection.
> Re-usability is purely a bonus. People could get into connectivity
> trouble if they were stored long-term like other cache items.

Sorry, I do not understand your argument. It seems to be revolving
around re-usability and "connectivity trouble". Both problems may be
about the same underlying concern, but I am addressing them separately:

* Both fake certificates and many other cached items are reusable, often
short- and sometimes long-term so there does not seem to be an important
difference as far as the probability of a hit is concerned. In fact,
fake certificates may be more reusable long-term than an average cached
HTTP response because the certificates they mimic and the mimicking
parameters are often stable for many days or even weeks.

* As for the "connectivity trouble", I assume that you are talking about
the cache user getting a stale (i.e., no longer applicable) fake
certificate from the cache without realizing it. I believe HTTP has
solutions for that problem already; any implementation using HTTP cache
for fake certificates would need to use the right HTTP knobs to ensure
freshness/applicability of the previously cached fake certificate to its
current user. Moreover, the existing fake certificate cache has to solve
exactly the same problem anyway, and does not have more appropriate
tools than an HTTP cache can offer.


AFAICT, the only real doubt regarding fake certificate caching is
whether the cost of generating the correct cache request (and/or
validating the hit response) is significantly lower than the cost of
generating a new fake certificate from scratch (i.e., the miss-vs-hit
cost factor). That problem exist for any cache, generic HTTP or
certificate-specific one. AFAIK, it needs studying/experiments.


Cheers,

Alex.