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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
