negotiation question
Rob Crittenden
provider mod_nss to handle the SSL client-initiated handshake bug.
NSS provides a callback, SSL_HandshakeCallback(), which according to the
docs is called when an SSL handshake has completed.
So let's say I have the following:
SECStatus FailureHandshakeCallback(PRFileDesc * socket, void *arg)
{
return SECFailure;
}
SECStatus InitialHandshakeCallback(PRFileDesc * socket, void *arg)
{
return SSL_HandshakeCallback(socket, (SSLHandshakeCallback)
FailureHandshakeCallback, NULL)
}
When I create a socket I'll set the handshake callback to
InitialHandshakeCallback(). Once the initial SSL handshake is done this
will then reset it to the failure mode, so that if any subsequent
handshaking happens it will fail.
The Apache configuration lets one have per-location configuration, for
example requiring SSL client auth only for a subdirectory. To do this it
updates the SSL options on the socket and calls SSL_ReHandshake().
What I was thinking about doing here is setting those options, then
setting the callback handler back to InitialHandshakeCallback(). This
should allow the server-initiated handshake to succeed and prevent any
other handshaking (unless we again want to restart it from the server).
Does this (1) seem like a reasonable approach and (2) will it protect
against the client rengotiation issue?
thanks
rob
Kyle Hamilton
A server-initiated handshake is also vulnerable to an MITM. The
attack scenario is a bit more complex, but it's doable. (More
specifically, as soon as a HelloRequest is sent from the server,
perhaps as a request to "upgrade" the authentication level, that
HelloRequest can be sent from MITM to the client, which possibly has a
persistent connection going to the MITM. At that point, the
protocol's broken.)
Apache's willingness to do per-Location/per-Directory/per-Whatever
renegotiation for client authentication is what forced us into this
situation in the first place. I believe it should be considered a
bug, and fixed on Apache's side. Unfortunately, few others agree.
-Kyle H
Nelson B Bolyard
> I'm considering how to handle SSL re-negotiation in the Apache NSS
> provider mod_nss to handle the SSL client-initiated handshake bug.
I hope you realize that there's no difference in vulnerability between
client initiated and server initiated renegotiation. A server that
participates in renegotiation with SSL 3.x (including TLS) today is
vulnerable, regardless of who initiates it. Today, the only way for a
server to be invulnerable is to NOT do renegotiation at all.
Soon (hopefully) the IETF TLS working group will adopt a modification to
TLS (and maybe SSL 3.0 also, although that was never an IETF-specified
protocol in the first place). When that has been published, and implemented
in most of the SSL/TLS protocol stacks on the Internet, then
renegotiation will (once again) be possible to be done safely. However,
it is possible that safe renegotiation will ONLY be possible with TLS,
and not with SSL 3.0. Servers will have a way of saying "I've been modified
so that I never do unsafe renegotiation", even if they never do
renegotiation at all, I believe.
> When I create a socket I'll set the handshake callback to
> InitialHandshakeCallback(). Once the initial SSL handshake is done this
> will then reset it to the failure mode, so that if any subsequent
> handshaking happens it will fail.
Having two separate callback functions is one way to try to address this
problem with versions of NSS prior to 3.12.5. But that callback will
get called after the handshake is done, and if an MITM attack was being
attempted, it may well appear to an outside observer that the attack was
successful. You really want to prevent that renegotiation handshake
from completing. The handshake completion callback is just too late for
that.
That's why, in NSS 3.12.5, I added a new SSL socket option to control
renegotiation, and set its default to disallow all renegotiation.
The default can be changed with an environment variable, or with an
API call. The value can also be changed on individual sockets.
In NSS 3.12.6 (or some other future NSS release, to follow the publication
of the new RFC mentioned above), this socket option will be further enhanced
with additional options, and safe renegotiation will become the
new default.
> The Apache configuration lets one have per-location configuration, for
> example requiring SSL client auth only for a subdirectory. To do this it
> updates the SSL options on the socket and calls SSL_ReHandshake().
Yes. Other web servers (e.g. Sun, Netscape) do something very similar.
But it's equally vulnerable.
> What I was thinking about doing here is setting those options, then
> setting the callback handler back to InitialHandshakeCallback(). This
> should allow the server-initiated handshake to succeed and prevent any
> other handshaking (unless we again want to restart it from the server).
In the immortal words of Richard M Nixon,
"We could do that, but it would be wrong." :)
The problem is, a server that does that is just as vulnerable as a server
that allows client initiated renegotiation.
> Does this (1) seem like a reasonable approach and (2) will it protect
> against the client rengotiation issue?
No. Sorry. You must disable ALL server renegotiation for a server to be
safe, until such time as new safe renegotiation is standardized and deployed.
Ian G
interesting description folded.
> Apache's willingness to do per-Location/per-Directory/per-Whatever
> renegotiation for client authentication is what forced us into this
> situation in the first place. I believe it should be considered a
> bug, and fixed on Apache's side. Unfortunately, few others agree.
I agree. It breaches that fundamental law of the Iang's mind-space:
there is only one mode, and it is secure. Break the law, time folds and
inverts on itself, and Mallory slips between your bytes.
Old military trick: attack between.
Ok, maybe not that dramatic, nobody got breached and nobody died, but it
does seem illogical to add options to such a foolish extent. Adding
options without a clear demand & use-case is just asking for trouble.
Shamefully, there's a lot of it going on in the protocol committees.
One wonders whether there is a correlation between the number of options
and the number of jobs...
iang
Kyle Hamilton
> I agree. It breaches that fundamental law of the Iang's mind-space: there
> is only one mode, and it is secure. Break the law, time folds and inverts
> on itself, and Mallory slips between your bytes.
'secure' is a state of mind, not too different from 'paranoid'. The
trade-off is in the amount of time you have to spend assessing
everything as a potential threat.
>
> Old military trick: attack between.
>
> Ok, maybe not that dramatic, nobody got breached and nobody died, but it
> does seem illogical to add options to such a foolish extent. Adding options
> without a clear demand & use-case is just asking for trouble.
Twitter was breached. Before they disabled renegotiation on their
servers, the status message POST update was POST [...], and then their
Basic-encoded username and password. Someone injected prior bytes
before allowing the renegotiation, and every time someone was
intercepted, that someone's status message changed to a whole bunch of
usernames and passwords.
> Shamefully, there's a lot of it going on in the protocol committees. One
> wonders whether there is a correlation between the number of options and the
> number of jobs...
The capability for TLS to renegotiate securely was missing in the
protocol, and it's obvious in hindsight. However, relying on
renegotiation to provide different levels of authentication/security
to different areas of the URL space without requiring the full request
to be resubmitted under the new credentials...
It's called "Defense In Depth" for a reason. Don't rely on any
particular aspect of your system going unbreached. Don't rely on an
underlying protocol to do precisely what you (and its designers)
expect. And don't design protocols that allow a single request to be
submitted across two different authentication levels.
My thought is this: if Apache needs to do a renegotiation, it should
*always* send a 302 header to have the client go where it thought it
needed to go. (It sucks to not be able to rely on the original URL
that was requested, since it came in under an unauthenticated cover,
but if there was a way in HTTP for the server to request to the client
that it reissue the request that it thought it sent... but that's a
bug in HTTP, and we don't talk about HTTP here.)
-Kyle H
-Kyle H
Nelson B Bolyard
use of renegotiation in SSL 3.x (including TLS 1.x). Briefly, they are:
a) It's SSL/TLS's fault, a failure in the design of renegotiation, or
b) It's the fault of the applications that assume (incorrectly) that all
sessions over a single SSL/TLS connection are necessarily between the same
two parties.
SSL 3.x's renegotiation feature allows a single connection to switch over
time between one "session" and one or more other sessions. It allows new
sessions to be created, and/or old sessions to be resumed. It is possible
for a pair of peers at the ends of a TCP connection to switch back and
forth (to "multiplex") repeatedly between two or more sessions on a single
connection.
Each of those different sessions may be associated with a different identity
than the other sessions, at either end. One session might represent one
client user, and a second session might represent another client user. By
the same reasoning, one session might represent one virtual server, and
another session might represent another virtual server.
When a particular session is resumed, SSL/TLS does offer cryptographic
assurances that it is between the same pair of identities as before, but
SSL/TLS make so such assurances about the pairs of identities between one
session and another.
Seen in this light, the SSL/TLS renegotiation facility is not flawed at all.
It is simply a mistake of any client or server product to assume that all
the sessions on a SSL/TLS connection represent the same pair of client and
server identities.
The trouble is that for the last decade or so, everybody and his brother
(including me, I must admit) misunderstood the SSL/TLS renegotiation
feature's capabilities and purposes. They/we ASSUMED that it offered the
assurance that all sessions were between the same pair of (id)entities,
and when they learned that it did not, they did not say "Oh, we've had a
bad assumption all along". They said "It's terribly flawed and vulnerable!"
In some sense, the question is: what was SSL/TLS _INTENDED_ to do?
Was it intended to offer the assurance that everyone assumed it did?
If so, then indeed it had failed to do that and is flawed.
Or, was intended to offer what it actually offers, session multiplexing,
in which case it is not flawed at all?
At present, the IETF TLS working group appears to have decided that it was
intended to have offered the assurance that everyone assumed that it did,
but actually did not. They (we) are working on defining a new form of
renegotiation that does offer that assurance. I suspect that in the next
version of TLS, that will be the only form of renegotiation defined, and
that the older session multiplexing form that offers no such assurances
will no longer be offered. I suspect that is no real loss, in practice.
Personally, I have sat of both sides of this issue. I think that it was
probably the original intent for the renegotiation feature to offer
multiplexing without any assurances of tying of identity between sessions.
But I think the market now demands those assurances, so it is probably good
to make this change. It is unfortunate that the original designers are
being smeared as having erred when (I suspect) they did not.
Ian G
On 01/12/2009 01:38, Nelson B Bolyard wrote:
> There are two schools of thought about the vulnerabilities related to the
> use of renegotiation in SSL 3.x (including TLS 1.x). Briefly, they are:
> a) It's SSL/TLS's fault, a failure in the design of renegotiation, or
> b) It's the fault of the applications that assume (incorrectly) that all
> sessions over a single SSL/TLS connection are necessarily between the same
> two parties.
>
> SSL 3.x's renegotiation feature allows a single connection to switch over
> time between one "session" and one or more other sessions. It allows new
> sessions to be created, and/or old sessions to be resumed. It is possible
> for a pair of peers at the ends of a TCP connection to switch back and
> forth (to "multiplex") repeatedly between two or more sessions on a single
> connection.
What is the use case for multiple sessions? Is this something like the
logic of trying to speed up the throughput, like SPDY (spelling? the
google idea for speeding it up) or DTLS?
> Each of those different sessions may be associated with a different identity
> than the other sessions, at either end. One session might represent one
> client user, and a second session might represent another client user. By
> the same reasoning, one session might represent one virtual server, and
> another session might represent another virtual server.
What is the use case for multiple sessions with different identity pairs
over a single TLS connection? I don't know if it is just me, but this
seems quite ... odd?
Maybe it was to accomodate the Apache HTTPD's desire to allow multiple
identity settings per directory?
> ... It is unfortunate that the original designers are
> being smeared as having erred when (I suspect) they did not.
I think it is probably unfair to smear them. The protocol had a good
run with no real harm until today. The designers did a pretty good job
with the circumstances (including some ropey assumptions and not a
little politics). Mismatches in expectations occur all the time in the
real world, what is somewhat surprising is this one took so long to surface.
If there is a flaw, it is not so much in the protocol, but more likely
the committee and the user communities, locked in a deadly embrace of
telling each other the protocol is the perfect tool for all purposes.
Thanks for the update! We can't all spend time in every forum.
iang
Ian G
> On Mon, Nov 30, 2009 at 1:07 PM, Ian G<ia...@iang.org> wrote:
>> I agree. It breaches that fundamental law of the Iang's mind-space: there
>> is only one mode, and it is secure. Break the law, time folds and inverts
>> on itself, and Mallory slips between your bytes.
>
> 'secure' is a state of mind, not too different from 'paranoid'. The
> trade-off is in the amount of time you have to spend assessing
> everything as a potential threat.
Indeed, the claim rests on an undefinition ;-)
Let me put it this way, the bottom-up target is to do whatever you can
with one mode. The top-down target is to do whatever you can to meet
the application need. With one mode.
> Twitter was breached. Before they disabled renegotiation on their
> servers, the status message POST update was POST [...], and then their
> Basic-encoded username and password. Someone injected prior bytes
> before allowing the renegotiation, and every time someone was
> intercepted, that someone's status message changed to a whole bunch of
> usernames and passwords.
I stand corrected! I heard it was demo'd, I didn't hear it was
breached? Was the attack more of a nuisance attack? How serious are
the damages?
> ...but that's a
> bug in HTTP, and we don't talk about HTTP here.)
Well, we shouldn't do architecture here. Other parts, well said.
iang
Eddy Nigg
> Twitter was breached. Before they disabled renegotiation on their
> servers, the status message POST update was POST [...], and then their
> Basic-encoded username and password. Someone injected prior bytes
> before allowing the renegotiation, and every time someone was
> intercepted, that someone's status message changed to a whole bunch of
> usernames and passwords.
>
Which was a clear failure on the application level, not SSL...the
renegotiation just made it work easily.
I claim that a correctly handled application is not subject to this kind
of attacks.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Nelson B Bolyard
> On 11/30/2009 11:47 PM, Kyle Hamilton:
>> Twitter was breached. Before they disabled renegotiation on their
>> servers, the status message POST update was POST [...], and then their
>> Basic-encoded username and password. Someone injected prior bytes
>> before allowing the renegotiation, and every time someone was
>> intercepted, that someone's status message changed to a whole bunch of
>> usernames and passwords.
>>
>
> Which was a clear failure on the application level, not SSL...the
> renegotiation just made it work easily.
>
> I claim that a correctly handled application is not subject to this kind
> of attacks.
It depends on a number of factors, including the capabilities of the
particular SSL library and its API that you're using. Some SSL libraries
handle renegotiation for the application automatically, without the
application's knowledge or participation, and without giving those apps
any way to disable it. Those apps have no defense.
Nelson B Bolyard
> Good article!
Thanks.
> On 01/12/2009 01:38, Nelson B Bolyard wrote:
>> There are two schools of thought about the vulnerabilities related to
>> the use of renegotiation in SSL 3.x (including TLS 1.x). Briefly, they
>> are: a) It's SSL/TLS's fault, a failure in the design of renegotiation,
>> or b) It's the fault of the applications that assume (incorrectly) that
>> all sessions over a single SSL/TLS connection are necessarily between
>> the same two parties.
>>
>> SSL 3.x's renegotiation feature allows a single connection to switch
>> over time between one "session" and one or more other sessions. It
>> allows new sessions to be created, and/or old sessions to be resumed.
>> It is possible for a pair of peers at the ends of a TCP connection to
>> switch back and forth (to "multiplex") repeatedly between two or more
>> sessions on a single connection.
>
> What is the use case for multiple sessions?
Well, I can think of numerous different uses of multiplexing multiple
sessions over a connection ... if that multiplexing was efficient.
> Is this something like the logic of trying to speed up the throughput,
> like SPDY (spelling? the google idea for speeding it up) or DTLS?
No. The overhead of renegotiating, switching from one session to another,
is at least as great as the overhead of a new TCP 3-phase connection.
If you had, say 5 sessions to multiplex, and you used 5 connections, you'd
do 5 3-phase connections, one for each session, and that's it. But with SSL
multiplexing, you go through that overhead each time you switch from one
session to another. It's like paying the overhead to disconnect and
reconnect. So, it's definitely not a performance win.
>> Each of those different sessions may be associated with a different
>> identity than the other sessions, at either end. One session might
>> represent one client user, and a second session might represent another
>> client user. By the same reasoning, one session might represent one
>> virtual server, and another session might represent another virtual
>> server.
>
>
> What is the use case for multiple sessions with different identity pairs
> over a single TLS connection? I don't know if it is just me, but this
> seems quite ... odd?
Well, again, if it was efficient, one could imagine lots of uses. Any of
the usual reasons for multiplexing would apply.
> Maybe it was to accomodate the Apache HTTPD's desire to allow multiple
> identity settings per directory?
I don't think so. The original rationale I heard for mid-connection
renegotiation was to facilitate re-keying the connections after a certain
amount of time or number of bytes had used the old keys. This use case
would seem to likewise assume that the identifies don't change when the
re-keying occurs. I think the multiplexing angle just fell out of the
combinatorics.