2,337 karma · joined June 15, 2010
Either all MiTM needs to be outlawed (with actual laws) or protocols need to recognize that laws mandate MiTM some places, and accommodate that with minimal loss of security and privacy.
The current weapons race just makes things more and more broken.
Have your forgotten (or maybe never seen ?) CNN's traffic graph from 9/11 ?
Experience so far is that emergency services web-pages tend to die the instant they are most needed. Addint TLS will just make that happen even more.
If you want to change that, vote.
Very few lawmakers have really tried, and few technologies have been worth it in the first place.
The relevant question is probably if technology can be delayed by lawmaking and how long time.
There is no doubt however that policies can be changed, most places it just takes elections but a few places may need a revolution.
Thinking this is a problem you can solve by rolling out SSL or TLS is incredibly naive.
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.
In the meantime we should not cripple our protocols, hoping that the NSA will go "aahh shucks!" and close shop, when the law clearly tells them to "Collect everything."
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.
There are many ways to break SSL, the easiest, cheapest and most in tune with the present progression towards police-states is to legislate key-escrow.
Google "al gore clipper chip" if you don't think that is a real risk.
Instead of all the servers dumping cookies on you, you send a session-id to them, for instance 127 random bits.
In front of those you send a zero bit, if you are fine with the server tracking you, and you save the random number so you send the same one every time you talk to that server. This works just like a cookie.
If you feel like you want a new session, you can pick a new number and send that instead, and the server will treat that as a new (or just different!) session.
If instead you send a one bit in front of the 127 random bits, you tell the server that once you consider this "session" over, and that you do not want them to track you.
Of course this can be abused, but not nearly as much as cookies are abused today.
But it has the very important property, that all requests get a single fixed size field to replace all the cookies we drag across the net these days.
Because I think that we can do much better than the pile of IT-shit we have produced until now.
I am actively trying to do that, through my own code, through the articles that I write and through the discussions I engage in.
Not everybody has the luxury of doing that -- the kids have to be fed and the mortgage has to be paid and a job is a job -- but those of us who can, have an obligation to try to make the world a better place, by raising quality if IT.
Try this one, it's better, but not perfect:
Imagine what happened if some cheap invention turned all buildings into inpenetrable fortresses unless you had a key for the lock.
Now police can not execute a valid judge-sanctioned search warrant.
How long time do you think lawmakers will take to react ?
Instead you will see key-escrow laws or even bans on encryption.
You cannot solve the political problem by applying encryption.
With a self-signed cert they would have to do a Man In The Middle attack on you to see your traffic.
They don't have the capacity (or ability! man of their fibertaps are passive) to do that to all the traffic at all the time.
The problem with making a CA-blessed cert a requirement for all or even most of the traffic, is that it forces the NSA to break SSL/TLS or CAs definitively, otherwise they cannot do their job.
Fundamentally this is a political problem, just slapping encryption on traffic will not solve it.
But it can shift the economy of the situation -- but you should think carefully what way you shift it.
Today they can grep plaintext as they want. With SSC's they would have to pinpoint what communication they really need to see.
That would be a major and totally free improvement in privacy for everybody.
As for why the browsers so consistently treat SSC's as ebola: I'm pretty sure NSA made that happen -- they would be stupid not to do so.
I'm arguing against making SSL mandatory, because that will force NSA to break it so they can do their work, and then we will have nothing to protect our privacy.
More encryption is not a solution to a political problem: http://queue.acm.org/detail.cfm?id=2508864
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.
FaceBook, Twitter etc. track you all over the internet with their cookies, even if you don't have an account with them, whenever a site puts up one of their icons for you to press "like".
With client controlled session identifies, uses would get to choose if they wanted that.
The reason YC gets by with 22 bytes is probably that they're not trying to turn the details of your life into their product.
The difference between you and me, may be that I have spent a lot of time measuring computers power usage doing all sorts of things. You seem to be mostly guessing ?
My big problem with HTTP/2 is that it's crap that doesn't solve any of the big problems.
CA's are trojaned, that's documented over and over by bogus certs in the wild, so in practice you have no authentication when it comes down to it.
Authentication is probably the hardest thing for us, as citizens to get, because all the intelligence agencies of the world will attempt to trojan it.
Secrecy on the other hand, we can have that trivially with self-signed certs, but for some reason browsers treat those as if they were carriers of Ebola.
You seem confused about cryptography.
Against NSA we only need secrecy, privacy is not required.
Likewise integrity does not require secrecy, but authentication (which doesn't require secrecy either).
You don't think that anybody can figure out what you are doing when you open a TCP connection to queue.acm.org right after they posted a new article, even if that connection is encrypted ? Really ? How stupid do you think NSA is ?
Have you never heard of meta-data collection ?
And if you like your encrypted connections so much, you should review at the certs built into your browser: That's who you trust.
I'll argue that's not materially better than unencrypted HTTP.
(See also Operation Orchestra, I don't think you perceive the scale of what NSA is doing)
You could look at section 15 here for instance: http://phk.freebsd.dk/words/httpbis.html
With respect to key-exchange, maybe the problem is that I do understand, and therefore know that there is a difference between privacy and secrecy ?
Some places we want privacy, some places we want secrecy.
Mandating privacy everywhere makes it almost mandatory for police-states to trojan the privacy infrastructure (ie: CA's -- yes they already did), and therefore we have neither privacy nor secrecy anymore.
PS: Dangerous for who ?
PPS": Google "Operation Orchestra" if you don't undstand the previous question.
If the IETF wanted a fresh look at HTTP, they would not have set such a short deadline for submissions.
It was evident from the start that this was about gold-plating & rubber-stamping SPDY, and people saw that and said so, already back then.
HTTP/2 isn't compatible with SPDY any more, but there is no significant difference between them, only a few deck-chairs were arranged differently in HTTP/2
The fact that people spend ages chewing the cud on a "clarification" of HTTP/1.1 has no impact on how long time it would take to define a HTTP/2 protocol.
Quite the contrary, HTTP/2 was a chance to jettison many of the horrors and mistakes that made the HTTP1.1bis effort so maddening.
You can see some of my thinking about what HTTP/2 should have been doing here:
Poul-Henning
All the ones I've looked at are shitty source code.