Re: Netcat through Squid HTTP Proxy

• Previous message: Anders Thulin: "Re: Port 9090 WServer??"
• In reply to: Joachim Schipper: "Re: Netcat through Squid HTTP Proxy"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Wed, 18 May 2005 17:01:44 +0200
To: Joachim Schipper <j.schipper@math.uu.nl>

Joachim Schipper wrote:

>On Tue, May 17, 2005 at 03:34:16PM +0200, Christoph Puppe wrote:
>
>
>>Henderson, Dennis K. schrieb:
>>
>>
>>
>>>It seems like he was looking for information on how to prevent this.
>>>
>>>
>> The most thorough way to prevent proxy abuses, that use the CONNECT
>>feature to simulate valid HTTPS traffic, is breaking up all this
>>connections, decrypted and have them scrutinized with your normal content
>>security tool. The Proxy acts like a man in the middle attacker, it get's
>>the HTTPS connection, produces a certificate that matches the site beeing
>>requested and presents this to the client. The client agrees on a
>>session-key with the proxy and starts sending requests. The proxy pipes
>>this requests through some logic to determine if this is an OK request,
>>most firewalls and CS-Tools will do this for you. Then the proxy opens a
>>new connection to the site requested, checks the certificate and sends the
>>requests. The results are processed likewise.
>>
>>
>The problem, of course, being that this makes verification of the remote
>end of the connection impossible as well as compromising privacy for the
>parties behind the firewall.
>
>So this will also make HTTPS less useful for the user. There is a trade
>off here...
>
> Joachim
>
>
This does not necessarily prevent the user from verifying the remote end
of the connection. If the MITM makes sure to only re-generate and sign
certificates that are already valid, using the MITM's CA key, then the
user can determine if the original certificate was valid also.

i.e.
WebServer provides a valid cert, signed, etc. The MITM generates a new
certificate with the same information, and signs it with its own trusted
cert. The user knows that the cert is OK.

WebServer provides a cert signed by an untrusted CA, the MITM recreates
the cert with the same information, but signs it with its own untrusted
cert. The user is prompted to accept the cert, exactly as they would
have othewise.

The only REAL flaw with this approach is the lack of support for client
side certs . . . . (and the privacy compromise on the MITM host, of
course, but we assume that this decision has already been made in favour
of content-security . . . .)

Regards,

Rogan

• Previous message: Anders Thulin: "Re: Port 9090 WServer??"
• In reply to: Joachim Schipper: "Re: Netcat through Squid HTTP Proxy"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]