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

81–90 of 113 posts

Re: Hypertext Transfer Protocol Version 2

#81

Post by nightcracker »

lucaspiller wrote: post #75
AlyssaRowan wrote: post #70

Earlier quoted context omitted.

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 ).

Sorry, but the link you posted is not even remotely related.

Re: Hypertext Transfer Protocol Version 2

#82

Post by lazyloop »

diafygi wrote: post #6

There is so much open wifi nowadays that non-https should really start to be considered harmful. A large portion of website visitors are probably connecting via Starbucks, airport wifi, etc., which means their session cookies are basically public information. So even given the mass surveillance problems, non-https connections need to start being treated as Bad Practice and discouraged by the sysadmin community.

One aspect of this many seem to forget is HTTP as a backend protocol, you will have to set up certificates and keep them up to date there too.

Re: Hypertext Transfer Protocol Version 2

#83

Post by inopinatus »

AlyssaRowan wrote: post #62
wyager wrote: post #10

To those saying HTTP2 should require HTTPS: do you really want to be stuck with our shitty CA model for even longer?

TLS is actually not glued to x.509 certificates, and certainly not to ones chained to the public CA system. DANE TLSA " rel="nofollow">https://tools.ietf.org/html/rfc6698> for example provides for a way to pin them to DNSSEC, whether in addition to or instead of the CA system. Other ways of keying may become available in the future, especially as we go through TLS 1.3 to future versions.

There's an argument I've heard that DANE TLSA ties crypto closer to nation-state control than the CAs do, since the DNS is ultimately managed through a governmental framework.

This was presented to me as a showstopper, on the grounds of government = bogeyman. Personally I'm much more equivocal about the dangers. But I do see DANE as a useful alternative in many circumstances, particularly those where defending against a major government isn't considered a worthwhile aspiration.

Or even better as a trust multiplier or CA-issued certs.

Re: Hypertext Transfer Protocol Version 2

#84

Post by rakoo »

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…

> It looks like just not-invented-here bloat

To me, the real advantage are:

- native multiplexing on a single TCP socket. No more connection pools, no more domain sharding...

- the server is now able to send data at arbitrary moments.

Here's a concrete example: how would you do a webchat ? You need bidirectional communication, potentially initiated by any party. Easy solution: use websockets.

With SPDY/HTTP2, you can use POSTs for sending messages and Server-sent events for receiving messages. You don't need to pool them, you don't need something-over-HTTP like websockets is; you just use standard HTTP semantics.

Re: Hypertext Transfer Protocol Version 2

#85

Post by rakoo »

stephenr wrote: post #25
diafygi wrote: post #12

Earlier quoted context omitted.

Alternative? Non-https is really harmful to users who browse via open wifi.

can be really harmful, in some applications I don't need to know that my connection to lol cats is secure and uninterrupted.

Do you want your location along with your credentials to your lol cats forum in the wild ?

Depending on what site you're going to, you can be screwed pretty easily.

Re: Hypertext Transfer Protocol Version 2

#86

Post by M2Ys4U »

AlyssaRowan wrote: post #63
bkeroack wrote: post #3

So TLS still isn't mandatory? Seems like a missed opportunity.

That's something the browsers are going to deal with. Chrome and Firefox have explicitly said they'll require HTTP/2 over TLS, full-stop. The big pushbacks came mostly from middlebox-makers, proxies and the like. Unsurprising. The market will decide. I'm sure the remaining browsers will make their own decisions, and I expect Opera and IE to fall on the TLS side, and then the decision will be effectively made. The TLS…

IIRC, Microsoft has already stated that IE will support unencrypted HTTP/2.

Re: Hypertext Transfer Protocol Version 2

#87

Post by sjwright »

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?

Here's one extremely important use-case for #2: router/server admin interfaces. For most people it's out of the question to deal with certificates here, but the advantages of end-to-end encryption are still obvious.

That's just one example, of course. There are countless others.

#3 can't be spun up on an ad-hoc basis. It requires a domain name and a signed certificate. This costs time and/or money, and simply isn't feasible for the smallest websites.

#2 can allow the most simple web server instance created in five minutes to be guarded against passive snooping by governments and hackers.

Re: Hypertext Transfer Protocol Version 2

#88

Post by [deleted] »

lucaspiller wrote: post #56
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, #…

Is encrypted-untrusted really a good idea? MITM attacks over wifi are nearly as easy as cookie sniffing. What sort of sites would fit into this category?

[deleted]

Re: Hypertext Transfer Protocol Version 2

#89

Post by stephenr »

rakoo wrote: post #85
stephenr wrote: post #25

Earlier quoted context omitted.

can be really harmful, in some applications I don't need to know that my connection to lol cats is secure and uninterrupted.

Do you want your location along with your credentials to your lol cats forum in the wild ? Depending on what site you're going to, you can be screwed pretty easily.

I didn't mention credentials. Plenty of web use is anonymous, and has 0 need for SSL/TLS

Re: Hypertext Transfer Protocol Version 2

#90

Post by stephenr »

harshreality wrote: post #46
stephenr wrote: post #25

Earlier quoted context omitted.

can be really harmful, in some applications I don't need to know that my connection to lol cats is secure and uninterrupted.

Let's assume a simple video site and html5 video. Do you want to bet there are no vulnerabilities in your browser's mp4/vp8 decoder? If there are, anyone can MITM your non-SSL connection and compromise the video decoding process, limited only by their cleverness and by whatever sandboxing your browser employs.

Why does it have to be video?

Some of the simplest sites around are plain text or text and images. Why do I need SSL or TLS to view either of these?

I am very aware that anything authenticated should be carried over an encrypted connection - I'm not arguing against that. I'm saying there are use-cases that do not require it.

Post reply on HN