[squid-users] Ssl-bump deep dive (self-signed certs in chain)

[Amos Jeffries]

On 26/05/2015 4:26 a.m., James Lay wrote:
> So following advice and instructions on this page:
> 
> http://wiki.squid-cache.org/Features/DynamicSslCert
> 
> I have set up my lab with explicit proxy by exporting http_proxy and
> https_proxy.  After creating the self-signed root CA certificate above
> and creating the .der file for the client, here are my results:
> 
> From the squid side:
> 2015/05/25 10:02:20.161| Using certificate
> in /opt/etc/squid/certs/SquidCA.pem
> 2015/05/25 10:02:20.170| support.cc(1743) readSslX509CertificatesChain:
> Certificate is self-signed, will not be chained
> I get the below when I don't specify a CA with curl, otherwise when I do
> I get no error:
> 2015/05/25 09:21:02.229| Error negotiating SSL connection on FD 12:
> error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca (1/0)

If that error is displayed by Squid about the clients connection. Then I
believe it means the client is attempting to perform TLS authentication
to Squid using the CA you installed there. Which is not possible as the
CA is supposed to make the client trust Squid generated certs, not the
other way around.


> 
> And from the client side:
> root at kali:~/test# curl -v https://mail.slave-tothe-box.net
> * About to connect() to proxy 192.168.1.9 port 3129 (#0)
> *   Trying 192.168.1.9...
> * connected
> * Connected to 192.168.1.9 (192.168.1.9) port 3129 (#0)
> * Establish HTTP proxy tunnel to mail.slave-tothe-box.net:443
>> CONNECT mail.slave-tothe-box.net:443 HTTP/1.1
>> Host: mail.slave-tothe-box.net:443
>> User-Agent: curl/7.26.0
>> Proxy-Connection: Keep-Alive
>>
> * Easy mode waiting response from proxy CONNECT
> < HTTP/1.1 200 Connection established
> < 
> * Proxy replied OK to CONNECT request
> * successfully set certificate verify locations:
> *   CAfile: none
>   CApath: /etc/ssl/certs
> * SSLv3, TLS handshake, Client hello (1):
> * SSLv3, TLS handshake, Server hello (2):
> * SSLv3, TLS handshake, CERT (11):
> * SSLv3, TLS alert, Server hello (2):
> * SSL certificate problem: self signed certificate in certificate chain
> * Closing connection #0
> 
> And testing with specifying the .der file:
> root at kali:~/test# curl --cacert /etc/ssl/certs/SquidCA.der -v
> https://mail.slave-tothe-box.net
> * About to connect() to proxy 192.168.1.9 port 3129 (#0)
> *   Trying 192.168.1.9...
> * connected
> * Connected to 192.168.1.9 (192.168.1.9) port 3129 (#0)
> * Establish HTTP proxy tunnel to mail.slave-tothe-box.net:443
>> CONNECT mail.slave-tothe-box.net:443 HTTP/1.1
>> Host: mail.slave-tothe-box.net:443
>> User-Agent: curl/7.26.0
>> Proxy-Connection: Keep-Alive
>>
> * Easy mode waiting response from proxy CONNECT
> < HTTP/1.1 200 Connection established
> < 
> * Proxy replied OK to CONNECT request
> * error setting certificate verify locations:
>   CAfile: /etc/ssl/certs/SquidCA.der
>   CApath: /etc/ssl/certs
> 
> * Closing connection #0
> curl: (77) error setting certificate verify locations:
>   CAfile: /etc/ssl/certs/SquidCA.der
>   CApath: /etc/ssl/certs
> 
> 
> I can confirm that the server is using a bona-fide certificate issued
> from StartSSL and works, so at this point I'm open to suggestions.
> Thank you.

curl is complaining that the CA chain for the Squid-generted cert has a
self-signed CA. This is expected and desired behaviour if the
self-signed CA was sent by Squid.

The errors only occur when the self-signed CA is not sent by Squid, but
using the one installed on the client.


For that I believe you need to configure Squid to sign/generate using
the intermediate certificate. The self-signed root CA not configured in
Squid at all.

Like so:

A)
 client Trust DB installed with self-signed root CA

 squid.conf cert= configured with intermediary CA certificate

 squid.conf cafile= configured with any other intermediary CA
certificates (in order back to root CA, but excluding it).

 Squid generates per-connection certificate

OR:

B)
 client Trust DB installed with self-signed root CA

 squid.conf cert= configured with self-signed root CA

 Squid generates per-connection certificate


Note that in (B) there is no intermediary certificate at all, and Squid
does not emit any CA chain to the client.

It works exactly the same way as the globally trusted CA do. But they
are contractually obliged to refuse giving out intermediary CA for
anyones use, or loose their status as trusted CA.

Amos