Re: [certid] review of draft-saintandre-tls-server-id-check-09

[Martin Rex <[e-mail]>]

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