Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard

From: Simon Josefsson <[email-masked]>
Date: Wed, 23 Sep 2009 18:13:32 +0200

I am aware that the IETF-wide last call has ended, but Daniel Black
provided a suggestion (posted on the gnutls-devel list) for the Security
Considerations that I agree with and believe can be important.  Quoting
him, slightly reworded:

  also maybe 11.1. could say, in response to the last paragraph of
  section 3, + "Server applications SHOULD validate server_name against
  any application layer equivalent field."

The last paragraph of section 3 reads:

   If an application negotiates a server name using an application
   protocol and then upgrades to TLS, and if a server_name extension is
   sent, then the extension SHOULD contain the same name that was
   negotiated in the application protocol. If the server_name is
   established in the TLS session handshake, the client SHOULD NOT
   attempt to request a different server name at the application layer.

It appears security relevant for the server to actual verify that the
client do not use another server name at the application layer to
circumvent authorization decisions.  I cannot find any MUST/SHOULD
requirement in the document for servers to test this right now.

One attack could works like this:

1) Client establish an client-authenticated HTTPS session with a TLS SNI
for blog.example.org and sends a HTTP GET with a Host: header for
internal-website.example.org.

2) The server TLS code authenticate and authorize the client (using the
certificate) for use with the blog.example.org domain.  The server HTTP
code serves the internal-website.example.org web page to the client.

This system would be insecure but still compliant with RFC 4366bis as
far as I can tell, which seems suboptimal.  Adding a requirement for
servers to check for this attack would solve the problem.

/Simon

---

From: Dean Anderson <[email-masked]>
Date: Wed, 23 Sep 2009 15:04:00 -0400 (EDT)

Is that insecure?

If the client is authorized by certificate, then it seems that it has 
that identity in addition to any application level identities.

The only insecurity is if the certifiate private key has been
compromised, which isn't something that TLS can protect against.

One problem with using TLS for virtual web hosts is that the server
names cannot match the single name allowed in the certificate.  I don't
want to see that get worse; I'd like to see it get better.

		--Dean

On Wed, 23 Sep 2009, Simon Josefsson wrote:

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

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Sep 2009 12:08:30 -0700

At Wed, 23 Sep 2009 15:04:00 -0400 (EDT),
> want to see that get worse; I'd like to see it get better.

The server_name extension [RFC 4366] allows this.

-Ekr

---

From: <[email-masked]>
Date: Fri, 25 Sep 2009 11:37:52 +0200

Simon Josefsson wrote:

> provided a suggestion (posted on the gnutls-devel list) for the
> Security Considerations that I agree with and believe can be
> important.  Quoting him, slightly reworded:
> 
> 1) Client establish an client-authenticated HTTPS session with a TLS
> SNI for blog.example.org and sends a HTTP GET with a Host: header
> for internal-website.example.org.

The specification is agnostic about the upper layer protocol, so it
doesn't have any HTTPS-specific details. So strictly speaking,
something like this is allowed by the spec, and could even make sense
with some upper layer protocols (although perhaps not HTTPS).

> servers to check for this attack would solve the problem.

This assumes that all TLS connections are "forwarded" to the same
"server instance" regardless of the SNI value. But it's also possible
that blog.example.org and internal-website.example.org would be, e.g.,
two server processes totally unaware of each other. And they could
even be using different upper-layer protocols (e.g. XMPP and HTTP).

But I agree that this is a detail that an implementor could
conceivably get wrong, and perhaps the spec should warn about it
(although MUST would probably be too strong -- it really depends on
the upper layer protocol).

Can you propose some text?

Best regards,
Pasi
(not wearing any hats)

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 25 Sep 2009 13:47:15 +0200

What about some text like

It is the responsibility of application to properly react on
the values for servername presented during session
initiation or session resumption and any related value(s)
presented during the application protocol
according to the needs of the application.
All values can vary and differ and can appear in various
orders depending the nature of the protocol and
the sequence of possible session resumptions or
renegotiations.

---

From: Martin Rex <[email-masked]>
Date: Mon, 28 Sep 2009 23:21:37 +0200 (MEST)

> servers to check for this attack would solve the problem.

I do not see why you consider this a vulnerability in the _server_!

This is exactly how virtual hosting works.  Virtual hosting
does NOT seperate content.  And neither will the use of TLS
provide any such content seperation.  The use or non-use of
server name indication does not make a difference.

Server Name Indication is a feature for the _client_ side, and was
invented to accomodate virtual hosting when HTTP over TLS is used
and the client performs weak server endpoint identification
that is suggested by rfc-2818, section 3.1.

If you can coerce a Browser into sending a Host: header field
different to the host that is used for server endpoint identification,
then this might possibly be considered a problem in the *client*.

When using Reverse Proxies with re-encryption, there may be
a by-design difference in the SNI as supplied by the client
(matching the hostname of the reverse proxy) and the
host header field that the backend server is going to see/use.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 28 Sep 2009 21:28:12 -0700

> I do not see why you consider this a vulnerability in the _server_!

Because a malicious client could theoretically establish a secure
connection using one server domain and then ask for pages from a
different domain.  If the server does not check for this, it could
potentially leak sensitive information.

> server name indication does not make a difference.

Virtual hosting does indeed allow for separate content for each
domain.  Or am I misunderstanding you?

The reason for the server name extension is because, for HTTPS, the
TLS layer is negotiated prior to the client sending its HTTP request
containing the Host: header.  A server that hosts multiple domains
needs to use the SNI to negotiate the proper secure connection using
a certificate with a matching commonName or dNSName.

> that is suggested by rfc-2818, section 3.1.

Perhaps it was originally a client feature, but my test server
has two certificate chains for two different domains, and it
negotiates TLS using one or the other depending on the SNI.  The
server name is then made available to the application layer.  I
don't know of any other way to do this since they share an IP
address.  (For anyone interested in testing against my server,
see http://mikestoolbox.com.)

And I'm curious: why do you call matching the commonName weak?

Mike

---

From: Martin Rex <[email-masked]>
Date: Tue, 29 Sep 2009 23:49:21 +0200 (MEST)

> potentially leak sensitive information.

You're barking up the wrong tree.  If the client did not use TLS,
the server wouldn't even know that.

It is inappropriate to assume that virtual hosting provides seperation
of content and draw a conclusion that, when accesses via HTTPS,
will provide a secure seperation of content instead.

If the lack of such a server-side check is a problem for your
server, then your server problably has a severe design flaw in
its session management.

> And I'm curious: why do you call matching the commonName weak?

Because in the vast majority of situatins it is the last step
in a long row of flawed assumptions.

Security is only as strong as its weakest link.  The authentication
process based on a DNSName involves a number of very weak authentications.

DNS domain names are not very genuine, and it is very non-obvious
which domain names are used by the business or peer someone is
looking for and which are used by others (different businesses with
the same name, cybersquatters or attackers).  Most HTTPS-URLs opened
by Web Browsers are served through plaintext HTTP pages.

Then most Browser PKIs come with a hundred or more trusted CAs
preconfigured, and browsers trust them equally.  Whether or how
secure the authentication is that the CA performs before issuing
a certificate is another flawed assumption that weakens the
rfc-2818 server endpoint authentication.

A final flaw that is still present in most browsers is the
lack of memory.  Not memorizing the certificate that a
server presented on the last contact perpetuates the
weakness of the original authentication.

Personally, I think that deriving a server endpoint identifier
from a network address is the most flawed assumption of all.

That is like asserting that if someone opens on a random door
on which you knock, and shows you an ID card with the correct
street address -- then he must be a GOOD guy.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 29 Sep 2009 16:48:22 -0700

> the server wouldn't even know that.

You must be talking about a particular server implementation that
has this shortcomings.  There is nothing inherent in TLS that
prevents a server from knowing when it is used.  Your library and/
or use of that library is the problem.

> will provide a secure seperation of content instead.

I'm not assuming anything; I have written a TLS library and an
HTTP server that provides the separation of content that you deny
is possible.

> server, then your server problably has a severe design flaw in

I never said my server suffered from this problem....

> in a long row of flawed assumptions.

OK, so you are complaining about the entirety of e-commerce on
the web.  Do you have any proposed solutions to these problems?

Mike

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 29 Sep 2009 17:01:55 -0700

It seems that this is really up to the application.  Both server names
are authenticated under the same session.  It seems an application
server may require them to be the same or allow them to be different.   

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Michael D'Errico
> Sent: Tuesday, September 29, 2009 4:48 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis 
> (Transport Layer
> 
> > You're barking up the wrong tree.  If the client did not 
> use TLS, the 
> > server wouldn't even know that.
> 
> You must be talking about a particular server implementation 
> that has this shortcomings.  There is nothing inherent in TLS 
> that prevents a server from knowing when it is used.  Your 
> library and/ or use of that library is the problem.
> 
> > of content and draw a conclusion that, when accesses via 
> HTTPS, will 
> > provide a secure seperation of content instead.
> 
> I'm not assuming anything; I have written a TLS library and 
> an HTTP server that provides the separation of content that 
> you deny is possible.
> 
> > If the lack of such a server-side check is a problem for 
> your server, 
> > then your server problably has a severe design flaw in its session 
> > management.
> 
> > Because in the vast majority of situatins it is the last step in a 
> > long row of flawed assumptions.
> 
> OK, so you are complaining about the entirety of e-commerce 
> on the web.  Do you have any proposed solutions to these problems?
> 
> Mike
> 
> 
> > which domain names are used by the business or peer someone 
> is looking 
> > for and which are used by others (different businesses with 
> the same 
> > name, cybersquatters or attackers).  Most HTTPS-URLs opened by Web 
> > Browsers are served through plaintext HTTP pages.
> > 
> > preconfigured, and browsers trust them equally.  Whether or 
> how secure 
> > the authentication is that the CA performs before issuing a 
> > certificate is another flawed assumption that weakens the
> > A final flaw that is still present in most browsers is the lack of 
> > memory.  Not memorizing the certificate that a server 
> presented on the 
> > last contact perpetuates the weakness of the original 
> authentication.
> > 
> > Personally, I think that deriving a server endpoint 
> identifier from a 
> > network address is the most flawed assumption of all.
> > 
> > That is like asserting that if someone opens on a random 
> door on which 
> > you knock, and shows you an ID card with the correct street 
> address -- 
> > then he must be a GOOD guy.
> > 
> > 
> > -Martin

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 30 Sep 2009 07:19:48 +0200

> server may require them to be the same or allow them to be different.   

I would agree if the draft wouldn't prevent clients from requesting a
different server name at the application layer:

At least that is how I read it.

/Simon

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 30 Sep 2009 09:45:37 -0700

> From: Simon Josefsson [mailto:[email-masked]] 
> Sent: Tuesday, September 29, 2009 10:20 PM
> To: Joseph Salowey (jsalowey)
> Cc: Michael D'Errico; [email-masked]; [email-masked]; [email-masked]
> I would agree if the draft wouldn't prevent clients from 
> requesting a different server name at the application layer:
> 
[Joe] Good point, however I still think it is application protocol that
needs to enforce the matching if it cares.  Perhaps we can add some text
that states

"Since it is possible for a client to present a different server_name in
the application protocol, application server implementators should take
this into account and take appropriate action to avoid introducing
security vulnerabilities if the names do not match.  "

Peter's text also included the possibility of server name change during
a renegotiation handshake, do you think we should include this
consideration here as well?   

> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >> Michael D'Errico
> (Transport 
> >> Layer
> >> You must be talking about a particular server 
> implementation that has 
> >> this shortcomings.  There is nothing inherent in TLS that 
> prevents a 
> >> server from knowing when it is used.  Your library and/ or use of 
> >> that library is the problem.
> >> 
> >> I'm not assuming anything; I have written a TLS library 
> and an HTTP 
> >> server that provides the separation of content that you deny is 
> >> possible.
> >> 
> >> OK, so you are complaining about the entirety of e-commerce on the 
> >> web.  Do you have any proposed solutions to these problems?
> >> 
> >> Mike
> >> 
> >>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Sep 2009 10:51:26 -0600

> security vulnerabilities if the names do not match.  "

I think that text is helpful. Overall, however, I wonder if this is
something that truly belongs in rfc4366bis or if it is more appropriate
to define a set of best practices for application protocols that use
TLS. A group of folks in the Apps Area has started to do that here:

http://tools.ietf.org/html/draft-saintandre-tls-server-id-check

It can't hurt to place a brief warning in the core TLS spec, though.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 30 Sep 2009 13:11:28 -0400

I think this text is helpful and does belong to RFC 4366bis. TLS is a tool.
This is a piece of information how to avoid a pitfall when using this tool.

Which does not preclude from writing a lengthier document - a guide for
application developers.

On 9/30/09  12:51 , "Peter Saint-Andre" <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkrDjI4ACgkQNL8k5A2w/vxLJwCgq4KOjJg17NEY0YpvNG2AL2yu
> 9HYAn3mYXXYY68hQmh+mJ8NxIsZ5XRMa
> =GdPy
> -----END PGP SIGNATURE-----

-- 
Regards,
Uri         [email-masked]
<Disclaimer>

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 30 Sep 2009 13:11:28 -0400

-- 
Regards,
Uri         [email-masked]
<Disclaimer>