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

[Michael D'Errico <[e-mail]>]

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