It's only a little easier. There are three scenarios I've been able to come up with:
The attacker triggers some kind of bug or odd mode in a router. That router happily floods packets to the wrong places, but still only accepts them from the right place.
The attacker can decrypt your WiFi plaintext, but not in realtime. You've already received the response from the server by the time the attacker can craft one for you.
The attacker is afraid of getting caught (he possibly needs to be on-location, and can't work through an intermediary), and is therefore restricted to passive methods.
As it happens, all three of these are pretty unlikely. They aren't impossible, but why put forth a large effort for JS crypto when you could put forth a small effort for SSL?
Here are some ways to modify traffic on typical networks, most have command-line or GUI point-and-click attack tools available. Some of these are documented to have been conducted on wide blocks of internet traffic.
The attacker broadcasts a SSID of 'Free Public Wifi', or one similar to what you normally use, then DoSes all other access points when you try to use them.
The attacker is on the same ethernet broadcast domain and replies to your DHCP query quicker than the legitimate DHCP server does.
The attacker poisons the router's ARP cache and impersonates your MAC.
The attacker leverages the unauthenticated nature of Spanning Tree Protocol STP.
The attacker pwns your home wifi router through a default password on its admin page or any number of other bugs.
The attacker messes with your DNS name resolution for sites of interest. Remember that time DNS resolution for some S. American (and a few US) ISPs got routed through the great firewall of China?
The attacker advertises a more-specific route for your IP address or that of a target site. Remember when that little ISP in Pakistan took YouTube offline?
The attacker could be your ISP working under order of some government. Yours, that of a country you're visiting, or of some territory the packets pass through along the way.
Or you could be using a hotel, airplane, library, mobile, etc. internet connection where transparent intercepting MitM proxies are standard fare. How good do you think the hotel staff are at securing that internet billing appliance they bought?
And of course, the attacker could always cut a cable somewhere and install a tap.
Was Amazon ever vulnerable to session resumption attacks? How?
Either way: every vulnerability we've found in SSL/TLS (the protocol) makes me more confident in it. Those findings are the product of millions of dollars of attention. Why would we think that any alternative to TLS wouldn't have the same flaws, or worse ones?
Was Amazon ever vulnerable to session resumption attacks?
I have no direct knowledge. I was personally extremely careful to never test any actual sites.
But unless they were running MS IIS or certain brands of SSL offload devices on every accessible host with the cert on it, they were likely willing to conduct client-initiated renegotiation. I know they use client certs for EC2 stuff, that likely involves a server-initiated renegotiation opportunity as well.
Just checked, they still haven't patched for the actual protocol fix, RFC 5746
How?
Frank Heidt came up with an awesome little exploit that isn't affected by anti-CSRF mitigations. Just find one single URL under HTTPS which redirects to HTTP. (E.g., https://www.amazon.com/) Inject a request to that and now you have a plain HTTP request to play with. You could enter an sslstrip scenario, replace the cert with a legitimate cert to a phishing site at a point the user isn't expecting the URL to change. How many users stop browsing after receiving a mixed content warning I wonder?
Other researchers showed you could replace the EV cert with a simple DV cert at that stage and the browser would still show the green bar.
Either way: every vulnerability we've found in SSL/TLS (the protocol) makes me more confident in it. Those findings are the product of millions of dollars of attention. Why would we think that any alternative to TLS wouldn't have the same flaws, or worse ones?
Absolutely. Those who criticize TLS need to understand why it is the way it is and either propose improvements (the IETF [TLS] mailing list is open) or propose a replacement that really does a better job delivering on all the security properties, not just one or two.
> How many users stop browsing after receiving a mixed content warning I wonder?
That's a blog post (and supporting data drop) that I would be interested in reading. Based on my experiences at a former employer the rate of cart abandonment on mixed pages is about 20% greater than on fully valid pages (someone hard coded a logo reference into a template) but the sample was fairly small and I would be curious to know what the difference would be on a broader sampling of sites.
From what I hear, newer browsers are said to be tightening the screws on mixed content and giving increasingly annoying warnings. For example, showing a red slash through the lock icon.
If you were very selective about it, and pulled it off without any disruption, you could get away without anyone noticing. Or, do it from a third-world ISP, and say "It was an accident whaduyagonnadoaboutit".
If there are big BGP changes, the world notices. If the BGP for the specific netblock your site is hosted on changes, the world probably does not notice. Your users will see slightly degraded performance (actually, in some cases it will improve), and (presumably) a number in the NSA will be <1% higher for a few minutes, but that's about it.
I've worked on software that literally (intentionally) publishes BGP updates every ~10 seconds. It didn't bother anyone, because it wasn't playing with many addresses.
The attacker triggers some kind of bug or odd mode in a router. That router happily floods packets to the wrong places, but still only accepts them from the right place.
The attacker can decrypt your WiFi plaintext, but not in realtime. You've already received the response from the server by the time the attacker can craft one for you.
The attacker is afraid of getting caught (he possibly needs to be on-location, and can't work through an intermediary), and is therefore restricted to passive methods.
As it happens, all three of these are pretty unlikely. They aren't impossible, but why put forth a large effort for JS crypto when you could put forth a small effort for SSL?