Subject: Re: Stopping loss of transparency...

From: David Hopwood <[email-masked]>
Date: Fri, 19 Aug 2005 05:21:05 +0100

Nicholas Staff wrote:
>>>>>yes , thats exactly what it  does , they call it  "Portal-Guided  
>>>>>Entrance" on port :80 and 443.
>>>>
>>>>Does this work on port 443? I would assume the SSL security checks  
>>>>wouldn't accept this.
>>>
>>>I believe the FQDN is not encrypted, though the part of the 
>>>url after the FQDN is (so one could redirect based on https:// and/or 
>>>specific FQDN's (whether http or https).
>>
>>That's beside the point. According to RFC 2818 section 3.1, 
>>where a hostname is given in an https: URL, the client MUST check this 
>>hostname against the name in the server's certificate. This check will
>>fail if the connection is redirected to a non-transparent proxy (assuming
>>that the web browser is complying to RFC 2818, no CA in the browser's
>>trusted CA list has been compromised, and the crypto is not broken).
> 
> The redirection or hijacking happens way before the browser gets involved
> (much lower layer).  My guess (again just one possibility) is that the portal
> is spoofing the address of the original destination and either sending a
> reset or some kind of redirect.

No, the hostname check will fail regardless of *how* the connection is redirected
(it wouldn't be of any use, otherwise).

The client browser expects to be connected to a host with a cert consistent
with the hostname in the URL. A redirect would only work if it was the
expected host that was sending the redirect over SSL/TLS.

Of course a failure of this check only causes a warning, not an error, on most
browsers. And to get back to the original point of the thread, just redirecting
plain http is obnoxious enough.

-- 
David Hopwood <[email-masked]>

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf