Subject: [TLS] Safe vulnerability probing of servers possible w/o extensions?

From: Nelson B Bolyard <[email-masked]>
Date: Sun, 15 Nov 2009 14:17:21 -0800

I believe that, if a client "knows" that a certain TLS or SSL 3.0 server
does not perform renegotiation (has disabled renegotiation), then the
client may safely initiate TLS/SSL3 handshakes with that server, without
any new extensions or other protocol changes.

This leads me to wonder if there is a way by which a client can "probe" a
remote server to determine whether that server does or does not support
renegotiation, without possibility of itself falling victim to this
renegotiation attack in the process of that probing.  Is there a "safe"
way to probe a remote server?

It seems to me that a client might safely conduct such a probe as follows:

1) Connect to the server via TCP.
2) Initiate and complete a TLS 1.0 (or SSL 3.0) handshake, with no session
ID (no attempt to resume any previously established session), and with no
client authentication, and with no hello extensions.
3) Do not send ANY application data.
4) When the handshake is complete, immediately initiate a second handshake
also with no session ID, with no client authentication, with no application
data, and with no hello extensions.
5) attempt to complete the renegotiation.  Then disconnect.

If the renegotiation completes, the server is known to be vulnerable.
If it does not, then repeat the test, but in step 3, send a simple anonymous
request (e.g. http GET / request) with no identification and authentication
of any form (no cookies, no basic auth, etc.)

Again, if the renegotiation completes, the server is known to be vulnerable.
If it does not, then the probability that the server supports renegotiation
has been established to be low.

I think this is "safe", in that, even if an attacker is attempting to use
this client's initial handshake in a renegotiation attack, the client
does not provide any I&A information that could be used to authorize the
attacker's transaction, or that the attacker could subsequently replay.

Are there any big holes in this scheme?

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 14:41:00 -0800

> any new extensions or other protocol changes.

Yes.

> way to probe a remote server?

I've thought about this too and my answer was, to some extent yes, but  
not entirely reliably.

> If the renegotiation completes, the server is known to be vulnerable.

This is not entirely true because a server that supports renegotiation  
only when the connection is quiet and there's no unhandled application  
data around could be secure even with old-style renegotiation.  I  
don't care too much about this special case, though: If renegotiation  
completes in this probe, the server is *probably* vulnerable, and we'd  
better flag it as such.

> Again, if the renegotiation completes, the server is known to be  

Yes.

> has been established to be low.

No -- maybe it's a server that will do renegotiation only if it has  
initiated renegotiation itself.  I.e., it will only accept a new  
ClientHello if it has sent a HelloRequest.

> Are there any big holes in this scheme?

Doing this probe is not dangerous (everything the clients does, the  
attacker could do on its own), and it will flag servers that are  
(probably) vulnerable.  However, you won't ever be entirely certain  
that a server doesn't support renegotiation.

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Sun, 15 Nov 2009 16:55:28 -0600

> data, and with no hello extensions.

IIS serves will hang up on you right there.

> Are there any big holes in this scheme?

Attacker can simulate a safe server when you probe it, yet exploit you
with a vulnerable server once you trust it.

- Marsh

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sun, 15 Nov 2009 23:56:28 +0100

Nelson,

Opera may be the client with the most complex TLS feature discovery  
mechanism, and it is IMO too complex already, so I am not going to be  
adding such a mechanism to Opera.

What I am intending to implement in Opera, whenever the WG settles on a  
mechanism where the client and server can exchange information about their  
secure renegotiation capability, is the following:

   Stage 1: Inform the user in secondary chrome about servers that does not  
support secure renegotiation
   Stage 2: At some time in the future Opera installations will start  
warning the user through warning dialogs that the server may not be  
secure. At this stage the sites will also lose the padlock indication.
   Stage 3: Some time after that Opera will start refusing to establish  
connections with such servers.

The functionality for these three stages will be built into the first  
version we ship with the new functionality, and will be controlled by an  
auto-update preference that is already (in Opera 10) controlling similar  
stage 2 and 3 functionality for MD5 and SHA-1 support in certificates, and  
for SSL v3 support.

IMO the dates for stage 2 and stage 3 should be included, as MUSTs, in the  
RFC for the specification that comes out of this discussion. The reason  
for this is, brutally put, that if there is no sunset for the unpatched  
servers, then the work on a protection mechanism is wasted effort. In a  
transition period clients will have to support unpatched servers, but the  
length of the period should be clear from day one. IMO the transition  
period should be much closer to 1 year than 5 years.

On Sun, 15 Nov 2009 23:17:21 +0100, Nelson B Bolyard <[email-masked]>  
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Nov 2009 00:23:53 +0100 (MET)

> It seems to me that a client might safely conduct such a probe as follows:

First of all, the idea that clients need to probe servers is a
fatally flawed idea.  There is a part of the TLS protocol called
handshake which is supposed to negotiate an interoperable set
of protocol features to perform a communication.

Clients simply want to connect to some servers and talk to them
secrely.  Client do _NOT_ want to probe servers and they do not
want to maintain lists of servers and the protocol features they
support in order to be able to talk to them.

When it happens to TLS that clients need to start doing this in order
to be able to talk to a server on first connect, then we have really
fucked up the protocol.

>
>   [complex probing scenario deleted]
>

It looks like a number of daring assumptions.

TLS session IDs are assigned by the server and at the discretion
of the server, the client has no say in this.

MS IIS does not accept unsolicited renegotiations, Marsh mentioned
that it will close the connection.

Really, out best bet is to make this fix a simple as possible and
equally suited for all protocol version 0x03,0x00->0x03,0x03 and
then we may actually come to the point where we can stop talking
to unpatched servers.

If the fix requires a TLS extension, does _not_ cover SSLv3 and
requires a TLS extension in the ClientHello in the initial handshake
of a connection, then it

    - will cause interop problems during the transition

    - which will require careful patch installation planning

    - which will slow down adoption of the patch considerably
      and lengthen the transition period by factors

    - which, all in all, will unnecesarily cost a lot of people
      a lot of time and money

    - and has a much higher risk to leave a non-negligable amount
      of unpatched servers at the end of the transition period.

Therefore, we should really change the signaling to something
that is more backwards compatible and easier to implement.

Drop the exchange of the finished messasges from the renegotiation
handshake entirely and adjust the definition of the handshake
message hash that goes into the CertificateVerify and the Finished
messsage instead to include the verify_data of the client.finished
and server.finished message instead on a renegotiation handshake.

I have not seen one single disadvantage to this approach on this
list.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Sun, 15 Nov 2009 15:49:23 -0800

> to be able to talk to a server on first connect, then we have really

We know that TLS can be fixed, that servers that implement hello extensions
can be fixed, and that servers that are willing to implement the next
version of TLS can be fixed, and that all of these can be fixed in a way
that requires no probing and no whitelists.  I've done it.

But we keep being told that there exists a huge body of servers with which
browsers work today, servers that are either still SSL 3.0 servers, or
non-compliant TLS servers that do not accept client hellos bearing hello
extensions, and that clients must continue to be able to interoperate
with those servers without vulnerability.  I am exploring how that can be
accomplished, if it can be accomplished.