[luser001]

I'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 they were interested in (except for Twitter – I helped write that TLS code, and I think we did it well). They later told me they’d already gotten a WhatsApp interception prototype working, and were surprised by how easy it was. The bar for most of these apps is pretty low."

[tptacek]

They pin the TLS certificate: to successfully create a connection to Twitter, their mobile apps will check not only the validity of the certificate the server presents, but also a hardcoded digest of the correct certificate, so that a "valid" certificate for Twitter from a CA Twitter has no relationship with will be rejected.

[tomjen3]

Wouldn't that break when they need to update the certificate, due to expiration?

[moxie]

What's "pinned" isn't the site's certificate, but rather the CA's certificate. Or more accurately, the CA's public key.

This is the problem with public key pinning. The site is still vulnerable to a compromise from its own CA, and many sites actually use a number of different CAs for unfortunate reasons. If you check out the list of pins for twitter.com, it's quite large. Still, at least it's not vulnerable to compromise from every CA that exists.

Trevor Perrin and I have been working on something called TACK (http://tack.io) to make all of this easier and more secure. Rather than embedding pin fingerprints into the binaries of web browsers and mobile apps, you can advertise them and update them via a TLS extension. What's pinned is also your site's certificate, not the CA's certificate, making the site additionally immune to compromise from its CA (or list of CAs, as it were).

[tptacek]

Just a quick note that there are apps that pin site certs and not just CA certs; if you're implementing your own iOS app, for instance, you can do it either way depending on your margin of error w/r/t certificate revocation and expiration and software update.

[moxie]

In that case, I would generally recommend that you create your own trust root and validate against it, rather than using pinning?

[tptacek]

That makes sense if yours is the only client that connects to your endpoint, but less sense if your client shares an endpoint with, say, a web app.

I try and I try to get clients to consider just rolling their own root certificate and eschewing the TLS PKI, but people have an irrational fear of the process of making certificates.

[josh2600]

Yes and that's kind of the point.

It's like Firmware in VoIP, although VoIP implementations leave something to be desired. In essence they're doing something similar to a checksum on the certificate such that any change to the certificate causes the transaction to fail.

You would have to hard code the new dates in.

[moxie]

WhatsApp doesn't use TLS, and their protocol has a fairly long history of criticism.

[josh2600]

http://www.neowin.net/forum/topic/1148702-realized-that-what...

I seem to remember their authentication was a combination of your phone number and the IMEI of your handset, which is woeful security through obscurity at best.

[spyder]

and it seems somebody got so angry about they security that he made this site: http://www.whatsappsucks.com