Subject: Stopping loss of transparency...

From: Roland Bless <[email-masked]>
Date: Wed, 17 Aug 2005 13:13:07 +0200

Hi,

just yesterday a larger german DSL/Internet provider activated
- without a real notice - a feature as "field trial" in my city,
so that HTTP(S) requests of customers are redirected to their own
web portal (apparently using some soft state timeout).
I'm also aware of several other dial-up providers who do that.
This breaks IMHO a lot of applications, e.g., DynDNS
registrations of DSL routers (which would not be necessary
with IPv6 but that is another issue), automated Windows/Linux
updates, anti-virus database updates, RSS and presumably many
more. Though they sell it as a "service to
customers" (luckily you still can turn this feature off
if you know how to do it...), I see it as very dangerous
since automated security updates etc. will fail, i.e. they
even decrease the security of their cutomers! Is there
anything newer than RFC 2775 that one could give as
strong technical advice to abandon that feature and to
not turn it on for all other users?

Regards,
 Roland

P.S.: please don't comment that I should just switch
the provider in this case. I like to raise the awareness of
the provider that this feature is _technically_ dangerous,
though it may make a lot of sense for the marketing people...

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

---

From: Peter Dambier <[email-masked]>
Date: Wed, 17 Aug 2005 14:26:54 +0200

> not turn it on for all other users?

Hi Roland,
I have seen the Heise forum is shaking up because of that. Today
it is GMX or United Internet but tomorrow it could be DTAG.DE and
in fact it is DTAG.DE who does offer this "service" to its clients
like United Internet. Obviously they (DTAG.DE) offered this
"service" as a trojan horse to get some of their T-online desserteurs
back. They did not only break software but they did break hardware too,
routers. Some of the end users are locked out. Switching off that
"service" means changing user id's. After that some routers did
not login again, neither using the old nor using the new user id.
I guess marketing is not amused.

> though it may make a lot of sense for the marketing people...

In fact things like that did stop me from changing. My isp is
not the cheapest nor do they offer the best service but they are
so predictable. Normally you dont need to be afraid of changes
from burocrates. :)

Oh, yes there have been changes too with DTAG.DE they changed
"my" DSLAM to 84.xxx.xxx.xxx and 84.xxx.xxx.xxx is still very new.
A lot of routers treat it as bogon. Of course United Internet
got that very same address range. They too do worry why some
ip addresses can no longer ftp, scp or VoIP.

Introducing a new "service" was just a means of throwing sand
into their customers eyes and keeping them from seeing the
big picture.

Regards,
Peter and Karin Dambier
-- 
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [email-masked]
http://iason.site.voila.fr
http://www.kokoom.com/iason

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Aug 2005 15:03:18 +0200

Roland,

You can ask some pointed questions using RFC 4084 ("exactly which
of these descriptions applies to your service, and please show
me in the contract where you are allowed to change your service
without notice").  But I suspect that even free copies of
RFC 1958, 2775, 3234 and 4084 will not be enough to convince them.

    Brian

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 17 Aug 2005 15:12:30 +0200

Roland Bless wrote:

> registrations of DSL routers

Some DynDNS clients allow to use port 8245 (JFTR, it's
clear that this isn't your point).

> Is there anything newer than RFC 2775 that one could
> give as strong technical advice to abandon that feature

Check out RfC 4084 (BCP 104) "full internet connectivity".
But I doubt that it helps, chapter 3 only says "MUST be
disclosed", they do this.

Maybe you find an appropriate MUST in the HTTP/1.1 RfC.

> I like to raise the awareness of the provider that this
> feature is _technically_ dangerous, though it may make a
> lot of sense for the marketing people...

Sure, it's also an opt-out scheme, just stating what it is
in public comparing it with similar features of say SpamCast
might help to "educate" them, otherwise many Web browsers
will soon offer to do a dummy HTTP GET on startup.  <sigh />

                        Good luck, Frank

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Aug 2005 15:20:08 +0200

> RFC 1958, 2775, 3234 and 4084 will not be enough to convince them.

Just to be sure: what were talking about is that when a customer gets  
up in the morning and connects to www.ietf.org they get  
www.advertising-down-your-throat.de instead, right?

Maybe a nice lawsuit will do the trick. They are assuming the  
identities of others. That can't be legal.

---

From: Marc Manthey <[email-masked]>
Date: Wed, 17 Aug 2005 15:34:16 +0200

On Aug 17, 2005, at 3:20 PM, Iljitsch van Beijnum wrote:

> Just to be sure: what were talking about is that when a customer  
> gets up in the morning and connects to www.ietf.org they get  

yes , thats exactly what it  does , they call it  "Portal-Guided  
Entrance" on port :80 and 443.

regards

marcM.

-- 
"If women didn't exist, all the money in the world
would have no meaning."

Les Enfants Terribles
www.let.de

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 17 Aug 2005 16:11:18 +0200

> Entrance" on port :80 and 443.

Does this work on port 443? I would assume the SSL security checks  
wouldn't accept this.

---

From: Marc Manthey <[email-masked]>
Date: Wed, 17 Aug 2005 16:17:32 +0200

> Does this work on port 443? I would assume the SSL security checks  

its  their  technolgie ,they call it  " ipass"  or something else
i guess it works ip adress based , another concern what someone posted,

>  there have been changes too with DTAG.DE they changed
> A lot of routers treat it as bogon.

thats bad!!

> Of course United Internet

so they  give you the ip adress that they  filter :-)

cheers

-- 
" The mind, once expanded to the dimensions of larger ideas,  never   
returns to its original size."

Les Enfants Terribles
www.let.de

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 17 Aug 2005 10:28:36 -0400

>RFC 1958, 2775, 3234 and 4084 will not be enough to convince them.

Publicity might help.  A few years ago, my local cable ISP (Comcast) 
deployed a "transparent" web proxy.  This prompted a lot of outrage, 
including claims that they were violating the wiretap law.  They backed 
down in about a week.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Roland Bless <[email-masked]>
Date: Wed, 17 Aug 2005 18:13:08 +0200

Hi Brian,

> of these descriptions applies to your service, and please show

Thanks for a pointer to that BCP...

> without notice").  But I suspect that even free copies of

Unfortunately they have a passage in their general terms and conditions
which explictly allows them to place their web portal as starting
page...however, they announced a new feature, but one could not
infer from that statement that they are really redirecting HTTP requests...
(for the interested reader who is able to read german:
http://www.heise.de/newsticker/meldung/62869)

> RFC 1958, 2775, 3234 and 4084 will not be enough to convince them.

Right, however, I have a slight hope that they may care, since
they are testing the feature in a limited scope instead of just
enabling it for all users, and, currently one can still turn it off
(but how for long?)

Regards,
 Roland

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Aug 2005 12:42:37 -0400

--On Wednesday, 17 August, 2005 18:13 +0200 Roland Bless
<[email-masked]> wrote:

> Hi Brian,
> 
>> You can ask some pointed questions using RFC 4084 ("exactly
>> which of these descriptions applies to your service, and
>> please show
> 
>> me in the contract where you are allowed to change your
>> service without notice").  But I suspect that even free
>> copies of
> 
> Unfortunately they have a passage in their general terms and
> conditions which explictly allows them to place their web
> portal as starting page...however, they announced a new
> feature, but one could not infer from that statement that they
> are really redirecting HTTP requests... (for the interested
> reader who is able to read german:

Roland,

It is impossible to close every loophole, or to prohibit every
bad behavior.  Certainly it is impossible to do so without
making a document like RFC 4084 so long and complex that no one
would read it.  However, there is a huge difference between
"place their portal as starting page" and "intercept every HTTP
request and divert it to where they want to".  The ordinary
interpretation of the former would mean doing something like
what the WiFi public hotspot folk do, i.e., to intercept your
_first_ URL in some "session" in order to display their page,
set up accounting information, etc.  But, after that, they
generally leave you alone.  

This is much more intrusive.  From your description and that in
the article, it would seem that they are using the "portal"
story as an excuse to force you into a private service, causing
increased costs in terms of the time it takes you to accomplish
anything, etc.  

FWIW, I think Steve Bellovin's advice is wise -- publicity, loud
public protests, appeals to regulators if there are _any_
pressures that prevent you from changing suppliers, etc. might
be effective and are worth trying.

    john

---

From: Prakash Jayaraman <[email-masked]>
Date: Wed, 17 Aug 2005 11:03:49 -0700

It seems this ISP wants to provide proprietary services tailored to each 
customer for differentiation. I am not going to question what they want 
to do, but they can do so without breaking the features you have 
mentioned. This is one of the main problems considered and resolved by 
the PANA WG (not that this ISP is going to adopt the solution just 
because it is available :)   If they specify the requirements in the 
form of an individual draft, IETF could suggest or develop more elegant 
solutions.

- prakash

---

From: "Nicholas Staff" <[email-masked]>
Date: Wed, 17 Aug 2005 21:10:10 -0700

> Does this work on port 443? I would assume the SSL security checks  

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).  If you've ever used websense I would assume the
technology is similar.

---

From: Prakash Jayaraman <[email-masked]>
Date: Wed, 17 Aug 2005 10:45:26 -0700

It seems this ISP wants to provide services tailored to each customer. I 
am not going to question the validity of it, but they can do so without 
breaking the features you have mentioned. This is one of the main 
problems considered and resolved by the PANA WG (not that this ISP is 
going to adopt the solution just because it is available :)  Most ISPs 
are trying to keep services proprietary for differentiation. If they 
specify the requirements in the form of an individual draft, IETF could 
suggest or develop more elegant solutions.

- prakash

---

From: David Hopwood <[email-masked]>
Date: Thu, 18 Aug 2005 20:05:27 +0100

Nicholas Staff wrote:
> (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).

-- 
David Hopwood <[email-masked]>

---

From: "Nicholas Staff" <[email-masked]>
Date: Thu, 18 Aug 2005 17:10:17 -0700

> 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.  Websense is one example of enterprise
software that does this, which is why I mentioned it.

nick

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 18 Aug 2005 20:32:18 -0400

On Thursday, August 18, 2005 05:10:17 PM -0700 Nicholas Staff 
<[email-masked]> wrote:

> (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) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Artur Hecker <[email-masked]>
Date: Fri, 19 Aug 2005 13:31:16 +0200

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:
> 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.
>

---

From: Bill Manning <[email-masked]>
Date: Fri, 19 Aug 2005 06:53:27 -0700

steve bellovin and jck have very good advice.

my question...  what happens when you use address literals in the URL; 
i.e.

http(s)://192.02.80/index.php

--bill

---

From: Roland Bless <[email-masked]>
Date: Fri, 19 Aug 2005 17:03:07 +0200

Bill Manning wrote:
> my question...  what happens when you use address literals in the URL; i.e.
> 

I already disabled the feature. :-)
I, too, want to investigate what happens exactly, but
I'm going on holiday right now, so unfortunately I don't
have the time now to test some things. I'll be back
in two weeks and then check it out..

Regards,
  Roland

---

From: David Hopwood <[email-masked]>
Date: Fri, 19 Aug 2005 22:00:44 +0100

> http(s)://192.02.80/index.php

Try it. With both Firefox (1.0.6) and MSIE (6.0.2600), I get a hostname
mismatch warning when replacing the hostname in an https: URL with its
IP address, because the IP address is not what is specified in the certificate.

However, I also use the Petname toolbar <http://www.waterken.com/user/PetnameTool/>,
which tells me that the site is in fact the expected one.