[squid-users] kinda confused about Peek and Splice

Marek Serafin marek.serafin at helion.pl
Sat Sep 19 16:19:14 UTC 2015


On 18.09.2015 22:29, Alex Rousskov wrote:


>> 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?

it should be either "ssl_bump splice nobumpSites" or peek at step 2 and 
splice it at step 3, right?  (depending on how deep we want to check) e.g:

ssl_bump peek step1 all
ssl_bump peek step2 nobumpSites
ssl_bump splice step3 nobumpSites
ssl_bump bump all


>> 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.

ok. got it.



>> 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.

not yet , but I will :) and  now I know what you mean.

>> 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:


>> 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
>>

> 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.

  I got it! I was thinking all the time that action taken at step 1 and 
step 2 (peeking or staring) is common to all connections. That's why I 
considered peeking at step 2 as useless because if server_name will not 
match the whitelist (majority of webpages) it would be impossible to 
bump the connection. And that are separate rules!!! like this:

## peeking at first step is mostly/always good idea (to get the SNI)
ssl_bump peek step1 all

# we want to check deeply what we're gonna splice
ssl_bump peek step2 nobumpSites
ssl_bump splice step3 nobumpSites

### we're bumping the rest. Fake cert will be generated
### based on server's cert (that's why we want to bump at step 3)
ssl_bump stare step2 all
ssl_bump bump step3 all


Does it make some sense?


> http://bugs.squid-cache.org/show_bug.cgi?id=4327

thanks a lot, it was very helpful!!

BTW my Squid v: 3.5.8 probably generates fake-certs based on server 
certificate even at bump step 2 (instead of client's SNI)

greetings Marek


More information about the squid-users mailing list