Re: [squid-users] kinda confused about Peek and Splice
On 09/19/2015 10:19 AM, Marek Serafin 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" Yes, that version makes sense to me if you want to splice based on client-provided info such as SNI (and not based on any server-provided info). > 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 Writing "all" after any other ACL should not be needed. It only wastes CPU cycles (Squid currently does not optimize this case). In recent Squids, writing "step2" in "peek step2" _after_ "peek step1" is not needed: "peek step1" will always match during step1 so the second peek rule will not get executed during step1. No "peek" rule can match during step3. Thus, the second peek rule will be automatically restricted to step2. If you combine the above, you get: ssl_bump peek step1 ssl_bump peek nobumpSites ssl_bump splice step3 nobumpSites ssl_bump bump all The above can be simplified further because if the transaction does not match nobumpSites at step2, then the last rule will match and the transaction will be bumped. Thus, only nobumpSites transactions will get to step3 and we can remove the nobumpSites restriction from that step (besides, it would be too late to bump at step3 anyway): ssl_bump peek step1 ssl_bump peek nobumpSites ssl_bump splice step3 ssl_bump bump all Furthermore, _if_ you do not need the side-effects (e.g., server certificate validation) of getting to step3 for nobumpSites, then you may splice during step2: ssl_bump peek step1 ssl_bump splice nobumpSites ssl_bump bump all which is actually the same as the other configuration you have considered!.. > 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? Yes, but it can be simplified using reasoning similar to the one I provided above. Cheers, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] kinda confused about Peek and Splice
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@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] kinda confused about Peek and Splice
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.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] kinda confused about Peek and Splice
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@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
[squid-users] kinda confused about Peek and Splice
Hello, I'm kinda confused about the "Peek and Splice" technique introduced in Squid 3.5.x. -- My goal is to allow CONNECT-method ONLY to certain web-pages (mainly banks, payment systems). The rest of https-sites should be allways bumped. - And this can be easily achieved even in squid 3.3 (I'm talking about situation where browser is totally aware of using proxy server -- not transparent mode). But when Squid allows CONNECT method - it allows any kind of TCP tunnel (e.g. OpenVPN over TCP or ssh tunnel). So, my real question is - if it's possible - using the new technique (Peek and Splice) to allow Splice method - but ONLY to real HTTPS Sites - not a ssh or VPN service? (I'm still talking about the situation where browsers are aware of proxying) I was thinking that it can be done by peeking in step 2 (peeing the server certificate) BUT there is a limitation: peeking at the server certificate usually precludes future bumping. So when we're peeking at step 2 we can only splice later (or terminate) - which is not what I wanted to achieve. If above is not possible, what is the main advantage of "Peek and Splice" comparing to old method (remember: browsers are aware of proxying). I can see advantage in transparent mode - obtaining domain name by SNI. But in "normal mode" squid knows the domain-name because of the connect request? And knowing the domain-name we can decide what to do. thx for any hints or explanation! HELION SA, 44-100 Gliwice, ul. Kościuszki 1C Numer KRS 121256 Sąd Rejonowy w Gliwicach, X Wydział Gospodarczy Krajowego Rejestru Sądowego. NIP 631-020-02-68, REGON: 271070648 Kapitał zakładowy: 500100 zł w całości wpłacony ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] kinda confused about Peek and Splice
On 09/17/2015 04:00 AM, Marek Serafin wrote: > Hello, I'm kinda confused about the "Peek and Splice" technique > introduced in Squid 3.5.x. > -- > My goal is to allow CONNECT-method ONLY to certain web-pages (mainly > banks, payment systems). The rest of https-sites should be allways bumped. > - > And this can be easily achieved even in squid 3.3 (I'm talking about > situation where browser is totally aware of using proxy server -- not > transparent mode). > > But when Squid allows CONNECT method - it allows any kind of TCP tunnel > (e.g. OpenVPN over TCP or ssh tunnel). > > So, my real question is - if it's possible - using the new technique > (Peek and Splice) to allow Splice method - but ONLY to real HTTPS Sites > - not a ssh or VPN service? The short answer to your question is "when splicing, it is only possible to check whether the service is using SSL". Here are the details: * Peeking or staring at step1 results in Squid parsing the client SSL Hello. This does not guarantee that the client is an HTTPS client, but it virtually guarantees that it is an SSL client. * Peeking or staring at step2 results in Squid validating the server certificate. This does not guarantee that the server is an HTTPS server, but it virtually guarantees that it is an SSL server. * Beyond step2, you have to bump to check that the SSL client and the SSL server are going to talk HTTP after CONNECT and SSL handshake. There is and will be no way around that. Staring allows you to bump if that is what you want. ... where "X at stepN" means "action X matched at SslBump step #N". However, your question seems to contradict your goal of splicing connections to "certain" known servers and only to those servers: If you know that example.com is a trusted bank, do you really need to check that nobody is creating an ssh connection to that bank? If not, then validating "bank" traffic beyond SSL handshake becomes irrelevant. You simply trust the "bank" not to provide any "bad" services. > (I'm still talking about the situation where browsers are aware of > proxying) Browser awareness does not really matter as far as non-HTTP detection is concerned. > I was thinking that it can be done by peeking in step 2 (peeing the > server certificate) BUT there is a limitation: peeking at the server > certificate usually precludes future bumping. So when we're peeking at > step 2 we can only splice later (or terminate) - which is not what I > wanted to achieve. You do not need to bump to validate the server certificate (and, hence, confirm that it is a known-to-you "bank"). If you want to bump, you can stare instead of peeking. > what is the main advantage of "Peek and > Splice" comparing to old method (remember: browsers are aware of proxying). > I can see advantage in transparent mode - obtaining domain name by SNI. > But in "normal mode" squid knows the domain-name because of the connect > request? In some cases, the CONNECT request contains an IP address instead of a domain name. HTH, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
