[higherpurpose]

I thought the whole point of HTTP2.0 was to make traffic encrypted by default, and not let bit vulnerability holes in the protocol like this. Saying "it just makes it as before" doesn't make me feel better.

Why are we moving to HTTP2.0 otherwise? For a 5 percent increase in speed? The big selling point of HTTP2.0 from my perspective was the "always-on encryption".

[tptacek]

You're referring, I think, to opportunistic encryption. As Brad Hill pointed out yesterday: the security situation with HTTP/2.0 opportunistic encryption is analogous to that of OS X with the SecureTransport TLS validation bug. In neither case is "encryption" any more than cosmetic.

[belorn]

Like running ssh without checking fingerprints is analogous to that of telnet.

I for one used to be thinking like that. I had my A4 paper with all my computers fingerprint in my pocket and painstakingly checked it every time I was at a new computer. In my university, studying in the computer security program, I think I was the single person checking fingerprints. Not even the system administrators did it.

I guess in practice, ssh today is nothing more than cosmetic compared to telnet.

[tptacek]

If you use SSH and ignore key fingerprint warnings then yes, your use of SSH is cosmetic. Competent operators freak out when they get an unexpected key warning.

I don't understand the comparison you're trying to make between SSH and a proposal to transparently MITM a protocol that is designed to be transparently MITM'd. Unless your gripe is that we shouldn't have protocols like that to begin with, in which case I agree, but you should direct your angst to the people who proposed HTTP/2.0 OE, not this proposal.

[belorn]

I have no gripe since I do no longer consider that better-than-nothing security to be bad.

In return for using ssh over telnet, I get security against any passive attack and attacks past first login. Thus the functionality is on a technical basis superior to telnet (except if you use IPsec, then telnet is better than SSH).

A personal question: when you install a new personal laptop or server, do you check the fingerprints of every ssh connection? Do you prune the CA list and remove any entry that you personally can't vouch the trustfulness of? This is after all what SSL require of each user, so it would be interesting to know if a founder of an software security company do this to his own personal equipment.

[tptacek]

No, I copy over my SSH configuration so that I don't need to do that.

[belorn]

How can you securely copy over the configuration? This sound as a chicken and egg problem.

[1stop]

I think the problem is, always on encryption, is always off caching...

[nknighthb]

I call that a feature. I'm way past sick of flakey transparent proxies with bad caching behavior.

[brokenparser]

That's not true, your browser still handles caching just fine. More bandwidth trumps caching anyway, and caching forward proxies will be a thing of the past.

[asabil]

Heh, bandwidth can help, but caching helps primarily with latency.

[brokenparser]

The latency benefits of an extra caching layer are minimal, especially since HTTP pipelining and CDNs will continue to exist.

[Rami114]

Judging from http://hillbrad.typepad.com/blog/2014/02/trusted-proxies-and... it looks like opportunistic encryption is not meant to convey security, but rather add obscurity to in-transit plain-text traffic from the perspective of any in-between listeners (and he has no qualms pointing the finger at governments there).

Sadly he now seems to have changed his mind about the validity of this approach, mostly because users and devs alike dislike complexity in their decision process as to what is secure and what is merely obscured.