Subject: [TLS] Server-only solution - proposed text

From: Yaron Sheffer <[email-masked]>
Date: Mon, 23 Nov 2009 11:24:06 +0200

Hi,

Both proposals on the table (draft-ietf-tls-renegotiation-00 and Martin's I-D-to-be) are making changes to the protocol, and therefore will only become effective once a good percentage of clients have been patched. In the meantime, administrators could fix their (patched) servers locally in many cases, without waiting for the client population to get fixed. I propose to add the following short section to both drafts:

X. Server-Side Mitigation Procedures

We assume that it will take a significant amount of time until the protocol change defined in this document is adopted by all clients. However, in many cases a server-only mitigation is possible in the interim: many TLS applications, and in particular, many Web (HTTPS) applications, do not require renegotiation for proper operation. Implementations of the current document (unless they employ a strict policy, allowing only protected clients to connect) SHOULD be configurable to disallow TLS renegotiation with vulnerable clients. The following three settings are RECOMMENDED:

-       Allow any renegotiation with unprotected clients.
-       Allow only server-initiated renegotiation with unprotected clients.
-       Disallow renegotiation with unprotected clients..

The default setting is a matter of vendor and/or local policy.

[Note: this contradicts the sentence "Servers SHOULD NOT allow clients to renegotiate without using this extension" in the Security Considerations of draft-ietf-tls-renegotiation-00, which unfortunately is unlikely to be followed by many implementers.]

Thanks,
            Yaron

---

From: <[email-masked]>
Date: Mon, 23 Nov 2009 13:50:17 +0100

Earlier Eric noted that if no application data is exchanged between the initial and renegotiation handshake (i.e. no application data is sent using the 1st session), this would be safe even without protocol changes. Should this be included in this section, too?

Best regards,
Pasi
(not wearing any hats)

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Yaron Sheffer
Sent: 23 November, 2009 11:24
To: [email-masked]
Subject: [TLS] Server-only solution - proposed text

Hi,

Thanks,
            Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 23 Nov 2009 15:48:49 +0200

Hi Pasi,

To clarify, are you proposing to add a vendor or an administrator requirement. That is: is the vendor supposed to detect these situations and allow renegotiation, even when a strict server is accessed by an unpatched client? Or do you expect the administrator to understand their application well enough to configure the server leniently in this case? I consider the latter a bit of a stretch.

Thanks,
            Yaron

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 23, 2009 14:50
To: Yaron Sheffer; [email-masked]
Subject: RE: Server-only solution - proposed text

Best regards,
Pasi
(not wearing any hats)

Hi,

Thanks,
            Yaron

---

From: <[email-masked]>
Date: Mon, 23 Nov 2009 14:56:21 +0100

Hi Yaron,

I was proposing a mitigation for the server TLS library implementation (not administrator) -- if it hasn't received any application data before renegotiation,  it could allow renegotiation (and if "interleaved" application data is received during the renegotiation handshake, tear down the connection).

(I don't think this can be correctly done by the application in most cases, especially since you could receive application data during the renegotiation handshake.)

Best regards,
Pasi
(not wearing any hats)

From: ext Yaron Sheffer [mailto:[email-masked]]
Sent: 23 November, 2009 15:49
To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
Subject: RE: Server-only solution - proposed text

Hi Pasi,

Thanks,
            Yaron

Best regards,
Pasi
(not wearing any hats)

Hi,

Thanks,
            Yaron

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Nov 2009 18:30:04 +0100 (MET)

[email-masked] wrote:
> 
> I was proposing a mitigation for the server TLS library implementation
> (not administrator) -- if it hasn't received any application data
> before renegotiation,  it could allow renegotiation (and if
> "interleaved" application data is received during the renegotiation
> handshake, tear down the connection).
> 
> (I don't think this can be correctly done by the application in most
> cases, especially since you could receive application data during
> the renegotiation handshake.)

That observation about app data interleaved with the renegotiation
is significant! 

This could be a conceivable backwards interoperability scenario for
updated servers with old clients that can not be upgraded for whatever
reason and use the renegotiation without prior app-data exchange only
for purposes like client identity protection.

The more common use case with HTTP over TLS and on-demand authentication
through TLS renegotiate (ab)uses the possibility to send app data
over the initial connection and let the server decide whether to
request client authentication after having seen the request.

To me, it looks like the only good advice for the latter is
to get server and clients updated as soon as humanely possible
and disable old renegotiation completely on the server.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 23 Nov 2009 19:29:00 +0000

> [Note: this contradicts the sentence "Servers SHOULD NOT allow clients to renegotiate without using this extension" in the Security Considerations of draft-ietf-tls-renegotiation-00, which unfortun…

I disagree -- it is entirely reasonable and necessary for servers to
disable renegotiation with unpatched clients immediately.

In any case, the proposed text above is misleading, since it gives the
impression that a connection that is seen as a renegotiation by the
server, actually is a renegotiation on the client side. In fact it
may be an instance of the attack, and there's no way for the server
to know that.

In other words, allowing renegotiations with unpatched clients is not
fixing the security flaw, it is just dumping the responsibility for
fixing it onto the clients. Under the assumption that "it will take a
significant amount of time until the protocol change defined in this
document is adopted by all clients", that is an unreasonable thing to
do.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: Marsh Ray <[email-masked]>
Date: Tue, 24 Nov 2009 14:43:44 -0600

[email-masked] wrote:
> Earlier Eric noted that if no application data is exchanged between the
> initial and renegotiation handshake (i.e. no application data is sent
> using the 1st session), this would be safe even without protocol
> changes. Should this be included in this section, too?

In order for that scenario to be 'safe' we would need to find some
language in the TLS spec, there since the beginning, which says that an
application MUST NOT attribute any semantics to the successful
authentication of the remote party. I don't believe the spec has any
such language.

There is probably some application out there which interprets a
connection from an authenticated client (or to an authenticated server)
as an "event" with real semantics.

Using SSH as an analogy, sometimes a login shell is set to, say, a
backup program. Commands get launched when the user authenticates.

Back with TLS, Microsoft IIS, for example, has a
client-certificate-to-user mapping facility. It's certainly possible
that the connection from such authenticated clients could trigger
certain "non-idempotent" activities, even if just adding false log records.

- Marsh

---

From: <[email-masked]>
Date: Wed, 25 Nov 2009 14:03:18 +0100

Hi Marsh,

You're right that such applications could exist, but it seems their
problems are quite independent of renegotiation.

Even if all clients and servers implement the new secure renegotiation
fix, the MitM could just forward the handshake messages as-is (so it
would look like an initial handshake to both the client and the
server)....?

Best regards,
Pasi
(not wearing any hats)

> -----Original Message-----
> From: ext Marsh Ray [mailto:[email-masked]]
> Sent: 24 November, 2009 22:44
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [TLS] Server-only solution - proposed text
>

---

From: Marsh Ray <[email-masked]>
Date: Wed, 25 Nov 2009 10:53:20 -0600

> would look like an initial handshake to both the client and the

Oh @(#$&!

Is there nothing in the spec which stops the client from flushing his
output buffer down an insecure channel at that point?!

Sure, supposedly he should have waited for the server's Finished message
and checked the cert and all that. But if he implemented the cert
checking in a callback (as he should), that might not process until the
server's Finished message arrives (which never happens because MitM
drops it).

- Marsh

---

From: <[email-masked]>
Date: Wed, 25 Nov 2009 18:10:55 +0100

Marsh Ray wrote:

> > Even if all clients and servers implement the new secure
> > renegotiation fix, the MitM could just forward the handshake
> > messages as-is (so it would look like an initial handshake to both
> > the client and the server)....?
> 
> Oh @(#$&!
> 
> Is there nothing in the spec which stops the client from flushing
> his output buffer down an insecure channel at that point?!
>
> Sure, supposedly he should have waited for the server's Finished
> message and checked the cert and all that. But if he implemented the
> cert checking in a callback (as he should), that might not process
> until the server's Finished message arrives (which never happens
> because MitM drops it).

The client MUST wait for the server's Finished message and verify it
before sending (or accepting) any application data. But in the
examples you gave, there was no application data -- the "event" was
triggered just by a successful handshake.

So the MitM doesn't actually have to drop any messages, either, just
forward all packets unchanged (which doesn't really count as 
an "attack", even...)

Best regards,
Pasi
(not wearing any hats)

---

From: Marsh Ray <[email-masked]>
Date: Wed, 25 Nov 2009 11:29:25 -0600

OK, I found it http://tools.ietf.org/html/rfc5246 :
> Once a side
>       has sent its Finished message and received and validated the
>       Finished message from its peer, it may begin to send and receive
>       application data over the connection.

OK, forget the client's data then.

However, I don't see anything that stops the server from sending
plaintext encrypted with a compromised key to a client which was
successfully authenticated by client certificate.

> forward all packets unchanged (which doesn't really count as 

Well, MitM might want to rig up a compromised key for the server to
transmit with. The client doesn't seem to be able to fully validate the
server's cert until he receives the Finished message. Maybe he could do
some checking in theory, but not completely, otherwise what would the
Finished message be for?

So a server application can receive a connection, properly validate the
client certificate, and write an unlimited amount of data which is
encrypted by a compromised key.

I'm probably missing something, what is it?

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Wed, 25 Nov 2009 12:19:33 -0600

> I'm probably missing something, what is it?

To answer my own question, presumably the server is going to correctly
validate the client's Finished message which covers the key data in
question.

Sorry for the confusion all.

- Marsh