|
Re: Stopping loss of transparency...
2005-08-19 04:31:21
hello
SSL is meant to and does protect against this kind of attacks. in
praxis, such redirection usually results in two "warnings": first
recognizing a server impersonation (url does not correspond to the
certified name) and the second about an unknown CA certificate (since
usually self-signed certs are used).
however, nothing can stop the user from clicking away the warnings...
the transparency is really lost only when using normal HTTP. this
technique (typically referred to as "captive portal") is IMHO a state of
the art in today's hotspot environments, where it is used with a
complete connection blocking prior to user authentication. as far as i
know, it is even part of WISPr recommendation.
what i don't like about it, is the fact that the users are literally
taught to ignore warning messages and are expected to accept typical
attack scenario connections.
what is practical about it, is the possibility to display any kind of
information prior to an accepted connection, thus allowing service
discovery before payment.
concerning Roland's original post, i doubt that any RFC of the world is
able to prevent them from continuing. it seems to me that it is more a
marketing than an engineering problem - perhaps a wrong product
packaging. while such "portal guided entrance" might be a good thing for
my grand-ma, it will most probably be perceived as a major nuisance by
any professional.
but wait, weren't browser start pages meant to achieve the same result?
(knowing that my grand-ma wouldn't ever change it) :-)
regards
artur
Jeffrey Hutzelman wrote:
On Thursday, August 18, 2005 05:10:17 PM -0700 Nicholas Staff
<nick(_dot_)staff(_at_)comcast(_dot_)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(_dot_)edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|