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
<david(_dot_)nospam(_dot_)hopwood(_at_)blueyonder(_dot_)co(_dot_)uk>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf