Re: Netcat through Squid HTTP Proxy

[Rogan Dawes <lists () dawes za net>]

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