<div dir="ltr"><span style="font-size:12.8px">Hi Amos,</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I kinda solved the problem (Thanks to you!!!)</div><div style="font-size:12.8px">All what was needed is to peek the important domains in step2 in order not to cause them harm and bump everything else in step3. In this case I'm able to read the dns names in the redirect script and block them accordingly</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Here is the relevant part:</div><span class="im" style="font-size:12.8px"><div>acl http_sites dstdomain <a href="http://play.google.com/" target="_blank">play.google.com</a> <a href="http://mydomain.com/" target="_blank">mydomain.com</a><br></div><div>acl https_sites ssl::server_name <a href="http://play.google.com/" target="_blank">play.google.com</a> <a href="http://mydomain.com/" target="_blank">mydomain.com</a><br></div><div><br></div></span><div style="font-size:12.8px"><div>ssl_bump peek step1 all</div><div>ssl_bump peek step2 https_sites</div><div>ssl_bump bump step3 all !https_sites #http_sites won't be bumped anyway. But just to be sure</div></div><div style="font-size:12.8px">url_rewrite_access allow all !http_sites<br></div><div class="gmail_extra" style="font-size:12.8px"><br></div><div class="gmail_extra" style="font-size:12.8px">Of course I'm still not able to rewrite https address as discussed, but this is a different story I guess.</div><div class="gmail_extra" style="font-size:12.8px"><br></div><div class="gmail_extra" style="font-size:12.8px">The SslPeekAndSplice wiki page needs serious rework though as many of the stuff discussed here are not explained on the page, which makes life really hard for noobs like me. Is there a way to contribute back a little bit by reworking that wiki page? I'll try to write a small post about the SslPeekAndSplice in the next few days.</div><div class="gmail_extra" style="font-size:12.8px"><br></div><div class="gmail_extra" style="font-size:12.8px">Many Thanks again for the great help. Really appreciate it</div><div class="gmail_extra" style="font-size:12.8px"><br></div><div class="gmail_extra" style="font-size:12.8px">Cheers,</div><div class="gmail_extra" style="font-size:12.8px">Moataz</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 10, 2016 at 10:42 AM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On 10/07/2016 8:13 p.m., Moataz Elmasry wrote:<br>
> Hi Amos,<br>
><br>
> Thanks I really learnt alot from your previous email.<br>
><br>
> going on..<br>
><br>
> On Fri, Jul 8, 2016 at 1:18 PM, Amos Jeffries <<a href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>> wrote:<br>
><br>
>> On 8/07/2016 10:20 p.m., Moataz Elmasry wrote:<br>
>>> Hi Amos,<br>
>>><br>
>>> Do you know any of those 'exceptional' redirectors that can handle https?<br>
>>><br>
>><br>
>> I know they exist, some of my clients wrote and use some. But I can't<br>
>> point you to any if thats what you are asking.<br>
>><br>
>> I can say though there r two things that can reliably be done with a<br>
>> CONNECT request by a URL-rewriter;<br>
>><br>
>> 1) return ERR, explicitly telling Squid not to re-write those tunnels.<br>
>><br>
>> This trades helper complexity for simpler squid.conf ACLs. Both simply<br>
>> telling Squid not to re-write.<br>
>><br>
>> 2) re-write the URI from domain:port to be IP:port.<br>
>><br>
> Funny thing is when I'm getting the URL in the redirect.bash, I'm not<br>
> getting an IP. I probed and logged in many fields as described in the<br>
> logformat page, and I usually get either the IP or the DNS inside<br>
> redirect.bash but not both<br>
><br>
>><br>
>> If the IP it gets re-written to is the one the client was going to, this<br>
>> is in effect telling Squid not to do DNS lookup when figuring out where<br>
>> to send it. That can be useful when you don't want Squid to use<br>
>> alternative IPs it might find via DNS.<br>
>>  (NP: This wont affect the host verify checking as it happens too late.<br>
>> This is actually just a fancy way to enforce the ORIGINAL_DST pass-thru<br>
>> behaviour based on more complex things than host-verify detects)<br>
>><br>
>><br>
>>> Ok. So let's ignore the redirection for now and just try to whitelist<br>
>> some<br>
>>> https urls and deny anything else.<br>
>>><br>
>>> Now I'm trying to peek and bump the connection, just to obtain the<br>
>>> servername without causing much harm, but the https sites are now either<br>
>>> loading infinitely, or loading successfully, where they should have been<br>
>>> blacklisted, assuming the https unwrapping happened successfully. Could<br>
>> you<br>
>>> please have a look and tell me what's wrong with the following<br>
>>> configuration? BTW after playing with ssl_bump I realized that I didn't<br>
>>> really understand the steps(1,2,3) as well as when to peek/bump/stare<br>
>>> etc... . The squid.conf contains some comments and questions<br>
>>><br>
>>> squid.conf<br>
>>><br>
>>> "<br>
>>> acl http_sites dstdomain <a href="http://play.google.com" rel="noreferrer" target="_blank">play.google.com</a> <a href="http://mydomain.com" rel="noreferrer" target="_blank">mydomain.com</a><br>
>>> acl https_sites ssl::server_name <a href="http://play.google.com" rel="noreferrer" target="_blank">play.google.com</a> <a href="http://mydomain.com" rel="noreferrer" target="_blank">mydomain.com</a><br>
>>><br>
>>> #match any url where the servername in the SNI is not empty<br>
>>> acl haveServerName ssl::server_name_regex .<br>
>>><br>
>>><br>
>>> http_access allow http_sites<br>
>>> http_access allow https_sites #My expectation is that this rule is<br>
>> matched<br>
>>> when the https connection has been unwrapped<br>
>><br>
>> On HTTP traffic the "http_sites" ACL will match the URL domain.<br>
>><br>
>> On HTTPS traffic without (or before finding) the SNI neither ACL will<br>
>> match. Because URL is a raw-IP at that stage.<br>
>><br>
>> On HTTPS traffic with SNI the "http_sites" ACL will match. Because the<br>
>> SNI got copied to the request URI.<br>
>><br>
>> The "https_sites" ACL will only be reached on traffic where the SNI does<br>
>> *not* contain the values its looking for. This test will always be a<br>
>> non-match / false.<br>
>><br>
> Ouch, I now see in the docs that ssl::server_name is suitable for usage<br>
> within ssl_bump. So this is the only use case I suppose.<br>
><br>
>><br>
>>><br>
>>> sslcrtd_program /lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB<br>
>>><br>
>>> http_access deny all<br>
>>><br>
>>> http_port 3127<br>
>>> http_port 3128 intercept<br>
>>> https_port 3129 cert=/etc/squid/ssl/example.com.cert<br>
>>> key=/etc/squid/ssl/example.com.private ssl-bump intercept<br>
>>> generate-host-certificates=on  version=1<br>
>>> options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE capath=/etc/ssl/certs/<br>
>>><br>
>>> sslproxy_cert_error allow all<br>
>>> sslproxy_flags DONT_VERIFY_PEER<br>
>>><br>
>>> acl step1 at_step SslBump1<br>
>>> acl step2 at_step SslBump2<br>
>>> acl step3 at_step SslBump3<br>
>>><br>
>>><br>
>>> ssl_bump peek step1  #Is this equivelant to "ssl_bump peek step1 all ???"<br>
>>><br>
>><br>
>> Yes. "all" is a test that always produces match / true.<br>
>><br>
>> The "ssl_bump peek step1 all" means:<br>
>>  If (at_step == SslBump1 and true == true) then do peeking.<br>
>>  else ...<br>
>><br>
>>> ssl_bump bump haveServerName !https_sites<br>
>>> #What about connections that didn't provide sni yet? Do they get to have<br>
>>> own definition for step2?<br>
>><br>
>> For those:<br>
>><br>
>>  "haveServerName" being a regex "." pattern will match the raw-IP in the<br>
>> CONNECT request, the SNI value, or any subjectAltName in the server<br>
>> certificate. One of those three will always exist and have a value that<br>
>> '.' is matched against. Basically it can't fail - therefore you can<br>
>> consider it just a complicated (and slow / CPU draining) way of checking<br>
>> "all".<br>
>><br>
>> AND<br>
>><br>
>>  "https_sites" produces false. The "!" turns that false into true.<br>
>><br>
>> So that line matches and "bump" action is done at step 2.<br>
>><br>
>> Bump being a final action means there is no step 3 for those requests.<br>
>><br>
>> NOTE:  Side effects of bump at step 2 (aka client-first bumping) is that<br>
>> certificate Squid generates will be generated ONLY from squid.conf<br>
>> settings and clientHello details.<br>
>>  No server involvement, thus a very high chance that the server TLS<br>
>> connection requirements and what Squid offers the client to use will<br>
>> conflict or introduce downgrade attack vulnerabilities into these<br>
>> connections.<br>
>><br>
>>  Whether that is okay is a grey area with disagreement possibilities on<br>
>> all sides.<br>
>>  * On the one hand you are probably configuring good security for the<br>
>> client connection even when the server connection has worse TLS.<br>
>>  * On the two hand you are potentially configuring something worse than<br>
>> some servers.<br>
>>  * On the third hand you are definitely fooling the client into thinking<br>
>> it has different security level than the server connection can provide,<br>
>> or vice-versa for the server knowledge about the client connection. Its<br>
>> risky, and you can expect problems.<br>
>><br>
>><br>
>>> #Is this equivelant to "ssl_bump  bump step2 haveServerName<br>
>> !https_sites" ??<br>
>><br>
>> Yes it is.<br>
>><br>
>>> #Can I use step2 with some other acl?<br>
>><br>
>> Er. You can use any ACL that has available data for the time and<br>
>> position at which it is tested.<br>
>>  In other words I would not suggest using ACLs that check HTTP response<br>
>> headers at the ssl_bump checking time.<br>
>><br>
>> At step 2 of SSL-Bumping process you have client TCP connection details,<br>
>> TLS clientHello details and initial extensions like SNI (well the ones<br>
>> that have been implemented - SNI being the only useful one AFAIK).<br>
>><br>
>>><br>
>>> ssl_bump splice all<br>
>>> #Is this now step3 for all?what about those urls who didn't have a match<br>
>> in<br>
>>> step2. Is this step2 for some and step3 for others?<br>
>><br>
>> Any step2 traffic which fails the "!https_sites" test will match this.<br>
>> Which means there is no step3 for those requests.<br>
>><br>
>> If you have been paying attention you will have noticed that all traffic<br>
>> passing the "!https_sites" has been bumped, and all traffic failing that<br>
>> same test has been spliced.<br>
>><br>
>> ==> Therefore, zero traffic reaches step 3.<br>
>><br>
>> Many thanks for the detailed clarification, this really helps ALOT!!!!<br>
><br>
><br>
>><br>
>> My advice on this as a general rule-of-thumb is to splice at step 1 or 2<br>
>> if you can. That solves a lot of possible problems with the splicing.<br>
>> And to bump only at step 3 where the mimic feature can avoid a lot of<br>
>> other problems with the bumping.<br>
>><br>
>> You will still encounter some problems though (guaranteed). Don't forget<br>
>> that TLS is specifically designed to prevent 'bumping' from being done<br>
>> on its connections. The fact that we can offer the feature at all for<br>
>> generic use is a terrible statement about the Internets bad lack of<br>
>> security.<br>
>><br>
>><br>
>> Cheers.<br>
>> Amos<br>
>><br>
>><br>
> Ok. new try.  The following are common configurations:<br>
> "<br>
><br>
> acl http_sites dstdomain <a href="http://play.google.com" rel="noreferrer" target="_blank">play.google.com</a> <a href="http://mydomain.com" rel="noreferrer" target="_blank">mydomain.com</a><br>
> acl https_sites ssl::server_name <a href="http://play.google.com" rel="noreferrer" target="_blank">play.google.com</a> <a href="http://mydomain.com" rel="noreferrer" target="_blank">mydomain.com</a><br>
><br>
> http_access allow http_sites<br>
><br>
> sslcrtd_program /lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB<br>
> http_access deny all<br>
><br>
> http_port 3127<br>
> http_port 3128 intercept<br>
> https_port 3129 cert=/etc/squid/ssl/example.com.cert<br>
> key=/etc/squid/ssl/example.com.private ssl-bump intercept<br>
> generate-host-certificates=on  version=1<br>
> options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE capath=/etc/ssl/certs/<br>
><br>
> sslproxy_cert_error allow all<br>
> sslproxy_flags DONT_VERIFY_PEER<br>
><br>
> acl step1 at_step SslBump1<br>
> acl step2 at_step SslBump2<br>
> acl step3 at_step SslBump3<br>
><br>
> url_rewrite_program /bin/bash -c -l /etc/squid/redirect.bash<br>
> url_rewrite_extras "%>a/%>A %<A la=%la:%lp la2=%<a/%<a  la3=%<la:%<lp %un<br>
> %>rm myip=%la myport=%lp  ru=%ru ru2=%>ru ru3=%<ru rd=%>rd rd2=%<rd h=%>h<br>
> ssl1=%ssl::bump_mode ssl2=%ssl::>sni ssl3=%ssl::>cert_subject<br>
> ssl4=%ssl::>cert_issuer  rp1=%rp rp2=%>rp rp3=%<rp h1=%>h h2=%>ha"<br>
> logformat squid "%>a/%>A %<A la=%la:%lp la2=%<a/%<a  la3=%<la:%<lp  %un<br>
> %>rm myip=%la myport=%lp  ru=%ru ru2=%>ru ru3=%<ru rd=%>rd rd2=%<rd h=%>h<br>
> ssl1=%ssl::bump_mode ssl2=%ssl::>sni ssl3=%ssl::>cert_subject<br>
> ssl4=%ssl::>cert_issuer  rp1=%rp rp2=%>rp rp3=%<rp h1=%>h h2=%>ha"<br>
> url_rewrite_access allow all<br>
> "<br>
><br>
> Using<br>
><br>
> "ssl_bump splice step1 all<br>
> ssl_bump bump step3 all"<br>
><br>
> Nothing is blocked. And I don't see any urls, nor sni info neither in<br>
> access.log nor in my redirect.log.Only IPs.  I'm trying many https sites.<br>
<br>
</div></div>Because "all" traffic got spliced at step1. Nothing go to the step3 bumping.<br>
<br>
Sorry if my general rule-of-thumb description was not clear. I meant<br>
those RoT to be used as a preference for what stage to do splice or bump<br>
- for the things you want them respectively to apply to.<br>
 You still need other ACLs defining what traffic the action is to be<br>
applied on.<br>
<span class=""><br>
<br>
><br>
> Using<br>
> "ssl_bump splice step2 all<br>
> ssl_bump bump step3 all"<br>
><br>
<br>
</span>Splice still happens to "all" traffic.<br>
<span class=""><br>
> Same result.<br>
><br>
> Using<br>
> "<br>
> ssl_bump peek step1 all<br>
> ssl_bump splice step2  all<br>
> ssl_bump bump step3 all<br>
> "<br>
><br>
> I can see URLs in the access.log and redirect.log but no IP's. Further I'm<br>
> getting the header forgery warning in the logs, and all pages start<br>
> loading, but never finish. Maybe this is something related to the nat rules<br>
> in the iptables?<br>
<br>
</span>No.<br>
<br>
peek is  non-final action, grabbing the SNI and clientHello details. It<br>
only stops the current step's ACL evaluation. ssl_bump gets re-evaluated<br>
for future step's.<br>
<br>
splice and bump are both "final" actions. SSL-Bumping process in its<br>
entirety stops and does the action chosen. It does not continue to do<br>
any other ssl_bump things once one of them is reached.<br>
<br>
In the above peek happens to all traffic, then splice happens to all<br>
traffic.<br>
<span class=""><br>
><br>
> For info, I'm using the simplest bash redirector for now. Here's the code<br>
> while true;<br>
> do<br>
>     read input;<br>
>     echo "input=${input}"  >>/var/log/squid/redirects.log 2>&1<br>
>     old_url=$(echo ${input} | awk '{print $1}')<br>
>     echo "${old_url}"<br>
>     [[ $? != 0 ]] && exit -1<br>
>     continue<br>
> done<br>
><br>
><br>
> I'll try squid4 next week, maybe the result will be better<br>
<br>
</span>It won't be much better, the problem so far is in the ssl_bump ACL design.<br>
<span class=""><font color="#888888"><br>
Amos<br>
<br>
</font></span></blockquote></div><br></div></div>