Matt McCutchen wrote: > > On Thu, 2010-09-23 at 03:48 +0200, Martin Rex wrote: > > > > Thinking about it, I feel slightly uneasy about some redirects, such as > > https://gmail.com -> 301 -> https://mail.google.com/mail > > The point from the draft was about a service that maps source domains to > target domains. A HTTP redirect is different: it is an instruction to > restart the process with a new source domain.
Admittedly, the processing of redirects happens at application software layers higher up the stack and for seperate TLS handshakes, whereas server endpoint identification is performed for a single TLS-Handshake directly above TLS. But that does not mean that there is no security problem. I'm trying to describe this behaviour in real world terms, maybe it becomes clearer that way. The current "server endpoint identification" would mean for the real world that you perform the matching when you enter the building (a store, gov. agency, bank, hotel, ...), and from that point on, blindly trust everything what happens to you. Now imagine a subsidiary of Western Union on an exceptionally busy time of the day with several people waiting in line waiting to arrage for a money order with cash they're carrying. Someone approaches a customer waiting in line and tells him that they've set up an additional teller in a camping truck across the street where they can place their money order. The browser behaviour, to blindly following 301 to other servers without second thoughts is a serious security problem. The problem arises because of the complete disconnect between the authentication (or its weak server identification substitute) of an area (or building) on entrance and the expectation what kind of protection this actually provides on the valuable/sensitive/confidential data of the end user. This is much less an issue of vulnerabilities in terms of probabilistic infeasibility, but instead a matter of sensible risk management. Server endpoint identification performed by current browsers, even when performed technically as described in the current draft, provides an extremely false sense of security to the end user. The "secure link" between the end users intention (who supplied https://gmail.com) and what the browser actually does (blindly follow the redirect to https://mail.google.com) is missing. The reference identifier that is passed into the server endpoint identification for the TLS handshake performed with https://mail.google.com results from an untrusted name transformation, and this is very relevant for the security considerations of this I-D. Getting trust decisions right is *much* harder than encrypting and integrity protecting communication data or performing certificate path validations. -Martin _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
