On Fri, 2010-09-24 at 17:11 +0200, Martin Rex wrote: > 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.
OK, so you are alleging a security problem that is unrelated to the provision in server-id-check for name-mapping services. > 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. This is a false analogy. In the Western Union building, it's expected that there may be other people you don't necessarily trust. But on https://gmail.com, assuming your browser and the server are designed properly and the trusted CAs don't mess up, there is no way for an attacker to introduce a redirect that is not authorized by the registrant of gmail.com. > 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. A user who visits https://gmail.com with a modern browser intends the browser to do whatever https://gmail.com says, which in this case is to follow a redirect. > 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. I'm not sure what kind of trust you were expecting here, but the transformation is authorized by https://gmail.com, so there is no reason the user shouldn't trust it for the purpose of interacting with the service she knows as https://gmail.com . It's true that the security considerations section of the draft states, "When the connecting application is an interactive client, the source domain name and service type MUST be provided by a human user", but I think that is pretty bogus. HTTP redirects in a web browser are one of many cases in which using a source domain from a source other than the user is the expected behavior. These cases are not going to go away with the publication of the standard. I would prefer to limit the scope of server-id-check to what happens after the source domain is provided (e.g., as an argument to an API call of the client library) and simply emphasize that a conformant client is only as secure as the source domain it is given. In a larger application, it's necessary to ensure that the manner in which the source domain is obtained meets the user's security expectations, but that's something to address in the documentation or standard for the application. -- Matt _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
