Hypertext Transfer Protocol Version 2 | Hacker News Reader

Hypertext Transfer Protocol Version 2

tools.ietf.org

99 pointsyoavz109 comments

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, #2 isn't a viable option, because HTTPS servers with self-signed certificates are correctly treated as dangerous. A URL that designates the HTTPS protocol must always require a trusted connection.

The solution is (relatively) simple: HTTP 2.0 should allow encrypted-untrusted connections for URLs designated with the HTTP protocol.

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

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.

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.

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.

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.

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

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

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.

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?

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 verification on the level of https.

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

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.

MITM isn't the only threat to Internet users. I can see three levels of security, each of which provides more security for users but less convenience for server operators:

1. Opportunistic encryption without certificates or identity pinning -- protects against dragnet surveillance and packet sniffing, but not MITM.

2. Encryption with pinned self-signed certs -- protects against second connection MITM, but not stolen certs without some revocation design.

3. Encryption and identity verification with CA- or WoT-signed certs -- protects against first connection MITM except by powerful adversaries.

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.

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

that sounds less possible than free certificates.

I completely agree, but what of the trouble of getting certificates? I have a hard time figuring out who to trust - the cheaper providers seem scammy and the expensive ones seem to be charging a lot. Self signed certs issue a big fat warning that deters users.

The cheaper ones aren't scammy - quite frankly it is the expensive ones that are the scammy ones!

I have used cheapssl.com (now ssls.com) for a number of years, probably a total of 20 sites, without a single issue.

That being said, namecheap or gandi.net also both offer reasonable priced certs.

Just so you are aware, if you think the $1,000,000 insurance policy offered with the more expensive providers is worth _anything_, be sure to read the fine print first.

The only potential more expensive thing of value is buying an EV cert to get the green URL bar - not that it actually provides even a little bit more protection, it doesn't - but because users see them and have been conditioned to immediately associate it with trust.

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.

Currently on the front page is an article[1] about Russian malware pen testing for SQL injection. Your attack surface increases dramatically when you have valid session cookies.

A good example of this is reddit, that is not https for logged in users with write ability (and thus PostgreSQL write ability). If you have malware that sniffs public wifi traffic for reddit session cookies, you can easily start to test all those write calls for exploits.

[1] - http://www.nytimes.com/2014/08/06/technology/russian-gang-sa...

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

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.

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

Yes there are other vulnerabilities, but that's not a reason to fail protect against this one (taking that reasoning to an extreme, all security is pointless because there always are other vulnerabilities). The purpose of security is to increase the cost of a successful attack; https has a high ROI in many cases. In the example you give, spear-phishing is much more expensive than sniffing wifi.

This particular devil needs no advocate; the risks of coffee shop MITM and dragnet surveillance are too great to ignore.

There isn't?

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.

This is now called opportunistic encryption: http://tools.ietf.org/html/draft-nottingham-http2-encryption...

STARTTLS mixes concerns in a very bad way and is a horrible hack. Let it die with FTP and SMTP.

Really, TLS should just be a mandatory part of the protocol. I haven't read any convincing reason why it isn't, other than vague hand-waving, eg, "we're just a standards body and can't enforce policy".

Faced with a choice of obtaining a TLS certificate or just going for the old HTTP/1.x protocol, it'd be a hard sell for HTTP/2 for any one-off, quick hack experiment/microsite/internal APIs...

The problem is browsers are mostly lousy at giving a good user experience with self-signed certificates. 99% of the time, self-signed doesn't matter except if the certificate changes unexpectedly - i.e. the service just isn't that important.

The 1% of sites it does matter for are things like banks and the like, where you need to hammer into users heads that certificates should be valid via other means.

Of course, it's casually accepted that it's a-ok for companies to MitM their employees encrypted connections anyway, so I don't really know where that leaves us.

What's this about the death of SMTP?

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.

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.

Well, websites that don't use sessions or cookies can still work harmlessly, right?

For context, this is the really-almost-final draft of HTTP/2. I would say speak now or forever hold your peace, but it's even too late for that.

The best description of this protocol I have seen is "TCP over TCP."

I wonder if most of the mileage here could be gained by simply augmenting javascript's networking capabilities, enabling the use of non-HTTP servers (and keeping the HTTP protocol simple).

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 cultism because these people superficially know security buzz-concepts but do not understand them deeply. The application of security concepts in this superficial way does tremendous harm, not to mention creating a false sense of security among the cargo cultists and their followers.

So we engage in an arms race with ourselves. We block everything, then design protocols to tunnel through our firewalls to reenable all the things we blocked, then repeat.

SSH is another penultimate tcp over tcp protocol.

The only real solution to the security problems these hacks fix is to fix operating system app and privilege isolation. But that's more work so let's just break IP with firewalls and then pretend it secures us.

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.

It's hard to beat the browser when it comes to building adequate software on a budget. It will never beat a native app in a race to be the best, but most software is about "making it work" instead of being #1 in the app store. The latter case of course gets a lot more press.

You say that as if cross platform development was easy.*

* (without cheating and effectively embedding a browser engine in your application.)

HTTP is really good at being a generic RPC protocol, what with proxy support and authentication and caching and content negotiation and automatic redirects and chunked streaming and etc. etc. ad infinitum. This, and not the fact that web browsers use it, is why people implement their service APIs in HTTP.

When you give a developer a websocket/WebRTC data channel/etc. and tell them to do RPC over it as a "lower-overhead alternative to HTTP", you inevitably get badly-greenspun (and almost never actually-lower-overhead) HTTP. Making HTTP itself lower-overhead is the best decision in the medium-term.

(In the long term, an HTTP-compatible RPC protocol that runs directly over SCTP+DTLS would be pretty cool, though.)

I'd say "HTTP over SCTP over TLS over TCP."

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

Mark Nottingham, who's chairing the working group, and has been at this stuff for a while, has a blog post about this: https://www.mnot.net/blog/2014/01/04/strengthening_http_a_pe...

Chrome and Firefox will still insist on TLS for HTTP/2. In addition, the HTTP/2 spec does mandate that any implementation must support TLS 1.2 and up, and it must support forward secret ciphersuites.

http://http2.github.io/http2-spec/#TLSUsage

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

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

That's "under review"...

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 "encryption disabled" makes perfect sense, but you definitely should be able to turn it off for content where it doesn't matter.

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.

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.

Try using SSH for big file transfers. Oh right - you don't - because the throughput is CPU limited by the encryption. Multithread it? Sure, now watch as your 8 core machine peaks pushing a gigabit of encrypted data which is actually just an image file of a movie you already have. You encrypt credentials (because they grant access) and sensitive data - like bank details. You don't encrypt the legal rips of movies you have streaming over your network because hey, that would be a complete waste of energy and processing power for literally zero-benefit.

Always on encryption is pointless and the type of always on encryption with HTTP 2 people talk about is worse then pointless. The idea that MitM is difficult is a farce - any number of WPS hijacking techniques involve forcing the host offline temporarily so it has to re-authenticate. The same thing would apply here. Taking what, 2 seconds?

You talk about defense in depth - one aspect of that is that a leaking side-channel has finite bandwidth and can't possibly hope to capture "all the data" which means it has to try and capture important data.

what if you want to roll your own encryption layer?

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.

In HTTP terms a reverse proxy is just a Web server (what it does internally is its own business), not a proxy. HTTP/2 load balancers have no trouble terminating TLS.

If you disagree with PHK, you have to refute the details in his notes, not just wave them away. That they can be made to work does not mean there is not a problem.

PHK keeps calling for radical changes to HTTP semantics which other people don't have the stomach for and would take a decade to deploy even if they did. In some sense, getting HTTP/2 done quickly clears the field for people like PHK to start on HTTP/3 sooner.

Not entirely true. PHK outlines some specific issues with HTTP/2 that makes a load balancer's job harder and/or less performant.

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/

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.

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

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.

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

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

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

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

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

Certificates are absolutely not required to have useful opportunistic encryption.

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

>Alternative?

There exist several semi-viable alternatives at the moment. The most promising is Namecoin, which essentially allows for cryptographically authenticated public key/value storage, and so can function as both a DNS system and a system for announcing SSL pubkeys (without any trusted parties).

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.

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

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

Again, why does it matter if you or Barack Obama or Kimg Jung Un knows that I like looking at Captain Picard meme pictures? How can you tell me that REQUIRES an encrypted connection?

You know what might actually make some fucking sense. Enforce SSL/TLS where it is needed - disable HTTP Auth, Cookies, Location Services, Local Storage, etc over plain HTTP connections.

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

You don't need credentials to be identified, your browser can be identified quite accurately (see https://panopticlick.eff.org/).

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

Well I'm glad you're able to miss the fucking point with such efficiency

Anyone have a link to a overview type blog post of the changes? This is a tad foreign for a guy like me who has little experience of this layer of the OSI model.

http://queue.acm.org/detail.cfm?id=2555617

https://www.mnot.net/blog/2014/01/30/http2_expectations

https://www.mnot.net/talks/http2-wtf/#/

very cool, thank you wmf that first one did the trick! I really can't beleive how hacked together / behind the original specification is compared to 2.

So what exactly is from HTTP2 to SPDY except for the TLS encryption?

"Expires: January 31, 2015" - What does it mean?

All Internet-drafts "expire" because they're intended to be work-in-progress documents that should either be updated to a new draft, finalized into an RFC, or abandoned. In this case, HTTP/2 will become an RFC long before January.

Reply on news.ycombinator.com