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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
