4 ms·

Interesting point for me is that those who serve over HTTP only are not vulnerable, which I think is a good case study in the risk of complexity. A lot of secur

by jl6 13y ago

Interesting point for me is that those who serve over HTTP only are not vulnerable, which I think is a good case study in the risk of complexity. A lot of security experts have been calling for HTTPS everywhere, on the basis that it is low cost. Clearly there is a cost to the extra complexity, and in this case a bug in the security layer that results in a worse situation than if there had been no security layer at all.

awj 13y ago
> Interesting point for me is that those who serve over HTTP only are not vulnerable ...yes they are. You don't even need remote private key disclosure to MITM an http-only server. The way HTTP digest is written means you either store all passwords in a retrievable form or drop down to basic auth where anyone capable of base64 decoding can read all passwords. This situation is by no means worse than if everyone had just used plain HTTP.
- jl6 13y ago
  MITM is only one type of attack, which is largely irrelevant to public sites serving non sensitive information. But server memory is always private and could assist in escalation of a further attack.
- subleq 13y ago
  It is worse than plain HTTP, actually. Heartblead allows an attacker anywhere on the internet to read out memory from your server. This is worse than plain HTTP in two ways: - With plain HTTP, the attacker would have to be in a MITM position to intercept traffic. With Heartblead, he can read traffic he wouldn't normally have access to from the server's memory. - There may be secrets in memory that would never even be sent over the network that are now accessible. For example, if running a web app in the same process doing SSL termination, private keys such as Django's SECRET_KEY may be available. Under certain situations, knowledge of the SECRET_KEY can effect remote code execution. In short, Heartbleed gives the entire world the ability to read memory from your server. This is much worse than an HTTP MITM.
- mikeash 13y ago
  Here's an example where Heartbleed is much, much worse. I run an HTTP-only server that's read-only for the public. However, I have an admin interface that lets me log in and make changes to the site. For example, a WordPress blog. Now, let's say that I run the server at home and I'm careful only to log in as an admin when on the home LAN. This is perfectly secure even though I'm only using plain HTTP. If I decided to instead serve HTTPS, the heartbleed vulnerability means that anybody could potentially hijack my sessions, steal my passwords, and edit the site. Depending on how much password reuse is going on, they could own the entire box, or just put malicious code on the site for all my visitors to run into.
andreasvc 13y ago
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.

by jl6 13y ago

awj 13y ago

> Interesting point for me is that those who serve over HTTP only are not vulnerable ...yes they are. You don't even need remote private key disclosure to MITM an http-only server. The way HTTP digest is written means you either store all passwords in a retrievable form or drop down to basic auth where anyone capable of base64 decoding can read all passwords. This situation is by no means worse than if everyone had just used plain HTTP.

jl6 13y ago
MITM is only one type of attack, which is largely irrelevant to public sites serving non sensitive information. But server memory is always private and could assist in escalation of a further attack.
subleq 13y ago
It is worse than plain HTTP, actually. Heartblead allows an attacker anywhere on the internet to read out memory from your server. This is worse than plain HTTP in two ways: - With plain HTTP, the attacker would have to be in a MITM position to intercept traffic. With Heartblead, he can read traffic he wouldn't normally have access to from the server's memory. - There may be secrets in memory that would never even be sent over the network that are now accessible. For example, if running a web app in the same process doing SSL termination, private keys such as Django's SECRET_KEY may be available. Under certain situations, knowledge of the SECRET_KEY can effect remote code execution. In short, Heartbleed gives the entire world the ability to read memory from your server. This is much worse than an HTTP MITM.
mikeash 13y ago
Here's an example where Heartbleed is much, much worse. I run an HTTP-only server that's read-only for the public. However, I have an admin interface that lets me log in and make changes to the site. For example, a WordPress blog. Now, let's say that I run the server at home and I'm careful only to log in as an admin when on the home LAN. This is perfectly secure even though I'm only using plain HTTP. If I decided to instead serve HTTPS, the heartbleed vulnerability means that anybody could potentially hijack my sessions, steal my passwords, and edit the site. Depending on how much password reuse is going on, they could own the entire box, or just put malicious code on the site for all my visitors to run into.

andreasvc 13y ago

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.