ietf
[Top] [All Lists]

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

2009-09-30 01:21:06
"Joseph Salowey (jsalowey)" <jsalowey(_at_)cisco(_dot_)com> 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: tls-bounces(_at_)ietf(_dot_)org 
[mailto:tls-bounces(_at_)ietf(_dot_)org] On 
Behalf Of Michael D'Errico
Sent: Tuesday, September 29, 2009 4:48 PM
To: martin(_dot_)rex(_at_)sap(_dot_)com
Cc: simon(_at_)josefsson(_dot_)org; ietf(_at_)ietf(_dot_)org; 
tls(_at_)ietf(_dot_)org
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
TLS(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf