Subject: [Captive-portals] FW: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Wed, 21 Oct 2015 01:14:23 +0000

Dear all,
I submitted a new document on https applications to TLS working group. And Benjamin Kaduk from the TLS wg thinks the work may be in the scope of capport. What do you think?

Best Regards,
Cathy

> -----Original Message-----
> From: Benjamin Kaduk [mailto:[email-masked]]
> Sent: Tuesday, October 20, 2015 11:34 PM
> To: Zhouqian (Cathy); [email-masked]
> Subject: Re: [TLS] FW: New Version Notification for
> draft-zhou-tls-server-redirect-00.txt
> 
> On 10/20/2015 01:38 AM, Zhouqian (Cathy) wrote:
> > Dear all,
> > This is a new document we have submitted on the TLS extension for server
> redirect. It aims to solve the problems in some applications, e.g., HTTPS
> redirect.
> > The "Hello Extensions" message is extended and a new TLS handshake packet
> is defined to support this kind of applications.
> > Your comments are welcome.
> >
> 
> I am not sure I understand the "overdue" use case, but the "web
> authentication" use case sounds like an ordinary captive portal; there's a
> proposed "capport" working group exclusively for handling captive portals
> (https://datatracker.ietf.org/wg/capport/) which might be worth visiting.  The
> "overdue" use case might also be considered a captive portal, but I can't quite
> tell given the current description.
> 
> In any case, it is far from clear that HTTP-specific issues should be handled at
> the TLS layer -- TLS is a generic secure channel protocol used in many
> applications other than HTTPS.
> 
> -Ben Kaduk

---

From: joel jaeggli <[email-masked]>
Date: Tue, 20 Oct 2015 19:12:52 -0700

On 10/20/15 6:14 PM, Zhouqian (Cathy) wrote:
> Dear all, I submitted a new document on https applications to TLS
> working group. And Benjamin Kaduk from the TLS wg thinks the work may
> be in the scope of capport. What do you think?

In general I would view a signal from a middle box that it is attempting
hijack an outstanding but unfulfilled tls connection attempt as a direct
attack on my attempt a secure communication.

I think the observation by Ben is correct, in the sense that the purpose
of capport as proposed is to render such attempts unnecessary, at least
in the cast of signalling the existence  of captive portals that need to
be addressed before communication should continue.

thanks
joel

> Best Regards, Cathy
> 
> 
>> -----Original Message----- From: Benjamin Kaduk
>> [mailto:[email-masked]] Sent: Tuesday, October 20, 2015 11:34
>> PM To: Zhouqian (Cathy); [email-masked] Subject: Re: [TLS] FW: New
>> Version Notification for draft-zhou-tls-server-redirect-00.txt
>> 
>>> Dear all, This is a new document we have submitted on the TLS
>>> extension for server
>> redirect. It aims to solve the problems in some applications, e.g.,
>> HTTPS redirect.
>> authentication" use case sounds like an ordinary captive portal;
>> there's a proposed "capport" working group exclusively for handling
>> captive portals (https://datatracker.ietf.org/wg/capport/) which
>> might be worth visiting.  The "overdue" use case might also be
>> considered a captive portal, but I can't quite tell given the
>> current description.
>> 
>> In any case, it is far from clear that HTTP-specific issues should
>> be handled at the TLS layer -- TLS is a generic secure channel
>> protocol used in many applications other than HTTPS.
>> 
>> -Ben Kaduk
> 
> _______________________________________________ Captive-portals
> mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Wed, 21 Oct 2015 03:19:23 +0000

Hi Joel,
Thanks. So should this work be done in capport?

Best Regards,
Cathy

> From: joel jaeggli [mailto:[email-masked]]
> Sent: Wednesday, October 21, 2015 10:13 AM
> To: Zhouqian (Cathy); [email-masked]
> Subject: Re: [Captive-portals] FW: [TLS] FW: New Version Notification for
> In general I would view a signal from a middle box that it is attempting hijack an
> outstanding but unfulfilled tls connection attempt as a direct attack on my
> attempt a secure communication.
> 
> I think the observation by Ben is correct, in the sense that the purpose of
> capport as proposed is to render such attempts unnecessary, at least in the
> cast of signalling the existence  of captive portals that need to be addressed
> before communication should continue.
> 
> thanks
> joel
> 
> > Best Regards, Cathy
> >
> >
> >> [mailto:[email-masked]] Sent: Tuesday, October 20, 2015 11:34 PM
> >> To: Zhouqian (Cathy); [email-masked] Subject: Re: [TLS] FW: New Version
> >> Notification for draft-zhou-tls-server-redirect-00.txt
> >>
> >> considered a captive portal, but I can't quite tell given the current
> >> description.
> >>
> >> In any case, it is far from clear that HTTP-specific issues should be
> >> handled at the TLS layer -- TLS is a generic secure channel protocol
> >> used in many applications other than HTTPS.
> >>
> >> -Ben Kaduk
> >

---

From: joel jaeggli <[email-masked]>
Date: Tue, 20 Oct 2015 22:29:34 -0700

> Thanks. So should this work be done in capport?

If the question is, "Is a proposal to facilitate the interception of ssl
connection attempts (enabling a man in the middle attack) by
intermediate parties appropriate work for captive portals to undertake?"
My personal opinion is no.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Oct 2015 11:56:28 +0100

> My personal opinion is no.
I fully agree.

I *could* see an argument for a some sort of error / flag that signals "I'm
a captive portal (or some other type of administrative middle box) - I've
*blocked* your TLS connection". This is preferable (I think) to just
dropping the packet, and definitely better than presenting a different
cert.

What is not appropriate (IMO) is to redirect this somewhere, or try hijack
the session.

Think ICMP Admin Prohibited, not ICMP Redirect :-p

But, whatever the case, this is way outside the CAPPORT scope - if anyone
were to create such a thing it would be in some other WG (probably TLS),
not here.

W

> >> From: joel jaeggli [mailto:[email-masked] <javascript:;>]
> >> To: Zhouqian (Cathy); [email-masked] <javascript:;>
> >>>> [mailto:[email-masked] <javascript:;>] Sent: Tuesday, October 20,
> 2015 11:34 PM
> >>>> To: Zhouqian (Cathy); [email-masked] <javascript:;> Subject: Re: [TLS]
> FW: New Version
> >>> mailing list [email-masked] <javascript:;>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Tim Chown <[email-masked]>
Date: Wed, 21 Oct 2015 14:07:38 +0100

> On 21 Oct 2015, at 06:29, joel jaeggli <[email-masked]> wrote:
> 

I would certainly agree. In my view the capport WG should be building a model to prevent that happening, through prior discovery of the portal.

As an aside, I wonder whether the recently defined MPD architecture can be used as at least one architecture to consider for capport - see https://tools.ietf.org/html/rfc7556. The opening work items of the updated mif charter seem to fit - https://datatracker.ietf.org/wg/mif/charter/, and it’s certainly not uncommon for a device to be presented with multiple captive portals in many locations. Or at the very least a 3G/4G interface and a WiFi interface that may see one captive portal (as per 4.1 of RFC 7556).

Tim

---

From: David Bird <[email-masked]>
Date: Wed, 21 Oct 2015 09:17:43 -0700

+1 for using ICMP to signal blocked by CP :)

Solving the problem of the "HTTPS home page" in captive portals is, indeed,
overdue, and the #1 thing to fix, imho. I hear about this problem _often_
(literally, just the other day), and it is shocking how many CP operators
consider hijacking HTTPS to prevent the customer care issues of people not
getting the portals due to a HTTPS (start) home page. It is to the point
where some vendors will default to hijacking HTTPS as well as HTTP.

On Wed, Oct 21, 2015 at 3:56 AM, Warren Kumari <[email-masked]> wrote:

> I *could* see an argument for a some sort of error / flag that signals
> "I'm a captive portal (or some other type of administrative middle box) -
> I've *blocked* your TLS connection". This is preferable (I think) to just
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> _______________________________________________
> Captive-portals mailing list
> [email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Oct 2015 21:52:00 +0300

> On 21 Oct 2015, at 7:17 PM, David Bird <[email-masked]> wrote:
> 

The problem with ICMP is that it needs to be handled by the operating system. Existing operating systems will ignore them and they usually don’t get reflected to the browser or other application.

Perhaps a special TLS alert. So the CP still has to MITM the TCP connection (just as in HTTP), but then it just fails the TLS handshake with a captive_portal alert. 

If the browser then does the normal HTTP probe in a special window it should work with an updated browser on a non-updated system. And really, browsers update with new features much more quickly than operating systems.

Yoav

---

From: David Bird <[email-masked]>
Date: Wed, 21 Oct 2015 13:21:14 -0700

Good point. However, browsers aren't the only applications that use
HTTPS...

Reading draft-zhou-tls-server-redirect-00.txt, I'm I understanding it
correctly that the "first" server must respond with the same certificate as
the "second" server (e.g. the cert returned from the first server must
match the Redirect URL hostname)?

A couple thoughts:

- This does mean any MitM can hijack, not just the local CP-NAS. This isn't
unique to the proposed scheme, but I suppose ICMP is interesting to me
because any "ICMP CP-Notification" packets can easily be filtered at the
network level -- so, a CP-NAS can prevent an outside HTTPS MitM (using
ICMP) from it's WAN side. It would be harder if the notification comes
within the TLS handshake.

- If the CP-NAS ("first" server) must have the same certificate as the
CP-WEB ("second" server), it does make the certificate a bit more
vulnerable being in multiple places and could violate the cert license
(which typically limit the cert to X number of machines). It is worth
noting that the CP-NAS (often an AP itself) does not necessarily belong to
the owners of the captive portal (take any hotspot services company as an
example).

David

On Wed, Oct 21, 2015 at 11:52 AM, Yoav Nir <[email-masked]> wrote:

> The problem with ICMP is that it needs to be handled by the operating
> system. Existing operating systems will ignore them and they usually don’t
> get reflected to the browser or other application.
>
> Perhaps a special TLS alert. So the CP still has to MITM the TCP
> connection (just as in HTTP), but then it just fails the TLS handshake with
> a captive_portal alert.
>
> If the browser then does the normal HTTP probe in a special window it
> should work with an updated browser on a non-updated system. And really,
> browsers update with new features much more quickly than operating systems.
>
> Yoav