Agreed - I didn't explain myself properly. I was thinking more like a man
in the middle attack. Since the client is going to a portal page the FQDN
is going to be that of the ISP. Because of that the certificate used by the
client would be the ISP's. I'm not saying this is how they're doing it,
It's just a way it could be done. Of course this scenario only works
because we're not trying to fool the client into thinking they arent going
through a portal page
Nick
-----Original Message-----
From: Iljitsch van Beijnum [mailto:iljitsch(_at_)muada(_dot_)com]
Sent: Thursday, August 18, 2005 3:09 AM
To: Nicholas Staff
Cc: IETF General Discussion Mailing List
Subject: Re: Stopping loss of transparency...
On 18-aug-2005, at 6:10, Nicholas Staff wrote:
Does this work on port 443? I would assume the SSL security checks
wouldn't accept this.
I believe the FQDN is not encrypted,
If you connect to www.example.com with SSL then there are two names
that are relevant: the one typed by the user (or clicked or
whatever)
and the one in the SSL certificate for the server. If this
communication is redirected, I assume the server it's redirected to
doesn't have a valid certificate for www.example.com, even though it
probably has a valid certificate for some other name. This should
trigger a warning or even a failure.
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).
Even though the DNS FQDN and the X.509 CN are available in
the clear,
the HTTP 1.1 "host" is encrypted, as are any HTTP responses
such as a
redirect. I don't see how you could get to that stage without an SSL
warning.
But it could very well be that there is a warning and they assume
people will ignore it.
If you've ever used websense I would assume the technology
is similar.
Not familiar with that...
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf