Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 30 Sep 2009 10:07:12 -0400

I'm jumping late on this discussion, but based on what I've seen - I agree with Michael and Simon. 

In my understanding, TLS-established server_name should be enforced by the server.

And Martin - I couldn't disagree more with you. The whole point of using TLS is to enforce who can access what. So the client makes sure he accesses the right server, the server makes sure he grants access to the right pages on the right virtual host. And if your server doesn't do that - please kindly tell me what commercial or freeware product it is included in, so I can avoid buying or using it in the future.

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Joseph Salowey (jsalowey) <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Wed Sep 30 01:19:48 2009
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

"Joseph Salowey (jsalowey)" <[email-masked]> writes:

> 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.   

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

   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.

At least that is how I read it.

/Simon

>
>> -----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
>> 
>> >>> 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.
>> > 
>> > 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.
>> 
>> > 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.
>> 
>> 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.
>> 
>> I never said my server suffered from this problem....
>> 
>> >> 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.
>> 
>> OK, so you are complaining about the entirety of e-commerce 
>> on the web.  Do you have any proposed solutions to these problems?
>> 
>> Mike
>> 
>> 
>> > 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
>> _______________________________________________
>> TLS mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tls
>> 
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Sep 2009 16:54:14 +0200 (MEST)

Blumenthal, Uri wrote:
> And Martin - I couldn't disagree more with you. The whole point of
> using TLS is to enforce who can access what. So the client makes sure
> he accesses the right server, the server makes sure he grants access
> to the right pages on the right virtual host. And if your server
> doesn't do that - please kindly tell me what commercial or
> freeware product it is included in, so I can avoid buying or
> using it in the future.

There seems to be a significant misunderstanding.

The Host header field of an HTTP request is a detail of an
application protocol.  The hostname conveyed by the TLS extension
server name indication (SNI) happens at a competely different
protocol layer.

The difference becomes obvious when you add reverse proxies
into the picture (those which terminate the TLS wrapping).

Conceptually, the Host: header field of a HTTP request is
part of the URL.  If a reverse proxy perform URL rewriting,
it may as well have to rewrite Host: header fields.  That
depends entirely on the backend architecture of each
particular software installation.

Whether or not an application may want to make consistency
checks between a Host: Header field and a hostname received
via SNI at the specific point of the backend architecture
where TLS was terminated depends entirely on the backend
architecture, and is an application issue.

-Martin