3 ms·
This says a lot about the ISP's ethics if they are shown to be consenting to this. One thing I didn't see in the EFF article is something a user could do about
by daemonize 15y ago
This says a lot about the ISP's ethics if they are shown to be consenting to this. One thing I didn't see in the EFF article is something a user could do about it: use SSL! This may eventually force these companies into more nefarulious and active techniques of hijacking, but it should alleviate the basic technique they are employing now, if i am not mistaken.
- osivertsson 15y agoFrom the EFF article: "And the best protection against the privacy and security risks created by this type of hijacking is to visit sites using HTTPS rather than HTTP, which can easily be achieved using EFF's HTTPS Everywhere Firefox extension"
- daemonize 15y agoYou're right, sry. Was on my mobile and must have glossed over that. Next time I will RTFA fully.
- pnathan 15y agoMy understanding is HTTPS only encrypts the content of the page, not the actual URL request. (And it's worth noting that proxies can unwrap HTTPS).
- rwolf 15y agoThis is something I keep circling around. The host doesn't seem like a thing you could encrypt, because the intermediaries need to know where to send your packets. It seems like https encrypts the headers: http://stackoverflow.com/questions/187655/are-https-headers-encrypted http://stackoverflow.com/questions/187655/are-https-headers-... but does this include the Location header?
- paxswill 15y agoThe HTTP request itself is encrypted, but the IP packet (including the source and destination IP addresses) is not. SSL/TLS is application level encryption, and if you wanted to encrypt the actual packet, you need to switch to something like IPsec, but even then you need some sort of routing method (which I can't remember).
- count 15y agoIPSec can work in many different ways. One of those is to encapsulate the entire packet as the encrypted payload of a new packet, with the new packet having headers in plain text leading to the other end of the IPSec tunnel. That other end will then decrypt and forward as appropriate (this is called a 'tunnel').
- count 15y agoYes. SSL / TLS happens below HTTP at the socket layer. This is why you couldn't have vhosts's using SSL on a single IP for a very long time (the webserver wouldn't know which certificate to use).
- JoachimSchipper 15y ago> proxies can unwrap HTTPS They cannot get at the plaintext without a certificate warning (or installing a certificate in the user's browser beforehand).
- pnathan 15y agoThey cannot get at the plaintext without a certificate warning (or installing a certificate in the user's browser beforehand). Which will get clicked through anyway, so, uh, the security is kinda moot. =)
- Cushman 15y agoI don't know why you were downvoted for this, it's a very cogent point— most users would probably click through a big red screen that says "DO NOT VISIT THIS WEB SITE!" We need to be thinking of them when we design our security model.
- tlrobinson 15y agoYour understanding is incorrect. This is the reason SSL is incompatible with virtual hosts (see http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Server_Name_Indication)
- rjbond3rd 15y agoIt's not! Just use the latest Apache. It works great. I have 30 domains on a single IP, all under SSL.
- mtogo 15y agoWhich is great unless you have to deal with IE6 users :(.
- rjbond3rd 15y agoDoes MS even support IE6 anymore? Or are people using it without the benefit of security patches? Where I work, IE7 is considered obsolete.
- abraham 15y agoIE6 has extended support until 2014 or market share is under 1% http://en.wikipedia.org/wiki/Internet_Explorer_6 http://en.wikipedia.org/wiki/Internet_Explorer_6
- tlrobinson 15y agoThen it's using SNI, which I linked to. The request is still encrypted, but the host name is passed unencrypted using SNI.