[squid-users] ssl_bump with intermediate CA

[senor]

Thank you Amos. I agree that adding the anchor is generally harmless and
you've chosen your battles wisely.
Also thank you Garri. I must have missed your response confirming the same.

For current squid versions the wiki page is misleading according to all
credible references I can find. Any application failing because the root
is missing is buggy itself and that is not a squid problem. There are
several very good arguments for excluding it, including to expose bad
apps. Trusting a root cert sent from a server is like trusting a
politician because all promises end with "trust me".

I'll submit a request for the description of cafile/tls-cafile to change
and move the discussion to there.

Thanks all,
Senor

On 1/6/2017 2:06, Amos Jeffries wrote:
> On 2017-01-06 21:27, senor wrote:
>> Thank you for the response but I think my question is still unanswered.
>> Comments below:
>>
>> On 1/5/2017 16:57, Bruce Rosenberg wrote:
>>> The cafile option specifies the "chain" file squid should send back to
>>> the client along with the cert, exactly as you would normally do with
>>> Apache httpd or Nginx.
>> (For clarity: I'm using 3.5.23. cafile was replaced in squid-4)
>> This may be what cafile is used for but that does not match the
>> directive description.
>> http://www.squid-cache.org/Versions/v3/3.5/cfgman/http_port.html
>> My suspicion is that the description is a confusion between the same
>> option in openssl and web server options (Apache SSLCACertificateFile
>> and similar).
>> What's it really used for? Chain completion, client cert verification or
>> both?
> 
> It is used for chain completion. *which* chain is being completed
> depends on the traffic mode.
> 
> clientca= should be the one used *only* for client cert verification (I
> think). But neither was used consistently in Squid-3, so YMMV based on
> the traffic modes.
> 
>>
>>> In the example the generated server cert is depth 0, CA2 is depth 1 and
>>> CA1 is depth 2.
>>> If the client has CA1 installed as a trust anchor then technically you
>>> don't need to send CA1 as it is discarded by the client once the trust
>>> relationship for CA2 is established.
>>> It's good practice to send the full chain though as it makes
>>> troubleshooting easier.
>>> From a client perspective you can quickly grab the whole chain with
>>> openssl s_client and check if CA1 is in the trust store.
>> I have to disagree with this. The anchor (CA1) is discarded regardless.
>> It cannot be used. If included it bloats the TLS handshake. Even openssl
>> will discard it and then look in the trusted CA store.
>>
>> I see with a packet cap that the mimicked server cert and the signing
>> cert are both included even without the cafile option specified.
>>
>> So is it safe to say that the referenced wiki page has just become
>> outdated? If cafile is used to fill in the cert chain it wouldn't be
>> needed unless there were additional intermediate certs between the mitm
>> cert and the trusted CA known to the client. (As in CA1 is trusted by
>> clients, CA1 signs CA2 which signs CA3 which is used as MITM cert,
>> cafile=CA2)
> 
> That wiki page was incorrect at the time of creation. But the author
> refuses to agree that root cert are discarded so I left it there instead
> of inciting an edit war. Saving the root CA into the file should be
> harmless anyway.
> 
> Amos
> 
> 
>