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
