The following is not original, but simply a summary of widely known information.
It has been known for decades that plaintext protocols, such as HyperText Transfer Protocol (http) are vulnerable to man-in-the-middle attacks. Yet we are now at the point where there is simply too many ways to man-in-the-middle the web browser, and too much lovely mayhem that can be constructed, for this to be tolerable. We MUST demand that web-sites shift to HTTPS for everything, and ship web browsers that disable http altogether.
How to Man in the Middle: There are simply far too many ways to act as a man in the middle to a web browser. These include maskerading as any access point requested by a system (Karma), ARP cache poisioning (arpiframe), DNS cache poisoning, WiFi packet injection ( airpwn), or simply an ISP attempting to monetize the network (advertisement injection,Phorm). If an adversary can eavesdrop on our HTTP sessions, they can act as a man-in-the-middle.
The problem arises from all the malicious fun that can be done by a man-in-the-middle. This can include:
- Cookie Pillaging: By having the web browser transparently redirect through a long list of sites, the browser will transmit EVERY non-secure (not-SSL-only) cookie to the eavesdropper. Which means the eavesdropper can read! your! gmail!! and other such lovely mayhem, as many sites which allow SSL access don't actually set the cookies properly to mandate SSL access, which means from the viewpoint of an active attacker, SSL does no good at protecting the site!
- Autocomplete Pillaging: Instead of just redirecting through a long list of sites, include hidden forms and javascript to capture all the autocomplete information present in the browser. A technique developed by H.D. Moore.
- SMB Reflection: IE will happily open an SMB share when given the proper URL, which can be the attacker's share on the local network. The attacker can use this for the SMB reflection attack (at least on older systems), allowing the attacker on many systems to read and write the user's directory if file sharing is enabled, or to relay authorization credentials to a third party file server. Its unclear how well this can still work, but its at least worth trying.
- Worms: Take the IE 0-day exploit-du-jour and make a worm that uses packet injection/AP spoofing to spread to all other systems on the local wireless network. For extra credit, release such a worm at JFK airport and include a phone-home visit to the CDC website giving the CDC a nice model for how an influenza-of-doom would spread. (Heathrow may be slightly better, but it is far cheaper to have your worm fly to heathrow in your place. Also, the spread rates in the Usenix paper are probably conservative, because they don't model effects like an infected notebook carrier doing work in a taxi)
- Drive traffic to your blog:. Gotta have a proof of concept to get people's attention! Note that it only took a couple of hours to hook up a fragile but nontheless working demo. The attack would have been much more effective if I actually played games with wireless transmission power.
So what is to be done? Simple. NO MORE HTTP! Everything, and I mean EVERYTHING should be through HTTPS/SSL. The security community managed to kill off Telnet. We need to do the same to HTTP (oh, and non-secure DNS, too.)
5 comments:
I like your conclusion! Yet people have strike out with unhealthy HTTP experiences until they really grasp the impact. It will probably take a while until such a (simple) change permeates.
The common argument against using HTTPS everywhere is processor time -- it's quite resource-intensive to encrypt everything, and this would mean the need for more web servers everywhere.
However, there's a bigger problem -- HTTPS does not work on multiplexed sites (e.g. this one, or any site on shared hosting, such as 75% of the Internet.) Most web servers won't honor the host header on HTTPS (IIS is the only one that will) and most web browsers won't bother to send one anyway (IE 7.0 is the only one that will by default.) Which means if you want your site to be standards-compliant and work with all browsers, you need a unique IP for every domain name. There aren't that many unique IPs to go around -- without multiplexing, IPv4 is broken.
Now, this is not insurmountable as a problem, of course. You can, with some minor hacking, make Apache use this behavior, too. It just means that every web server and browser there is will need to be upgraded to exhibit a non-standards-compliant behavior.
That will take some time even after the server & browser manufacturers are convinced to do it.
The problem with HTTPS is you're going have to find unique IP addresses for every domain name. Hosting would get a lot more expensive if hosts couldn't put 10k domains on each server. And that's even before the certificates, a racket at a couple hundred each.
1. eliminating http for classes of opaque date elements like jpgs, pngs, mp3s, etc is pointless and stupid.
2. https does not protect you from the most pernicious attack vector on the web - xss
3. https doesn't scale like http because it wasn't meant to, it has an entirely independent state model.
4. https introduces usability issues when used in places it does not need to be used...timeouts being the most obvious
5. what is more effective is to eliminate mode switching on secure sites. i.e. sites that use https in part of the user experience should use it everywhere. the notion that i need to see 4chan in https on the other hand is frankly retarded.
Another problem is that central virus scanner cannot scan the traffic without terminating the SSL connection. And terminating SSL connection and establishing a new one with the server means the certificate needs to replaced.
And a replaced certificate will yell warnings in web browser if the end user has not installed the CA root in the web browser.
It would be better with some selective https, that the web site decides which data should be encrypted, and the antivirus scanner can scan all other data. All pages are then signed to prevent a attacker from removing the "require encryption" from specific form fields.
And a antivirus scanner could scan how much % of the document, and how much % of the sent data that is encrypted, if that % is too high, the antivirus scanner can block the request/response.
That would allow for example forcing encryption for the form field where you enter credit card data, or force encryption for the credit card number shown at your bank.
So the bank could use for example "This is your credit card number: &encrypt&1234 1234 1234 1234&/encrypt&", the server would parse that and know that it should use encryption for "1234 1234 1234 1234", on the line it would look like "This is your credit card number: ghsdjkkgdghssdgglskdghslhsjgsldhgkhsldkghsdfgkljsdhlgshl", so only selective data is encrypted.
Same with form fields... For example &Input type=text name=firstname& &input type=text name=cc forceencryption& would cause the client to send like for Firstname is sebastian and cc is 1234 1234 1234 1234: firstname=sebastian&cc=fklhasflshaflhsdlghseiuglbidbgdfskfgslkdghdsklhgdskl
I replaced angled brackets with & since HTML is not allowed here.
That would be a great addition instead of plain HTTPS/SSL.
Post a Comment