On 22/12/2015 2:34 a.m., dc wrote:
>
> Am 19.12.2015 um 00:52 schrieb Amos Jeffries:
>> Why not?
>> * NAT/TPROXY is mandatory to happen on the Squid machine directly since
>> kernel and Squid are performing integrated operations.
>> * PROXY protocol passes the ORIGINAL_DST explicitly over the wire
Am 19.12.2015 um 00:52 schrieb Amos Jeffries:
> Why not?
> * NAT/TPROXY is mandatory to happen on the Squid machine directly since
> kernel and Squid are performing integrated operations.
> * PROXY protocol passes the ORIGINAL_DST explicitly over the wire.
> * SSL-Bump all happens "inside Squid".
On 19/12/2015 12:30 p.m., dc wrote:
> Thank you very much for this detailed explanation!
>
> I have a setup where squid doesn't know about the original destination
> IP address,
Why not?
* NAT/TPROXY is mandatory to happen on the Squid machine directly since
kernel and Squid are performing integr
Thank you very much for this detailed explanation!
I have a setup where squid doesn't know about the original destination
IP address, so I tried to enforce using DNS responses as destination
addresses for any request, without success. Looking at the relevant code
I found the limitation (and CVE) t
On 19/12/2015 8:52 a.m., dc wrote:
> Hello,
>
> please help me to understand the issue of CVE-2009-0801. Description of
> the CVE:
>
> "Squid, when transparent interception mode is enabled, uses the HTTP
> Host header to determine the remote endpoint, which allows remote
> attackers to bypass acc
Hello,
please help me to understand the issue of CVE-2009-0801. Description of
the CVE:
"Squid, when transparent interception mode is enabled, uses the HTTP
Host header to determine the remote endpoint, which allows remote
attackers to bypass access controls for Flash, Java, Silverlight, and
prob
