Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hypertext Transfer Protocol Version 2

tools.ietf.org

Post reply on HN
Print view View original

71–80 of 113 posts

Re: Hypertext Transfer Protocol Version 2

#71

Post by bsdetector »

agl wrote: post #26
nly wrote: post #21

The accompanying HTTP header compression standard seems a lot more terrifying on the complexity scale, compared to Googles suggestion with SPDY of just dumping everything through zlib: http://tools.ietf.org/html/draft-ietf-httpbis-header-compres...

But dumping everything through zlib turned out to be a security hole: http://en.wikipedia.org/wiki/CRIME . I wrote some terrible, terrible code for Chromium to patch zlib in order to segment different sources of data and compress them separately while still being wire compatible with zlib. I'll be very happy when I can remove it.

Just like it turned out that minimized HTTP was faster than SPDY: http://research.microsoft.com/apps/pubs/?id=170059

I'm not sure what the motivation is behind HTTP2/SPDY. There have been consistent misinformation from Google about the performance of it (for instance including initial connection time for HTTP but omitting it for SPDY, using an outdated HTTP stack, not using HTTP pipelining) so I doubt the motivation is performance.

It looks like just not-invented-here bloat, but I wouldn't be surprised to find out that the SPDY connection to google-analytics.com is kept open and reused across tabs.

Re: Hypertext Transfer Protocol Version 2

#72

Post by waps »

riffraff wrote: post #69
sjwright wrote: post #50

Earlier quoted context omitted.

If only it were that simple. As it stands now, the problem with HTTP/HTTPS is that encryption is an all-or-nothing proposition. There should be three modes supported: 1. Unencrypted (for casual/ad-hoc web servers serving cache-able static assets) 2. Encrypted-untrusted (for casual/ad-hoc web servers that just want to thwart basic Wi-Fi cookie sniffing) 3. Encrypted-trusted (for most established websites) Right now, #…

what is the point of having #2 in the first place, rather than moving on to #3 directly?

thepiratebay ... and other sites that would expose themselves by using #3

Re: Hypertext Transfer Protocol Version 2

#73

Post by xorcist »

rurounijones wrote: post #51
kaoD wrote: post #42

Earlier quoted context omitted.

> but no cert is needed for unauthenticated encrypted connections That is a common misconception. If I MITM when you establish connection, how would you notice? My self-signed certificate looks like a real one. That's why we need CAs (or WoT, or whatever), to verify identity after we've established a secure channel.

Which is why the pinning bit comes in. If I connect to server X at home, get their self-signed cert and then connect later at starbucks on a MITM'd connection, I will know something is wrong. Best solution? Not by a long shot, but it is a reasonably simple one to implement and does improve things.

You need to complete that sentence before it is a real suggestion: "and either the keys were changed or there is an active MITM. The browser then ..".

It would not be acceptable to trade the ability to change SSL keys for a trust-on-first-use model. There are solutions to this of course, but also tradeoffs. These needs to be taken into account.

Re: Hypertext Transfer Protocol Version 2

#74

Post by xorcist »

7952 wrote: post #61
phaer wrote: post #37

Earlier quoted context omitted.

How can you (or an 'average user' whoever that might be) carefully evaluate untrusted certificates? Wouldn't i need some kind of detached information like the certificates hash signed by an already known gpg key? The CA idea is broken but not too easy to replace. http://convergence.io/ could be a few steps forward.

You could have a URL format that includes the signature of the key. Big sites would transparently add the signature and the browser would give a warning if the signature is different. You could add the same signature information to cookies and warn the user if it changes.

There is a big tradeoff here: The ability to enter URLs manually.

This is what we tell users to do today for important sites, and not click in links in mail or elsewhere. It is not obvious that there is a net benefit in security.

Re: Hypertext Transfer Protocol Version 2

#75

Post by lucaspiller »

AlyssaRowan wrote: post #70
lucaspiller wrote: post #67

Earlier quoted context omitted.

Sorry, maybe I wasn't clear... With encrypted-trusted if you try an MITM, unless you have a valid SSL key, the browser will show a big error screen and not send any cookies. With encrypted-untrusted the browser wouldn't do that, so the cookies would still be sent. You don't even need to route the connection, you could just present an "Error connection to server" page and most users would just think the wifi isn't wor…

No illusion whatsoever. OE looks to browsers just like HTTP - no lock icon, nothing. This is http: protocol. For what it's worth, YouTube does use HTTPS for My Little Pony shows. Actually, there's a hidden service on Tor for that. (I'm not even joking.)

Thanks, that makes sense. As long as people understand that although it's encrypted it's still not really safe. That could be the hard part though, as I expect a lot of people assume anything encrypted is safe (related, see malicious SHA1 - https://news.ycombinator.com/item?id=8136526).

Re: Hypertext Transfer Protocol Version 2

#76

Post by xorcist »

api wrote: post #13
stonogo wrote: post #9

Earlier quoted context omitted.

I'm amused and depressed that the industry is willing to consider almost any solution -- except using something other than a web browser for tasks that do not involve browsing the web. Seriously... it works for Spotify, even now.

The world is full of clueless firewall administrators who block everything but port 80 and 443 because security. It inconveniences users a lot more than attackers, but if you try explaining this you get a bunch of cargo cultism about reducing attack surface area, etc. Never mind that these protocols now tunnel everything and thus have equivalent attack surface area to just opening your network. I call it cargo cultis…

The firewalls are going to get very expensive once everything runs on port 80.

Unhappy users are sometimes the only way to get policies to change.

Re: Hypertext Transfer Protocol Version 2

#77

Post by xorcist »

lazyloop wrote: post #28
0x0 wrote: post #17

I'm curious to see how transparent proxies handle all the crazy framing (will poor software corrupt the bytestream?) and if there will be a wave of exploits for both client and server implementations; the complexity and subtleties appear to be almost a magnitude higher than http/1.

That's simple, they just won't, browsers will only support HTTP/2 over TLS, so proxies are effectively dead.

Every large web site uses a load balancer, effectively a proxy. I don't understand why Poul Henning-Kamp's experience with that didn't carry more weight in the working group.

Re: Hypertext Transfer Protocol Version 2

#78

Post by XorNot »

AlyssaRowan wrote: post #60
XorNot wrote: post #24

Earlier quoted context omitted.

I think you should always be able to turn encryption off. Encryption is expensive. I run OpenSSH-HPN partly so, on my local network I can get secure logins but then not pay the throughput hit of encryption when it just doesn't matter. The same even applies to internet connections, such as big but generally uninteresting things like log files. Defaulting to "encryption enabled" and throwing a browser warning of "encry…

Ah, you think your local network is trusted? So did Google. It isn't.

I'm impressed I'm somehow getting modded down for that opinion.

My local network is trusted. Google does not have a local network. But the cables and wires physically within my house or even my office building can be presumed to be secure, since if you can get access to those, then you could also just take the physical machines by any numbers of methods.

You also don't address "large but insensitive data" - which is where YouTube video downloads and the like mostly lies. Encryption is not costless on small devices like laptops/desktops.

Re: Hypertext Transfer Protocol Version 2

#79

Post by youngtaff »

bsdetector wrote: post #71
agl wrote: post #26

Earlier quoted context omitted.

But dumping everything through zlib turned out to be a security hole: http://en.wikipedia.org/wiki/CRIME . I wrote some terrible, terrible code for Chromium to patch zlib in order to segment different sources of data and compress them separately while still being wire compatible with zlib. I'll be very happy when I can remove it.

Just like it turned out that minimized HTTP was faster than SPDY: http://research.microsoft.com/apps/pubs/?id=170059 I'm not sure what the motivation is behind HTTP2/SPDY. There have been consistent misinformation from Google about the performance of it (for instance including initial connection time for HTTP but omitting it for SPDY, using an outdated HTTP stack, not using HTTP pipelining) so I doubt the motivation…

Apart from it's a couple of years old…

There are also a number of potential shortcomings and details missing from the study e.g. you've only got to look at httparchive.org, to see the dummy page isn't representative of real world pages, and then they used similar small pages for the other sites.

We also don't have any information on the TLS setup e.g. was it well optimized etc.

The study provides some interesting datapoints but would benefit from further research

Re: Hypertext Transfer Protocol Version 2

#80

Post by bsdetector »

youngtaff wrote: post #79
bsdetector wrote: post #71

Earlier quoted context omitted.

Just like it turned out that minimized HTTP was faster than SPDY: http://research.microsoft.com/apps/pubs/?id=170059 I'm not sure what the motivation is behind HTTP2/SPDY. There have been consistent misinformation from Google about the performance of it (for instance including initial connection time for HTTP but omitting it for SPDY, using an outdated HTTP stack, not using HTTP pipelining) so I doubt the motivation…

Apart from it's a couple of years old… There are also a number of potential shortcomings and details missing from the study e.g. you've only got to look at httparchive.org, to see the dummy page isn't representative of real world pages, and then they used similar small pages for the other sites. We also don't have any information on the TLS setup e.g. was it well optimized etc. The study provides some interesting dat…

> to see the dummy page isn't representative of real world pages, and then they used similar small pages for the other sites.

If you believe the SPDY marketing material that one of the reasons behind it is to reduce delay from TCP window expansion then small sites should be where it shines. A small site is more influenced by time to 'ramp up' connections. Yet it appears to be slower on small sites.

Also, bbc.com and greenweddingshoes.com (now 10 MiB) are small pages? Hardly.

It's pretty clear to me with the slew of basic errors and oversights in Google's numbers that performance wasn't the motivation behind this protocol. I'm scratching my head trying to understand what they were thinking.

Post reply on HN