issues with sslbump and "Host header forgery detected" warnings

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

issues with sslbump and "Host header forgery detected" warnings

Leonardo Rodrigues Magalhães

     Hello Everyone,

     I'm trying to setup sslbump for the first time (on squid-4.13) and,
at first, things seems to be working. After taking some time to
understand the new terms (splice, bump, stare, etc), seems to got things
somehow working.

     Actually i'm NOT looking for complete bumping (and decrypting) the
connections. During my lab studies, I found out that simply 'splice' the
connections is enough for me. I just wanna intercept https connections
and have them logged, just the hostname, and that seems to be
acchievable without even installing my certificates on the client, as
i'm not changing anything, just 'taking a look' on the SNI values of the
connection. The connection itself remains end-to-end protected, and
that's fine to me. I just wanna have things logged. And that's working
just fine.

     However, some connections are failing with the "Host header forgery
detected" warnings. Example:

2020/11/06 18:04:21 kid1| SECURITY ALERT: Host header forgery detected
on local=216.58.222.106:443 remote=10.4.1.123:39994 FD 73 flags=33
(local IP does not match any domain IP)
2020/11/06 18:04:21 kid1| SECURITY ALERT: on URL:
chromesyncpasswords-pa.googleapis.com:443

     and usually a NONE/409 (Conflict) log entry is generated on those.
Refreshing once or twice and it will eventually work.

     I have found several discussions on this and I can confirm it
happens on hostnames that resolvs to several different IPs or hostnames
that, somehow, keeps changing IPs (CDNs or something like that).

     Clients are already using the same DNS server as the squid box, as
recommended, but problem is still happening quite a lot. For regular
hostnames who translates for a single IP address, things are 100% working.

     Questions:

     - without using WPAD or without configuring proxy on the client
devices, is this somehow "fixable" ? Same DNS already being used ...
     - is there any chance the NONE/409 (Conflict) logs i'm seeing are
not related to this? Maybe these are just WARNINGs and not ERRORs, or
these would really cause a fail to the intercepted connection?
     - any other hint on this one without having to set proxy, in any
way, on the clients? I just wanna have hostnames (and traffic generated)
logged, no need for full decrypt (bumping) of the connections.


     Thanks !!!






--


        Atenciosamente / Sincerily,
        Leonardo Rodrigues
        Solutti Tecnologia
        http://www.solutti.com.br

        Minha armadilha de SPAM, NÃO mandem email
        [hidden email]
        My SPAMTRAP, do not email it



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

Re: issues with sslbump and "Host header forgery detected" warnings

Amos Jeffries
Administrator
On 7/11/20 10:18 am, Leonardo Rodrigues wrote>
>      However, some connections are failing with the "Host header forgery
> detected" warnings. Example:
>
...
>      Questions:
>
>      - without using WPAD or without configuring proxy on the client
> devices, is this somehow "fixable" ? Same DNS already being used ...

All we can do is minimize the occurrences (sometimes not very much).
This wiki page has all the details of why and workarounds
<https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery>.


>      - is there any chance the NONE/409 (Conflict) logs i'm seeing are
> not related to this? Maybe these are just WARNINGs and not ERRORs, or
> these would really cause a fail to the intercepted connection?

No. The only time current Squid produce 409 status is these Host header
problems.

>      - any other hint on this one without having to set proxy, in any
> way, on the clients? I just wanna have hostnames (and traffic generated)
> logged, no need for full decrypt (bumping) of the connections.
>

No, sorry.


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

Re: issues with sslbump and "Host header forgery detected" warnings

Alex Rousskov
In reply to this post by Leonardo Rodrigues Magalhães
On 11/6/20 4:18 PM, Leonardo Rodrigues wrote:

> 2020/11/06 18:04:21 kid1| SECURITY ALERT: Host header forgery detected...
> 2020/11/06 18:04:21 kid1| SECURITY ALERT: on URL:...

> - without using WPAD or without configuring proxy on the client
> devices, is this somehow "fixable" ?

Yes, it is possible to modify Squid to correctly forward the intercepted
TCP connection where it was going despite the host validation failure.
Squid already does that for some use cases, but that code currently
excludes intercepted TLS connections (among other cases).


>     - is there any chance the NONE/409 (Conflict) logs i'm seeing are
> not related to this? Maybe these are just WARNINGs and not ERRORs, or
> these would really cause a fail to the intercepted connection?

Bugs notwithstanding, your Squid is terminating the TLS connection after
printing the _second_ ALERT line above:

> debugs(85, DBG_IMPORTANT, "SECURITY ALERT: on URL: " << ...
> // IP address validation for Host: failed. reject the connection.
> repContext->setReplyToError(ERR_CONFLICT_HOST, Http::scConflict,

The documented intent of that code path is to eventually terminate the
TLS connection without contacting the origin server. I suspect that is
what actually happens, but I did not check. You can check this
(indirectly) by reproducing the problem while capturing client<->Squid
and Squid->server traffic.


>     - any other hint on this one without having to set proxy, in any
> way, on the clients? I just wanna have hostnames (and traffic generated)
> logged, no need for full decrypt (bumping) of the connections.

You have a use case where connection rejection is not the best handling
option. Implementing and defending proper support for that specific use
case is probably not trivial, but I think it is doable.

https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F

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

Re: issues with sslbump and "Host header forgery detected" warnings

Eliezer Croitoru-3
In reply to this post by Leonardo Rodrigues Magalhães
Hey Leonardo,

I assume The best solution for you is a simple SNI proxy.
Squid does also that and you can try to debug this issue to make sure you understand what is wrong.
It clearly states that Squid doesn't see this specific address: local=216.58.222.106:443
As the domain: chromesyncpasswords-pa.googleapis.com:443 "real" destination address.

Maybe Alex or Amos remember the exact and relevant debug_options:
https://wiki.squid-cache.org/KnowledgeBase/DebugSections

I assume section 78 would be of help.
debug_options ALL,1 78,3

Is probably enough to discover what are the DNS responses and from where these are.
On what OS are you running this Squid?

Thanks,

----
Eliezer Croitoru
Tech Support
Mobile: +972-5-28704261
Email: [hidden email]

-----Original Message-----
From: squid-users <[hidden email]> On Behalf Of Leonardo Rodrigues
Sent: Friday, November 6, 2020 11:18 PM
To: [hidden email]
Subject: [squid-users] issues with sslbump and "Host header forgery detected" warnings


     Hello Everyone,

     I'm trying to setup sslbump for the first time (on squid-4.13) and,
at first, things seems to be working. After taking some time to
understand the new terms (splice, bump, stare, etc), seems to got things
somehow working.

     Actually i'm NOT looking for complete bumping (and decrypting) the
connections. During my lab studies, I found out that simply 'splice' the
connections is enough for me. I just wanna intercept https connections
and have them logged, just the hostname, and that seems to be
acchievable without even installing my certificates on the client, as
i'm not changing anything, just 'taking a look' on the SNI values of the
connection. The connection itself remains end-to-end protected, and
that's fine to me. I just wanna have things logged. And that's working
just fine.

     However, some connections are failing with the "Host header forgery
detected" warnings. Example:

2020/11/06 18:04:21 kid1| SECURITY ALERT: Host header forgery detected
on local=216.58.222.106:443 remote=10.4.1.123:39994 FD 73 flags=33
(local IP does not match any domain IP)
2020/11/06 18:04:21 kid1| SECURITY ALERT: on URL:
chromesyncpasswords-pa.googleapis.com:443

     and usually a NONE/409 (Conflict) log entry is generated on those.
Refreshing once or twice and it will eventually work.

     I have found several discussions on this and I can confirm it
happens on hostnames that resolvs to several different IPs or hostnames
that, somehow, keeps changing IPs (CDNs or something like that).

     Clients are already using the same DNS server as the squid box, as
recommended, but problem is still happening quite a lot. For regular
hostnames who translates for a single IP address, things are 100% working.

     Questions:

     - without using WPAD or without configuring proxy on the client
devices, is this somehow "fixable" ? Same DNS already being used ...
     - is there any chance the NONE/409 (Conflict) logs i'm seeing are
not related to this? Maybe these are just WARNINGs and not ERRORs, or
these would really cause a fail to the intercepted connection?
     - any other hint on this one without having to set proxy, in any
way, on the clients? I just wanna have hostnames (and traffic generated)
logged, no need for full decrypt (bumping) of the connections.


     Thanks !!!






--


        Atenciosamente / Sincerily,
        Leonardo Rodrigues
        Solutti Tecnologia
        http://www.solutti.com.br

        Minha armadilha de SPAM, NÃO mandem email
        [hidden email]
        My SPAMTRAP, do not email it



_______________________________________________
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: issues with sslbump and "Host header forgery detected" warnings

Leonardo Rodrigues Magalhães
In reply to this post by Amos Jeffries
Em 07/11/2020 08:42, Amos Jeffries escreveu:
>
> All we can do is minimize the occurrences (sometimes not very much).
> This wiki page has all the details of why and workarounds
> <https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery>.
>

     Thanks Amos, I had already find that and it has very good
information on the subject. Also found an old thread of you discussing
the security concerns on bypsasing those checks, very good information,
thanks so much :)


--


        Atenciosamente / Sincerily,
        Leonardo Rodrigues
        Solutti Tecnologia
        http://www.solutti.com.br

        Minha armadilha de SPAM, NÃO mandem email
        [hidden email]
        My SPAMTRAP, do not email it



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

Re: issues with sslbump and "Host header forgery detected" warnings

Leonardo Rodrigues Magalhães
In reply to this post by Eliezer Croitoru-3
Em 07/11/2020 22:19, Eliezer Croitor escreveu:

> Hey Leonardo,
>
> I assume The best solution for you is a simple SNI proxy.
> Squid does also that and you can try to debug this issue to make sure you understand what is wrong.
> It clearly states that Squid doesn't see this specific address: local=216.58.222.106:443
> As the domain: chromesyncpasswords-pa.googleapis.com:443 "real" destination address.
>
> Maybe Alex or Amos remember the exact and relevant debug_options:
> https://wiki.squid-cache.org/KnowledgeBase/DebugSections
>
> I assume section 78 would be of help.
> debug_options ALL,1 78,3
>
> Is probably enough to discover what are the DNS responses and from where these are.
> On what OS are you running this Squid?
>
>

     Hi Eliezer,

     I have already tracked the DNS stuff and I could confirm that squid
is resolving to a different IP address than the client is, despite both
using the same DNS server. It only happens for hosts with multiple A
addresses or CDN hostnames that changes IP very often (every 10 seconds
for example). It's not a bug in that regards, absolutely not, the client
connecting to a specific IP address and squid seeing another IP to that
hostname caught on the TLS transaction is real.

     I'm running on CentOS 8 ... and after all, maybe these findings,
I'm about to realize doing this kind of interception, even without the
full decrypt part, is not trivial at all, despite it works flawlessly
(and very easily) for "regular" hostnames which translates to a single
IP and never changes it.

     Will study this a little more. Thanks for your observations and
recommendations!



--


        Atenciosamente / Sincerily,
        Leonardo Rodrigues
        Solutti Tecnologia
        http://www.solutti.com.br

        Minha armadilha de SPAM, NÃO mandem email
        [hidden email]
        My SPAMTRAP, do not email it



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