> -----Original Message----- > From: Simon Josefsson [mailto:simon@xxxxxxxxxxxxx] > Sent: Tuesday, September 29, 2009 10:20 PM > To: Joseph Salowey (jsalowey) > Cc: Michael D'Errico; martin.rex@xxxxxxx; ietf@xxxxxxxx; tls@xxxxxxxx > Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis > (Transport Layer > > "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. > [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? > /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