There needs to be an RFC for Postcard Key Encryption - send each other public keys on hand-written postcards to single-use P.O. boxes to avoid mitm of the initial key exchange. I don't understand why anyone trusts CAs any more.
[deleted]
A Saudi Arabia Telecom's Surveillance Pitch
21–30 of 115 posts
Re: A Saudi Arabia Telecom's Surveillance Pitch
#22Earlier quoted context omitted.
> Nobody trusts CAs. No. The problem is that pretty much everyone trusts them, at this point in time. That was Peter's point. Sure, there are researchers and engineers who rightfully don't trust CAs. But we don't really matter. The users, the consumers, the parents, the grandparents, the activists do.
I am not sure what the point of this comment is. What conclusion do you come to as a result of this "everyone trusts CA" belief that is different from mine?
The point I'm trying to make is that the CA trust problem has been known for quite a long time now (although it's only recently arrived in the hivemind).
Sure, there's a lot of research being done to find the Next Great Thing (tm), but how about a short/mid-term emphasis on shoring up the glaring problems in the existing technologies first? Tighten the number of default CAs, shore up bad SSL and TLS code, tighten default settings in client software.
Things like Chrome popping up warnings about self-signed, expired, or invalid certs may have been a great start, but nobody's really tidying up much on the server end, so the end effect is that the users blindly click through the Chrome warnings.
TL;DR: The Next Big Thing (tm) is going to be great, I'm sure, but how about fixing/tightening existing configurations in the mean time?
Re: A Saudi Arabia Telecom's Surveillance Pitch
#23Earlier quoted context omitted.
I am not sure what the point of this comment is. What conclusion do you come to as a result of this "everyone trusts CA" belief that is different from mine?
The point I'm trying to make is that the CA trust problem has been known for quite a long time now (although it's only recently arrived in the hivemind). Sure, there's a lot of research being done to find the Next Great Thing (tm), but how about a short/mid-term emphasis on shoring up the glaring problems in the existing technologies first? Tighten the number of default CAs, shore up bad SSL and TLS code, tighten def…
You and I are saying exactly the same thing. TACK, for instance, doesn't replace the CA system; it creates a vehicle by which browsers can pin certificates on the fly, the way Chrome already pins certificates for certain web properties, which creates a key-continuity system without changing browser UI or the protocol as it is run between browsers and servers.
You and I might also agree: browsers make it too easy to click through the bad-cert warnings. It used to be a trendy thing to argue on HN that these warnings were entirely pointless and should be done away with, which, of course, would have done grievous harm to security above the harm already done by the click- click-click- you're- done UX browsers have already established here.
Re: A Saudi Arabia Telecom's Surveillance Pitch
#24This stuff happens more than anyone in infosec wants to admit; it's (ironically) what got me into professional software security to begin with, after being upset by what a commercial network monitoring tool would have allowed us to do to our customers at an ISP I helped run. It's especially funny to see a government sponsored telecom reaching out to Moxie Marlinspike. Also: this isn't like that time a random Microsof…
In this case I was mostly referring to the inclusion of certificate pinning (ex: https://github.com/moxie0/AndroidPinning) in the mobile apps, which would theoretically prevent them from using a UAE or Saudi controlled CA to do the interception. In addition to iOS and Android, we also refused to compromise with low-end platforms like MediaTek, and made sure those clients were also all-TLS and that they employed certificate pinning. We also did common sense stuff like including assertions in all the platforms that would prevent accidental HTTP leakage.
More generally, a lot of common sense effort was put into the general TLS posture of the website. From certificate pinning baked into the browsers, to HSTS headers, to making sure the links in search results are https.
There was a bunch of generally nice TLS stuff in the pipe as well, but I'm not sure if it shipped yet.
Re: A Saudi Arabia Telecom's Surveillance Pitch
#25"... insecurity predominately tended to be leveraged by a class of people that I generally liked against a class of people that I generally disliked..."
This, this, a thousand times this. We cannot look the other way because the "good guys" are benefiting. Not any more.
The person that reads an article about the USA implementing some automated service to monitor foreign communication must realize that other governments are now doing the exact same thing. We no longer have the luxury of pretending that as long as the outcome is good the means do not matter.
Re: A Saudi Arabia Telecom's Surveillance Pitch
#26The reality is that they will eventually find a company or five that will do exactly what they asked. Thanks to their checkbook. Moxie: Do not go to Saudi Arabia, you are probably persona non-grata by now.
The persona non-grata status isn't limited to the .sa region -- he will likely feel retaliatory measures implemented against him from within the safety of the West.
Re: A Saudi Arabia Telecom's Surveillance Pitch
#27I'm very curious what aspect of Twitter's TLS code makes hard to intercept whereas other websites can be easily intercepted? I'm also very curious about how they intercepted Whatsapp. Does it do something stupid like eval'ing code received over regular HTTP? Quoting the paragraph, in case my paraphrasing is inaccurate: "What’s depressing is that I could have easily helped them intercept basically all of the traffic t…
WhatsApp doesn't use TLS, and their protocol has a fairly long history of criticism.
Re: A Saudi Arabia Telecom's Surveillance Pitch
#28> TextSecure and RedPhone could serve as appropriate secure replacements sadly those are only available for Android.
[deleted]
Re: A Saudi Arabia Telecom's Surveillance Pitch
#29There needs to be an RFC for Postcard Key Encryption - send each other public keys on hand-written postcards to single-use P.O. boxes to avoid mitm of the initial key exchange. I don't understand why anyone trusts CAs any more.
Nobody trusts CAs. There is a lot of work being done on layering more trustworthy authentication features on top of the TLS CA system, one good one being TACK: http://tack.io/draft.html The problem with simply abandoning CAs is that it creates a situation in which it's even easier for government sponsored agencies to mass-intercept traffic, at least for a window of time (probably several years), and all that window b…
So, even though the government can snoop on us, we shouldn't stop using CAs, because then the government could snoop on us.
With TACK you depend on CAs to establish the initial connection, set up a "pin", and then no longer rely on the CA for future connections. That initial connection is fungible by a MITM, so it's not secure. We need a term for connections that are "probably" secure, but for which there is no complete assurance of security, which is what any connection based around a CA really is.
This is why the postcard method is superior. Unless someone spends the time to intercept every anonymous postcard with a secret code on it, rewrite the message with perfect imitation handwriting, and send it on to the unknown P.O. box, without more than a couple days delay, it's next to impossible to circumvent this initial key exchange. For those that need real privacy I would recommend this method; for those that just want to order Jolt Cola on an open wifi connection, CAs are good enough.
Re: A Saudi Arabia Telecom's Surveillance Pitch
#30Earlier quoted context omitted.
Nobody trusts CAs. There is a lot of work being done on layering more trustworthy authentication features on top of the TLS CA system, one good one being TACK: http://tack.io/draft.html The problem with simply abandoning CAs is that it creates a situation in which it's even easier for government sponsored agencies to mass-intercept traffic, at least for a window of time (probably several years), and all that window b…
So, even though the government can snoop on us, we shouldn't stop using CAs, because then the government could snoop on us. With TACK you depend on CAs to establish the initial connection, set up a "pin", and then no longer rely on the CA for future connections. That initial connection is fungible by a MITM, so it's not secure. We need a term for connections that are "probably" secure, but for which there is no compl…
Yes, that is exactly what I am saying. The current CA situation is bad, the "abandon the CAs and come up with an interim plan" solution is worse.
Meanwhile, the world in which most of the mainstream browsers support TACK is imperfect, but immediately better than what we have now. TACK also sets us up to continue decoupling ourselves from the CA system.