6 ms·
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 c
by moxie 14y ago
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.
- scott_s 14y agoSince you were mentioned by name in the paper, and you consider their analysis to be incomplete, you should email the authors.
- tptacek 14y agoYou assume he hasn't? Did you notice how many times he was mentioned in the paper? This is one of Moxie Marlinspike's research areas.
- scott_s 14y agoYes, 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.
- tptacek 14y agoI'm really just commenting to note that Moxie Marlinspike isn't just the author of some random piece of software cited in the paper.
- scott_s 14y agoThe 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.
- kenko 14y agoAcademic papers are certainly not stingy with references.
- scott_s 14y agoIn 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.
- lmm 14y agoNah, these are academics, so they would've supported and justified their work with fewer citations
- mjn 14y agoI 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.
- austinpilot 14y agoOne of the authors here... The paper is accompanied by a FAQ, which among other things explains the impact on specific software: https://docs.google.com/document/pub?id=1roBIeSJsYq3Ntpf6N0PIeeAAvu4ddn7mGo6Qb7aL7ew https://docs.google.com/document/pub?id=1roBIeSJsYq3Ntpf6N0P... 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.
- scott_s 14y agoCan you address his specific point about TextSecure?
- zx2c4 14y agoplease would ya?
- deleted 14y ago[deleted]
- moxie 14y agoOh 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.
- quasistar 14y agoVideo of moxie at BlackHat 2012 for deep essential background on the subject: SSL and the Future of Authenticity http://www.youtube.com/watch?v=Z7Wl2FW2TcA http://www.youtube.com/watch?v=Z7Wl2FW2TcA What's the status of the Convergence SSL alternatives that were going to be built into Chrome/FF? http://convergence.io/ http://convergence.io/
- moxie 14y agoTrevor 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 http://tack.io
- apawloski 14y agoWhy are you shifting from convergence? It seemed like such an ingenious solution.
- tptacek 14y agoI'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.
- subiye 14y agoAnother author here. With regards to TextSecure specifically, I will quote the code in the paper here: schemeRegistry.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80)); schemeRegistry.register(new Scheme("https", SSLSocketFactory.getSocketFactory(), 443)); ... HttpHost target = new HttpHost(hostUrl.getHost(), hostUrl.getPort(), HttpHost.DEFAULT_SCHEME_NAME); ... HttpResponse response = client.execute(target, request); 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.
- tptacek 14y agoNit: "May not result in exploitable vulnerabilities" is not "clear qualification" that a vulnerability isn't exploitable directly.