ietf
[Top] [All Lists]

Re: Gen-ART and OPS-Dir review of draft-wkumari-dhc-capport-13

2015-07-12 15:59:40
On 07/12/2015 01:59 PM, Christian Huitema wrote:
My advice to implementers would be to consider the capture portal web page as 
fundamentally untrusted, and for example not allow it to run scripts. Then system 
administrators could consider "white listing" some of these pages, provided of 
course that the connection could be authenticated and protected through HTTPS.
This is good advice. If it's not specifically stated, I suspect it's because the authors thought it was obvious (I haven't read the draft in about two months, so I don't remember what it says about this).

That said, the reality is that most hosts are not configured as you suggest, and configuring them that way would substantially reduce their usability. To expand this document to the point where it covers all the advice that should be given to implementers of such systems would be challenging, to say the least.

E.g., you suggest using https, but that's not really adequate: https is safer than it otherwise would be because e.g. Google and other browser vendors have blacklists that prevent you from going to known bad web sites. These blacklists are (I assume, I haven't checked) updated by the browser. So should the host software vendor fail if the blacklist can't be updated?

Should the captive portal allow downloading of such updates? I would say yes to both questions, but we have no control at all over either captive portal vendors or host vendors, and in the case of captive portal vendors, the state of the art is atrocious: a typical captive portal that I've had to interact with a lot recently uses https, but uses an invalid cert!

Not running scripts is a great suggestion, but we know that many hosts are vulnerable to SSL hacks. So there's always going to be some exposure here. A lot of what host software vendors ought to be doing to protect hosts from problems of this sort are so far out of scope of this document that it seems pointless to discuss them. If in fact we want to offer advice of this sort, I think it ought to be in a separate document, done by a working group with participants who are qualified to give such advice, if such a working group exists.

<Prev in Thread] Current Thread [Next in Thread>