Comment by phkamp | Hacker News Reader

Comment by phkamp | Hacker News Reader

Parent Full thread

No, this is actually a very important point for me.

If HTTP/2.0 had done this right, there wouldn't be a need for your employer to trojan your CA list so they can check for "inappropriate content" going either way through their firewall. (Under various laws they may be legally mandated to do so, flight controllers, financial traders etc.)

But because HTTP/2.0 was more about $BIGSITEs unfettered access to their users, no mechanism was provided for such legally mandated M-I-T-M, and therefore the CA-system will be trojaned by even more people, resulting in even less security for these users.

Likewise, pushing a lot of traffic which doesn't really need it onto SSL/TLS will only force NSA and others to trojan the CA-system even harder, otherwise they cannot do the job the law says they should do.

As I've said earlier: Just mindlessly slapping encryption on traffic will not solve political problems but is likely to make them much worse.

See for instance various "Law Enforcement" types calling for laws to ban encryption or Englands existing law that basically allow them to jail you until you decrypt whatever they want you to decrypt (never mind if you actually can or not...)

Edit to add:

The point about $BIGSITE is that everybody hates it when Hotels, ISPs and Phone companies modifies the content to insert adds etc. Rightfully so.

Any proxy which does not faithfully pass content should be forced to need the clients accept for its actions.

But since such proxies are legal and in some cases legally mandated some places (smut filters in libraries & schools, filters in jails. Parental controls at home, "compliance gateways" at companies) trying to make them impossible with the protocol just means that the protocol will be broken.

I think the big point that a lot of people are raising, however, is that a "proxy which does not faithfully pass content" shouldn't be legal in the first place. Users don't want network operators to be snooping on them if they can avoid it. The fact that such behaviors are formally legal now does not mean that we (i.e. internet users as a whole) should just lay on our backs and let $BIGSITE have its way with us.

In fact, the uses of proxies that you seem to be pointing out as examples of why ubiquitous encryption is a "bad thing" - such as those in schools, homes, workplaces, etc. to block "objectionable content" - would probably be better handled by blocking IP addresses or domain names, rather than trying to break into encrypted HTTP sessions, would it not? Last I checked, TLS does not prevent the ability to detect when a user agent attempts to access a particular host (whether by IP address or domain name), thus allowing $BIGSITE to close off access to blacklisted or non-whitelisted hosts without needing to know the exact data being exchanged.

Honestly, and with all due respect, the idea that ubiquitous use of TLS would in any way, shape, or form stifle $BIGSITE's ability to monitor and block attempts to access "objectionable" sites seems absurd when there are plenty of more effective ways to do such things that don't involve a total compromise of privacy or secrecy.

You are welcome to that opinion, take it up with your lawmakers, vote based on it, or run for office yourself to make it reality.

Just don't think you will make such proxies disappear with technical means -- in particular not where they are mandated by law.

I fully agree with you when we're talking about people trying to make money by modifying 3rd party traffic.

But I leave it to the relevant legislatures (and their electorates!) to decide with respect to libraries, schools, prisons, financial traders, spies, police offices and so on.

With respect to HTTP/2 there were two choices:

1) Try to use the protocol to force a particular political agenda through.

2) Make the protocol such that people behind manipulating proxies have notice that this is so, and leave the question of which proxies whould be there to the political systems.

Implementing policy with protocols or standardisation has never worked and it won't work this time either.

At the end of the day: IETF has no army, NSA is part of one.

Fair enough. My point, however, was that an always-encrypted internet protocol would not prevent the legitimate uses of these proxies - namely, the monitoring and blocking of attempts to access particular hosts on a network - from being possible; any competent network administrator could implement filters on particular network addresses and hostnames without needing to decrypt anything in the application and transport layers, since they're operating beneath those layers in the first place (perhaps from the router/firewall, even; I'm willing to bet that such monitoring/blocking would be relatively trivial to implement as a pf ruleset, using tables for blacklisted or whitelisted hosts) or are otherwise able to view information beyond what's encrypted (such as DNS lookups). That seems to be much easier and more surefire than trying to break into TLS sessions.

I'm not 100% certain I understand your position, so I'll attempt to restate it in my own words. Please correct me if I'm wrong. The TLS requirement in HTTP 2.0 is objectionable on the grounds that it makes filtering/monitoring difficult or impossible. This is a problem because in some places the filtering/monitoring is legally mandated and in some others merely legal. It would also aid these intermediaries if the opening stanza of the HTTP request were sent unencrypted.

To that, I disagree. On a practical level, many sites are already encrypted with TLS, especially the $BIGSITEs, so intermediaries that want to MITM their subordinates already must compromise their hosts. No browser is likely to ship an update that would regress on the privacy guarantees of traffic on the wire in this way.

On an ideological level I believe that it is better to err on the side of making information available to those who want it rather than empowering those who wish to censor and monitor access of information. I would also add that the RFCs issued by the IETF have historically been ideologically aligned with free and unimpeded access to information, and have more frequently treated censorship and monitoring as attacks to defend against rather than use cases to fulfill.

> If HTTP/2.0 had done this right

Is "right" in your opinion keeping SSL/TLS optional as it is today? Don't we already have the same concerns (legal obligation to MITM HTTPS connections)?

> no mechanism was provided for such legally mandated M-I-T-M

Maybe this is what you meant by doing it "right". How would this look? I'm having trouble imagining how such a mechanism could be securely built into HTTP.

It's certainly not a trivial thing to design, but the "GET https://..." proposal floating around solves a lot of the relatively benign cases (company/school smut-proxies etc.)

My point is that HTTP/2 didn't even try, because the political agenda for a lot of people were more or less "death to all client side proxies".

They're entitled to that opinion of course, but given that laws in various countries say the exact opposite, the only thing they achieve by not making space for it in the security model is that the security model will be broken.

> But because HTTP/2.0 was more about $BIGSITEs unfettered access to their users

Can you explain the link from required SSL to this point? I'm not seeing it...don't they already have unfettered access?

Reply on news.ycombinator.com