Live data from Hacker News

Hypertext Transfer Protocol Version 2

tools.ietf.org

91–100 of 113 posts

Re: Hypertext Transfer Protocol Version 2

#91
post #37
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.

> How can you (or an 'average user' whoever that might be) carefully evaluate untrusted certificates?

Well, you decide whether you want to trust the person on the certificate, and if the security ever changes again that'd be the red flag. Initial trust is always difficult.

Re: Hypertext Transfer Protocol Version 2

#93
post #84

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…

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

I actually agree with you for the most part. Google wants with HTTP2/SPDY to foster an internet based on highly stateful applications, the web as a remote GUI to their servers, rather than mostly stateless documents as it has been. I don't see this as an improvement.

Re: Hypertext Transfer Protocol Version 2

#94
post #86

Earlier quoted context omitted.

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.

That's "under review"...

Re: Hypertext Transfer Protocol Version 2

#95

Earlier quoted context omitted.

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 agains…

Jurisdiction is a complex question, and one I can't answer, but people should think about the jurisdictional consequences of using ccTLDs in particular. You are at the mercy of whomever's higher in the DNS hierarchy - that's why the root control is such a big deal and needs to come out of the US into some sort of non-governmental or international treaty org.

However, certainly DANE 2 & 3 are way better than nothing, and DANE 0 & 1 let you limit the subset of "people who can spoof your site" from "people who have pwned any CA they want trusted by a major browser, including intermediates" (do we even know how many intermediates are out there? Answer: No, we don't!! It's an open research question to scan to try to find out: please save us, Certificate Transparency!) to "people who have pwned the correct CA, or the government with the most obvious jurisdiction over my site".

If that isn't enough for you, and I can understand why it may not, then you need to be considering using Tor or something similar to meet your threat model...

Re: Hypertext Transfer Protocol Version 2

#96

Earlier quoted context omitted.

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.

Because otherwise nation-state adversaries can see everything you read.

IETF position on this is pretty clear after the technical plenary last year.

Re: Hypertext Transfer Protocol Version 2

#97
post #85

Earlier quoted context omitted.

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

Counterexample: If you want it to be anonymous, you need TLS (and Tor!).

Re: Hypertext Transfer Protocol Version 2

#98
post #78

Earlier quoted context omitted.

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…

Considering that your local network is trusted defies "defense in depth" - do you use Telnet for your admin? What happens with your Wifi, or if one of your computers gets pwned and starts becoming a packet-sniffing machine?

Google feel it's potentially sensitive data. After all, it's showing what you're reading, what you're downloading, what you're seeing.

Laptops/desktops are way too big to feel any noticeable effect from modern encryption: that's nonsense, look at the benches. You won't even feel that impact on a Raspberry Pi (actually the VC4 is surprisingly good at some crypto - I'm halfway to a ChaCha implementation on it, if I can just sort out the diagonal round permutation!). TLS 1.2+extensions and 1.3 will have things which make good encryption even faster: the use of fast AEADs like AES-GCM and ChaCha20-Poly1305, and ECDHE using Curve25519, etc. This decision is underpinned by, and supported by, all that work.

If your use case was toasters and 8-bit microcontrollers (as opposed to 16-bit or 32-bit AVR-type ones), then you'd have a discussion, but I've seen efficient Atmega implementations of this, I could probably cook something up for a 68000 myself, and anyone who really fancies a challenge should go for a 6502 or z80 implementation. I'd simply respond that lack of privacy is not costless, and you've really no excuse anymore.

Re: Hypertext Transfer Protocol Version 2

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

Read my final paragraph. You don't have to care about MITM to benefit from opportunistic encryption.

> You don't have to care about MITM to benefit from opportunistic encryption.

How? An encrypted connection subject to MITM is as secure as an non-encrypted one. Attackers will stop listening for plaintext credentials at WiFi spots and will just launch their favorite HTTPS MITM tool instead.

Certificate pinning is flawed because you cannot revoke certificates from your clients. How would you distinguish a MITM attack from a certificate change? And if you can't revoke certificates, what happens after an attacker gains access to the private keys? Definitely flawed model.

HTTPS without identity verification is even worse than HTTP. IMHO a false sense of security is more dangerous than no security. Self-signed certificates must not be advertised as secure by browsers (the famous lock icon) because they are not! This would render them invisible for most users.

Self-signed certificates are only viable for tech-savvy users, and even then the dangers are too many and the burden too heavy (did the server change certs, or am I being subject to a MITM attack?) for them to be useful.

Re: Hypertext Transfer Protocol Version 2

#100

Earlier quoted context omitted.

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

A valuable target will always get hacked because they'll be specifically targeted. For most of them it'll be from spearphishing, but there's a multitude of ways to attack people even if https is the default. All well known celebrity hacks are done either by spearphishing or breaking into an account independent of contact with the person.

And in general it's probably not a good idea to set world-wide standards on the most used high level protocol in the world based on a few rich people who use the net from an unsecure device.

Post reply on HN