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

[James Lay]

Thanks for this Amos....I will try and do more experimenting this week
with more results.

James

On Tue, 2015-05-26 at 19:46 +1200, Amos Jeffries wrote:

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150528/15a23b34/attachment-0001.html>