[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