Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jan 2010 15:40:07 +0100 (MET)

Kemp, David P. wrote:
> 
> Amazon and Google are free to accept SSLv2 as well as TLSv1.x-unpatched
> (minor MSbit unset) if they perceive the benefit of communicating to be
> greater than the risk of being attacked.   That has no bearing on
> whether the protocol spec for TLSv1.x-patched requires aborting
> connections with bozo endpoints, which of course it should.   Service
> providers/consumers can make their own choice of which protocol versions
> and ciphersuites to accept, with the knowledge that more restrictive
> choices will lock out some endpoints.   It has always been thus.

I don't understand what you mean.

If by "accept TLSv1.x-unpatched" you mean initial handshakes with the
installed base of SSLv3, TLSv1.0, TLSv1.1 or TLSv1.2 without the
renegotiation protection then your assertion is flawed.

There is absolutely _NO_ known security problem and no vulnerability for
a server to accept an initial handshake with the existing SSLv3, TLSv1.0,
TLSv1.1 or TLSv1.2 protocol, even when the ClientHello handshake
message does neither contain SCSV nor an empty extension RI.

The possibility for an "attack" where an old client's renegotiation
handshake is proxied into the initial handshake of a server is of
no concern to the server.  That's purely a client issue and has the
prerequisite that the client completely botches the server authentication
on the initial handshake and is equivalent in effectiveness to XSRF, XSS
and server impersonation -- something that protected TLS renegotiation
can not protect from.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Tue, 12 Jan 2010 09:17:32 -0600

> message does neither contain SCSV nor an empty extension RI.

Baloney!

> no concern to the server.

TLS is a network data security protocol. Both parties have an interest
in the security of the connection.

If a client has the attacker's data in his input buffer, then a
legitimate server's handshake provides a certificate which the client
interprets as authenticating the previous data, the attacker has stolen
the servers credentials!

(Interpreting TLS credentials over a connection this way was previously
thought to be a valid and secure thing to do, and is made so by the RI
extension.)

> That's purely a client issue and has the
> on the initial handshake

TLS specifies no requirement for the client to authenticate the server
on the initial handshake. It is completely within the spec for a client
to negotiate an anon-anon connection which is then upgraded to anon-cert
or cert-cert.

Regardless, this necessary requirement for security (that a client must
fully validate and verify the server's certificate during and not after
every handshake) is non-obvious and basically undocumented for
application developers.

Heck, most of us didn't even know renegotiation existed or that our SSL
stacks would do it automatically. There are surely applications coded by
competent and conscientious developers which do not behave this way only
because no one was aware of the need to do so. And that need only exists
because TLS renegotiation was vulnerable to a MitM attack before this fix!

> and is equivalent in effectiveness to XSRF, XSS

You can't have it both ways. You can't say there's "absolutely _NO_
known security problem" and that "protected TLS renegotiation can not
protect from" it.

But in fact, there is an attack. The good news is that having both
endpoints patched to support RI, or just one endpoint patched and
configured in strict-secure mode, does protect your connection from this
attack.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jan 2010 16:37:38 +0100 (MET)

> to negotiate an anon-anon connection which is then upgraded to anon-cert

That is a client-problem and the only means to fix this is to
update the client.  Personally, I consider a client plain stupid to do so.
I consider the server-anonymous ciphersuites much more dangerous
than the EXPORT ciphersuites or even the non-encrypting ciphersuites.

And most of the installed base of clients does not seem to offer
server-anonymous ciphersuites.

Keep in mind that it has been known and documented for several years that
DH_anon ciphersuites on the initial handshakes are susceptible to
man-in-the-middle attacks.

So please stop making such a big fuzz about them.

> known security problem" and that "protected TLS renegotiation can not

There is _NO_ known security problem in the TLS protocol.
There are only well-known and documented security problems with
the use of DH_anon ciphersuites on the initial TLS handshake.

There may be a number of flawed assumptions out there created
by clients that use the technology in an incorrect fashion.

> 
> But in fact, there is an attack.

There are possibilities to attack clients.  There is no possibility
to attack the TLS protocol.

> The good news is that having both endpoints patched to support RI,
> or just one endpoint patched and configured in strict-secure mode,
> does protect your connection from this attack.

It protects from only one particular incarnation of a number of
same-effect attacks on the same flaw in the clients architecture.

-Martin

---

From: Steve Dispensa <[email-masked]>
Date: Tue, 12 Jan 2010 09:42:31 -0600

> interprets as authenticating the previous data, the attacker has  

FWIW, I believed as Martin did in the early days while we were trying  
to work out the implications of the attack, but I've come to believe  
that Marsh is right - letting a client get data into his input buffer  
that is subsequently authenticated by a legitimate server is obviously  
a bad thing, and there's enough vagueness in real implementations (and  
complete silence in documentation) that I would be shocked if someone  
weren't vulnerable to this attack.

Now, of course, it's a client attack at that point, not a server  
attack, so one might reasonably wonder whether it's the server's  
responsibility to defend against it. (A patched client that indicates  
support for safe renegotiation to a server that also supports it will  
defeat this attack, without the server doing anything special.)

Still, I think you can make an argument about total Internet security  
that says that servers shouldn't negotiate with unpatched clients.  
That obviously involves a giant trade-off in the short term, but don't  
be caught thinking that there is no security impact to agreeing to  
negotiate (as opposed to re-negotiate) with an unpatched client.

  -Steve

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 12 Jan 2010 10:43:33 -0500

Perhaps I misunderstand the issue, but if there is absolutely no
known security problem in the absence of C->S signaling (ClientHello
contains neither SCSV nor empty RI), then it would seem that
C->S signaling is superfluous and should have been omitted from
the renego spec.  I inferred from its existence that it served
some useful purpose.

If a renegotiation attack exists (which I also infer from the
urgent discussions over the past several months), then either
a client or a server may wish to guarantee that it is not
subject to that attack.

The only way to provide that guarantee is for the new protocol
spec to require that both client and server support the new
protocol or abort the connection.  If the attack could be
prevented by modifying only clients, then the spec would not
have required modifications to the installed base of servers,
and vice versa.

That is not a policy decision embedded in protocol, it is a
truth in advertising requirement.  If a client's or server's
policy is that communication is more important than resistance
to renegotiation attack, than that policy is expressed by accepting
connections using the SSLv3, TLSv1.0, TLSv1.1, and TLSv1.2
protocols.

Dave

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, January 12, 2010 9:40 AM
To: Kemp, David P.
Cc: [email-masked]
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

There is absolutely _NO_ known security problem and no vulnerability for
a server to accept an initial handshake with the existing SSLv3,
TLSv1.0,
TLSv1.1 or TLSv1.2 protocol, even when the ClientHello handshake
message does neither contain SCSV nor an empty extension RI.

prerequisite that the client completely botches the server
authentication

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Tue, 12 Jan 2010 10:31:19 -0600

Steve Dispensa wrote:
> 
> Now, of course, it's a client attack at that point, not a server attack,
> so one might reasonably wonder whether it's the server's responsibility
> to defend against it.

If it were a buffer overflow in the client or server code, then it would
be a client- or server-specific attack.

In this case, it's doable with ordinary valid protocol structures and at
least one case doesn't depend on the particulars of the implementation
of either side. To me, that makes it a protocol attack.

Turn it around: Consider the demonstrated attack where MitM renegotiated
with the Twitter server and caused the user of the client to publicly
tweet his own password. Just because it was the server which saw the
renegotiation does that make it only the concern of the server? A year
from now, will you be willing to conduct your online banking with an
unpatched server on the logic that it's "not my responsibility"?

Again, TLS is a general-purpose network data security protocol that's
supposed to offer some basic guarantees. Any break in those guarantees
is a break in the protocol. Whether or not the loss of any specific
guarantee represents a significant problem for a specific party using
some specific application layer protocol is irrelevent to the security
analysis of TLS.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jan 2010 17:40:39 +0100 (MET)

> the renego spec.  I inferred from its existence that it served

We need the C->S signaling in order to allow the S->C signaling,
because the originial SSL&TLS protocols do not provide sufficient
slack for S->C signaling without prior C->S signaling.

Technically a S->C signaling for the initial handshake would be
sufficient to prevent an updated client from having a client
perform an old renegotiation with an updated server.  Doing
it both ways makes it more robust, and provides additional
room for policy decisions.

> connections using the SSLv3, TLSv1.0, TLSv1.1, and TLSv1.2

A TLS client or TLS server that does _not_ interoperate with an old
TLS implementation on the initial handshake is simply not compliant
to whatever protocol (SSLv3, TLSv1.0, TLSv1.1 or TLSv1.2) is
negotiated.

The new specification about (secure) TLS renegotiation _only_
deprecates an optional feature of the existing protocol and
adds a new optional feature for them.  This spec does _NOT_
change the core protocol.  Otherwise it would not be an
update, but a new protocol.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jan 2010 17:52:45 +0100 (MET)

> some specific application layer protocol is irrelevent to the security

Your "conceived" attack has the prerequsite of the client completely
botching the server authentication.

The DH_anon ciphersuites have been known and documented to be
susceptible to man-in-the-middle attacks for several years.
This much more a defect in the design of the DH_anon ciphersuites, not
of the TLS protocol itself.  This flaw of those ciphersuites seems
to have been so non-interesting, that no-one has tried to do anything
about it.

Btw. the TLS secure renegotiation spec does _not_ affect the
susceptibility of the DH_anon ciphersuite to man-in-the-middle
attacks in any way.

Which particular (broken) clients do you have in mind that
you think need to be educated with a complete ban on interoperability?

If you want to make your servers "anal" about clients that allow
DH_anon ciphersuites, you could alternatively make your server
detect such clients and either show them special greeting pages
when they connect or abort/fail the handshake for _those_ only
(this is going to be a much smaller group).  Of the hundreds of
millions clients out there that are currently unpatched, only a
small fraction is "defective" in that it implements or
offers DH_anon ciphersuites.  

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Tue, 12 Jan 2010 11:22:06 -0600

> to whatever protocol (SSLv3, TLSv1.0, TLSv1.1 or TLSv1.2) is

I can write an HTTPS server that refuses to talk to clients which do not
send the SNI extension. I can write a client that refuses to talk to a
server that doesn't supply some obscure field in the server cert. Don't
say it's "simply not compliant" to refuse to talk to somebody you decide
not to trust.

> adds a new optional feature for them.

That's news to me.

> This spec does _NOT_

Here's the part about "Updates:". Those look like "core protocol" RFC
numbers to me, but I suppose it's academic.

> Network Working Group                                        E. Rescorla
> Internet-Draft                                                RTFM, Inc.
> Updates:  RFCs 5246, 4366, 4347,                                  M. Ray
> 4346, 2246 (if approved)                                     S. Dispensa
> Intended status:  Standards Track                            PhoneFactor
> Expires:  July 8, 2010                                          N. Oskov
>                                                                Microsoft
>                                                             Jan 04, 2010

Maybe in theory, this is an optional extension, don't implement it if
you don't want it. But you'll probably have to explain to your customers
why you won't fix something their vulnerability scanners are complaining
about.

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Tue, 12 Jan 2010 11:44:16 -0600

Martin Rex wrote:
> susceptible to man-in-the-middle attacks for several years. This much
>  more a defect in the design of the DH_anon ciphersuites, not of the 
> TLS protocol itself.  This flaw of those ciphersuites seems to have 
> been so non-interesting, that no-one has tried to do anything about 
> it.

It's a fundamental property of anon-anon connections, not any "defect in
the design of DH".

> susceptibility of the DH_anon ciphersuite to man-in-the-middle 

Not true.

The RI fix allows you to negotiate an anonymous connection then
renegotiate it to provide certificate authentication which retroactively
covers data exchanged over the previous session.

This is how HTTPS client certificates work, but you know that already.

> Which particular (broken) clients do you have in mind that you think 
> need to be educated with a complete ban on interoperability?

Probably anything implemented with Perl:

http://search.cpan.org/dist/Net_SSLeay.pm/SSLeay.pm
> At this moment the implementation of verify_callback is crippeled in 
> the sense that at any given time there can be only one call back 
> which is shared by all SSL contexts, sessions and connections...
> ...
> KNOWN BUGS AND CAVEATS
> 
> Callback set using SSL_set_verify() does not appear to work. This may
> well be eay problem (e.g. see ssl/ssl_lib.c line 1029). Try using
> SSL_CTX_set_verify() instead and do not be surprised if even this
> stops working in future versions.
> 
> Callback and certificate verification stuff is generally too little
> tested.

Except perhaps things using a higher-level
Net::HTTP("https://dns.name/")-type API.

Take a look at the client example code:
http://search.cpan.org/dist/Net_SSLeay.pm/SSLeay.pm#EXAMPLES
I would say it's vulnerable to this except that it doesn't bother to
check the name on the cert at all. :-)

Show me one tutorial on the web of "Here's how to use this SSL/TLS
library safely" which provides example code that does this correctly. It
may exist, but I haven't found it yet. The fact that I haven't found it
suggests strongly to me that there are plenty of vulnerable client apps
out there.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jan 2010 19:15:53 +0100 (MET)

> It's a fundamental property of anon-anon connections, not any "defect in

It's a defect in the design of the DH_anon ciphersuites which lead
to the deprecation of these ciphersuites in rfc-5246 (TLSv1.2)--
and if you check, these ciphersuites are quite difficult to find
(being enabled by default) in most of the installed base of
SSLv3, TLSv1.0 and TLSv1.1 as well:

rfc-5246, Appendix A.5 (mid of page 76):

   The following cipher suites are used for completely anonymous
   Diffie-Hellman communications in which neither party is
   authenticated.  Note that this mode is vulnerable to man-in-the-
   middle attacks.  Using this mode therefore is of limited use: These
   cipher suites MUST NOT be used by TLS 1.2 implementations unless the
   application layer has specifically requested to allow anonymous key
   exchange.  (Anonymous key exchange may sometimes be acceptable, for
   example, to support opportunistic encryption when no set-up for
   authentication is in place, or when TLS is used as part of more
   complex security protocols that have other means to ensure
   authentication.)

> Probably anything implemented with Perl:

While you started off with clients using DH_anon plus renegotiation,
you are now quoting clients that completely botch server authentication.

> suggests strongly to me that there are plenty of vulnerable client apps

What you quote is SSL clients that effectively do not perform
server endpoint identification at all, not even the weak endpoint
identification suggested by rfc-2818 (HTTP over TLS).

To such clients, an MitM attacker can always perform a complete
server impersonation, and secure TLS renegotiation is not going
to affect that at all.  Unless the core TLS protocol offers
some kind of channel bindings (which the current spec doesn't),
there is no need to splice TLS sessions.  A simple traditional MitM 
is perfectly sufficient to attack all scenarios that do not use
SSL client certs (which is the vast majority), but either
basic authentication, form-based authentication, cookie-based
authentication or "negotiate" authentication (NTLM or Kerberos tokens).

Please do _not_ mislead others about what secure TLS renegotiation
addresses and fixes, and what it leaves untouched and in whatever
miserable situation that it has always been.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 12 Jan 2010 13:23:35 -0500

That is simply a terminology issue.  Whether you call TLSv1.1 (without
renegotiation protection) and TLSv1.1p (with protection) different
protocols or the same protocol with different features, the point
is that the UI must have a separate checkbox for the version/feature.
The fact that there will be a new RFC and that it assigns a new minor
version number influenced my terminology, but it is fine to regard
the "p" as a feature instead.

If only "p" versions are checked or if the "p" feature is checked
(depending on which way the UI is designed), then an RFC-WXYZ-compliant
endpoint MUST either abort any connection with partners that do
not support protection or it MUST disable its own support for
renegotiation.

This is no different than ciphersuites - if your policy is to
require AES encryption, then you would demand that the partner
also support AES or you would refuse to connect.  If your policy is
that single DES is good enough, then you will check both the DES
and AES boxes and communication with DES-only installed-base
partners is possible.

Dave

(To head off other red herrings, the UI checkbox is just
an example - obviously policy may be expressed using header files,
config files, registry settings, or otherwise.)

-----Original Message-----

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Tue, 12 Jan 2010 12:55:36 -0600

Martin Rex wrote:
>>> susceptible to man-in-the-middle attacks for several years. This
>>> much more a defect in the design of the DH_anon ciphersuites, not
>>> of the TLS protocol itself.  This flaw of those ciphersuites
>>> seems to have been so non-interesting, that no-one has tried to
>>> do anything about it.
>> It's a fundamental property of anon-anon connections, not any
>> "defect in the design of DH".
> 
> It's a defect in the design of the DH_anon ciphersuites which lead to
> the deprecation of these ciphersuites in rfc-5246 (TLSv1.2)-- and if
> you check,

How about you check freaking Wikipedia
http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange

> In the original description, the Diffie–Hellman exchange by itself
> does not provide authentication of the communicating parties and is
> thus vulnerable to a man-in-the-middle attack. A person in the middle
> may establish two distinct Diffie–Hellman key exchanges, one with
> Alice and the other with Bob, effectively masquerading as Alice to
> Bob, and vice versa, allowing the attacker to decrypt (and read or
> store) then re-encrypt the messages passed between them. A method to
> authenticate the communicating parties to each other is generally
> needed to prevent this type of attack.

It's a well-understood and fundamental limitation of all anon-anon
connections, not a "defect" in a particular ciphersuite.

> these ciphersuites are quite difficult to find (being
> enabled by default) in most of the installed base of SSLv3, TLSv1.0
> and TLSv1.1 as well

So they decided to make it difficult for their customers to shoot
themselves in the foot. Probably a wise decision.

> [...] (Anonymous key exchange may sometimes be acceptable, for 

Did you see that part about "Anonymous key exchange may sometimes be
acceptable" and "other means to ensure authentication"?

Conducting safe renegotiation to elevate the level of authentication on
the connection is such a means.

> [...]
> What you quote is SSL clients that effectively do not perform server
> endpoint identification at all, not even the weak endpoint 
> server impersonation, and secure TLS renegotiation is not going to
> affect that at all.

It is sad, isn't it?

How about this pseudo-code:

String dnsName = "secure.example.com";
IpAddress ip = dnsResolve(dnsName);
Socket s = connectTo(ip);

SSL ssl = connectSSL(s, REQUIRE_SERVER_CERT);

Cert serverCert = ssl->getPeerCert();

if (serverCert->getSubjectName() != dnsName)
    dieWithError("cert mismatch");

exchangeCriticalData(ssl);

This code was secure with SSLv2, but silently becomes vulnerable when
used with SSLv3+ and an upatched stack that handles renegotiation
transparently for the app (most of them).

Patching both the client and server to support RI makes this application
code secure again. It also re-enables interesting new possibilities.

not vulnerable -> vulnerable -> not vulnerable
   SSLv2            SSLv3+        SSLv3+RI

I believe this code is representative of many applications.

I don't know how to put it more simply than that.

>> library safely" which provides example code that does this
>> correctly. It may exist, but I haven't found it yet. The fact that
>> I haven't found it suggests strongly to me that there are plenty of
>> vulnerable client apps out there.

Still waiting.

> miserable situation that it has always been.

Likewise.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jan 2010 20:39:15 +0100 (MET)

> >> message does neither contain SCSV nor an empty extension RI.

Steve and Marsh.

There is a document, approved by the IESG, where both of you are listed
as document co-authors, and it says this:

http://tools.ietf.org/html/draft-ietf-tls-renegotiation-03#section-4.3

   4.3. Server Considerations

   If the client does not offer the "renegotiation_info" extension or
   the TLS_RENEGO_PROTECTION_REQUEST SCSV then this indicates that the
   client does not support secure renegotiation.  However, because the
   above attack looks like two handshakes to the server, the server can
   safely continue the connection as long as it does not allow the
   client to renegotiate. 

I'm fine with that "the server can safely continue the connection as long
as it does not allow the client to renegotiate."

I don't want to continue discussing this issue.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Tue, 12 Jan 2010 13:55:23 -0600

Martin Rex wrote:
> 
> There is a document, approved by the IESG, where both of you are
> listed as document co-authors, and it says this:
> 
> I'm fine with that "the server can safely continue the connection as
> long as it does not allow the client to renegotiate."

I'm not, and I argued against the inclusion of that language repeatedly.

The explanation I was given, IIRC, was that it was just referring to
"the above attack" which was the one simplest case to explain. It was
not supposed to be exhaustive of all attacks.

I firmly believe that the language "the server can safely continue the
connection as long as it does not allow the client to renegotiate" is in
error.

It was not worth continuing to argue about if it delays the
implementation of the fix (which is the same in any case).

> I don't want to continue discussing this issue.

Agreed.

I'll just have to make my point with working exploit code.

- Marsh

---

From: Kyle Hamilton <[email-masked]>
Date: Tue, 12 Jan 2010 15:55:32 -0800

The only way to prevent a reneg-naïve client from creating any
security risk to the server is to:
1) enforce the highest security that anything on that server requires
as a prerequisite to *all* connections to that server, and
2) use mutual authentication instead of only authenticating one side.

The requirement: An unauthenticated client that sends a command to the
server that requires it to have higher access credentials than the
connection has cannot cause the server to initiate a renegotiation.

Not meeting that requirement is what got us into the problem in the first place.

I join Marsh in dissenting to that "safely" message, as there is NO
way to safely renegotiate unless both sides are mutually authenticated
before the first bytes are received by the server process (as a client
of the TLS implementation, since the TLS implementation handles the
crypto part of the transaction).  Even then, that is only as far as
the identification doesn't change.

(Note: Firefox specifically disables HTTP pipelining over TLS
connections by default.)

-Kyle H

On Tue, Jan 12, 2010 at 11:55 AM, Marsh Ray <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>