Wed, 27 Mar 2002 17:10:21 +0100
On Wednesdayen den 27 March 2002 16.17, Jean-Michel Hemstedt wrote:
> - If your proxy allows "CONNECT" requests, then virtually anything
> can pass through it, and HTTPS decrypting proxy does not make sense.
A proxy can in theory verify that the supposedly SSL stream looks like a SSL
stream and not something else.. The SSL and TLS data streams are quite
structured. But a proxy cannot and must not decrypt or alter the SSL traffic.
A "decrypting proxy" would of course intercept the CONNECT requests as SSL.
> Then, if you are really concerned by insider attacks, what about a
> session/tunnel timer which could be a possible (ugly) protection
> against wormhole kinds of attacks, without invalidating ssl?
Fact 1: If there is as much as a 1 bit communication channel (or even less if
quantifiable), then this can be abused to build tunnels if you can place
equipment on both sides.
Fact 2: Valid use of SSL can be quite lengthy. For example a web application
refreshing the display once each 5 minutes or so can easily keep a persistent
connection open all the time.
In my view the only acceptable use of a decrypting "SSL proxy" is if an
organisation have a policy whereby all transmitted data must be logged or
inspected upon leaving the organisation. In such policy the user would not
(by the policy) be allowed at all to use encrypted SSL services without
surrending the encryption to the organisation.
In such case the "decrypting SSL proxy" is providing the service to reach
https:// sites from within the organisation, not the use of SSL. Technically
the term "SSL proxy" for this kind of service is quite misleading. "SSL or
https gateway" is a better description.
Not that this really has anything to do netfilter development or the TPROXY
feature as such.. this is my las post on this thread.