7 ms·

Strengthening HTTP: A Personal View

51 points by tkorotkikh 12y ago

johnlewis 12y ago
Very much agree, HTTP2 ftw.11.11
TazeTSchnitzel 12y ago
Myself, I like the idea of opportunistic encryption. Why not require TLS for HTTP/2 but don't require authentication for http:// http:// URLs?
- matthewmacleod 12y ago
  It's hard to see what benefit that would offer. Non-authenticated TLS is trivially vulnerable to MITM attacks. This is especially the case because I can't foresee a situation in which a website would put the effort in to implement opportunistic TLS, but not implement straightforward authenticated HTTPS…
  - TazeTSchnitzel 12y ago
    It completely prevents passive surveillance, however. Sure, you can MITM, but the point is now to look at anything you have to do an MITM attack, unlike now, where most traffic is unencrypted and you can do surveillance passively. This makes surveillance more difficult. Net gain for everyone.
    - matthewmacleod 12y ago
      I'll concede that passive surveillance would not be possible. However, I think that benefit is marginal - AFAIK, unencrypted support in HTTP2 is optional and won't be supported by browsers in any case.
  - jessaustin 12y ago
    Non-authenticated TLS is trivially vulnerable to MITM attacks. I don't think a well-implemented TOFU/POP policy would be "trivially vulnerable", but it would still accommodate self-signing. Standardizing this would have been a worthy goal for IETF.
    - TazeTSchnitzel 12y ago
      I'd argue that even if it is MITM-vulnerable, it's still very useful, as it makes passive surveillance impossible.
  - tmorton 12y ago
    This article has a great response to that argument: https://www.tbray.org/ongoing/When/201x/2014/07/28/Privacy-Economics https://www.tbray.org/ongoing/When/201x/2014/07/28/Privacy-E...
higherpurpose 12y ago
There goes HTTP2's most exciting feature. I guess IETF will remain as useless as ever. Strong encryption on the Internet will need to arrive organically from certain projects catching momentum, and then Internet stakeholders can adopt them as they are, or risk being left behind. IETF standards will always have a multitude of compromises to please all the top Internet stakeholders (even if that's detrimental to the Internet ecosystem and its security). Also are those 1 or 2 (from what we know of) NSA employees still shaping crypto policy at IETF?
jbb555 12y ago
I hate this new HTTP. They seem to have taken a beautifully simple concept and added so much complexity it's ugly and horrible and awful.
- matthewmacleod 12y ago
  I hear this a lot, but without a consistent argument as to why that's the case. Do you have anything more than that to offer? HTTP 1.1 is relatively simple, but it's also a bottleneck.
  - Ono-Sendai 12y ago
    Are you claiming HTTP2 is not more complicated than HTTP 1.1?
    - matthewmacleod 12y ago
      Is is more complex - why is that inherently a bad thing?
      - Ono-Sendai 12y ago
        Complexity is bad, all other things being equal, because it takes longer to implement, is more likely to contain bugs, etc..
        matthewmacleod 12y ago
        Right, but obviously that's not the case here - there are actual benefits of using HTTP2. The fact that it's more complex doesn't necessarily (and I would argue, definitely doesn't) outweigh that.
  - protonfish 12y ago
    Don't shift the burden of proof-It is up to HTTP/2 proponents to demonstrate that the benefits are greater than the costs and from everything I've seen the benefits are meager and the costs are large.
jessaustin 12y ago
For example, in the current design of HTTP the decision as to whether to use encryption is completely up to the server; the only thing the user can do is observe whether a URL is “HTTP” or “HTTPS” (or maybe watch a lock icon) and decide whether they can continue surfing. This seems a strange characterization. As in any other network protocol, if the client and server don't agree then nothing happens. If either insists on something the other finds unacceptable (e.g. a 404 response to "GET /your-secret-plans HTTP/1.1") then the transaction doesn't take place. Perhaps this could be made more explicit via a header, but what would that really gain?
- rx4g 12y ago
  I think he's saying that clients could decide beforehand whether they want to go into HTTPS-only mode, for example. But this is something clients can actually do today, without the need for a new protocol or any awareness on the server side. URL isn't HTTPS? Don't load it. I actually did a Firefox plugin that implements this, called http-nowhere.
  - matthewmacleod 12y ago
    But this is something clients can actually do today, without the need for a new protocol or any awareness on the server side. URL isn't HTTPS? Don't load it. I actually did a Firefox plugin that implements this, called http-nowhere. Yes - and my understanding is that the browser developers are going to require all HTTP2 connections to be over TLS anyway.
rx4g 12y ago
It's disappointing to hear that the idea of requiring TLS with HTTP/2 has lost traction. For me, TLS-everywhere was the carrot on the stick. I recognize that getting consensus is hard work, but I don't think creating another encryption-optional protocol and letting vendors duke it over security is going to end well for the users. HTTP is a deployed protocol with lots of existing stakeholders, like proxy vendors, network operators, corporate firewalls and so on. Requiring encryption with HTTP/2 means that these stakeholders get disenfranchised. I'd like to hear the arguments of the potentially-disenfranchised stakeholders first hand. Is it mainly because it makes it harder to sell or use products that allow traffic snooping?
- matthewmacleod 12y ago
  One obvious change here is that it would make CA-signed certificates mandatory for all HTTP2 web servers - is that really a situation we want?
  - quicksilfer 12y ago
    That doesn't have to be the case. You could still allow self-signage, with all of the security caveats that presents. Who knows. Maybe that arrangement could even spur a sorely needed push for a free certificate trust network and get rid of CA's entirely.
    - rx4g 12y ago
      Self-signed certs are much harder to get browsers to accept these days. The "I know what I'm doing" button and process are becoming ever more complex, and I wouldn't be surprised if they just start going away in favor of a list of trusted root CAs, which you may or may not be able to control as a user, depending on your browser. Which sucks. But anyway. StartSSL is one place where you can get a free cert for your website today (and yes, they charge for revocation, but revocation is pretty ineffective anyway). I got a free cert from them, but my mobile browser doesn't trust it, so I decided to shell out $10 for a cert that's more widely auto-trusted by browsers. Not a huge cost, IMO.
  - 12y ago
jimktrains2 12y ago
Beyond everything else, someone should have stopped and said "Wait, this is level 4 stuff we're implementing in level 7. There has to be a saner way" I also find the naming very disingenuous. This is not even an HTTP-style protocol, it should not be named HTTP2. As for people who want to require CA certs everywhere: Are all the free certs out there accepted by all browsers? (Honest question).
bkeroack 12y ago
Forget the hand-waving and excuses, TLS needs to be mandatory, period. This alone would make me forgive just about any other problem with HTTP/2.
- Touche 12y ago
  Disagree, purely informational websites have no need for TLS.
  - x1798DE 12y ago
    The need for TLS is less in purely information websites, but there are a number of problems with this attitude. For one thing, the content of the pages you visit still leaks information about a user, even if the page isn't customized per user. Second, authenticated, trustworthy SSL connections provide MITM protection and prevents modification of the content you receive - the transition from HTTP to HTTPS is generally going to be vulnerable to an sslstrip-like attack, homoglyph attacks, etc, plus content could be modified maliciously in transit directly over an HTTP connection (a less drastic form of this sort of thing has happened many times with ISPs adding in tracking cookies in transit, or comcast adding some javascript to pages when you get close to your bandwidth limit). In any case, the cost of all-TLS is really not so high that you can't enable it just for edge cases who want or need to use secure connections for all internet communication.
  - bretthoerner 12y ago
    1) There are regimes that would lock you up (or worse) for looking at some "purely informational" sites. 2) Defaults matter and developers make mistakes. Without required TLS many sites that should be encrypted won't be (they forgot, the site grew into something it didn't used to be, they had no idea what TLS was, etc)
    - Touche 12y ago
      Ruining the web in order to prevent any possibility of bad things happening is something I'm firmly against. I have several small blogs and websites that I absolutely would not bother with if I had to pay for and set up https on each.

51 points by tkorotkikh 12y ago

Very much agree, HTTP2 ftw.11.11

Myself, I like the idea of opportunistic encryption. Why not require TLS for HTTP/2 but don't require authentication for http:// http:// URLs?

matthewmacleod 12y ago
It's hard to see what benefit that would offer. Non-authenticated TLS is trivially vulnerable to MITM attacks. This is especially the case because I can't foresee a situation in which a website would put the effort in to implement opportunistic TLS, but not implement straightforward authenticated HTTPS…
- TazeTSchnitzel 12y ago
  It completely prevents passive surveillance, however. Sure, you can MITM, but the point is now to look at anything you have to do an MITM attack, unlike now, where most traffic is unencrypted and you can do surveillance passively. This makes surveillance more difficult. Net gain for everyone.
  - matthewmacleod 12y ago
    I'll concede that passive surveillance would not be possible. However, I think that benefit is marginal - AFAIK, unencrypted support in HTTP2 is optional and won't be supported by browsers in any case.
- jessaustin 12y ago
  Non-authenticated TLS is trivially vulnerable to MITM attacks. I don't think a well-implemented TOFU/POP policy would be "trivially vulnerable", but it would still accommodate self-signing. Standardizing this would have been a worthy goal for IETF.
  - TazeTSchnitzel 12y ago
    I'd argue that even if it is MITM-vulnerable, it's still very useful, as it makes passive surveillance impossible.
- tmorton 12y ago
  This article has a great response to that argument: https://www.tbray.org/ongoing/When/201x/2014/07/28/Privacy-Economics https://www.tbray.org/ongoing/When/201x/2014/07/28/Privacy-E...

higherpurpose 12y ago

There goes HTTP2's most exciting feature. I guess IETF will remain as useless as ever. Strong encryption on the Internet will need to arrive organically from certain projects catching momentum, and then Internet stakeholders can adopt them as they are, or risk being left behind. IETF standards will always have a multitude of compromises to please all the top Internet stakeholders (even if that's detrimental to the Internet ecosystem and its security). Also are those 1 or 2 (from what we know of) NSA employees still shaping crypto policy at IETF?

jbb555 12y ago

I hate this new HTTP. They seem to have taken a beautifully simple concept and added so much complexity it's ugly and horrible and awful.

matthewmacleod 12y ago
I hear this a lot, but without a consistent argument as to why that's the case. Do you have anything more than that to offer? HTTP 1.1 is relatively simple, but it's also a bottleneck.
- Ono-Sendai 12y ago
  Are you claiming HTTP2 is not more complicated than HTTP 1.1?
  - matthewmacleod 12y ago
    Is is more complex - why is that inherently a bad thing?
    - Ono-Sendai 12y ago
      Complexity is bad, all other things being equal, because it takes longer to implement, is more likely to contain bugs, etc..
      - matthewmacleod 12y ago
        Right, but obviously that's not the case here - there are actual benefits of using HTTP2. The fact that it's more complex doesn't necessarily (and I would argue, definitely doesn't) outweigh that.
- protonfish 12y ago
  Don't shift the burden of proof-It is up to HTTP/2 proponents to demonstrate that the benefits are greater than the costs and from everything I've seen the benefits are meager and the costs are large.

jessaustin 12y ago

For example, in the current design of HTTP the decision as to whether to use encryption is completely up to the server; the only thing the user can do is observe whether a URL is “HTTP” or “HTTPS” (or maybe watch a lock icon) and decide whether they can continue surfing. This seems a strange characterization. As in any other network protocol, if the client and server don't agree then nothing happens. If either insists on something the other finds unacceptable (e.g. a 404 response to "GET /your-secret-plans HTTP/1.1") then the transaction doesn't take place. Perhaps this could be made more explicit via a header, but what would that really gain?

rx4g 12y ago
I think he's saying that clients could decide beforehand whether they want to go into HTTPS-only mode, for example. But this is something clients can actually do today, without the need for a new protocol or any awareness on the server side. URL isn't HTTPS? Don't load it. I actually did a Firefox plugin that implements this, called http-nowhere.
- matthewmacleod 12y ago
  But this is something clients can actually do today, without the need for a new protocol or any awareness on the server side. URL isn't HTTPS? Don't load it. I actually did a Firefox plugin that implements this, called http-nowhere. Yes - and my understanding is that the browser developers are going to require all HTTP2 connections to be over TLS anyway.

rx4g 12y ago

It's disappointing to hear that the idea of requiring TLS with HTTP/2 has lost traction. For me, TLS-everywhere was the carrot on the stick. I recognize that getting consensus is hard work, but I don't think creating another encryption-optional protocol and letting vendors duke it over security is going to end well for the users. HTTP is a deployed protocol with lots of existing stakeholders, like proxy vendors, network operators, corporate firewalls and so on. Requiring encryption with HTTP/2 means that these stakeholders get disenfranchised. I'd like to hear the arguments of the potentially-disenfranchised stakeholders first hand. Is it mainly because it makes it harder to sell or use products that allow traffic snooping?

matthewmacleod 12y ago
One obvious change here is that it would make CA-signed certificates mandatory for all HTTP2 web servers - is that really a situation we want?
- quicksilfer 12y ago
  That doesn't have to be the case. You could still allow self-signage, with all of the security caveats that presents. Who knows. Maybe that arrangement could even spur a sorely needed push for a free certificate trust network and get rid of CA's entirely.
  - rx4g 12y ago
    Self-signed certs are much harder to get browsers to accept these days. The "I know what I'm doing" button and process are becoming ever more complex, and I wouldn't be surprised if they just start going away in favor of a list of trusted root CAs, which you may or may not be able to control as a user, depending on your browser. Which sucks. But anyway. StartSSL is one place where you can get a free cert for your website today (and yes, they charge for revocation, but revocation is pretty ineffective anyway). I got a free cert from them, but my mobile browser doesn't trust it, so I decided to shell out $10 for a cert that's more widely auto-trusted by browsers. Not a huge cost, IMO.
- 12y ago

jimktrains2 12y ago

Beyond everything else, someone should have stopped and said "Wait, this is level 4 stuff we're implementing in level 7. There has to be a saner way" I also find the naming very disingenuous. This is not even an HTTP-style protocol, it should not be named HTTP2. As for people who want to require CA certs everywhere: Are all the free certs out there accepted by all browsers? (Honest question).

bkeroack 12y ago

Forget the hand-waving and excuses, TLS needs to be mandatory, period. This alone would make me forgive just about any other problem with HTTP/2.

Touche 12y ago
Disagree, purely informational websites have no need for TLS.
- x1798DE 12y ago
  The need for TLS is less in purely information websites, but there are a number of problems with this attitude. For one thing, the content of the pages you visit still leaks information about a user, even if the page isn't customized per user. Second, authenticated, trustworthy SSL connections provide MITM protection and prevents modification of the content you receive - the transition from HTTP to HTTPS is generally going to be vulnerable to an sslstrip-like attack, homoglyph attacks, etc, plus content could be modified maliciously in transit directly over an HTTP connection (a less drastic form of this sort of thing has happened many times with ISPs adding in tracking cookies in transit, or comcast adding some javascript to pages when you get close to your bandwidth limit). In any case, the cost of all-TLS is really not so high that you can't enable it just for edge cases who want or need to use secure connections for all internet communication.
- bretthoerner 12y ago
  1) There are regimes that would lock you up (or worse) for looking at some "purely informational" sites. 2) Defaults matter and developers make mistakes. Without required TLS many sites that should be encrypted won't be (they forgot, the site grew into something it didn't used to be, they had no idea what TLS was, etc)
  - Touche 12y ago
    Ruining the web in order to prevent any possibility of bad things happening is something I'm firmly against. I have several small blogs and websites that I absolutely would not bother with if I had to pay for and set up https on each.