"Joseph Salowey (jsalowey)" <jsalowey@xxxxxxxxx> 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@xxxxxxxx [mailto:tls-bounces@xxxxxxxx] On >> Behalf Of Michael D'Errico >> Sent: Tuesday, September 29, 2009 4:48 PM >> To: martin.rex@xxxxxxx >> Cc: simon@xxxxxxxxxxxxx; ietf@xxxxxxxx; tls@xxxxxxxx >> 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@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf