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. Regards Henrik Nordström
