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

51–60 of 113 posts

Re: Hypertext Transfer Protocol Version 2

#51

Post by rurounijones »

kaoD wrote: post #42
nitrogen wrote: post #36

Earlier quoted context omitted.

Opportunistic encryption of all sessions doesn't require any certificates. All that's needed is a key exchange algorithm and browser support. The UI would make it clear when a certificate was presented and validated, but no cert is needed for unauthenticated encrypted connections. The next step up from that would be unsigned public keys with pinning (like ssh) to reduce MITM, and finally above that would be identity…

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

Re: Hypertext Transfer Protocol Version 2

#52

Post by michaelsbradley »

ChikkaChiChi wrote: post #47

Is there any particular reason why more work isn't being done on developing new protocols? It seems like given the past 20 years of the web there is clearly a need of a presentation protocol, a stateful application protocol, and a stateless application protocol. Seems like it makes more sense to separate them.

OPC UA is a relatively new standard worth a look for those in the market for a stateful application protocol that provides both an information model and transport layer. One downside is that, presently, only member organizations of the OPC Foundation are given full access to the specifications and reference implementations. Membership is certainly affordable, but interest and adoption might be accelerated if the specs and reference clients/servers were publicly accessible. Perhaps if the Foundation received enough enthusiastic inquiries they might change their policy in that regard.

http://en.wikipedia.org/wiki/OPC_Unified_Architecture

https://opcfoundation.org/about/opc-technologies/opc-ua/

Re: Hypertext Transfer Protocol Version 2

#53

Post by woah »

peterwwillis wrote: post #27
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.

Devil's Advocate: there is no world wide cabal of wifi hackers trying to steal the Facebook login cookies of starbucks customers. The lack of security is real, but the dangers are overblown.

There isn't?

Re: Hypertext Transfer Protocol Version 2

#55

Post by hackuser »

peterwwillis wrote: post #27
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.

Devil's Advocate: there is no world wide cabal of wifi hackers trying to steal the Facebook login cookies of starbucks customers. The lack of security is real, but the dangers are overblown.

> Devil's Advocate: there is no world wide cabal of wifi hackers trying to steal the Facebook login cookies of starbucks customers. The lack of security is real, but the dangers are overblown.

Perhaps not, but consider for example that the Starbucks near people with valuable IP (e.g., many Starbucks in Silicon Valley, in NYC, in Washington DC, in Redmond WA, in Cambridge MA, in Beverly Hills, in the Hamptons, etc.) would be valuable targets.

Re: Hypertext Transfer Protocol Version 2

#56

Post by lucaspiller »

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

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?

Re: Hypertext Transfer Protocol Version 2

#57

Post by AlyssaRowan »

lazyloop wrote: post #31
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.

For this to work we need free certificates. Many still keep referring to StartSSL, but there you just pay double later on in revocation fees. https://www.startssl.com/?app=43

No: DANE TLSA.

https://tools.ietf.org/html/rfc6698

What, your domain doesn't have DNSSEC because your registrar doesn't offer it? It'll have to have the opportunity to next year, if they want to renew their contract with ICANN...

Re: Hypertext Transfer Protocol Version 2

#58

Post by mappu »

lazyloop wrote: post #31
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.

For this to work we need free certificates. Many still keep referring to StartSSL, but there you just pay double later on in revocation fees. https://www.startssl.com/?app=43

Everyone says that, but revocation doesn't even work anyway.

- Any time a certificate could be impersonated by an attacker, the attacker is also able to block a revocation check.

- Live revocation checks (A) kill performance, and (B) leak information as a side-channel.

- You could solve this by predownloading every single revocation ever. But that is massive (infeasible for mobile), never going to be up to date, and leaks information about private domains.

See Adam Langley's blog for more about OCSP vs CRLsets.

Re: Hypertext Transfer Protocol Version 2

#59

Post by AlyssaRowan »

girvo wrote: post #44
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.

I was going through that article after you posted it... is BREACH still an exploit in the wild? Turning off compression altogether seems painful :/

Well, the exploit doesn't just go away.

Any context compressor could introduce the same hole if attacker-provided and sensitive data share contexts.

Specific countermeasures include salting your anti-CSRF tokens (so make sure they're not consistent but differ on every page load!).

Re: Hypertext Transfer Protocol Version 2

#60

Post by AlyssaRowan »

XorNot wrote: post #24
Mandatum wrote: post #4

Earlier quoted context omitted.

I agree encryption is something that should be mandatory, but you can't pin down an encryption algo to be used by HTTP/2 without allowing for future changes..

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.

Post reply on HN