RE: Stopping loss of transparency...

[Jeffrey Hutzelman <jhutz at cmu.edu>]

On Thursday, August 18, 2005 05:10:17 PM -0700 Nicholas Staff 
<nick.staff at comcast.net> 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.

Sure.  But the result is that the thing the browser ends up with a 
connection to is not the server the user intended to talk to.  Since the 
fake server doesn't have the real server's private key, it cannot 
successfully complete an SSL negotiation with the client using the real 
server's certificate.  And unless some CA has been compromised, no other 
certificate will have a server name which matches the one the user typed, 
which will result in at least a warning, if not the browser aborting the 
connection entirely.  The result is that the user doesn't get to talk to 
either the real site _or_ the redirected one.

The SSL protocol is designed specifically to protect against this attack.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf