, January 7, 2021 6:08 PM
To: Eliezer Croitoru ; squid-users@lists.squid-cache.org
Cc: squid-...@lists.squid-cache.org
Subject: Re: [squid-users] Host header forgery detected on domain:
mobile.pipe.aria.microsoft.com
On 1/6/21 10:26 PM, Eliezer Croitoru wrote:
> The main issue now is the ext
lex Rousskov
> Sent: Wednesday, January 6, 2021 10:42 PM
> To: squid-users@lists.squid-cache.org
> Cc: Eliezer Croitoru
> Subject: Re: [squid-users] Host header forgery detected on domain:
> mobile.pipe.aria.microsoft.com
>
> On 1/6/21 2:49 PM, Eliezer Croitoru wrote:
>
>
ing soon
-Original Message-
From: Alex Rousskov
Sent: Wednesday, January 6, 2021 10:42 PM
To: squid-users@lists.squid-cache.org
Cc: Eliezer Croitoru
Subject: Re: [squid-users] Host header forgery detected on domain:
mobile.pipe.aria.microsoft.com
On 1/6/21 2:49 PM, Eliezer Croitoru wr
On 1/6/21 2:49 PM, Eliezer Croitoru wrote:
> I am trying to think about the right solution for the next issue:
> SECURITY ALERT: Host header forgery detected on conn18767
> local=52.114.32.24:443 remote=192.168.189.52:65107 FD 15 flags=33 (local IP
> does not match any domain IP)
As you know, thi
FYI my long term plan is to extend squids internal representation of DNS results to include the TTL for each address, and set pass-thru client connection lifetimes to the TTL of the IP they are using. That will solve all the issues with pipelined traffic and expired TTLs which is a huge chunk of th
I'm testing SSL BUMP in 5.0.4 and it's working pretty well despite some
hiccups.
I am trying to think about the right solution for the next issue:
SECURITY ALERT: Host header forgery detected on conn18767
local=52.114.32.24:443 remote=192.168.189.52:65107 FD 15 flags=33 (local IP
does not match an
They’re probably matching about 40% of the time on twitter.com, though 😒
> On 25 Nov 2015, at 11:40 AM, Dan Charlesworth wrote:
>
> Alright, thanks for the hint.
>
> My proxy and clients definitely have the same DNS server (I removed the
> secondary and tertiary ones to make totally sure) but
Alright, thanks for the hint.
My proxy and clients definitely have the same DNS server (I removed the
secondary and tertiary ones to make totally sure) but the results definitely
aren’t matching 99% of the time. Probably more like 90%.
Perhaps it’s 'cause my clients are caching records locally
On 25/11/2015 12:20 p.m., Dan Charlesworth wrote:
> Thanks for the perspective on this, folks.
>
> Going back to the technical stuff—and this isn’t really a squid thing—but is
> there any way I can minimise this using my DNS server?
>
> Can I force my local DNS to only ever return 1 address fro
Thanks for the perspective on this, folks.
Going back to the technical stuff—and this isn’t really a squid thing—but is
there any way I can minimise this using my DNS server?
Can I force my local DNS to only ever return 1 address from the pool on a
hostname I’m having trouble with?
> On 30 Oc
On 10/29/2015 11:29 AM, Matus UHLAR - fantomas wrote:
>> On 10/28/2015 10:46 PM, Amos Jeffries wrote:
>>> NP: these problems do not exist for forward proxies. Only for traffic
>>> hijacking interceptor proxies.
>
> On 29.10.15 09:05, Alex Rousskov wrote:
>> For intercepted connections, Squid shoul
On 10/28/2015 10:46 PM, Amos Jeffries wrote:
NP: these problems do not exist for forward proxies. Only for traffic
hijacking interceptor proxies.
On 29.10.15 09:05, Alex Rousskov wrote:
For intercepted connections, Squid should, with an admin permission,
connect to the intended IP address with
On 10/28/2015 10:46 PM, Amos Jeffries wrote:
> NP: these problems do not exist for forward proxies. Only for traffic
> hijacking interceptor proxies.
For intercepted connections, Squid should, with an admin permission,
connect to the intended IP address without validating whether that IP
address
This is happening when my client and proxy are using the same DNS server. In
this case, a local OS X Server which forwards to my ISP’s DNS servers.
As far as I can tell Google’s DNS isn’t in the equation any more. Even so, if I
run a `dig watch` on the domain, it happily cycles through a pool of
On 29/10/2015 1:16 p.m., Dan Charlesworth wrote:
> It looks like there’s certain hosts that are designed to load balance (or
> something) between a few IPs, regardless of geography.
>
> For example pbs.twimg.com resolves to wildcard.twimg.com which returns two
> different IPs each time, from a p
It looks like there’s certain hosts that are designed to load balance (or
something) between a few IPs, regardless of geography.
For example pbs.twimg.com resolves to wildcard.twimg.com which returns two
different IPs each time, from a pool of 5–6, at random. Basically rolling the
dice whether
22.10.15 15:58, Amos Jeffries пишет:
On 21/10/2015 4:53 p.m., Dan Charlesworth wrote:
I’m getting these very frequently for api.github.com and github.com
I’m using the same DNS servers as my intercepting squid 3.5.10 proxy and they
only return the one IP when I do an nslookup as well …
Any
Ah-ha. Thanks for digging into that a bit Amos.
In my case 8.8.8.8 is the tertiary server, so I’m surprised it’s being used at
all. Could be a local DNS server is forwarding to it, though.
I’ll remove that from the equation tomorrow and see how it fares.
Cheers
> On 22 Oct 2015, at 8:58 PM, Am
On 21/10/2015 4:53 p.m., Dan Charlesworth wrote:
> I’m getting these very frequently for api.github.com and github.com
>
> I’m using the same DNS servers as my intercepting squid 3.5.10 proxy and they
> only return the one IP when I do an nslookup as well …
>
> Any updates from your end, Roel?
I’m getting these very frequently for api.github.com and github.com
I’m using the same DNS servers as my intercepting squid 3.5.10 proxy and they
only return the one IP when I do an nslookup as well …
Any updates from your end, Roel?
> On 8 Oct 2015, at 8:29 PM, Eliezer Croitoru wrote:
>
> Si
Since they are using the same dns server there is no need to run some
trials.
The only test you should in any case test is to see how long is the IP
list from the DNS request for the domain name.
Eliezer
On 08/10/2015 12:12, Roel van Meer wrote:
Eliezer Croitoru writes:
Are the users and pr
Eliezer Croitoru writes:
Are the users and proxy using different dns server?
No, they are using the same server.
Can you run dig from the proxy on this domain and dump the content to verify
that the ip is indeed there?
I'm currently running with 3.5.8 again, so I'll have to find a quiet h
Hey,
Are the users and proxy using different dns server?
Can you run dig from the proxy on this domain and dump the content to
verify that the ip is indeed there?
Eliezer
On 06/10/2015 14:55, Roel van Meer wrote:
Hi everyone,
I have a Squid setup on a linux box with transparent interception
On 8/10/2015 6:41 p.m., Dan Charlesworth wrote:
> Same here—I've been meaning to ask the list about this too. I’m still on
> 3.5.9, by the way.
>
>> On 6 Oct 2015, at 10:55 PM, Roel van Meer wrote:
>>
>> Hi everyone,
>>
>> I have a Squid setup on a linux box with transparent interception of both
Same here—I've been meaning to ask the list about this too. I’m still on 3.5.9,
by the way.
> On 6 Oct 2015, at 10:55 PM, Roel van Meer wrote:
>
> Hi everyone,
>
> I have a Squid setup on a linux box with transparent interception of both
> http and https traffic. Everything worked fine with S
Hi everyone,
I have a Squid setup on a linux box with transparent interception of both
http and https traffic. Everything worked fine with Squid 3.5.6. After
upgrading to version 3.5.10, I get many warnings about host header forgery:
SECURITY ALERT: Host header forgery detected on local=10
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Oh, shi..
It can't be on proxy host or other infrastructure. It can be on these
client..
Let's check.
27.01.2015 10:41, Amos Jeffries пишет:
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBAgAGBQJUx1jpAAoJENNXIZxhPexG24YIAL1ncl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Oh, shi..
It can't be on proxy host or other infrastructure. It can be on these
client..
Let's check.
27.01.2015 10:41, Amos Jeffries пишет:
> On 27/01/2015 11:13 a.m., Yuri Voinov wrote:
>
> > -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/01/2015 11:13 a.m., Yuri Voinov wrote:
>
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>
> Hi gents,
>
> who knows - what does it mean below?
>
> 2015/01/27 04:11:42.289 kid1| SECURITY ALERT: Host header forgery
> detected on local=192.168
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi gents,
who knows - what does it mean below?
2015/01/27 04:11:42.289 kid1| SECURITY ALERT: Host header forgery
detected on local=192.168.200.3:80 remote=192.168.200.5:9909 FD 18
flags=33 (intercepted port does not match 443)
2015/01/27 04:11:42.2
30 matches
Mail list logo
