Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

[David Bird <[e-mail]>]

Thanks for your presentation! Yes, I think that use-case fits in with the
group's understanding of captive portals.

Fixing HTTPS hijacking is priority #1 for this WG, imho.

On Wed, May 3, 2017 at 5:42 AM, Heiko Folkerts <[e-mail]>
wrote:

> Hi everybody,
>
> I visited the capport WG the first time in Chicago. Thank you very much for
> the presentations! Afterwards I had a very brief chat with Martin about a
> use
> case, I name “carrier grade captive portals”. As a result I want to present
> this use case to you on this mailing list:
>
> *Background and use case:*
> In Germany the Federal Office for Information Security informs the ISPs
> with
> IPs, timestamp and other information of users that are part of a botnet.
> The
> ISPs are informing the users about the infection. We can not inform the
> users
> without the help of the ISP as they are the only ones knowing who is behind
> the dynamic IP address users get normally in Germany.
> There are different ways to inform users by the ISPs: e-mail, snail mail
> or a
> carrier grade captive portal (aka walled garden, forced portal),
>
> The most efficient way to inform and get systems cleaned has been proven is
> the carrier grade captive portal.
> One of the  internet service providers, NetCologne, uses a, as they call
> it,
> Forced Portal. The current solution is legal in germany, if the ISPs terms
> of
> service are appropriate.
>
> *Technically it roughly works like this:*
> - When the abuse management system detects that a user is infected, the CPE
> customers router connection (PPOE connection) is disconnected and
> immediately
> a new PPOE connection is started.
> - With the new PPOE connection, the CPE customers router gets a new
> DNSServer,
> IP, gateway (policy routing) and is connected to a carrier grade captive
> portal.
> - Within the new network connection all traffic is routed through a
> HTTP/HTTPS
> proxy. This proxy allows the user to access selected sites like
> informational
> sites about infections, AV and OS vendors and will otherwise present an
> information page to the user. This information page tells the user about
> the
> situation, including information about the infection(s) and instructs him
> how
> to clean the system.
>
> *Problem (almost the same as you know it):*
> As with captive portals in local networks this worked pretty well using
> HTTP.
> Also on Browsers, which first tries a HTTP connection, the information
> page  is displayed. Problem occurs now with HTTPS. Especially Google Chrome
> does no longer connect first using HTTP when the user enters a domain name
> of
> a web page if using HSTS and HSTS preload.
> Connecting with HTTPS, the browser detects a MITM attack (which of course
> makes sense, because it is MITM) and does not display the information page.
> Instead an error page is displayed, which generates a whole lot of calls to
> the costumer support. An addional problem we encounter is that the well
> known
> detection strategies used by iOS/macOS, Windows and Android for captive
> portals do *never* work in our case.
> Reason is that these detection strategies will only test for captive
> portals,
> when the network connection of the actual device (for example using WiFi)
> is
> started new. In our case the customers CPE router gets a new PPPOE
> connection, but the client  does not detect that the network connection to
> the internet was dropped by the router.
>
> Do you think that „carrier grade captive portals“ are in scope of the
> capport
> WG charta? Would the work already done at capport help to cope with this
> problem?
> My understanding of the current work in capport is, that it will not solve
> this problem entirely, but I think, it may already be half-way towards a
> solution. Because pushing a customer to a walled garden does not do a
> status
> change on the client system, but the CPE might work as some kind of
> “captive
> portal relais”, using at least parts of the current architecture of capport
> on the internal LAN.
>
> Do you think it is usful that the capport WG considers our use case in its
> work? Any help is appreciated.
>
> Best regards,
>
> Heiko.
>
> --
> Heiko Folkerts
> ---------------------------------------------------
> Referat CK 15
> Federal Office for Information Security (BSI)
>
> Godesberger Allee 185 -189
> 53175 Bonn
> Germany
> Telefon:        [phone]
> Fax:            [phone]-5955
> E-Mail: [e-mail]
> Internet:       www.bsi.bund.de
>                 www.bsi-fuer-buerger.de
>
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals
>