[saurik]

Wasn't this already discussed on Hacker News, in quite some detail, yesterday? And wasn't the big revelation that this only applied to traffic that was not CA verified and thereby was inherently man-in-the-middle-attackable anyway (as the actually-secure https connections are marked in a way where this feature does not apply), making this a misunderstanding?

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

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

[flipgimble]

It should be discussed as long as its new or interesting to someone so people can form their own opinion of a potentially important security issue. Your statement is suspiciously close to trying force a consensus opinion that there is nothing to see here. While I give you the benefit of the doubt, this type of steering of online discussion that benefits those that would like to weaken internet security. It might help linking to the previous discussion as well.

[saurik]

Given that I summarized the pretty-simple point from the previous conversation, if you really think that's wrong you should say why. The Internet has this core problem that people don't learn from discussions and then keep saying things that are clearly, obviously, and even trivially false, giving emotional weight to ideas that actively harm the understanding of others. I mean: look at yourself... in addition to not responding to the specific factual detail I laid out, you are refusing to even take thirty seconds to find the previous discussion yourself... this is work you should have done before ever coming here to post something on this subject... it is the basic, core due diligence that I would argue is not just a courtesy but a responsibility for those who join online discourse :/. This "you may have said something factual, but damn it I like being angry at people for no reason, so I'm going to ignore what you said and pull the 'you are trying to steer the conversation' card" is ridiculous... facts should steer conversations :(.

[tptacek]

Yes.

[nitrogen]

A possible objection to the proposal is that those who opt not to use "trusted" proxies will be making themselves more visible, like users of Tor are more visible.