I'm a little disappointed with the answers from Zypher (one of the Stack Exchange sysadmins) and Jeff Atwood. Particularly troublesome is Jeff's statement "If you have a 'man in the middle' then there are deeper problems, like, you're using a compromised network." I'd argue that it's appropriate, from a security architecture perspective, to treat the entire Internet as a "compromised network".
Admittedly, my use-case for the Stack Exchange sites (specifically Server Fault) is a little different than most people's and I'm a lot more worried about "theft" of my "identity" there than most people would be. Still, though, I'd like to see the answer revisited in light of mid-2012 technology / costs. I suppose I should go post something over there...
Out of curiosity, does anyone know how much traffic I'd have to hit before my "$20 SSL certificate" started being a chokepoint and bottleneck? If I were able to hit stackoverflow levels of traffic, I'm sure I'd be able to figure out a way to afford it (although maybe even they haven't yet), but I'm curious at lower levels of traffic if I should still worry.
The price of the certificate is irrelevant. The issue is that encryption and decryption eats CPU cycles, so running all traffic via HTTPS on a busy site is going to require significantly more processing power.
"In order to do this we had to deploy no additional machines and no special hardware. On our production front-end machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that."
I realize that. I'm asking how much traffic can be handled by a simple single server before it starts dying due to SSL CPU cycles.
I do realize now that my question is too simplistic and obviously varies according to the nature of the application, server config, etc. So won't expect any answers for it. :)
Definitely a question I can't answer. Although these days SSL is rarely implemented on each individual server. Instead, load balancers handle SSL and traffic is passed unencrypted to the backend servers doing the real work (presumably at this point, you're on a secure network). Many hardware load balancers even have specialized chips for handling SSL.
Just a guess but if you are running your site on a single server you're going to hit other bottlenecks in things such as your application code or database, your http server, or disk contention, or RAM starvation, before SSL encryption becomes the overriding one.
The only clarification I'd make here is the distinction between "public wifi" and "unencrypted wifi". Some cafes I frequent have WPA2 secured networks with the SSID and password made freely available. I'm pretty sure that solves the Firesheep problem (I don't know for sure, but I'm reasonably confident that other people on the WPA2 network still can read my connection).
With most WiFi encryption (basically except WPA2 Enterprise, which won't be in use in cafés) you can still receive the traffic as long as you see the initial handshake for the device connecting to the network.
Sniffing software like Wireshark or Aircrack-NG can handle the decryption transparently.
Once you can see the traffic Firesheep or something like it will work in the same way as on an unencrypted network.
You could still probably do a MITM attack using ARP poisoning or something of the like (IE redirect all traffic through one machine), if there is the ability to access other machines on the network.
If this is a WPA2 shared-password setup then your traffic can be captured, dumped and decrypted with aircrack-ng. Firesheep may not work, but it's trivial to present cookies which match captured values.
Not sure why the author goes through pains not to call out the fact that SO is not secure in the layman sense. In general, if a service requires users to understand the lack of SSL and to take security into their own hands, the service is not secure. Worse than that, SO does not even explicitly communicate this to users.
Also, the author omits a crucial workaround. When on a public network, communication can be made secure if routed through an encrypted tunnel to a known-secure network, such as with a properly configured VPN.
> The only instance in which I’d really urge caution is that public Wi-Fi scenario, particularly when you’re in an environment surrounded by other people with technical know-how.
The first condition is satisfied whenever you're in a coffee shop, airport, hotel, university campus, wifi-enabled public transportation ... i.e. pretty much everywhere except your own home and possibly your workplace. Some of these places use WPA, but most I've seen don't use any encryption. The second condition shouldn't be too easy to satisfy, either, particularly when you're in a place like the Bay Area.
Blacklisting isn't good enough when it comes to security, we all know that. So the advice should rather be: Anyone can steal your Stack Overflow session at any time whatsoever, unless you're using an Ethernet cable or your own secure Wi-Fi. (Even then, your ISP or a three-letter government agency could see your traffic, but they're probably more interested in watching you than impersonating you.)
I don't think it's a safe assumption that the only parties upstream from you are ISPs and TLA government agencies. If script kiddies are hacking major corporations I think it's a safe bet that ISPs are vulnerable, too. Your Stack Overflow "identity" may not be of great value, but it's worth keeping in mind that any cleartext traffic is vulnerable. Being cognizant of sending data over the Internet in cleartext is a good thing, to me.
wow, it stuns me how people can write so much text for something so trivial. what's your point?
"i don't really care that the stackoverflow guys don't care because it doesn't really matter"
"i'll just post it here knowing that it won't help the average joe either, because he will never read or understand what i wrote"
who's the target audience for that post? if you're just explaining cookie theft ssl and openid to unknown audience by the example of stackoverflow. by all means write it in the first paragraph.
A little harsh. I think it's a good reminder for all of those new products and services being developed as we speak who can make this a priority now instead of having to layer it on later.
Would that fit your definition of a "call to action?"
I'm working on a side project now which uses a similar approach for security (delegate it). While I had already planned on making sure the app would be available over SSL, this was a good reminder of why.
The beautiful thing about the Internet and, indeed, free choice is that you could have stopped reading this article and moved on at any time.
but it's not. the way i see it, op seems to have a rather big audience. but it rather reads like a highschool it essay. see if he had been in any way related to stackoverflow the message would've been ok, but too long.
"A little harsh. I think it's a good reminder for all of those new products and services being developed as we speak who can make this a priority now instead of having to layer it on later."
i hope you see the irony. you're right with what you say. but it would be even better of a place if people would actually try to create something of value, both positive or negative. but this is somewhere in between.
something with more value and much more precise is the stackoverflow link someone posted in this thread
