Subject: [TLS] matching identity, by default

From: James Manger <[email-masked]>
Date: Wed, 2 Dec 2009 00:43:17 +1100

I strongly support the consistent identity check in the Security Considerations section of draft-ietf-tls-renegotiation-01.

There may be some niche uses of TLS for which changing an identity during renegotiation makes sense. That is adequately supported by the last paragraph in the Security Considerations: "A TLS library MAY provide a means for the application to allow identity and/or server_name changes across renegotiations...". However, for 99.9...% of TLS uses an identity changing during renegotiation will be totally unexpected by the higher-layer application and can only cause problems.

A few people have argued that the consistent identity check is a separate issue that should not be addressed now. I don't think that is a fair characterisation. Even unpatched current TLS implementations  can unambiguously describe the authenticity and confidentiality of every byte of application data. The bug only occurs because apps don't expect a per-byte security context, but a per-TLS-connection security context. Allowing the authenticated identity to change per-byte does not solve this underlying mismatch between what almost all apps expect and what TLS delivers. Keeping identity consistent does narrow this mismatch.

James Manger

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Dec 2009 14:38:04 +0000

> I strongly support the consistent identity check in the Security Considerations section of draft-ietf-tls-renegotiation-01.

Fair enough.

> There may be some niche uses of TLS for which changing an identity during renegotiation makes sense. That is adequately supported by the last paragraph in the Security Considerations: "A TLS librar…

I'd buy that.

> A few people have argued that the consistent identity check is a separate issue that should not be addressed now. I don't think that is a fair characterisation. 

I'm not sure what you mean by "characterisation."

My point was simply that this *is* a different issue from the
renegotiation bug, that we're fixing that bug in "emergency"
mode and that we therefore shouldn't change *anything* else
whilst in that mode.

To give one example - rfc 2712 says how to use kerberos with
TLS. (I've no idea if that's really in use.) The text in -01
doesn't say how to handle that, but does have a MUST on
no-change. That could break something. I don't want to hold
the bug fix while we figure that out.

I just thinks its safer to do this later with some other draft
that UPDATEs 5246.

Stephen.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 3 Dec 2009 13:01:43 +0100

]On Dec 1, 2009, at 2:43 PM, James Manger wrote:

> I strongly support the consistent identity check in the Security  
> Considerations section of draft-ietf-tls-renegotiation-01.
>
> There may be some niche uses of TLS for which changing an identity  
> during renegotiation makes sense. That is adequately supported by  
> the last paragraph in the Security Considerations: "A TLS library  
> MAY provide a means for the application to allow identity and/or  
> server_name changes across renegotiations...". However, for 99.9...%  
> of TLS uses an identity changing during renegotiation will be  
> totally unexpected by the higher-layer application and can only  
> cause problems.
>
> A few people have argued that the consistent identity check is a  
> separate issue that should not be addressed now. I don't think that  
> is a fair characterisation. Even unpatched current TLS  
> implementations  can unambiguously describe the authenticity and  
> confidentiality of every byte of application data. The bug only  
> occurs because apps don't expect a per-byte security context, but a  
> per-TLS-connection security context. Allowing the authenticated  
> identity to change per-byte does not solve this underlying mismatch  
> between what almost all apps expect and what TLS delivers. Keeping  
> identity consistent does narrow this mismatch.

My point wasn't actually that I expect the peer's "identity" to change  
-- I expect that the peer's *identification information* may change in  
renegotiation handshakes, while each party should still be able to  
rely that it's continuing to talk to the *same* peer it has  
authenticated in the preceding handshake.

Your point seems to be that particularly creative use of the protocol  
may violate the latter assumption.   TLS has never meant to allow a  
new client or server application entity to enter the conversation when  
a renegotiation handshake takes place, but I agree that if this isn't  
sufficiently clear from the existing RFCs, then that's a concern  
addressing which is in the scope of the present ID.  The Security  
Considerations section of draft-ietf-tls-renegotiation-01.txt has a  
fluffy layer of FUD around this core, however, which can easily get in  
the way -- and would impose rules that don't fit well into the overall  
design of TLS renegotiations.

Here's a new proposal:

"A TLS renegotiation handshake is a new handshake, including new  
cipher suite negotiation, and new Certificate messages where  
applicable.  Accordingly, in the renegotiation handshake, clients and  
servers can use identifying information that is different from the  
identifying information used in the preceding handshake.  (For  
example, one use of renegotiation is for TLS servers to initiate  
client authentication by sending a CertificateRequest message only  
when demanded by the application layer, in response to specific  
application-layer requests.  The renegotiation handshake thus is  
expected to involve a client Certificate message when the preceding  
handshake did not.  Furthermore, cipher suite selection during  
renegotiation will have to obey any restrictions imposed by  
CertificateRequest.certificate_types, and thus may require a different  
server Certificate message.)

However, even when a TLS renegotiation handshake takes place,  
application data continues to be handled by the same application  
entity as before.  TLS implementations MUST NOT use a change of  
Certificate information to indicate that subsequent application data  
will be in the responsibility of a different client or server  
application entity.  That is, if a new or changed Certificate message  
appears in a renegotiation handshake and is successfully verified, it  
is understood that this is a change in identification information only  
and not a change in identity."

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Thu, 03 Dec 2009 07:54:01 -0600

Bodo Moeller wrote:
> TLS has never meant to allow a new
> client or server application entity to enter the conversation when a
> renegotiation handshake takes place

I disagree. The person(s) who added renegotiation clearly wanted to
enable multiple "application entities" to run on the same port 443.
These may be communicated over the same pool of active socket
connections, as Nelson Bolyard of NSS (hier of the Netscape legacy
implementation, twice removed) has described.

Whether or not that was a wise design, or whether it was implemented
perfectly is certainly debatable. We can all agree that certain
implications of this design were under-documented.

> Here's a new proposal:
> 
> "[..] TLS implementations MUST NOT use a change of Certificate
> information to indicate that subsequent application data will be in the
> responsibility of a different client or server application entity.

I don't support such wording. If someone wants to write a TLS
application layer protocol that way, there's no good reason for the spec
to prohibit it at this stage in the game.

> That
> is, if a new or changed Certificate message appears in a renegotiation
> handshake and is successfully verified, it is understood that this is a
> change in identification information only and not a change in identity."

It might not even be a swap-out change, it could be additive or have
other app-defined semantics. For example, a client or server application
could renegotiate ten times and provide ten different certificates, then
renegotiate to ephemeral Diffie-Hellman. The application protocol may be
defined to treat subsequent data as being authenticated to any or all of
the ten certificated identities.

Another point is that TLS doesn't have to run over TCP. Imagine you need
a way to securely convey authenticated data over a bare synchronous or
asynchronous link (e.g. RS-232). TLS would be a natural choice, but if
you restrict arbitrary certificate changes, you won't be able to use it
continuously. You'll have to drop out of TLS altogether and start a new
handshake, thus introducing unnecessary encryption and authentication gaps.

- Marsh

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 3 Dec 2009 17:30:50 +0100

> enable multiple "application entities" to run on the same port 443.

I don't think this is true, and certainly not clear -- for example, see:

http://www.imc.org/ietf-tls/mail-archive/msg01294.html ("This is how  
cipherSuites are renegotiated" - Eric Rescorla, 1998)
http://www.imc.org/ietf-tls/mail-archive/msg01295.html ("Hello  
requests can also be used to cause re-keying ... like, if you sent  
more data than you think you should send with a given set of keys" -  
David Brownell, 1998)

-- and do you remember http://web.archive.org/web/19990422033121/http://developer.netscape.com/tech/security/stepup/overview.html?

Also, ever since the SSL 2.0 protocol specification, the documents  
have said that the client is one application entity ("the application  
entity that initiates a connection"), and the server is one  
application entity ("the application entity that responds to requests  
for connections from clients").  If you look at the SSL 3.0  
specification, renegotiation takes place between "the" client and  
"the" server.  A scenario where one SSL-level client does multiplexing  
on behalf of multiple application-level clients, or one SSL-level  
server does multiplexing on behalf of multiple application-level  
servers, just wouldn't be covered by this.

> implementation, twice removed) has described.

Where has he described this?  (Sorry -- I've tried to find something  
using various keywords, but to no avail.)

> to prohibit it at this stage in the game.

As explained above, I don't think this would be within what the SSL/ 
TLS base specification allows -- of course you can still decide do it  
anyway, as a custom modification to the standard protocol.

Well, I guess we could cater for that, by again saying "by default":

However, even when a TLS renegotiation handshake takes place,  
application data <NEW>normally</NEW> continues to be handled by the  
same application entity as before.  TLS implementations <NEW>by  
default</NEW> MUST NOT use a change of Certificate information to  
indicate that subsequent application data will be in the  
responsibility of a different client or server application entity.   
That is, if a new or changed Certificate message appears in a  
renegotiation handshake and is successfully verified, it is understood  
that this is a change in identification information only and not a  
change in identity.  <NEW>Still any party relying on peer  
authentication remains responsible for verifying authentication  
information even on renegotiation handshakes.</NEW>

<NEW>Some application protocols might have to use the TLS protocol in  
a nonstandard setting where a single connection is used with  
renegotiation to multiplex for multiple application entities.  The  
design of such application protocols requires special care to ensure  
that application data cannot be processed or sent in an inappropriate  
context, taking into account that the TLS protocol generally allows  
application data to be interleaved with renegotiation handshakes, and  
that the record layer cannot generally be expected to preserve  
application message boundaries, and may send application data at lower  
priority than other content types.  Thus, such application protocols  
will have to specify their special requirements on TLS  
implementations.  TLS implementations to be used for such applications  
may require additional API facilities.</NEW>"

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Thu, 03 Dec 2009 12:54:38 -0600

>>> renegotiation handshake takes place

Granted, they didn't expect it to be MitM-able.

> I don't think this is true, and certainly not clear -- for example, see:

Here's what I've been reading, which goes back earlier:

http://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft302.txt

INTERNET-DRAFT                  SSL 3.0                November 18, 1996

"The client can also send a client hello in response to a hello request
or on its own initiative in order to renegotiate the security parameters
in an existing connection."

What exactly are these "security parameters" the authors are referring
to? Well the document doesn't define the term exactly, but uses it again
with more context:

"Sessions define a set of cryptographic security parameters, which can
be shared among multiple connections.  Sessions are used to avoid the
expensive negotiation of new security parameters for each connection."

"The cryptographic parameters of the session state are produced by the
SSL Handshake Protocol, which operates on top of the SSL Record Layer.
When a SSL client and server first start communicating, they agree on a
protocol version, select cryptographic algorithms, optionally
authenticate each other, and use public-key encryption techniques to
generate shared secrets."

It certainly sounds to me like the spec intended to allow anything that
was valid in an initial negotiation to be valid in a renegotiation.

Interestingly, variations on the word "renegotiate" only appear three
times. The Hello Request message does not use the term, instead it talks
about a new "negotiation". To me, this reinforces the idea that the
authors of the SSLv3 spec intended renegotiation to be fully equivalent
to a new handshake.

> Also, ever since the SSL 2.0 protocol specification, the documents have
> said that the client is one application entity ("the application entity
> that initiates a connection"), and the server is one application entity
> ("the application entity that responds to requests for connections from
> clients").  If you look at the SSL 3.0 specification, renegotiation
> takes place between "the" client and "the" server.  A scenario where one
> SSL-level client does multiplexing on behalf of multiple
> application-level clients, or one SSL-level server does multiplexing on
> behalf of multiple application-level servers, just wouldn't be covered
> by this.

The 3.0 spec uses the term "application entity" in two places"

"client               The application entity that initiates a connection
to a server."

"server               The server is the application entity that responds
to requests for connections from clients.  The server is passive,
waiting for requests from clients."

These definitions were inherited verbatim from the SSLv2 spec, so I
don't think much weight was placed on the term "application entity". In
any case, it just refers to the initial connection process which
esatablishes the roles of client and server.

But I believe one of the initial motivations of renegotiation was to
enable multiple CGI-type applications to run on the same server. These
could certainly have different authentication requirements, and
renegotiation was added (at least in part) to provide for dynamic
(re)authentication.

> using various keywords, but to no avail.)

Sorry, I think it may have been a private mail. Nelson, would you mind
posting that? I refer to it often. I have it in my box dated 10/16/2009
6:27 PM Message-ID: <[email-masked]>.

I'm sure he wouldn't mind me sharing this tidbit:

"It is also possible that, in response to a client hello request, the
client will send a client hello bearing a session ID that is not empty
and is NOT the session ID of the session presently in use on that
connection.  This can happen when the client has multiple connections
going in parallel between the same client identity session cache and the
same remote server."

Now I don't perfectly understand how Mozilla handles its "client
identity session cache" (I suspect no one does), but it sounds plausible
to me that renegotiation with resumption could, in theory, switch
between differing client certs over the same connection.

This might be fun to test, actually.

>> If someone wants to write a TLS
> As explained above, I don't think this would be within what the SSL/TLS
> base specification allows -- of course you can still decide do it

What wording in what spec prohibits it?

Everything I read is consistently "anything goes" in renegotiation, just
like an initial handshake. OpenSSL, for example, had to add new code in
order to disable renegotiation: there was previously zero special-case
handling for it.

> Well, I guess we could cater for that, by again saying "by default":

This does not appeal to me in a spec. It seems like it would be saying
"here's how you have to do it ... except if you don't want to, then just
do whatever".

> "A TLS renegotiation handshake is a new handshake, including new cipher
> suite negotiation, and new Certificate messages where applicable. 
> Accordingly, in the renegotiation handshake, clients and servers can use
> identifying information that is different from the identifying
> information used in the preceding handshake.  (For example, one use of
> renegotiation is for TLS servers to initiate client authentication by
> sending a CertificateRequest message only when demanded by the
> application layer, in response to specific application-layer requests. 
> The renegotiation handshake thus is expected to involve a client
> Certificate message when the preceding handshake did not.  Furthermore,
> cipher suite selection during renegotiation will have to obey any
> restrictions imposed by CertificateRequest.certificate_types, and thus
> may require a different server Certificate message.)
> 
> application data <NEW>normally</NEW> continues to be handled by the same
> application entity as before.  TLS implementations <NEW>by default</NEW>
> MUST NOT use a change of Certificate information to indicate that
> subsequent application data will be in the responsibility of a different
> client or server application entity.  That is, if a new or changed
> Certificate message appears in a renegotiation handshake and is
> successfully verified, it is understood that this is a change in
> identification information only and not a change in identity. 
> <NEW>Still any party relying on peer authentication remains responsible
> for verifying authentication information even on renegotiation
> handshakes.</NEW>
> 
> <NEW>Some application protocols might have to use the TLS protocol in a
> nonstandard setting where a single connection is used with renegotiation
> to multiplex for multiple application entities.  The design of such
> application protocols requires special care to ensure that application
> data cannot be processed or sent in an inappropriate context, taking
> into account that the TLS protocol generally allows application data to
> be interleaved with renegotiation handshakes, and that the record layer
> cannot generally be expected to preserve application message boundaries,
> and may send application data at lower priority than other content
> types.  Thus, such application protocols will have to specify their
> special requirements on TLS implementations.  TLS implementations to be
> used for such applications may require additional API facilities.</NEW>"

This is outside the scope of the wire protocol and on new territory
attempting to specifying the library API. Not saying that's necessarily
bad, but more than likely it will simply be ignored.

What I think would be far more useful is a practical treatment of the
best practices and possible pitfalls for implementing and using typical
library APIs. Some of this is in Appendix D. Implementation Notes, but
it could be given its own section with advice like:

* Although most TLS libraries will properly validate a cert, the
application code is usually still responsible for checking that the cert
identifies the intended host. This is because the exact method to be
used depends upon the application protocol in use. This check MUST be
done at the earliest opportunity during the handshake process. This
usually necessitates an application-supplied callback function be
registered with the TLS implementation. Returning a failure code from
the callback MUST terminate the handshake.

* The TLS protocol allows application data to be interleaved within
rengotiation handshake messages. Sometimes this is desired, but may
require extra care. The application-supplied callback and TLS library
normally SHOULD discard any buffered plaintext at the point of
renegotiation. It is recommended that TLS libraries default to neither
sending nor accepting of application data during a renegotiation
(between the Hello and the Finished handshake messages).

and so on...

- Marsh

---

From: Bill Frantz <[email-masked]>
Date: Thu, 3 Dec 2009 13:07:25 -0800

Perhaps we might be able to get a bit more clarity on this issue if we
consider the authorizations that the application layer may make based on
the identification provided by TLS and by additional
identification/authorization information in the data stream.

It seems to me that we are trying to fix a bug in exhibited by some systems
where some data is received before the information needed to perform an
authorization (AInfo) is sent by the sender. When this data is generated by
a sender with different goals than the entity which sends the AIinfo, and
the application treats is as if it was sent by the same entity the bug
occurs. At the same time, we want to permit the renegotiations and data
stream to increase the authorizations associated with the channel[1]. Some
people seem to want to allow losing the previous authorizations, and
presumably the associated requests, when new identifications are received.
If this logic were universally implemented, we wouldn't have a bug to fix.

Since I like to have concrete examples to test my reasoning against, I offer two:

  HTTPS: The MITM offers it's own GET/POST line, and eats the client's
  GET/POST line with an unterminated header. The client's cookies (AInfo)
  are applied to the MITM's GET/POST.

  Waterken: "Each invocation is sent as an HTTP request: either a POST for
  an update, or a GET for a query. The request URL fully identifies the
  invocation target and any arguments are carried in the request body,
  encoded in JSON."[2] The MITM can substitute his own GET/PUT line as with
  HTTPS, allowing his own resource to gain access to the argument
  authorizations carried in the request body.

It would be nice to have some more examples, especially from non-HTTP based
protocols.

Since we also want the maximum level of backward compatibility with
existing applications, some of which may be buggy in this area, and we have
limited information about what they actually do, there is significant
controversy about what the draft should say. Since this issue impacts the
library API and application logic, which are outside the scope of our

>(between the Hello and the Finished handshake messages).

Cheers - Bill

[1] To use David-Sarah's definition of channel where he referenced the
channel bindings draft and RFC 5056. I hope the TLS 1.3 effort results in
good names for all of these states of TLS so we can communicate better.

[2] <http://waterken.sourceforge.net/>

-------------------------------------------------------------------------
Bill Frantz        | Airline peanut bag: "Produced  | Periwinkle
(408)356-8506      | in a facility that processes   | 16345 Englewood Ave
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, CA 95032

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 03 Dec 2009 15:03:20 -0800

>>> connections, as Nelson Bolyard of NSS (heir of the Netscape legacy

NSS _is_ the Netscape legacy implementation, much evolved.

> I'm sure he wouldn't mind me sharing this tidbit:

I don't mind a bit.

> going in parallel between the same client identity session cache and the

To explain that slightly, NSS explicitly allows a process to act as multiple
independent client entities, e.g. multiple virtual http clients,
each with its own separate TLS session cache, so that each entity can
restart its own TLS sessions, and not accidentally restart sessions of
another entity.  This greatly facilitates writing test clients that simulate
large numbers of independent clients all pounding on a test server for
(e.g.) benchmark purposes.

Most client apps only operate as a single entity and only use one client
identity cache, so it was a detail that's not necessarily important to this
discussion.  But if an app wants to have multiple connections to the same
server, with some of them client authenticated with some identity, and
others not authenticated, or authenticated with a different identity, then
it should use a separate cache for each of those identities, including one
for the anonymous (non-authenticated) identity.

A single client entity may have multiple sockets open, with multiple TLS
connections to the same server, and multiple of those connections may be
using the same TLS session (the same session ID).  Generally, whenever any
handshake (initial or renegotiation) occurs with a server, the code finds
the TLS session most recently established with that server in that client
entity's session cache, and offers that session's ID in the client hello.

So, if a client has multiple connections going to a server, all sharing the
same client entity's session cache, and it renegotiates on one connection
with a full handshake, establishing a new TLS session (with or without
client authentication), then the next time it renegotiates on any connection
to that same server, it will offer in the client hello the most recently
initiated session ID, even if that is not the session ID that was already in
use on that connection.

> identity session cache" (I suspect no one does), 

<sound src="blowing_raspberry.mp3"/>

> but it sounds plausible to me that renegotiation with resumption could,
> in theory, switch between differing client certs over the same
> connection.

Switch between different TLS sessions that had bee previously authenticated
with different certs.  Yes, I agree completely.

I see TLS as being capable of multiplexing multiple independent sessions
over a single connection.  Perhaps it's not terribly efficient at that --
the round trip time cost of switching sessions (doing session-restart
handshakes) is at least as great as the cost of a 3-phase connection --
but I read nothing in the SSL/TLS specs that disallow it, and I have seen it
used, at least experimentally in development.

>>> If someone wants to write a TLS application layer protocol that way,
>>> there's no good reason for the spec to prohibit it at this stage in
>>> the game.

I agree that we should not absolutely prohibit it.  But clearly most of the
people who have ever coded apps to use SSL/TLS have never contemplated this
session multiplexing capability, and have imagined that TLS was always about
a secure connection between a single pair of these (loosely defined)
entities.  So, it might be good to suggest that TLS implementations operate
BY DEFAULT in a mode that supports that all-too-common assumption, and if
desired, offer a session multiplexing mode as a selectable alternative that
is not the default.  But this is API advice.  I see no reason for the
over-the-wire protocol specification to prohibit it.

> (between the Hello and the Finished handshake messages).

I agree that implementation guidance is a good thing.  For a long time,
there has been a certain tension between those who think that IETF RFCs
should be only concise and precise specifications, with a minimum of extra
verbiage, and those who think that implementation guidance is important,
especially in security protocols.  Count me in the latter group.

In the history of SSL/TLS we have seen numerous instances where a little
more explicit implementation guidance would have gone a long way to avoiding
certain divisive implementation problems.  One example is the stripping of
leading zero bits from derived DH/DHE pre-master secrets, which seemed
obviously wrong to mathematicians and obviously right to most of the early
implementers (but I digress).  One of the later versions of TLS addressed
this explicitly.  It could have been avoided with a little more guidance
from the beginning.

---

From: James Manger <[email-masked]>
Date: Fri, 4 Dec 2009 11:10:09 +1100

I had a quick look at the Java API for TLS and HTTPS to judge how "typical" applications might cope with changing peer certificates from TLS renegotiations.

The javax.net.ssl.HttpsURLConnection class includes the following methods:
  getPeerPrincipal()
  getServerCertificates()
  getInputStream()

Consider a client written in Java that:
1. makes an HTTPS connection;
2. extracts the server's authenticated name;
3. reads secured content;
4. displays the server's name on a green or white background, depending on whether or not Extended Validation occurred.

1. HttpsURLConnection https = (HttpsURLConnection) url.openConnection();
2. serverName = https.getPeerPrincipal().getName();
3. in = https.getInputStream();
    in.read()...
4. colour = isEVCertificate(https.getServerCertificates()[0]) ? green: white;

Unfortunately this is insecure.
If a TLS renegotiation completed between steps 2 & 4 then the serverName may have come from a different certificate than the one whose Extended Validation status was checked.

An attacker defeats a weak domain-validation (DV) process to get a cert for paypal.com; and gets an extended-validation cert for Attacker Corp. Now the attacker can fool the client's user: initially negotiating with the DV cert then renegotiating with the EV cert. The client indicates to its user that paypal.com was strongly identified -- which is wrong.

This example is a little contrived, but I don't think the vulnerability in the code would be obvious to even a security-aware programmer.
The fact that calls to getServerCertificates() and getPeerPrincipal(), or multiple calls to either of these methods, can return different identity information each time is highly likely to surprise app developers -- which is a recipe for vulnerabilities.

TLS libraries ensuring that any authenticated peer identity does not change across renegotiations -- unless the app has explicitly indicated it is expecting this -- should be a requirement.

P.S. Java's HttpsURLConnection often uses a default HostnameVerifier that probably mitigates the specific example above, but not minor variations.

-- 
James Manger (Telstra)

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 04 Dec 2009 00:29:54 +0000

Marsh Ray wrote:
> renegotiation.

I appreciate the problem that this recommendation is trying to solve,
but as stated here it may do more harm than good. Discarding any plaintext
may cause the application protocol states at the client and server to
lose synchronization, creating a vulnerability, or at least incorrect
behaviour.

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

---

From: Marsh Ray <[email-masked]>
Date: Thu, 03 Dec 2009 18:32:08 -0600

James Manger wrote:
> 
> 1. HttpsURLConnection https = (HttpsURLConnection)
> url.openConnection(); 2. serverName =
> https.getPeerPrincipal().getName(); 3. in = https.getInputStream(); 
> in.read()... 4. colour =
> isEVCertificate(https.getServerCertificates()[0]) ? green: white;
> 

Yep.

> If a TLS renegotiation completed between steps 2 & 4 then the
> serverName may have come from a different certificate than the one
> whose Extended Validation status was checked.

Yep.

> An attacker defeats a weak domain-validation (DV) process to get a
> cert for paypal.com; and gets an extended-validation cert for
> Attacker Corp. Now the attacker can fool the client's user: initially
> negotiating with the DV cert then renegotiating with the EV cert. The
> client indicates to its user that paypal.com was strongly identified
> -- which is wrong.

Or he may even be able to start with an EV cert for "evil.example.com".

> This example is a little contrived, but I don't think the
> vulnerability in the code would be obvious to even a security-aware
> programmer.

It is usually how example code is shown, especially for scripting languages.

> The fact that calls to getServerCertificates() and
> getPeerPrincipal(), or multiple calls to either of these methods, can
> return different identity information each time is highly likely to
> surprise app developers -- which is a recipe for vulnerabilities.
> 
> TLS libraries ensuring that any authenticated peer identity does not
> change across renegotiations -- unless the app has explicitly
> indicated it is expecting this -- should be a requirement.

It's completely fixed by draft-ietf-tls-renegotiation, no additional
constraints on the certs are necessary.

> P.S. Java's HttpsURLConnection often uses a default HostnameVerifier
> that probably mitigates the specific example above, but not minor
> variations.

Yep.

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Thu, 03 Dec 2009 18:34:41 -0600

> lose synchronization, creating a vulnerability, or at least incorrect

Good point. It certainly "requires extra care".

Ideally the app layer would be defined to discard all state and buffered
data at the point of renegotiation, too.

- Marsh

---

From: Michael Gray <[email-masked]>
Date: Fri, 4 Dec 2009 10:35:43 +1000

> indicated it is expecting this -- should be a requirement.

+1

- Mick Gray

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

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Dec 2009 01:52:10 +0100 (MET)

> constraints on the certs are necessary.

That is a pretty bold statement and doesn't match the question.

Unless you and Nasko have made a U-turn on your position about "lockdown
of established identities during renegotiation", the change of
the certificate will continue to be possible, and therefore
"can return different identity information each time" remains valid.

The TLS renegotiation vulnerability allowed to pass along the
TLS endpoint during renegotiation freely, an in particular to
unsuspecting TLS peers.

The secure renegotiation will ensure that the endpoint of
a renegotiated TLS session will be tied securely to the
endpoints of the enclosing TLS session.

And if one does _not_ use any of the plain RSA ciphersuites (but instead
the DHE ones), then even an attacker in possession of the
server's long term credential (like a disgruntled admin)
will not be able to manipulate the renegotiation and get someone
else to authenticate injected requests.

What the renegotiation fix also not fixes is any potential
security vulnerabilites from the interleaving of
application data during the renegotiation handshake.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Dec 2009 02:04:28 +0100 (MET)

> data at the point of renegotiation, too.

When previously established identities are locked down, secure
renegotiation is used, and newly established identites during
renegotiation are _not_ made available before the renegotiation
handshake has successfully completed, then there is no need
to discard any buffers or prohibit the interleaving of
application data with the renegotiation.

There is probably no "one size fits all" semantics,
maybe we need several different semantics "profiles"
among which an application can chose:

 1) allow arbitrary changes of identites during renegotiation,
    but prohibit any transfer of application data during the
    renegotiation handshake,

 2) lock down previously established identities during renegotiation
    and do not make newly established identities available to app
    before the renegotiation has successfully completed.

 3) renegotiation completely disabled

 4) your favourite

 ...

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Thu, 03 Dec 2009 19:12:01 -0600

> "can return different identity information each time" remains valid.

Yes, it will be possible for authentication credentials/certificates to
change. That's one of the primary purposes of renegotiation.

No, it will not be possible for a MitM or other network-level attacker
to coordinate the change.

> endpoints of the enclosing TLS session.

It ensures continuity-of-identity of the client and server across all
the [unnamed things between handshakes] on the connection.

This is not the same as saying the certificates never change, but it
restores the missing and essential property that everyone thought they
were getting when they made a connection with the "secure sockets layer"
protocol.

In a sense, it takes the authentication which is currently per-session
and makes it cumulative across the entire connection. Applications may
not treat it that way, but at least one important case (HTTPS) does.

> else to authenticate injected requests.

Someone in possession of an RSA private key can do anything that cert
represents except decrypt a previously-captured DH session. It's
debatable whether or not this is even an "attack" since he has the
primary (and usually only) credentials.

> application data during the renegotiation handshake.

Yes, but I suspect that those attacks are greatly mitigated by
preventing a MitM from monkeying around with the renegotiation in the
first place.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Dec 2009 02:54:18 +0100 (MET)

> the [unnamed things between handshakes] on the connection.

I'm sorry, but these two things are mutually exclusive.
The TLS renegotiation fix addresses only the TLS endpoint thing,
it does absolutely nothing about the identities.

continuity-of-identity is _ONLY_ possible if you lock down the
certificates of the peers during renegotiation.  That is _not_
part of the TLS renegotiation fix.

Any notion of identity related to attributes in the certificate that
was used to carry the public key around is out-of-scope for TLS.
Two certs that differ in at least one bit refer to seperate
identies, as far as TLS is concerned.

It may be that an application considers a Server certificate for
CN=www.foo.com issued by VeriSign and another one with the
same CN=www.foo.com issued by GlobalSign to be interchangeable,
but they _DEFINITELY_ are completely different identities.

If you have an end user cert and a renewed end user cert
(same public key, same CA, but different validity), then
these might refer to the same Identity in your PKI, but
for TLS these are definitely distinct identities.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Thu, 03 Dec 2009 21:37:55 -0600

> it does absolutely nothing about the identities.

There's more to identities than certificates. Is there not more to
"Martin Rex" than his driver's license?

> certificates of the peers during renegotiation.

No, even anon-anon sessions have identity. Why do you think they call it
a "session identifier"? Isn't resuming such a session different than
establishing a new one? If not, why do you still have to prove you know
the master_secret?

> That is _not_

In the case of HTTPS client certs for example, an anonymous-client
session was established and transferred data. Then the connection was
renegotiated to provide a client cert, and the data from the previous
session was authenticated retroactively.

This was not a design error! It was entirely reasonable for the HTTPS
designers who had worked with SSLv2 in the past to expect that SSLv3
would not degrade on any of its basic guarantees, even if the new
feature of renegotiation was used.

The mistake was that the SSLv3 designers thought that by ensuring
continuity-of-encryption (the new handshake is encrypted with the
connection state of the old) they were also providing
continuity-of-authentication. Or else they thought, like Martin, that an
anonymous endpoint had no identity whatsoever, and a
certificate-authenticated identity would be re-validated on the handshake.

The reality is that that initial "anonymous" session does in fact have a
very important identity: he's "the party that sent me the data that I am
now authenticating with this client certificate". In order to do this
securely, you have to prove that he is the same party as the one now
sending you the certificate. In other words, you have to authenticate
the anonymous client as being the certified client, and the certified
client as being the anonymous client!

The way we accomplish this in draft-ietf-tls-renegotiation is by having
each side present something in the current connection state that
unambiguously states their belief about the previous session state. In
this way they cooperate to enforce the continuity-of-authentication, but
this only works because both the client and server systems have an
interest in seeing that this is done securely.

Once our fix reestablishes continuity-of-authentication between
connection states, it ensures that the actual party remains the same. It
does this regardless of certificates (or lack thereof). This has a
dramatic effect: it changes the auth model from
independent-authentication-per-connection-state to
cumulative-over-entire-connection! In other words, an endpoint could
renegotiate an anonymous connection ten times to provide ten different
certificates, and the other party can securely treat all data sent over
that connection as having been authenticated to all ten certificates!
(whatever that means for the specific application protocol)

> identies, as far as TLS is concerned.

There's nothing in the TLS spec that says such a thing.

> but they _DEFINITELY_ are completely different identities.

I have a driver's license issued by Kansas and a passport issued by the
US Dept of State, yet I do not assume two different identities.
Sometimes, I am even requested to provide both!

They are separate credentials though. Whether or not they are treated as
equivalent is extremely context-dependent.

> for TLS these are definitely distinct identities.

I have been working in the authentication business for a few years now
and have learned a lot. I have seen plenty of subtle bugs and security
issues caused by imprecise definitions and mismatching assumptions about
identity. There is in fact an entire sub-industry dedicated to "Identity
Management Solutions" which makes products for these problems.

I'm not saying this to convince you how much I know about it, but to say
that I am sure that I don't know much about it at all. Identity is an
extremely deep concept with many context-dependent perspectives and
opportunities for error. Authentication is a fundamental human activity
(and for other animals as well), so most of us are experts in it at some
biological level. We also tend to vastly oversimpify issues of identity
and underestimate our capacity for error. "Social engineering" is one
whole category of examples, the concept of "identity theft" is another.

The TLS specs were very wise to defer these issues elsewhere, especially
since it deals with a rich mixture of cipher suites and credential types.

So riddle me this, Batman: How can someone reading this know that this
is the authentic "Marsh Ray" emailing with the authentic "Martin Rex"?
In particular, how can we know that you or I were not accidentally
switched at the hospital shortly after birth? Do "birth certificates"
represent the answer?

We should maybe follow this up off-list.

- Marsh

---

From: James Manger <[email-masked]>
Date: Fri, 4 Dec 2009 21:37:20 +1100

Marsh,

> In other words, an endpoint could

This point about all data being authenticated by all certs is a good point to emphasis.
Unfortunately, it does not mean typical applications wont get confused (ie have vulnerabilities) when they hadn't explicitly anticipated that 10 certs could be renegotiated.

> Sometimes, I am even requested to provide both!

Consider turning up to a Whitehouse check point, showing your credentials to a guard, and "renegotiating" whenever you like by showing another credential. A controller talking to the guard on the phone asks:
[controller] What is the name on the credential?
[guard] Marsh Ray
[controller] Type of credential?
[guard] passport
now you show the guard your driver license
[controller] Issuer of credential?
[guard] Kansas

The controller thinks he has authenticated Marsh Ray with a passport issued by Kansas.
If you happen to have a library card under a fake name and you showed that first, the controller might think he has authenticated Bugs Bunny with a Passport from the US Dept of State. Ouch! That might allow the wrong person into a Whitehouse party ;-)

In this analogy, the guard is a TLS library, the controller is an application, your cards are certificates, and the protocol of showing your cards is TLS (with the fix!).

Is the error the controller's fault or the guards fault? The application's or the TLS library's (or the protocol's for not providing sufficient guidance)?

This suggests another way for a TLS library to ensure it doesn't confuse an application that doesn't explicitly stated it is prepared for renegotiations.
A library could tell the application only about one peer identity it authenticates (probably the first it authenticates).
For instance, Java's HttpsURLConnection.getServerCertificates() method could return the same set of certificates for the life of the object (the life of the TLS connection), and simply not tell the application about any different certificates from renegotiations. The TLS library could still renegotiate and switch to new sessions, but the application would be blissfully unaware -- and still secure.

Somehow this behaviour doesn't feel quite right, but I think it would be ok. It might be easier to implement than comparing identities across negotiations, and it would cope with those (somewhat unbelievable) niche cases of renegotiating with a re-issued certificate etc.

-- 
James Manger

---

From: Marsh Ray <[email-masked]>
Date: Fri, 04 Dec 2009 07:41:54 -0600

James Manger wrote:
> Unfortunately, it does not mean typical applications wont get confused
> (ie have vulnerabilities) when they hadn't explicitly anticipated that
> 10 certs could be renegotiated.

Yep.

> Consider turning up to a Whitehouse check point, showing your
> credentials to a guard, and "renegotiating" whenever you like by showing
> another credential. A controller talking to the guard on the phone asks:
> /now you show the guard your driver license/

lol - good example

> If you happen to have a library card under a fake name and you showed
> that first, the controller might think he has authenticated Bugs Bunny
> with a Passport from the US Dept of State. Ouch! That might allow the
> wrong person into a Whitehouse party ;-)
> 
> In this analogy, the guard is a TLS library, the controller is an
> application, your cards are certificates, and the protocol of showing
> your cards is TLS (with the fix!).

In real applications, there's also the possibility you could end up
authenticated as Kansas.

> Is the error the controller's fault or the guards fault? The
> application's or the TLS library's (or the protocol's for not providing
> sufficient guidance)?

Oh there's probably enough blame to go all around.

> This suggests another way for a TLS library to ensure it doesn't confuse
> an application that doesn't explicitly stated it is prepared for
> renegotiations.

I think it's becoming clear that very few application developers
realized that TLS had this capacity for renegotiation, much less that
their TLS library was doing it automatically.

'No renegotiation' is probably a good default.

> A library could tell the application only about one peer identity it
> authenticates (probably the first it authenticates).
> For instance, Java's HttpsURLConnection.getServerCertificates() method
> could return the same set of certificates for the life of the object
> (the life of the TLS connection), and simply not tell the application
> about any different certificates from renegotiations. The TLS library
> could still renegotiate and switch to new sessions, but the application
> would be blissfully unaware -- and still secure.
> 
> Somehow this behaviour doesn't feel quite right, but I think it would be
> ok.

Does seem a bit busted. The application may be renegotiating for the
explicit purpose of dropping credentials, such as when switching to a
new identity.

There's no solution short of disabling renegotiation by default, seeing
what breaks, and helping app developers fix it securely. But that's a
decision for each library vendor independently, not for the TLS wire
protocol spec.

> It might be easier to implement than comparing identities across
> negotiations, and it would cope with those (somewhat unbelievable) niche
> cases of renegotiating with a re-issued certificate etc.

SSL/TLS has been around long enough, and has been popular enough, that
it's pretty much guaranteed to have some of everything in operation. Any
change to the semantics of the protocol or widely-used interfaces is
going to break something. It's a question of how much you break, whether
anything ends up less secure as a result, and whether the result ends up
being easier or harder to understand.

Solutions that involve adding new logic (such as keeping the old
certificate and showing it to the application in place of the new) seem
to have a lot of potential for breaking things in subtle and silent ways.

- Marsh

---

From: Bill Frantz <[email-masked]>
Date: Fri, 4 Dec 2009 09:31:25 -0800

[email-masked] (James Manger) on Friday, December 4, 2009 wrote:

>For instance, Java's HttpsURLConnection.getServerCertificates() method could return the same set of certificates for the life of 
>the object (the life of the TLS connection), and simply not tell the application about any different certificates from 
>renegotiations. The TLS library could still renegotiate and switch to new sessions, but the application would be blissfully unaware 
>-- and still secure.

Yet another way would be to have the library return an array of structures,
each member of which has the complete information from the client/server
certificate chain.[1] This array would only grow as new certificates are
received, leaving existing members constant. In Java, the array type would
emphasize to the programmer that there might be more than one structure in
the array. A C programmer would not have that protection, since in C it is
easy to confuse an array reference with a reference to the first element.

Cheers - Bill

[1] The CA chain signing the certificate could be yet another array
reference.

-------------------------------------------------------------------------
Bill Frantz        | When it comes to the world     | Periwinkle
(408)356-8506      | around us, is there any choice | 16345 Englewood Ave
www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032

---

From: Kyle Hamilton <[email-masked]>
Date: Fri, 4 Dec 2009 11:15:59 -0800

PKIX -- as a subset of X.509 -- states that the Subject and Issuer
together describe the identity.  Specifically, the Subject contains
the (unique) moniker for the entity which the certificate has been
issued to.  The Issuer describes which trust anchor to use to verify
the signature.

(Trust anchor management is horrible, and there's been no discussion
of any UI to state that, for example, the "Snake Oil RSA Root" and
"Snake Oil EC Root" are really the same Authority, simply with a
different TA.)

I believe that this specific issue (identity) is out of scope of TLS,
and is within the scope of PKIX.  Specifically, they've already
defined a way to compare identities with certificates, and it
certainly isn't with a bitwise comparison of an expired certificate!
(Hint: the Subject contains several Directory Components, and each of
those should be compared, if you want to verify that the identity
hasn't changed.)

In the alternative, I believe that the bit-wise comparison is worse
than useless, and I believe that the "MAY" should be changed to a very
strong "SHOULD".

-Kyle H

---

From: Kyle Hamilton <[email-masked]>
Date: Fri, 4 Dec 2009 11:34:17 -0800

Isn't "SHOULD" something like "There are some really good reasons for
us to recommend this, but we understand that there might be some
really good reasons to ignore it"?

I believe that "SHOULD" is the correct term for guidance to a
programmer as far as his software interfacing with the protocol.
"MUST" is the correct term for guidance to a programmer as far as the
protocol interfacing with the network, as far as bits-on-the-wire
goes.

I think Marsh's wording is about the best that can be applied.  I'd
probably end up with something like  "Sometimes processing this
application data within handshake is desired, but generally a TLS
implementation SHOULD discard any buffered plaintext before the
renegotiation's Finished messages UNLESS the renegotiation has the
same identity (as defined in [PKIX]).  TLS implementations SHOULD
expose the details of identity associated with each byte of
application data, though the details of such an API are beyond the
scope of this document."

-Kyle H

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Dec 2009 21:13:11 +0100 (MET)

> authenticated in the preceding handshake.

OpenSSL actually has been offering a "lockdown established identity"
for the client (cert) during TLS renegotiation (I'm unsure whether this
applies also to cached sessions, but I believe so) for probably 10 years
at least.

It is the verify option SSL_VERIFY_CLIENT_ONCE, which will cause an
OpenSSL server to _not_ send a CertificateRequest message in a
TLS renegotiation handshake if the server has already obtained
a client certificate in a previous handshake.

-Martin