On Wed, Mar 20, 2002 at 12:12:24AM +0100, Henrik Nordstrom wrote: > > 2) the 50080/50443 applications rely on TPROXY framework and uses > > nonlocal_bind. > > Except that nonlocal_bind do not yet work in TPROXY, does it?
not yet. > > > Zorp supports HTTPS, but it doesn't encapsulate it into CONNECT. > > > It simply decrypts ongoing traffic, checks HTTP within it, and > > > sends it on reencrypted. But for this to work you'd need to run > > > Zorp on your firewall (where it was meant to run) > > At the cost of totally invalidating SSL in terms of proxying. > > - Client can no longer verify the authenticity of the origin server > further than the proxy. > - Servers can no longer authenticate or verify the client. > > Typical man-in-the-middle scenario. > > I assume we are talking about what is nominated by the IEFT WREC > group as "surrogate" servers rather than proxies here.. If not then > decrypting proxied SSL traffic is a serious breach of security. Tunnelling SSL through firewalls _is_ a more serious breach of security. It is a full-speed covert channel. IRC and ICQ clients began to use such holes in the firewall to send IRC/ICQ traffic. Of course a proxy sitting between the client and the server means that peer certificates cannot be verified on the other peer. On the server side the firewall can perform this verification (and show a trusted certificate to the client) Providing a client certificate to the server is not very common, if it is required a tunnel can be opened to that _specific_ server, and nothing else. So using a real decrypting HTTPS proxy for general https traffic, and opening holes to specific destinations is definitely more secure than a simple 'pass-through' hole in the firewall. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
