In this short HOWTO I'm gonna show you how to deal with SSL connections in Squid 3.5.x. Despite that there are many of examples on the Internet, but most of them based on earlier version of Squid (below 3.5). There is some new terminology introduced along with Squid v. 3.5 which may be a little bit confused (for me it was).


let's consider such an example:

There is a typical corporate network where users outbound connections are firewalled and the only possible way to browse the Internet is using a proxy. Let's assume that users are aware of this proxy - or at least their browsers are. (so it's a "normal" proxy mode, not so called "transparent mode", where users are unknowingly redirected by the router).

Our goal is to allow our users to browse some important web pages (like banking or payments systems) without SSL interception (it's called Splice in Squid's terminology) but the rest of HTTPS traffic should be intercepted ("bumped") in order to verify the content.

first of all we must prepare a whitelist of domains/subdomains and save it as a file '/etc/squid3/nobumpSites.txt'. One example of the whitelisted domain could be ebay.com

Below is the chunk of Squid's config.
	http_port 8080 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=6MB cert=/etc/squid3/ssl_cert/proxy.pem

	acl step1 at_step SslBump1
	acl step2 at_step SslBump2
	acl step3 at_step SslBump3

	acl nobumpSites ssl::server_name "/etc/squid3/nobumpSites.txt"
	
have a look at the nobumpSites directive. Instead of using "dstdomain" parameter like we used to do in earlier version, we should use ssl::server_name.

This is because Squid now has a far more advanced capability to determine the real "server_name" requested by the user.

In earlier versions Squid determined the servername only by looking at the "CONNECT request" header. If there was no "CONNECT request" (like in transparent mode) it was often impossible to determine the right servername and thus the fake certificate generated by Squid couldn't have had a propper CommonName.
Now thanks to the TLS extension in HTTPS standard (introducing SNI) and Squid's peek & splice feature it's possible to determine server_name by peeking at client's request (as long as the client is TLS/SNI compatible).

To take advantage of this feature we must define it in our config file (see below)

	ssl_bump peek step1 all         # at step 1 we're peeking at client's TLS-request in order to find the SNI

	ssl_bump splice  nobumpSites    # here we're splicing trusted connections to servers which names match our whitelist

	#### ssl_bump peek step2 nobumpSites   # here we're peeking at server certificate

	#### ssl_bump splice step3 nobumpSites 

	ssl_bump bump                  # and finally we're bumping all other SSL connections
	

In above example we're not going to check server certificate before splicing. The server_name parameter which is matched against the whitelist is determined only by client-provided info like SNI (or sometimes by CONNECT request, when SNI is not available). But sometimes checking server certificate might be desirable. Peeking at step 2 will check the name stored in server certificate (CommonName, SubjectAltName) as well. So let's do it! you must enable peek at step 2 and finally splice at step3 (if certName matches the whitelist). Have a look:


	ssl_bump peek step1 all               # at step 1 we're peeking at client TLS-request in order to find the SNI

	ssl_bump peek step2 nobumpSites       # here we're peeking at server certificate

	ssl_bump splice step3 nobumpSites     # here we're splicing connections which match the whitelist

	ssl_bume bump                         # finally we're bumping all other SSL connections
	

So far, we've discussed actions like: peek, splice and bumb, but there are also terminate (which is obvious) and stare.
According to Squid documentation peeking at step 2 (peeking at server certificate) preserves the possibility of splicing the connection but usually precludes possibility of future bumping. For that reason peeking at server certificate (step 2) makes sense with nobumpSites acl. If you want Squid to stare at the server certificate before bumping the connection you must use stare option. (see below)

	ssl_bump peek step1 all               # at step 1 we're peeking at client TLS-request in order to find the "SNI"

	ssl_bump peek step2 nobumpSites       # here we're peeking at server certificate

	ssl_bump splice step3 nobumpSites     # here we're splicing connections which match the whitelist

	ssl_bump stare step2                  # here we're staring at server certificate

	ssl_bump bump step3                   # finally we're bumping all other SSL connections at step 3
	

Honestly I don't see a reason to stare at the server certificate before bumping. Even without "staring" the fake-certificate has the same attributes (Common Name etc.) like the original one. But it might change in the future (click here for more details).




special thx for squid developers, especially Alex who helped me a lot

20.09.2015 , marek