[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Wednesday, October 21, 2015, joel jaeggli <[email protected]> wrote:
On 10/20/15 8:19 PM, Zhouqian (Cathy) wrote:
> Hi Joel,
> 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.

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. 


> Best Regards,
> Cathy
>> -----Original Message-----
>> From: joel jaeggli [mailto:[email protected]]
>> Sent: Wednesday, October 21, 2015 10:13 AM
>> To: Zhouqian (Cathy); [email protected]
>> Subject: Re: [Captive-portals] FW: [TLS] FW: New Version Notification for
>> draft-zhou-tls-server-redirect-00.txt
>> 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 protected]] Sent: Tuesday, October 20, 2015 11:34 PM
>>>> To: Zhouqian (Cathy); [email protected] 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
>>> _______________________________________________ Captive-portals
>>> mailing list [email protected]
>>> https://www.ietf.org/mailman/listinfo/captive-portals

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.