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

61–70 of 113 posts

Re: Hypertext Transfer Protocol Version 2

#61

Post by 7952 »

phaer wrote: post #37
duaneb wrote: post #33

Earlier quoted context omitted.

No, I don't think we need free certificates, I think we need people who can carefully evaluate an untrusted certificate and make their own decision. The whole idea of a CA is pretty broken at current scale. Meanwhile, self-signed certificates are seen as a red flag. Should they be?

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.

Re: Hypertext Transfer Protocol Version 2

#62

Post by AlyssaRowan »

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.

Re: Hypertext Transfer Protocol Version 2

#63

Post by AlyssaRowan »

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 WG will watch the result with interest, I'm sure, looking forward into TLS 1.4/2.0/whatever...

Re: Hypertext Transfer Protocol Version 2

#64

Post by AlyssaRowan »

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?

Absolutely everywhere you use HTTP now. It's never worse than plaintext, and it's an effective replacement for it.

Encrypted-untrusted prevents mass passive surveillance, and requires it to be active MITM. And - as I've pointed out on the TLS WG list a few times - if an attacker can't tell you're being opportunistic, they might not be willing to risk being detected. We can make them take that risk by reducing the visible distinguishers there.

Re: Hypertext Transfer Protocol Version 2

#65

Post by AlyssaRowan »

sjwright wrote: post #50
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.

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, #…

Exactly: I believe that's actually the plan from browser-makers, that the "S" designates not whether you want to use encryption, but whether the encryption will be required to be trusted. We'll see what actually happens.

Going forward hopefully TLS 1.3 or a later version will be able to encrypt enough of the exchange that a passive sniffer can't necessarily tell between 2 or 3 - hopefully they won't be able to see the certificate, or there'll be a way to negotiate an anonymous DH as a minimum that an attacker cannot observe (without that in place right now, I've argued against aDH remaining in TLS 1.3).

Re: Hypertext Transfer Protocol Version 2

#66

Post by AlyssaRowan »

api wrote: post #11
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.

At the very least, regular http should support starttls to allow encryption. That at least requires your attacker to go to the trouble of man in the middle.

STARTTLS has risks over and above pure use of TLS - in particular where it's been used in IMAP and POP3, an attacker injecting plaintext commands before STARTTLS/STLS occurs, tricking an early (plaintext) login and other such shenanigans.

This is why the SMTPS port is being resurrected, and STARTTLS-type upgrades are not considered good practice in future - port assignments in future are likely to take that into account.

Re: Hypertext Transfer Protocol Version 2

#67

Post by lucaspiller »

AlyssaRowan wrote: post #64
lucaspiller wrote: post #56

Earlier quoted context omitted.

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?

Absolutely everywhere you use HTTP now. It's never worse than plaintext, and it's an effective replacement for it. Encrypted-untrusted prevents mass passive surveillance, and requires it to be active MITM. And - as I've pointed out on the TLS WG list a few times - if an attacker can't tell you're being opportunistic, they might not be willing to risk being detected. We can make them take that risk by reducing the vis…

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

My question is given that what is the purpose of encrypted-untrusted? It's no more secure than HTTP for anything that uses session cookies or the like. Sure the connection is encrypted, but then all you are doing is stopping people seeing that you are accessing My Little Pony shows on YouTube. If it's a public hotspot at the coffee shop, they can probably see you watching it (IRL) anyway. Given the connection is untrusted, it wouldn't be hard for the NSA to do a MITM attack at the ISP level.

Re: Hypertext Transfer Protocol Version 2

#69

Post by riffraff »

sjwright wrote: post #50
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.

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?

Re: Hypertext Transfer Protocol Version 2

#70

Post by AlyssaRowan »

lucaspiller wrote: post #67
AlyssaRowan wrote: post #64

Earlier quoted context omitted.

Absolutely everywhere you use HTTP now. It's never worse than plaintext, and it's an effective replacement for it. Encrypted-untrusted prevents mass passive surveillance, and requires it to be active MITM. And - as I've pointed out on the TLS WG list a few times - if an attacker can't tell you're being opportunistic, they might not be willing to risk being detected. We can make them take that risk by reducing the vis…

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

Post reply on HN