Sorry about the certificate validation errors. Blame the reSIProcate SVN admins.
TLS Details
The attack exploits TLS's renegotiation feature, which allows a client
and server who already have a TLS connection to negotiate new
parameters, generate new keys, etc. Renegotiation is carried out
in the existing TLS connection, with the new handshake packets
being encrypted along with application packets. The difficulty
is that they're not otherwise tied to the channel, which gives
the attacker a window. The simplest form of the attack is shown
below [cribbed from
draft-rescorla-tls-renegotiate.txt]
Client Attacker Server
------ ------- ------
<----------- Handshake ---------->
<======= Initial Traffic ========>
<-------------------------- Handshake ============================>
<======================== Client Traffic ==========================>
So, in order to mount the attack, the attacker first connects to the TLS server. He can communicate with the server as much as he wants, including making an arbitrary number of requests/responses, etc. This traffic is all encrypted and shown as ==. Then when he's ready, he hijacks the client's connection to the server (in practice he might start by hijacking the connection and then connect to the server but it doesn't matter) and just proxies the client's traffic over the encrypted channel. The client negotiates with the server and from that point on the client and the server communicate directly. Note that the client is communicating with the attacker in the clear but the second handshake is encrypted and goes over the attacker's channel. Thus, the client does not know that he is renegotiating. However, the server thinks that the initial traffic with the attacker is also from the client. There are also other (probably less useful) variants where both sides see a renegotiation but of different connections.
Impact on Existing Applications
TLS itself is just a security protocol, so the impact of this
attack depends on the application protocol running over TLS.
The most important of these protocols is of course HTTP over
TLS (HTTPS). Most Web applications do initial authentication
via a username/password pair and then persist that authentication
state with HTTP cookies (a secret token that is sent with any
request). An attacker might exploit this issue by sending a
partial HTTP request of his own that requested some resource. This
then gets prefixed to the client's real request.
E.g., the attacker would send:
GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 X-Ignore-This:
And leave the last line empty without a carriage return line feed. Then when the client makes his own request
GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 Cookie: victimscookie
the two requests get glued together into:
GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 Cookie: victimscookie
And the server uses the victim's account to send a pizza to the attacker.
You can mount a similar attack if the server uses certificate-based client authentication: it's common (well, common in the small number of cases where client certs are used at all) for the server to let the client connect and request a resource and then if the resource is protected renegotiate asking for a certificate. The attacker can exploit this by doing the initial handshake and asking for the resource and then letting the client do the renegotiation, at which point the server acts as if the initial request was made by the client.
It's important to note that in both the cases we just described the attacker doesn't get to see any sensitive information directly: that's just sent back encrypted to the client. However, he can exploit side effects of the exchange, e.g., to get a pizza. It may also be possible to exploit HTTP features to directly access the data. For instance, he might be able to generate a combined request that would cause the server (or perhaps somehow mirrored through the client) to send the original client request to the attacker. If the request contains the client's cookie or password, this would cause their credentials to leak. It's not clear to me if this is possible, but I'm hoping some of the Web security specialists will weigh in.
The impact on other protocols (IMAP, SIP, etc.) would depend on those protocols and I haven't seen complete analyses of these yet.
Mitigations
Eventually there will be a TLS level protocol fix (see below).
However, in the meantime options are limited.
For 99+% of applications, the mitigation is very simple: the server should simply disable all renegotiation, which stops the attack. (OpenSSL will helpfully automatically renegotiate which facilitates the attack even if the application isn't otherwise set up to do renegotiation). Unfortunately, there is no similar defense on the client side. In the example I showed above, the client is unaware that renegotiation happened. Moreover, the client can't tell that the server will refuse renegotiation (it could explicitly probe but the attacker could of course fake a failure). So, the client can't really do anything useful to protect itself.
The second drawback is that there are a small number of cases (e.g., the certificate authentication one I described above) where renegotiation actually should happen. The most practical defense on the server side is to restructure the site so that requests which require client auth are redirected to a different address or port which always requests a certificate and itself refuses renegotiation. However, this obviously requires major work on many sites.
There are a few other legitimate reasons for renegotiation, but they're mostly things one doesn't need to do. For instance, people sometimes renegotiate to force the generation of fresh keying material. This is not necessary with modern cryptographic algorithms. Another example provided by Ray is sites that support algorithms with differential strength. Again, this isn't really necessary. Unless you're doing certificate-based client authentication it's very unlikely you need to renegotiate and if you are using it, the workaround above is the simplest.
Long-Term Defense
Despite the existence of some defenses, it seems clear that TLS should
really defend against this. There's a fairly obvious defense that
at least three people have independently come up with: carry
information about handshake n-1 in handshake n (if n==1 you just
carry an empty field). This prevents attacks where the client
and server have different views of the negotiation state.
The predisclosure group that worked on this after Ray discovered this
worked to develop a draft
describing this technique which can found at
draft-rescorla-tls-renegotiate.txt
and we'll be submitting it to the TLS working group shortly. Of course,
this will take a very long time to make it into enough clients and
servers to make a real difference, so for now we're mostly stuck
with the mitigations I've described.
The Software Situation
People have also developed patches for existing implementations. These
fall into two categories:
As far as I know none of these have been formally released yet. Ben Laurie's OpenSSL disabling patch can be found here. I've developed a patch that performs the long-term fix protocol pieces but it doesn't disable non-fixed renegotiation so it's usable primarily for interop testing right now. That can be found here. Expect both of these to eventually appear in official OpenSSL distributions/patches. I don't know the release status of other fixes.
Big Picture Perspective
Now that we've covered how this attack works, how bad is it? It's being
billed as a man-in-the-middle attack, but it's really far more limited
than your classic MITM. Rather, it's a plaintext injection attack.
I'm not saying that's good, but we need to put it into perspective:
over the past two years, we have seen two separate issues that allow
a complete TLS server impersonation: the Debian PRNG bug
(see our paper here
for a description of the issue [which we did not discover] and its impact)
and the TLS certificate "NULL" issue. Both of these issues had
much more severe impact since they allowed the attacker access to all
the data sent by the client. However, it's worth noting that they differed
from this issue in that they were detectable/fixable on the
client side so people could in principle protect themselves. As a practical
matter, however, most clients never checked the Debian keys against a
blacklist, so that protection was minimal at best.
Second, it's important to remember that even simple MITM attacks with fake certificates don't seem that hard to mount. Cranor et al. report that users very frequently ignore browser warnings of bad certificates, which more or less obviates any security protections TLS provides. If the user will accept the attacker's certificate, there's no need to do anything as limited as the attack described here. Obviously, that's not information that should give you a huge amount of confidence in any form of Internet communications security, but it does provide some perspective on the marginal impact of this attack.
One other comparison point is a remote vulnerability in the server. TLS implementations have historically had and continue to have remote vulnerabilities which would allow an attacker to subvert the server. Such an attacker could read all your traffic to that server. As with this issue, you can't really detect that from the client side and need to rely on the server being upgraded. So, this issue is somewhat less serious than a remote vulnerability in a really popular server stack like OpenSSL. It's primarily unusual because it's an issue in the protocol not the software and those are quite rare.
Bottom Line
As I said at the beginning, this obviously isn't good. We'd like SSL/TLS
to provide it's nominal security guarantees and it clearly doesn't.
There likely to be exploitable attack paths using this issue.
It's far less clear whether they will actually see exploitation,
given that these attacks aren't necessarily as powerful as other
already known paths. In the not too distant future you should expect
most important servers to have fixed, at which point most of your
Web server interactions will be safe (even though you can't
verify it easily).
In the long term, most clients and servers will adopt the protocol
fix at which point clients will be able to be sure that the servers
they are interacting with are safe.
That thing to the left of the sink is an automatic soap dispenser (surprisingly, powered by a battery pack underneath the sink). Now notice that the sink itself is manually operated. Isn't this kind of backwards? The whole point of automatic soap dispensers and sinks in bathrooms is to appeal to your OCD by freeing you from having to touch any surface which has been touched by any other human without being subsequently sterilized. But when you wash your hands, the sequence of events is that you turn on the water, wet your hands, soap up, rinse, and then turn off the water. So, if you have a manually operated sink, people contaminate the handles with their dirty, unwashed hands, which means that when you go to turn the sink off, your just-washed hands get contaminated again. The advantage of automatic faucets, then, is the automatic shutoff, which omits the last stage. By contrast, having the soap dispenser be automatic doesn't buy you that much because you only need to touch it before washing your hands. There's probably some analogy here to viral spread in computer systems, but for now let's just say that this is how security guys think.
UPDATE: Corrected the quote a bit. Thanks to Greg Lebovitz for the correction.
The context of this draft is that currently messages in XMPP from alice@atlanta.com to bob@biloxi.net go through Alice and Bob's respective servers (atlanta.com and biloxi.net) in transit. This implies that Alice and Bob need to trust their servers both to enforce appropriate security policies (i.e., to make sure there is TLS along the whole path if appropriate) and not to actively subvert security as by message sniffing, injection, etc. The purpose of this document is to allow Alice and Bob to establish an end-to-end secure cryptographic channel that does not rely on the server for security. THREAT MODEL Before talking about the draft details, it's important to get clear on the threat model. In particular, we need to be clear on how much the server are trusted. There are at least three plausible models: - The server is trusted completely (the current system). - The server is trusted to authenticate Alice and Bob, but should not see the traffic. - Server not trusted at all. Clearly, we're trying to do better than the first of these, so it's between the second two. For contrast, in SIP (cf. RFC 4474) the basic assumption is that that proxy (the server) owns the namespace associated with it. So, for instance, if atlanta.com decides it wants to take the name "alice@atlanta.com" away from Alice and give it to her sister "Alice", it can. So, the proxy is trusted to authenticate Alice, but shouldn't see the traffic, i.e., the second model. The security requirements for these two are different. In particular, in the second case, you need some independent mechanism for Alice and Bob to authenticate each other. I think it's important to be clear on which of these environments you think is the dominant one. I'm sure there are *some* cases where people don't trust the servers at all, but I suspect in most cases they just want (1) not to have to trust the server to enforce security policy and (2) deter casual sniffing by server operators. In these cases, a model where the server authenticates the users for an E2E connection (a la DTLS-SRTP) is appropriate. If that's a common model, then forcing all users to use a secure independent channel just because some want to is going to be a very serious inconvenience. My instinct is that that's a mistake. AUTHENTICATION MECHANISMS The design of a system in which the servers vouch for the users identities is fairly straightforward, with DTLS-SRTP as a model: the servers simply authenticate the users and then pass on digests of the user's certificates (as provided by the user) along with an authenticated indication of the user's identity (a la RFC 4474 or even the current TLS model) and the end-to-end connection is compared to these fingerprints. As noted above, the design of a system in which the servers aren't trusted is significantly more complicated. Roughly speaking, thre are three major techniques available here: key/certificate fingerprints, a shared password, and a short authentication string. See [http://www.educatedguesswork.org/2008/08/authentication.html] for some background here. I think it's generally agreed that fingerprints are too much of a hassle for regular use, though if your model was that most users would be happy without it, then you might think that they would be OK for the exceptionally paranoid. This leaves us with SAS and shared passwords. The important interface differences here are as follows: - The SAS must be verified *after* the connection is set up. The password must be set up before hand. - You can use the same password with multiple people semi-safely. The SAS is new for every message. - SAS probably requires modifying TLS. There are existing mechanisms for passwords. - The SAS is "optional" in the sense that you can generate it and not check it. The password is "mandatory" in the sense that if it's specified, it must be supplied or the connection will not be set up. Passwords can be further broken down into two variants: ZKPP/PAKE schemes and ordinary PSK schemes. The relevant differences between these two are that PSK schemes are susceptible to offline dictionary attack but that ZKPP/PAKE schemes have a much more problematic IPR situation. Finally, there is the question of where the authentication is done. As I noted above, TLS has existing PSK and SRP mechanisms. However, one could also add at least password and PAKE mechanisms to SASL if one wanted and use a channel binding to connect the two.
More to come at the XMPP2 BOF next week in San Francisco, which BOF for some unknown reason, I'm chairing.
In principle, there might be a fourth category: documents which contain old text but where the contributors have obtained licenses from all the copyright holders. Unfortunately, the form that the IETF meant to provide for this purpose is, uh, broken so you're kind of on your own, unless, that is, you can convince people to sign a blank signature page. I'm not aware of any documents that fall into this category, but maybe there are some. In any case, I know a number of authors who are holding back documents because they don't believe they can obtain the necessary rights.
The current state of play is that the IETF Trustees have proposed some new boilerplate that will go onto submissions that more or less disclaims the 5378 rights grants. Unfortunately, the current text is inadequate and it's not clear when new text will be posted, let alone approved. IETF San Francisco (March) may turn out to be pretty interesting.
The IETF has opted to deal with this situation with a combination notify and attest model, which works like this. There are three main ways in which people submit "contributions" i.e., text for documents, comments, etc. to the IETF:
The first case is the clearest: every I-D submission is required to have a boilerplate license grant attached to it, or rather a reference to a license grant. It looks (or at least until recently) something like this:
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
That's the attest part. But what about submissions on mailing lists, stuff said at the mic at meetings, etc.? It's not really practical to expect people to start every comment with a copyright statement. Instead, the IETF has a general policy on submissions which you're given a copy of when you sign up for an IETF meeting or join a mailing list. (This policy is colloquially called "Note Well" after the title of the document). Contributing once you've read the statement is deemed to be an acknowledgement and acceptance of the policy. Note: I'm not a lawyer and I'm not taking a position on whether this will hold up in court. I'm just reporting how things are done.
OK, so you have to agree to some license terms. But what are those terms? Until recently (confusingly, the date is a bit uncertain), they were approximately that the text in your document could be reused for any IETF purpose, e.g., you could republish them, prepare derivative works for the purpose of doing revisions, etc. So far so good. Once documents were in the IETF system you could pretty much do anything IETFy with them, since you could safely (at least that's the theory) assume that the authors had granted the appropriate rights. What you couldn't do, however, was take text out of the documents and use them to prepare documents for some other standards body such as OASIS, ITU, etc. Anyway, IETF decided that it was a good idea to fix this and so a new set of license terms were prepared which involved granting this additional set of rights (the details are actually quite a bit more involved, but not really that relevant). Moreover, the new rules required IETF contributors (i.e., document authors) to attest that they had the right to submit the document under these new terms.
This last bit is where things started to go wrong. Consider what happens if you want to prepare a revision of some RFC that was written before the rule change. Ordinarily, you could do this, but now you need to submit under the new rules, and moreover you need to attest that you've obtained the necessary permissions to do so. But since all you know is that the document was submitted under the old rules, you need to go back to every contributor to the original document and get them to provide a more expansive license grant. That's fairly inconvenient already, but it gets worse. IETF doesn't really keep records of who contributed which piece of each document (remember: if it's in the system it was supposed to be automatically OK), so you don't actually know who you're supposed to contact. Even if you just take the list of people who were acknowledged in the document, this can run to tens of people, some of whom might have changed employers, died, or whatever. So, there's a reasonable chance that some documents can't practically be revised under these terms, and some IETFers are already avoiding contributing documents they would otherwise have submitted. The IETF hasn't totally ground to a halt yet, presumably due to some combination of virgin submissions, participants unaware of the issue, and participants aware of the issue but assuming they're not going to get caught.
Unfortunately, this didn't quite get figured out (for some unknown reason, people aren't really excited about spending a lot of time reading licensing agreements) until it was too late and the terms were already in effect. Next step: figure out how to unscrew things. Outstanding!
There are two tools:
bibxml2rfc: the bibliography manager. It runs through
the XML file, finds everything that looks like a reference, and
the builds a pair of bibliography files (one for normative and
one for informative) for inclusion into your XML file. It automatically
fetches reference entries for RFCs and Internet Drafts. You can use
ordinary XML inclusion techniques so you don't need to modify the
XML file reference section when the bibliography changes.
bibxml2rfc-merge: a tool to make merged files for submission.
The Internet Drafts submission tool won't accept a bunch of separate
XML files, so bibxml2rfc-merge merges them into one for submission.
You don't need this for your ordinary work.
The source can be found at: https://svn.resiprocate.org/rep/ietf-drafts/ekr/bibxml2rfc. Documentation for bibxml2rfc can be found at https://svn.resiprocate.org/rep/ietf-drafts/ekr/bibxml2rfc/bibxml2rfc.txt
D. McGrew, E., Rescorla, Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP), draft-ietf-avt-dtls-srtp-02.txt.
J. Fischl, H. Tschofenig, E., Rescorla, Framework for Establishing an SRTP Security Context using DTLS, draft-ietf-sip-dtls-srtp-framework-01.txt.
E. Rescorla, Keying Material Extractors for Transport Layer Security (TLS), draft-ietf-tls-extractor-01.txt.
T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2, draft-ietf-tls-rfc4346-bis-09.txt.
