Hi guys,
I'm still confused about peek and stare. Correct me please if I'm wrong.
1. the only way to by absolutely sure what is transmitted over a SSL
tunnel is bumping the connection - there is no other possibility.
2. some important websites shouldn't be bumped - like banking or payment
systems. Such pages should be spliced by a whitelist at step 2?
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
at step 2 (like banking systems)?
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
--------------------------------------
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)
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. Is 'ssl::server_name' more reliable than
'dstdomain' ?
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?
If yes, tell me what's the advantage of stare at step 2 - instead of
bumping everything after splicing the exceptions?
I truly apologize for so long email, but I wanted to put as much doubts
as I can :)
thanks a lot!
Marek
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
