3 ms·

That comparison is off. HTTPS secures communications; this bug exposes memory, you still want the first without the second and HTTP doesn't offer it. Minimizing

That comparison is off. HTTPS secures communications; this bug exposes memory, you still want the first without the second and HTTP doesn't offer it. Minimizing complexity is a worthwhile goal but definitely not the only one since otherwise we could simply opt not to have communication that needs to be secured at all.

mikeash 13y ago
Sometimes you don't actually care about the first but still care about the second. In cases like that, HTTPS with heartbleed makes you much worse off than plain HTTP.
- andreasvc 13y ago
  Yes if you add that qualification your point is true but still not very compelling. The number of gratuitous HTTPS installations is low, I expect, given the hassle required to properly install it, so the ones that are there are probably there because secured communications were deemed necessary. On the other hand, there is nothing inherent in HTTPS which makes it vulnerable to remote exploits such as these, anything in the stack could have such a vulnerability. Therefore I think it is misleading to argue that we're worse off with HTTPS--the same argument could be made for Apache, PHP, Linux, Windows, etc., as they've all contained vulnerabilities.
  - mikeash 13y ago
    Lots of places use "gratuitous" HTTPS. This is particularly striking to me because I enabled HTTPS on my own site despite not needing it at all, and subsequently got caught up in this bug. Google.com could be another example. It's not strictly gratuitous because you can log in there, but in theory the search functionality could be partitioned off, and it did use plain HTTP for a very long time. For a more fitting example, DuckDuckGo uses HTTPS but doesn't, as far as I know, offer accounts or anything else that strictly needs security. They do it for the privacy of your searches, but if they were vulnerable to Heartbleed then they could have ended up exposing much more than they protected. I don't think the argument is that you're worse off with HTTPS in general, only that in certain circumstances you were worse off in this particular case, and that should cause at least some consideration for the increased attack surface incurred in enabling HTTPS when you don't otherwise need it.

mikeash 13y ago

Sometimes you don't actually care about the first but still care about the second. In cases like that, HTTPS with heartbleed makes you much worse off than plain HTTP.

andreasvc 13y ago
Yes if you add that qualification your point is true but still not very compelling. The number of gratuitous HTTPS installations is low, I expect, given the hassle required to properly install it, so the ones that are there are probably there because secured communications were deemed necessary. On the other hand, there is nothing inherent in HTTPS which makes it vulnerable to remote exploits such as these, anything in the stack could have such a vulnerability. Therefore I think it is misleading to argue that we're worse off with HTTPS--the same argument could be made for Apache, PHP, Linux, Windows, etc., as they've all contained vulnerabilities.
- mikeash 13y ago
  Lots of places use "gratuitous" HTTPS. This is particularly striking to me because I enabled HTTPS on my own site despite not needing it at all, and subsequently got caught up in this bug. Google.com could be another example. It's not strictly gratuitous because you can log in there, but in theory the search functionality could be partitioned off, and it did use plain HTTP for a very long time. For a more fitting example, DuckDuckGo uses HTTPS but doesn't, as far as I know, offer accounts or anything else that strictly needs security. They do it for the privacy of your searches, but if they were vulnerable to Heartbleed then they could have ended up exposing much more than they protected. I don't think the argument is that you're worse off with HTTPS in general, only that in certain circumstances you were worse off in this particular case, and that should cause at least some consideration for the increased attack surface incurred in enabling HTTPS when you don't otherwise need it.