[squid-users] Squid 4.x: Intermediate certificates downloader
Yuri Voinov
yvoinov at gmail.com
Mon Jan 23 19:22:31 UTC 2017
24.01.2017 0:06, Alex Rousskov пишет:
> On 01/23/2017 10:41 AM, Yuri Voinov wrote:
>> 23.01.2017 23:31, Alex Rousskov пишет:
>>> On 01/23/2017 04:28 AM, Yuri wrote:
>>>> I.e., where downloaded certs stored, how it
>>>> handles, does it saves anywhere to disk?
>>> Missing certificates are fetched using HTTP[S]. Certificate responses
>>> should be treated as any other HTTP[S] responses with regard to caching.
>>> For example, if you have disk caching enabled and your caching rules
>>> (including defaults) allow certificate response caching, then the
>>> response should be cached. Similarly, the cached certificate will
>>> eventually be evicted from the cache following regular cache maintenance
>>> rules. When that happens, Squid will try to fetch the certificate again
>>> (if it becomes needed again).
>> I.e., fetchesd intermediate certificate stores only in memory cache for
>>
>> sslcrtd_program /usr/local/squid/libexec/security_file_certgen -s
>> /var/lib/ssl_db -M 4MB
>>
>> daemon, right? And never stores anywhere on disk?
> No, this is incorrect -- sslcrtd_program settings are independent from
> fetching missing certificates. The ssl_crtd helper is about fake
> certificate generation. The helper does not use the Squid cache to cache
> its results. The "missing certificates" features are about the virgin
> server certificates that are necessary to complete/validate the server
> chain but absent from the server's ServerHello response.
>
> The only relationship between the ssl_crtd helper and fetching of the
> missing certificates (that I can think of) is that the helper will mimic
> the fetched certificates (in some cases). However, I am not even sure
> whether the helper gets the virgin incomplete certificate chain or the
> completed-by-Squid certificate chain in such cases. I only suspect that
> it is the latter. @Christos, please correct me if my suspicion is wrong.
>
>
>>>> 2. How this feature is related to sslproxy_foreign_intermediate_certs,
>>>> how it can interfere with it?
>>> AFAICT by looking at the code, Squid only downloads certificates that
>>> Squid is missing when trying to build a complete certificate chain for a
>>> given server connection. Any sslproxy_foreign_intermediate_certs are
>>> used as needed during the chain building process (i.e., they are _not_
>>> "missing").
>> Ok, so, this file uses for complete chains, and it contains statically
>> added (manually) certs only, right?
> Yes, the sslproxy_foreign_intermediate_certs file is maintained by the
> Squid administrator. Squid does not update it.
>
>
>> I.e., downloader should not save fetched intermediate CA's here,
> Correct.
>
>
>> which will be logically, isn't it?
> I believe it is better to use the regular Squid cache for storing the
> fetched missing certificates. I would not call abusing the
> sslproxy_foreign_intermediate_certs file for this purpose completely
> illogical, but such abuse would create more problems than it would solve
> IMO. We have also considered using a dedicated storage for the fetched
> missing certificates, but have decided (for many reasons) that it would
> be worse than reusing the existing caching infrastructure.
>
> FWIW, IMO, storing the generated fake certificates in the regular Squid
> cache would also be better than using an OpenSSL-administered database.
Exactly.
>
>
> HTH,
>
> Alex.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170124/84983bf9/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170124/84983bf9/attachment-0001.sig>
More information about the squid-users
mailing list