v4.2 url_rewrite Uri.cc line 371 bad URL parsing on SSL

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

v4.2 url_rewrite Uri.cc line 371 bad URL parsing on SSL

David Touzeau-3

Hi,

 

I have written my own url_rewrite helper

 

On SSL sites, the helper answering a redirect to a remote denied php  page.

 

With HTTP, no issue but on SSL there is a different behavior

 

My helper return

 

rewrite-url= https://192.168.1.122:443/myguard.php?rule-id=0&SquidGuardIPWeb=aHR0cDovLzE5Mi4xNjguMS4xMjI=&clientaddr=192.168.1.1&clientname=192.168.1.1&clientuser=unknown&clientgroup=default&targetgroup=P109&url=http%3A%2F%2Fwww.youporn.com

 

but according to debug, the Uri.cc understand : host='https', port='443', path=''

 

In this case, squid try to connect to an https machine name and return bad 503

 

 

 

018/08/16 01:42:59.681 kid1| 84,3| Reply.cc(63) finalize: helper Result = OK

2018/08/16 01:42:59.681 kid1| 61,5| redirect.cc(83) redirectHandleReply: reply={result=OK, notes={webfiltering: block,0,P109; status: 302; rewrite-url: https://192.168.1.122:443/myguard.php?rule-id=0&SquidGuardIPWeb=aHR0cDovLzE5Mi4xNjguMS4xMjI=&clientaddr=192.168.1.1&clientname=192.168.1.1&clientuser=unknown&clientgroup=default&targetgroup=P109&url=http%3A%2F%2Fwww.youporn.com; }}

2018/08/16 01:42:59.681 kid1| 85,5| client_side_request.cc(1197) clientRedirectDone: 'www.youporn.com:443' result={result=OK, notes={webfiltering: block,0,P109; status: 302; rewrite-url: https://192.168.1.122:443/myguard.php?rule-id=0&SquidGuardIPWeb=aHR0cDovLzE5Mi4xNjguMS4xMjI=&clientaddr=192.168.1.1&clientname=192.168.1.1&clientuser=unknown&clientgroup=default&targetgroup=P109&url=http%3A%2F%2Fwww.youporn.com; }}

 

Here  -----------------à Uri.cc did not understand correctly the returned URL.

 

2018/08/16 01:42:59.681 kid1| 23,3| Uri.cc(371) parse: Split URL 'https://192.168.1.122:443/myguard.php?rule-id=0&SquidGuardIPWeb=aHR0cDovLzE5Mi4xNjguMS4xMjI=&clientaddr=192.168.1.1&clientname=192.168.1.1&clientuser=unknown&clientgroup=default&targetgroup=P109&url=http%3A%2F%2Fwww.youporn.com' into proto='', host='https', port='443', path=''

 

 

2018/08/16 01:42:59.681 kid1| 24,7| SBuf.cc(212) append: from c-string to id SBuf346713

2018/08/16 01:42:59.681 kid1| 24,7| SBuf.cc(160) rawSpace: reserving 0 for SBuf346713

2018/08/16 01:42:59.681 kid1| 24,7| SBuf.cc(167) rawSpace: SBuf346713 not growing

2018/08/16 01:42:59.681 kid1| 24,6| SBuf.cc(99) assign: SBuf346714 from c-string, n=4294967295)

2018/08/16 01:42:59.682 kid1| 24,7| SBuf.cc(212) append: from c-string to id SBuf346714

2018/08/16 01:42:59.682 kid1| 24,7| SBuf.cc(160) rawSpace: reserving 0 for SBuf346714

2018/08/16 01:42:59.682 kid1| 24,7| SBuf.cc(167) rawSpace: SBuf346714 not growing

2018/08/16 01:42:59.682 kid1| 24,6| SBuf.cc(99) assign: SBuf346709 from c-string, n=4294967295)

2018/08/16 01:42:59.682 kid1| 24,7| SBuf.cc(212) append: from c-string to id SBuf346709

2018/08/16 01:42:59.682 kid1| 24,7| SBuf.cc(160) rawSpace: reserving 0 for SBuf346709

2018/08/16 01:42:59.682 kid1| 24,7| SBuf.cc(167) rawSpace: SBuf346709 not growing

 

Here ----------à Address.cc did not find the https machine.

2018/08/16 01:42:59.682 kid1| 14,3| Address.cc(382) lookupHostIP: Given Non-IP 'https.domain.local': Name or service not known

 

 

Did i miss something ???


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: v4.2 url_rewrite Uri.cc line 371 bad URL parsing on SSL

Amos Jeffries
Administrator
On 16/08/18 11:58, David Touzeau wrote:

> Hi,
>
>  
>
> I have written my own url_rewrite helper
>
>  
>
> On SSL sites, the helper answering a redirect to a remote denied php  page.
>

No your helper *rewrite* the URL without changing any other properties
of the request message. This can be seen clearly in the use of
"rewrite-url=" instead of "url=".

The difference is important when it comes to the type of message being
processed.

>
> With HTTP, no issue but on SSL there is a different behavior
>
> My helper return
>
> rewrite-url= https://192.168.1.122:443/myguard.php?rule-id=0&....
>
> but according to debug, the Uri.cc understand : host='https',
> port='443', path=''
>
> In this case, squid try to connect to an https machine name and return
> bad 503
>
>  
...
>
> Did i miss something ???
>

Look at the input received by the helper. HTTPS uses CONNECT requests.
Those messages have authority-form URI not URLs. The above behaviour is
what happens when your helpers response is interpreted according to
authority-form syntax.

<https://tools.ietf.org/html/rfc7230#section-5.3.3>


You can prevent the SSL-Bump CONNECT messages being sent to the
re-writer with:
  url_rewrite_access deny CONNECT

OR,
 you can try to do a proper redirect by having the helper send:
  OK status=302 url=...


The latter *might* work. Depending on whether the client handles
redirection on CONNECT requests. Browsers don't support anything other
than 200 status. Other clients have a mix of behaviours so its somewhat
unreliable.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: v4.2 url_rewrite Uri.cc line 371 bad URL parsing on SSL

David Touzeau-3
Thanks Amos for details.

Working like a charm now.

Instead of sending https://192.168.1.122:443/myguard.php?rule-id=0&....

Helper sends 192.168.1.122:443


" url_rewrite_access deny CONNECT" is not a solution because, everything using SSL today ( thanks to Google that wants to encrypt all the Net and make proxies/Firewall/ICAP unusable )  and many Porn/Malwares/Hacking/Hacked websites using SSL.




-----Message d'origine-----
De : squid-users <[hidden email]> De la part de Amos Jeffries
Envoyé : jeudi 16 août 2018 03:51
À : [hidden email]
Objet : Re: [squid-users] v4.2 url_rewrite Uri.cc line 371 bad URL parsing on SSL

On 16/08/18 11:58, David Touzeau wrote:

> Hi,
>
>  
>
> I have written my own url_rewrite helper
>
>  
>
> On SSL sites, the helper answering a redirect to a remote denied php  page.
>

No your helper *rewrite* the URL without changing any other properties of the request message. This can be seen clearly in the use of "rewrite-url=" instead of "url=".

The difference is important when it comes to the type of message being processed.

>
> With HTTP, no issue but on SSL there is a different behavior
>
> My helper return
>
> rewrite-url= https://192.168.1.122:443/myguard.php?rule-id=0&....
>
> but according to debug, the Uri.cc understand : host='https',
> port='443', path=''
>
> In this case, squid try to connect to an https machine name and return
> bad 503
>
>  
...
>
> Did i miss something ???
>

Look at the input received by the helper. HTTPS uses CONNECT requests.
Those messages have authority-form URI not URLs. The above behaviour is what happens when your helpers response is interpreted according to authority-form syntax.

<https://tools.ietf.org/html/rfc7230#section-5.3.3>


You can prevent the SSL-Bump CONNECT messages being sent to the re-writer with:
  url_rewrite_access deny CONNECT

OR,
 you can try to do a proper redirect by having the helper send:
  OK status=302 url=...


The latter *might* work. Depending on whether the client handles redirection on CONNECT requests. Browsers don't support anything other than 200 status. Other clients have a mix of behaviours so its somewhat unreliable.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: v4.2 url_rewrite Uri.cc line 371 bad URL parsing on SSL

Amos Jeffries
Administrator
On 16/08/18 19:34, David Touzeau wrote:
> Thanks Amos for details.
>
> Working like a charm now.
>
> Instead of sending https://192.168.1.122:443/myguard.php?rule-id=0&....
>
> Helper sends 192.168.1.122:443
>

That is only useful if the server at that IP:port can present the client
with a TLS certificate valid for the server the client thinks it is
connected to. ie all the SSL-Bump equivalent logics are in that server.

In which case there is likely no point to having the traffic NAT'ed to
Squid. Just have your NAT and/or routing send it directly into that server.

>
> " url_rewrite_access deny CONNECT" is not a solution because, everything using SSL today ( thanks to Google that wants to encrypt all the Net and make proxies/Firewall/ICAP unusable )  and many Porn/Malwares/Hacking/Hacked websites using SSL.
>

If you are SSL-Bump'ing in Squid then you need to not rewrite the
initial CONNECT message (or two) - doing so will interfere the server
which bumping is interacting with.

IIRC the at_step ACL type can be used in the *_access rules as well to
skip ("deny CONNECT foo") the helper query until the ssl_bump processing
is expected to be completed.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users