ssl_bump with intermediate CA

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

ssl_bump with intermediate CA

senor
Hello All.
I'd like clarification of the documentation at
http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpWithIntermediateCA

In section "CA certificate preparation" it is stated that a file should
be created with "intermediate CA2 followed by root CA1 in PEM format".
CA1 is the cert trusted by the clients. CA2 is used to sign the mimicked
certs. And finally the statement "Now Squid can send the intermediate
CA2 public key with root CA1 to client and does not need to install
intermediate CA2 to clients."

The specification states that the clients MUST NOT use CA1 provided in
the TLS exchange. CA1 must be (and in this scenario is) already included
in its trusted store of CAs.

As I understand it, the TLS exchange with the client for a bumped
connection should have the mimicked server cert followed by the
intermediate cert (CA2) and that's all. The client completes the chain
with the already trusted CA1.

The example file created is used for cafile= option to http_port which
is supposed to be for verifying client certs which is not part of this
scenario.

This is getting a little long-winded so I'll wait to see what anyone has
to say about my assumptions or understanding.

Thanks,
Senor

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ssl_bump with intermediate CA

Bruce Rosenberg
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.
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.

On Fri, Jan 6, 2017 at 10:40 AM, senor <[hidden email]> wrote:
Hello All.
I'd like clarification of the documentation at
http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpWithIntermediateCA

In section "CA certificate preparation" it is stated that a file should
be created with "intermediate CA2 followed by root CA1 in PEM format".
CA1 is the cert trusted by the clients. CA2 is used to sign the mimicked
certs. And finally the statement "Now Squid can send the intermediate
CA2 public key with root CA1 to client and does not need to install
intermediate CA2 to clients."

The specification states that the clients MUST NOT use CA1 provided in
the TLS exchange. CA1 must be (and in this scenario is) already included
in its trusted store of CAs.

As I understand it, the TLS exchange with the client for a bumped
connection should have the mimicked server cert followed by the
intermediate cert (CA2) and that's all. The client completes the chain
with the already trusted CA1.

The example file created is used for cafile= option to http_port which
is supposed to be for verifying client certs which is not part of this
scenario.

This is getting a little long-winded so I'll wait to see what anyone has
to say about my assumptions or understanding.

Thanks,
Senor

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ssl_bump with intermediate CA

Garri Djavadyan
In reply to this post by senor
On Thu, 2017-01-05 at 23:40 +0000, senor wrote:

> Hello All.
> I'd like clarification of the documentation at
> http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpWithInter
> mediateCA
>
> In section "CA certificate preparation" it is stated that a file
> should
> be created with "intermediate CA2 followed by root CA1 in PEM
> format".
> CA1 is the cert trusted by the clients. CA2 is used to sign the
> mimicked
> certs. And finally the statement "Now Squid can send the intermediate
> CA2 public key with root CA1 to client and does not need to install
> intermediate CA2 to clients."
>
> The specification states that the clients MUST NOT use CA1 provided
> in
> the TLS exchange. CA1 must be (and in this scenario is) already
> included
> in its trusted store of CAs.
>
> As I understand it, the TLS exchange with the client for a bumped
> connection should have the mimicked server cert followed by the
> intermediate cert (CA2) and that's all. The client completes the
> chain
> with the already trusted CA1.
>
> The example file created is used for cafile= option to http_port
> which
> is supposed to be for verifying client certs which is not part of
> this
> scenario.
>
> This is getting a little long-winded so I'll wait to see what anyone
> has
> to say about my assumptions or understanding.
>
> Thanks,
> Senor

Hi Senor,

You are right, it is not required to send root CA cert to a client. It
is already installed in client's cert store. You can find more details
in bug report 3426 [1] (comments 11 and 13).

[1] http://bugs.squid-cache.org/show_bug.cgi?id=3426


Garri
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ssl_bump with intermediate CA

senor
In reply to this post by Bruce Rosenberg
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?

> 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)

Thanks for comments.
Senor

>
> On Fri, Jan 6, 2017 at 10:40 AM, senor <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hello All.
>     I'd like clarification of the documentation at
>     http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpWithIntermediateCA
>     <http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpWithIntermediateCA>
>
>     In section "CA certificate preparation" it is stated that a file should
>     be created with "intermediate CA2 followed by root CA1 in PEM format".
>     CA1 is the cert trusted by the clients. CA2 is used to sign the mimicked
>     certs. And finally the statement "Now Squid can send the intermediate
>     CA2 public key with root CA1 to client and does not need to install
>     intermediate CA2 to clients."
>
>     The specification states that the clients MUST NOT use CA1 provided in
>     the TLS exchange. CA1 must be (and in this scenario is) already included
>     in its trusted store of CAs.
>
>     As I understand it, the TLS exchange with the client for a bumped
>     connection should have the mimicked server cert followed by the
>     intermediate cert (CA2) and that's all. The client completes the chain
>     with the already trusted CA1.
>
>     The example file created is used for cafile= option to http_port which
>     is supposed to be for verifying client certs which is not part of this
>     scenario.
>
>     This is getting a little long-winded so I'll wait to see what anyone has
>     to say about my assumptions or understanding.
>
>     Thanks,
>     Senor
>
>     _______________________________________________
>     squid-users mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://lists.squid-cache.org/listinfo/squid-users
>     <http://lists.squid-cache.org/listinfo/squid-users>
>
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ssl_bump with intermediate CA

Amos Jeffries
Administrator
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

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ssl_bump with intermediate CA

Eliezer Croitoru
Hey Amos,

We can use the discussion section of the wiki to add some comments but the thing is that reality is almost the only answer to some questions.
IE a "cafile" in the normal world would be a certificate on the wall or in some database(back yard archive).
When in most places and cases one's diploma certificate is enough since not most of the world are certificate forgers.
Depends on the locality different measures to enforce the diploma validation are in place.
So if we would compare the real CA's world to the Computer Based one's there would be a big enough different.
Most web applications are more "aware" to these issues then any normal citizen would understand and know about.
The simple answer in most cases is that on the stage of validation there are  two things to validate:
- Authenticity
- Validity(expiration)

When a client probes for a connection it would first verify the chain in some places, but, let say I have a hospital and doctors inside, most clients of the hospital would not require validation of authenticity for the doctor diploma since the hospital is the proxy for this part of the connection and the client left alone to only present the request for care.

With the above real world "example" in hands we know that in the servers world we need to be able to inspect the certificate at-least once in period and we as sysadmins are required to present a full chain in order to meet the clients requests at-least once if not more.

I believe that a proxy should be required to be able to present the full chain certificates to be compatible with the way web applications themselves present their certificates.

And the simplest way to not open an "Edit" war is in most cases comments on the wiki discussion section..
But I do understand that there are wars which needs to be left alone.

All The Bests,
Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: [hidden email]


-----Original Message-----
From: squid-users [mailto:[hidden email]] On Behalf Of Amos Jeffries
Sent: Friday, January 6, 2017 12:06 PM
To: [hidden email]
Subject: Re: [squid-users] ssl_bump with intermediate CA

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

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ssl_bump with intermediate CA

senor
In reply to this post by Amos Jeffries
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
>
>
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users