I agree that these APIs are fundamentally difficult to use correctly (sometimes it almost seems as if they've been designed to trick you), and that developers commonly get them wrong, but this paper is perhaps a little more inflammatory than it should be.
They cast a really wide net, looking for as many examples as possible where non-browser applications fail to do SSL validation correctly, but then conclude that this will result in a security compromise without fully examining the implications.
For instance, they point out that many SDKs for Amazon FPS don't validate certificates correctly. But I didn't see them mention that the FPS protocol does its own signature-based authentication and that credentials are never transmitted in the clear: it was essentially designed to operate over an insecure transport to begin with.
Likewise, they point out an "unsafe" construction that an Android application that I wrote (TextSecure) uses. But they don't mention that this is for communication with an MMSC, that this is how it has to be (many don't present CA-signed certificates), and that the point of TextSecure is that an OTR-like secure protocol is layered on top of base transport layer (be it SMS or MMS).
So I think the paper would be a lot stronger if they weren't overstating their position so much.
For example, broken SSL in Amazon FPS allows a MITM
attacker to forge instant payment notifications and
defraud merchants who use vulnerable SDKs. This
is a real vulnerability, acknowledged by Amazon.
Oh thanks, I think that FAQ is exactly what I was looking for. I realize we might not be your target audience, but it seems like it'd be worth including those impact analysis statements in the paper itself, since they're short and do really help to clarify the situation.
I'll have to take a second look at the instant payment notification forgery. Last I used FPS, I remember the transaction notifications being signed. Maybe "instant payments" are a new thing.
Viewing the code sample from the paper it can be seen that an SSLSocket was meant to be used if the connection was over HTTPS. However this use of the API results in a request being sent over HTTP instead of HTTPS. The argument for CAs not having correct certs makes less sense here in conjunction with the use of SSL API.
We clearly qualify in the paper that this is not exploitable directly.
Trevor Perrin and I are actually making some encouraging progress with TACK, which is a less controversial proposal with fewer moving parts. It's for dynamic certificate pinning rather than a full CA replacement, but we feel that it takes a big bite out of the problem and is potentially a step on the path out of the current mess.
The internet draft and reference code can be found here: http://tack.io
is there a faq or tack for dummies? i'm reading the rfc, but somewhat confused.
edit: http://blog.cryptographyengineering.com/2012/05/tack.html helps (i was missing that it is in addition to tls, so it's like perspectives / network notaries, but over (limited) time, for a single client, rather than over multiple clients)
I'm not Moxie, but one attractive thing about TACK is that it standardizes something browser vendors already do: if you're on a short list of sites trusted or taken seriously by Google, for instance, your certificates can be "pinned" in Chrome; essentially, Chrome builds in a notion of what your certificate is supposed to be. As a result, no matter which CAs have been compromised by which foreign governments, Chrome isn't going to believe that a pinned site, like MAIL.GOOGLE.COM, is represented by a Diginotar or Comodo certificate.
The obvious problem with that is that you have to call in a favor from Google to get that level of security. TACK is a mechanism that allows any site to get something comparable.
Another attractive thing about TACK is that it follows a model that other security features in the browser already use. For instance, the HSTS header is a widely-supported feature that allows websites to instruct browsers to remember that a site is intended to be reached only via HTTPS. TACK does something similar, but with a much more useful assertion.
Yep, it also has benefits to the site. AGL is quite generous with his time in terms of accepting static pin requests, but it can become a difficult situation for large website operators. It's a little nerve-wracking to know that the fastest you can make a change is 10 weeks out (the expiration for Chrome pins post-build), and some of those pin lists get pretty long (CDNs, multiple CAs for whatever reason, multiple SPKIs per CA, etc).
TACK is designed to alleviate that pain for the site owner by providing flexibility, and by eliminating even the CAs the site uses from its scope of exposure.
I conceptualize Convergence as providing trust agility for situations where a client needs third party verification. TACK is about reducing the number of situations where we even need to trust a third party at all.
The latter helps the former by making it easier to deploy. If TACK were the norm, then the only purpose CAs would serve is to introduce clients to websites they have never seen before (rather than authenticating every single connection to a website during every page load to that website).
By taking a bite out of the problem, we feel the remainder will be easier to solve. And yeah, hopefully we can position convergence as that solution.
It's also easier to get TACK done with browser vendors, simply because it's well encapsulated as a TLS extension, is fairly uncontroversial, and requires them to write less code. Basically, we feel it's a good first step.
One question I have about convergence.
I understand how it helps prevent MITM attacks by getting consensus from a trusted third party as to the authenticity of a particular cert.
However what happens if the MITM attack is on the other end, in other words somebody has got into a hosting providers network and is MITMing a bunch of traffic to some of their servers.
They could use this to pass back bullshit certs/public keys to all clients (including notaries) who connect to servers they have MITMd.
One way to prevent this of course would be to have the server keep it's own list of notaries and self-check every so often and alert clients if something appears wrong.
However here you are relying on server administrators keeping this configured and working.
I could imagine less scrupulous administrators on strict SLAs disabling this and letting it fail in a way that is silent to the end user to avoid downtime. This would be more difficult to do with the traditional CA structure since the attacker would need a valid cert for the site or would need to SSL strip everything (which would eventually get noticed).
Or do I have this wrong and it is intended to augment the existing CA structure rather than replace it?
Yes, I do assume so, since neither the authors nor Moxie himself indicate that they have had any communication. I cite people all the time without contacting them, and I have been cited without being contacted.
The paper makes that quite clear by calling him an SLL expert and referencing two of his vulnerability discoveries. Academic papers are stingy with both personal praise and references. Anyone who receives either one of those I assume is an expert in the field.
In my experience as an author and reader of such papers, they are. References take up space, and every reference you make is less of your own work that you can discuss. So I think very carefully about who I'm going to give my precious paper-space to.
Don't confuse a paper having 30+ references as being generous. If they could have supported and justified their own work with less citations, they would have.
I have somewhat different experience. I usually include more references than strictly necessary to support the work, because there's an expectation of general credit-giving: if someone else works in a related area, even if their work isn't directly on-point or needed in the specific paper at hand, it's often expected that they get a generic nod in the "related work" section, and reviewers may complain if that's not done. But often the reference amounts to little more than a friendly ack: yes, I know paper [2] exists, and I hereby acknowledge it.
My last (ok, only) published paper cited 47 other papers or books. I felt absolutely no compulsion to reduce (or, for that matter, increase) that number, nor does the number of citations have any connection to the amount of time I could discuss my own ideas ("See \textcite[p 6]{someone2005}" doesn't take much space).
It's not the citation in the paper, it's the two or three lines the reference itself takes up in the references section. When we publish papers, we are always pressed for space, and we always have to decide what we have to cut. I can't speak for where you publish, but in computer science conferences, we have page limits.
They cast a really wide net, looking for as many examples as possible where non-browser applications fail to do SSL validation correctly, but then conclude that this will result in a security compromise without fully examining the implications.
For instance, they point out that many SDKs for Amazon FPS don't validate certificates correctly. But I didn't see them mention that the FPS protocol does its own signature-based authentication and that credentials are never transmitted in the clear: it was essentially designed to operate over an insecure transport to begin with.
Likewise, they point out an "unsafe" construction that an Android application that I wrote (TextSecure) uses. But they don't mention that this is for communication with an MMSC, that this is how it has to be (many don't present CA-signed certificates), and that the point of TextSecure is that an OTR-like secure protocol is layered on top of base transport layer (be it SMS or MMS).
So I think the paper would be a lot stronger if they weren't overstating their position so much.