[squid-users] SSL bumping without faked server certificates

Stefan Kutzke stefan.kutzke at bettermarks.com
Sat Nov 14 19:59:19 UTC 2015


... and more ...


I don't know what is going wrong or what is missing in the configuration.

Both Squid and client are able to connect to 212.45.105.89:443 with
# openssl s_client -connect 212.45.105.89:443
CONNECTED(00000003)
depth=3 C = ZA, ST = Western Cape, L = Cape Town, O = Thawte Consulting cc, OU = Certification Services Division, CN = Thawte Premium Server CA, emailAddress = premium-server at thawte.com<mailto:premium-server at thawte.com>
verify return:1
depth=2 C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA
verify return:1
depth=1 C = US, O = "Thawte, Inc.", CN = Thawte SSL CA
verify return:1
depth=0 C = DE, ST = Berlin, L = Berlin, O = bettermarks GmbH, CN = *.bettermarks.com
verify return:1
---
Certificate chain
 0 s:/C=DE/ST=Berlin/L=Berlin/O=bettermarks GmbH/CN=*.bettermarks.com
   i:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
 1 s:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
   i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
 2 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
   i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server at thawte.com<mailto:CA/emailAddress=premium-server at thawte.com>
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEljCCA36gAwIBAgIQDgGSShcLYslr7WvI8BNFWDANBgkqhkiG9w0BAQUFADA8
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMVGhhd3RlLCBJbmMuMRYwFAYDVQQDEw1U
aGF3dGUgU1NMIENBMB4XDTEzMTIyNDAwMDAwMFoXDTE2MDEyMzIzNTk1OVowZjEL
MAkGA1UEBhMCREUxDzANBgNVBAgTBkJlcmxpbjEPMA0GA1UEBxQGQmVybGluMRkw
FwYDVQQKFBBiZXR0ZXJtYXJrcyBHbWJIMRowGAYDVQQDFBEqLmJldHRlcm1hcmtz
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANZNN7SeA27FgU3W
QEHHfgQhTnJ3zwviubXSU3vppqDmguuMfdR0NIqHQv3ds7QdEK0jik3rDzAzadBD
mQDmN4IIbp1IgFKuI9IWF/6jXv3ViNwdbIadUxPGHqa/SYO4XPFA3wpMBjHymvK2
GpXMD7vp7MxBCydtod5SY5kft6Y1T3jgIAjS2BUhXS8uQCra2kXLc2Jwu/JX5Asa
oQvnGhyltpnEQZto5MK1zeGaEi/AoJZOsrIv3nVULTyIqLqI33BD6Vru8kXp939k
rofE63723dA4YHhtVmrzn55milysxMZnR6XjdywFF41xFqed6dmHGOnGAkAJicqZ
QCOF2+cCAwEAAaOCAWgwggFkMBwGA1UdEQQVMBOCESouYmV0dGVybWFya3MuY29t
MAkGA1UdEwQCMAAwQgYDVR0gBDswOTA3BgpghkgBhvhFAQc2MCkwJwYIKwYBBQUH
AgEWG2h0dHBzOi8vd3d3LnRoYXd0ZS5jb20vY3BzLzAOBgNVHQ8BAf8EBAMCBaAw
HwYDVR0jBBgwFoAUp6KDuzRFQD381TBPErk+oQGf9tswOgYDVR0fBDMwMTAvoC2g
K4YpaHR0cDovL3N2ci1vdi1jcmwudGhhd3RlLmNvbS9UaGF3dGVPVi5jcmwwHQYD
VR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMGkGCCsGAQUFBwEBBF0wWzAiBggr
BgEFBQcwAYYWaHR0cDovL29jc3AudGhhd3RlLmNvbTA1BggrBgEFBQcwAoYpaHR0
cDovL3N2ci1vdi1haWEudGhhd3RlLmNvbS9UaGF3dGVPVi5jZXIwDQYJKoZIhvcN
AQEFBQADggEBAFXVX0KqaJHiMZo7PjbWSfXunaZYdV4KIjpYlfyWBJ8Gb7p3e+4j
aKrs3Nq+ffRPnm+TtbJWRcJ0ssHSymJNiDw6UfYprNkIiOzgPisY8g32yPjUIekf
GPm9RaAO0ml9vQH/cNJjw4+Da249W0PYbkGWngozYqH9bOYIu88kqCVUePeHzQjI
rI9kUiXJOUZYwIhsdtFNiPbvLHyYdvWLsCvLYAk2hbJd2L1j7Z3YdO+Lf+gK+kj+
rgMji14ibaWx1iKfVJ7RaNBkNWsX3aE7dlBdx35Tc30Hy1eADq029ae+41oDEO8y
4f38eLFMYfXzHx0j1Td0WAXMGK3Nyhiquck=
-----END CERTIFICATE-----
subject=/C=DE/ST=Berlin/L=Berlin/O=bettermarks GmbH/CN=*.bettermarks.com
issuer=/C=US/O=Thawte, Inc./CN=Thawte SSL CA
---
No client certificate CA names sent
---
SSL handshake has read 3618 bytes and written 607 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-SHA256
    Session-ID: D4883E09C2BAD02BACEB79C87CB6B7583D2D907FE6DA11290920CC6D4AEFD98D
    Session-ID-ctx:
    Master-Key: 8A2CE177DFFD2FDD36124CF95CE4BA09D768FE919F001FE87B68ADF7881BFF9C50DDFDB0ADDC223AE34E58F30663935C
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1447183108
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---


Is there anything I can do in order to address my problem? More or other debugging options? Unfortunatily I am not
very familiar with Squid.

The next step would be to get CloudFront working. To be precise: I want to use a further hostname cdn.bettermarks.com
that is only a CNAME for d2gs9kr1131uxo.cloudfront.net. CloudFront provides several IP addresses, each of them is shared
by multiple hostnames/domains. There is no way to make a https connection to CloudFront without SNI.


Best regards,
Stefan


Am Dienstag, den 10.11.2015, 08:49 -0700 schrieb Alex Rousskov:
On 11/10/2015 07:05 AM, Stefan Kutzke wrote:

My assumption is that I have to use in Squid's config:

acl MYSITE ssl:server_name .mydomain.com
ssl_bump bump MYSITE
ssl_bump splice all

This results in tunneling all https traffic, nothing will be bumped and
cached.

Yes, probably because MYSITE (ssl::server_name) often needs SNI and SNI
is not available during step1 when MYSITE is evaluated in your config.
In other words, your config is equivalent to

  ssl_bump splice all

unless reverse DNS works perfectly well.


I'm a little bit confused about the documentation:

Under the headline "Processing steps":
*Step 2:*
 1. Get TLS clientHello info, including *SNI* where available.


Under the headline "Actions":
peek/stare Receive client *SNI (step1)*, ...


I know it is confusing, but I cannot find a better way to explain this
in brief documentation without pictures. Improvements are welcomed. The
key here is that ssl_bump rules are evaluated at the end of a step and
usually allow Squid to do something at the beginning of the next step.

For example, during step1, Squid does not have SNI. If a peek rule
matches during step1, then Squid proceeds to step2. At the beginning of
step2, Squid gets SNI. Thus, a step1 peek rule controls whether Squid
will get SNI (during step2).


Is it possible to achieve my goal with Squid in transparent mode?

I should be possible, but I do not know whether anybody has done exactly
that so there could be some minor bugs along the way. You need
configuration suggested by Sebastian and the latest Squid you can build.


HTH,

Alex.

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


More information about the squid-users mailing list