Re: [squid-users] SSL bumping without faked server certificates
Hi Alex, sorry for the late reply. > > 2015/11/10 19:24:30.181 kid1| 33,5|... > > 2015/11/10 19:25:30.016 kid1| 33,3| AsyncCall.cc(93) ScheduleCall: > > IoCallback.cc(135) will call > > ConnStateData::clientPinnedConnectionRead(local=172.31.1.15:49421 > > remote=212.45.105.89:443 FD 15 flags=1, flag=-10, data=0x19ced08) > > [call349]> > > This one second gap after a successful SSL negotiation with the > origin server is rather suspicious, but I am going to ignore it ... This is not one second but one minute and just the default timeout of curl. Nevertheless I have built a new RPM package with the latest 3.5.11 source and the patch you mentioned. The result is the same. I have reduced the curl timeout to 10 seconds: Client: # curl -vvv --connect-timeout 10 https://school.bettermarks.com/static/flexclient4/bm_exerciseseries.swf -o /dev/null * About to connect() to school.bettermarks.com port 443 (#0) * Trying 212.45.105.89... connected * Connected to school.bettermarks.com (212.45.105.89) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * NSS error -5990 * Closing connection #0 * SSL connect error curl: (35) SSL connect error Now there is a 10 second gap in Squid's cache log. Squid: 2015/11/23 10:20:05.152 kid1| 33,5| client_side.cc(3693) httpsCreate: will negotate SSL on local=212.45.105.89:443 remote=10.0.0.2:41428 FD 11 flags=33 2015/11/23 10:20:05.152 kid1| 33,5| AsyncCall.cc(26) AsyncCall: The AsyncCall ConnStateData::requestTimeout constructed, this=0x1ff6340 [call77] 2015/11/23 10:20:14.992 kid1| 83,7| bio.cc(168) stateChanged: FD 11 now: 0x10 UNKWN (before/accept initialization) 2015/11/23 10:20:14.992 kid1| 83,7| bio.cc(168) stateChanged: FD 11 now: 0x2001 UNKWN (before/accept initialization) 2015/11/23 10:20:14.992 kid1| 83,5| bio.cc(118) read: FD 11 read 0 <= 11 2015/11/23 10:20:14.992 kid1| 83,5| bio.cc(144) readAndBuffer: read 0 out of 11 bytes 2015/11/23 10:20:14.992 kid1| 83,2| client_side.cc(3725) Squid_SSL_accept: Error negotiating SSL connection on FD 11: Aborted by client: 5 I digged deeper into the traffic using Wireshark. As a reminder my network setup: Client (10.0.0.2) <---> (10.0.0.1) Squid (10.31.1.15) <---> 212.45.105.89 (Origin) Here is the relevant packet flow. I have stripped off DNS, NTP, etc. and time format is UTC (Squid's cache log above shows UTC+1): Client: 10 2015-11-23 09:20:04.971734836 10.0.0.2 212.45.105.89 TCP 74 41428→443 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=5322725 TSecr=0 WS=128 12 2015-11-23 09:20:04.971946983 212.45.105.89 10.0.0.2 TCP 74 443→41428 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=2202045 TSecr=5322725 WS=128 13 2015-11-23 09:20:04.971968589 10.0.0.2 212.45.105.89 TCP 66 41428→443 [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=5322726 TSecr=2202045 17 2015-11-23 09:20:05.047529339 10.0.0.2 212.45.105.89 SSL 174 Client Hello 19 2015-11-23 09:20:05.047868761 212.45.105.89 10.0.0.2 TCP 66 443→41428 [ACK] Seq=1 Ack=109 Win=14592 Len=0 TSval=2202121 TSecr=5322801 26 2015-11-23 09:20:14.980851745 10.0.0.2 212.45.105.89 TCP 66 41428→443 [FIN, ACK] Seq=109 Ack=1 Win=14720 Len=0 TSval=5332735 TSecr=2202121 27 2015-11-23 09:20:14.982049717 212.45.105.89 10.0.0.2 TCP 66 443→41428 [FIN, ACK] Seq=1 Ack=110 Win=14592 Len=0 TSval=2212055 TSecr=5332735 28 2015-11-23 09:20:14.982087279 10.0.0.2 212.45.105.89 TCP 66 41428→443 [ACK] Seq=110 Ack=2 Win=14720 Len=0 TSval=5332736 TSecr=2212055 Squid: 13 2015-11-23 09:20:04.983024000 10.0.0.2 212.45.105.89 TCP 74 41428→443 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=5322725 TSecr=0 WS=128 14 2015-11-23 09:20:04.98308 212.45.105.89 10.0.0.2 TCP 74 443→41428 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=2202045 TSecr=5322725 WS=128 17 2015-11-23 09:20:04.983252000 10.0.0.2 212.45.105.89 TCP 66 41428→443 [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=5322726 TSecr=2202045 26 2015-11-23 09:20:05.058868000 10.0.0.2 212.45.105.89 SSL 174 Client Hello 27 2015-11-23 09:20:05.058927000 212.45.105.89 10.0.0.2 TCP 66 443→41428 [ACK] Seq=1 Ack=109 Win=14592 Len=0 TSval=2202121 TSecr=5322801 32 2015-11-23 09:20:05.060596000 172.31.1.15 212.45.105.89 TCP 74 34995→443 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=2202122 TSecr=0 WS=128 33 2015-11-23 09:20:05.081926000 212.45.105.89 172.31.1.15 TCP 74 443→34995 [SYN, ACK] Seq=0 Ack=1 Win=4380 Len=0 MSS=1460 TSval=866426570 TSecr=2202122 SACK_PERM=1 34 2015-11-23 09:20:05.081976000 172.31.1.15 212.45.105.89 TCP 66 34995→443 [ACK] Seq=1 Ack=1 Win=14600 Len=0 TSval=2202144 TSecr=866426570 35 2015-11-23 09:20:05.082267000 172.31.1.15 212.45.105.89 TLSv1.2 359 Client Hello 36 2015-11-23 09:20:05.114617000 212.45.105.89 172.31.1.15 TLSv1.2 1514 Server Hello 37 2015-11-23 09:20:05.114654000 172.31.1.15 212.45.105.89 TCP 66 34995→443 [ACK] Seq=294 Ack=1449 Win=17376 Len=0 TSval=2202177 TSecr=866426602
Re: [squid-users] SSL bumping without faked server certificates
... 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(0003) 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-ser...@thawte.com<mailto:premium-ser...@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-ser...@thawte.com<mailto:CA/emailAddress=premium-ser...@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 MYSI
Re: [squid-users] SSL bumping without faked server certificates
2.31.1.15:49421 remote=212.45.105.89:443 flags=1, data=0x19ced08) 2015/11/10 19:29:30.299 kid1| 33,5| AsyncCall.cc(93) ScheduleCall: comm.cc(1579) will call ConnStateData::requestTimeout(local=212.45.105.89:443 remote=10.0.0.2:42825 FD 11 flags=33, data=0x19ced08) [call351] 2015/11/10 19:29:30.299 kid1| 33,5| AsyncCallQueue.cc(55) fireNext: entering ConnStateData::requestTimeout(local=212.45.105.89:443 remote=10.0.0.2:42825 FD 11 flags=33, data=0x19ced08) 2015/11/10 19:29:30.299 kid1| 33,5| AsyncCall.cc(38) make: make call ConnStateData::requestTimeout [call351] 2015/11/10 19:29:30.299 kid1| 33,5| AsyncJob.cc(123) callStart: Http::Server status in: [ job4] 2015/11/10 19:29:30.299 kid1| 33,3| client_side.cc(3512) requestTimeout: requestTimeout: FD -1: lifetime is expired. 2015/11/10 19:29:30.299 kid1| 33,5| AsyncCall.cc(93) ScheduleCall: comm.cc(730) will call ConnStateData::connStateClosed(FD -1, data=0x19ced08) [call332] 2015/11/10 19:29:30.300 kid1| 33,5| AsyncJob.cc(152) callEnd: Http::Server status out: [ job4] 2015/11/10 19:29:30.300 kid1| 33,5| AsyncCallQueue.cc(57) fireNext: leaving ConnStateData::requestTimeout(local=212.45.105.89:443 remote=10.0.0.2:42825 flags=33, data=0x19ced08) 2015/11/10 19:29:30.300 kid1| 33,5| AsyncCallQueue.cc(55) fireNext: entering ConnStateData::connStateClosed(FD -1, data=0x19ced08) 2015/11/10 19:29:30.300 kid1| 33,5| AsyncCall.cc(38) make: make call ConnStateData::connStateClosed [call332] 2015/11/10 19:29:30.300 kid1| 33,5| AsyncJob.cc(123) callStart: Http::Server status in: [ job4] 2015/11/10 19:29:30.300 kid1| 33,2| client_side.cc(815) swanSong: local=212.45.105.89:443 remote=10.0.0.2:42825 flags=33 2015/11/10 19:29:30.300 kid1| 33,3| client_side.cc(5060) unpinConnection: local=172.31.1.15:49421 remote=212.45.105.89:443 flags=1 2015/11/10 19:29:30.300 kid1| 33,3| client_side.cc(846) ~ConnStateData: local=212.45.105.89:443 remote=10.0.0.2:42825 flags=33 2015/11/10 19:29:30.300 kid1| 33,4| ServerBump.cc(44) ~ServerBump: destroying 2015/11/10 19:29:30.300 kid1| 33,4| ServerBump.cc(46) ~ServerBump: e:=sp2XDIV/0x19d6b20*1 2015/11/10 19:29:30.300 kid1| 33,5| AsyncCallQueue.cc(57) fireNext: leaving ConnStateData::connStateClosed(FD -1, data=0x19ced08) 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. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] SSL bumping without faked server certificates
an secure SSL ports http_access deny CONNECT !SSL_ports # Only allow cachemgr access from localhost http_access allow localhost manager http_access deny manager # Only allow purge from localhast (squidclient -m PURGE acl Purge method PURGE http_access allow localhost Purge http_access deny Purge # Allow access from your local networks http_access allow localnet http_access allow localhost # And finally deny all other access to this proxy http_access deny all # Squid normally listens to port 3128 http_port 3128 http_port 10.0.0.1:3129 intercept https_port 10.0.0.1:3443 intercept ssl-bump cert=/etc/squid/certs/bettermarks.com-chain.crt key=/etc/squid/certs/bettermarks.com-unsecure.key ## Memory only caching # Cache memory size (default: 256 MB) cache_mem 512 MB # Max object size in memory (default: 512 KB) maximum_object_size_in_memory 2 MB # Uncomment and adjust the following to add a disk cache directory. #cache_dir ufs /var/spool/squid 100 16 256 # Leave coredumps in the first cache dir coredump_dir /var/spool/squid ## Refresh patterns # BM static refresh_pattern -i ^https:\/\/(school|cdn)\.bettermarks\.com\/static\/.*? 1440 100% 1440 # BM dynamic refresh_pattern -i ^https:\/\/school\.bettermarks\.com\/.*? 0 0% 0 # default refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 # Cache log debug_options ALL,1 33,5 83,5 89,5 My first goal is to replace the old working server-first bumping method: # SSL Bump acl MYSITE dst 212.45.105.89 ssl_bump server-first MYSITE ssl_bump none all with the new peek and splice method: # SSL Bump acl step1 at_step SslBump1 acl MYSITE ssl::server_name school.bettermarks.com ssl_bump peek step1 ssl_bump bump MYSITE ssl_bump splice all The hostname school.bettermarks.com has the dedicated IP address 212.45.105.89 and points to a F5 loadbalancer that terminates SSL for *.bettermarks.com using the same certificate as Squid. I have called the following command on the client machine: # curl -v https://school.bettermarks.com/<https://school.bettermarks.com/static/flexclient4/bm_exerciseseries.swf> -o /dev/null * About to connect() to school.bettermarks.com port 443 (#0) * Trying 212.45.105.89... connected * Connected to school.bettermarks.com (212.45.105.89) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none The command have failed after a while with: * NSS error -5938 * Closing connection #0 * SSL connect error Squid's access.log: 1447179870.180172 10.0.0.2 TAG_NONE/200 0 CONNECT 212.45.105.89:443 - ORIGINAL_DST/212.45.105.89 - More information follows in my next post (to not exceed the maximum post size). 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. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] SSL bumping without faked server certificates
Hi Sebastian, I will give it a try. Regards, Stefan Am Dienstag, den 10.11.2015, 14:27 + schrieb Sebastian Kirschner: > Hi Stefan, > > I think it would be better to peek at step1 (Then you have the Client > SNI) and at step2 you could bump or splice. > Your config > > My assumption is that I have to use in Squid's config: > > https_port :3443 intercept ssl-bump cert= > > key= > > acl MYSITE ssl:server_name .mydomain.com > > ssl_bump bump MYSITE > > ssl_bump splice all > > A better way might be > # acl step1 at_step SslBump1 > # acl MYSITE ssl:server_name .mydomain.com > # > # ssl_bump peek step1 > # ssl_bump bump MYSITE > # ssl_bump splice all > > Best Regards > Sebastian > ___ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] SSL bumping without faked server certificates
Hi, I needed to setup Squid as a transparent proxy with SSL bumping for only one single https website. The goal was to bump https connections to this website with its offical signed SSL certificate. As an illustration: Website/hostname: https://abc.mydomain.com DNS: abc.mydomain.com A 1.2.3.4 Official wildcard certificate: CN = *.mydomain.com (server.crt, server.key) I used Squid 3.4.10 from CentOS repository and configured iptables DNAT rules for intercepting. Squid config: https_port :3443 intercept ssl-bump cert= key= acl MYSITE dst 1.2.3.4 ssl_bump server-first MYSITE ssl_bump none all Everything worked perfectly. All traffic to https://abc.mydomain.com was bumped for caching purposes, all traffic to other https websites was simply tunneled. Squid did not need to generate faked server certificates and clients were left untouched (no proxy settings, no self-signed CA). Now some parts of the website are delivered by Amazon CloudFront. CloudFront has the SSL certificate installed (same official signed certificate as mentiod above). Additional website/hostname: https://xyz.mydomain.com DNS: xyz.mydomain.com CNAME .cloudfront.net Official wildcard certificate: CN = *.mydomain.com (server.crt, server.key) I cannot simply extend my ACL with all destination IPs used by CloudFront, because these are shared IPs and CloudFront needs to know which domain/hostname is asked to provide the correct certificate. Usually a client uses the SNI extension of TLS to transmit the required domain/hostname. I have heard of the new "SSL Peek and Splice" feature in Squid 3.5 but don't get it working (Squid 3.5.9). My assumption is that I have to use in Squid's config: https_port :3443 intercept ssl-bump cert= key= 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. 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), ... Is it possible to achieve my goal with Squid in transparent mode? In other words: Is there a way to bump https connections to destinations with shared IPs? Best, Stefan ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
