[squid-users] kinda confused about Peek and Splice

[Alex Rousskov]

On 09/18/2015 01:38 PM, Marek Serafin wrote:

> 1. the only way to by absolutely sure what is transmitted over a SSL
> tunnel is bumping the connection - there is no other possibility.

Correct.


> 2. some important websites shouldn't be bumped - like banking or payment
> systems. Such pages should be spliced by a whitelist at step 2?

Whether some sites should or should not be bumped is a local policy
decision. There is no one-size-fits-all answer to this question. The
specifics of that local policy may affect _when_ you splice those
important sites (if any) or, in other words, _how_ you identify those
important sites.


> 3. some websites/services can't  be bumped because of HPKP feature. So
> if we want to allow users to use such sites/services we must splice it

Or, if you can reinstall all browsers from scratch, you can
overwrite/delete site's Public-Key-Pins headers when bumping. HPKP is a
Trust on First Use feature so you can essentially disable it if you
control that "first use". Please note that I am not an expert on this --
I am just reading Mozilla's description of the feature at
https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning

There are other reasons a site may not support bumping. You will need to
babysit your bumping Squid to make sure your users are as happy as can
be expected.


> at step 2 (like banking systems)?

The best timing (i.e., the step number) for splicing depends on many
local factors.


> My policy is: bump everything except banking systems (and some other
> important domains):  My config is like this:
> --------------------------------------
> acl nobumpSites ssl::server_name "/etc/squid3/allowed_SSL_sites.txt"
> 
> ssl_bump peek step1
> ssl_bump splice step2 nobumpSites
> ssl_bump bump all
> --------------------------------------

I do not see the reason for the "step2" ACL in the above. Do you?


> So tell me what's the reason of peeking at step1 ? I suppose getting the
> real server_name based on SNI instead of reading it from CONNECT
> request?  (remember: all browsers are proxy aware)

Yes. Not all CONNECT requests have host names.


> I'm asking because when I change my configuration to this one:
> 
> --------------------------------------
> acl allowed_https_sites dstdomain "/etc/squid3/allowed_SSL_sites.txt"
> ssl_bump splice allowed_https_sites
> ssl_bump bump all
> --------------------------------------
> It seems to work the same way.

Have you tested both configurations using a CONNECT request with an IP
address? Have you tested with a CONNECT request for a foo.example.com
domain when that domain responds with a bar.example.com certificate?

If not, your testing is not good enough to expose [at least two]
differences between the two configurations.


> Is  'ssl::server_name' more reliable than 'dstdomain'?

"reliable" is an undefined term in this context.

ssl::server_name may use SNI (where available). Dstdomain does not know
about SNI. There are other important documented differences as well:

> The server name is obtained during Ssl-Bump steps from such sources
> as CONNECT request URI, client SNI, and SSL server certificate CN.
> During each Ssl-Bump step, Squid may improve its understanding of a
> "true server name". Unlike dstdomain, this ACL does not perform
> DNS lookups.



> So, despite that I'm still confused about peek & stare -  for me
> it makes only sense in this order
> 
> 1. peek everything at step 1 (to get reliable server name by SNI ???)
> 2. splicing exceptions ("whitelist") at step 2
> 3. stare all at step 2  (or just bump the rest at step 2)
> 4. bump all at step 3
> 
> does it make sense according to my policy assumptions?

It depends how you want to identify whitelisted sites. For example, if
you want to validate the server certificate before splicing, then the
above will not work.


> what's the advantage of stare at step 2 - instead of
> bumping everything after splicing the exceptions?

I am not sure, but it is possible that bumping at step 2 will not mimic
some server certificate features in the future (it does now). For a
related discussion, please see
http://bugs.squid-cache.org/show_bug.cgi?id=4327


HTH,

Alex.