tor 2006-12-21 klockan 10:09 +0800 skrev Adrian Chadd: > I could've sworn I've seen certificates signed with the IP address of the > server in the past, rather than the current practice of signing w/ website > name.
Certificates can be signed with any name, but the browsers will complain if the certificate does not contain the exact requested hostname or a matching wildcard either in the DN or in a specific attribute for the purpose.. > Using TPROXY allows you to transparently proxy the TCP/IP connection without > either side necessarily knowing there's a proxy in the middle. It does mean > you can't get your grubby hands into the stream to figure out whats going on > without causing issues, like you've noted below, but it would allow admins > to apply basic ACLs on intercepted HTTPS connections. Yes, but so would doing the same thing without TPROXY. Only difference is which IP the server sees as source IP. The ssl/tls crypto does not care, but server side access controls may care just as it might for http. > You could do it without TPROXY, sure - the client would think its talking > direct to the server IP but the server wouldn't see the client IP. I'm not > sure there's any easy way (sans decrypting the SSL stream and re-encrypting > it before forwarding) to indicate that you have. This could make things > somewhat dangerous (eg breaks forwarding loop detection.) SSL does not care, neither does most servers. In fact if you are not using TPROXY then most servers is more happy with this as then https and http is both coming from the same source IP (the proxy). > I've seen people do this before. In fact, I remember reading something > talking about "interfering" with the encryption negotiation to encrypt > the session w/ no encryption but i could be very misled. I have to admit > I haven't looked into SSL stuff at all for a number of years now. No clients or servers have support for the null crypto unless manually enabled in the settings, but there is some attacks on SSLv2 where a man-in-the-middle can force the clients to downgrade to very low grade encryption unless disabled in the crypto profile, which isn't far from the same thing.. (i.e. 40-bit DES or similar grade) > I believe just intercepting the HTTPS TCP connection to feed through > ACLs and delay pools would be a positive benefit. And very simple thing to do. But most admins will be very confused when this traffic will bypass any domain checks. Only ip checks are valid without decrypting the traffic. > I'm a bit worried > about loop detection and prevention but I'd be more worried about clients > seeing invalid SSL certificate warnings. This is especially going to be > an issue with IE7 and its "anti-phishing" stuff.. Intercepting https in tunnel mode will work fine, TPROXY or not. But it must be real interception where the proxy/tunnel can tell the original destination address from the connection as no details about the request as such is available in the normal case.. To the client and server it's the same as if the connection had been SNAT:ed when not using TPROXY. And with TPROXY it can look like a direct connection without SNAT. Regards Henrik
signature.asc
Description: Detta är en digitalt signerad meddelandedel
