Re: [TLS] Fwd: I-D Action: draft-lemon-tls-blocking-alert-00.txt

[Ted Lemon <[e-mail]>]

The point of the different result codes is to give the end-user some basis
for figuring out why they didn't get to the site.   "Malicious site" is
different than "policy violation."   A malicious site is a site that serves
malware, or does phishing, or typosquatting, or something like that.
Policy violation could be "no facebook during business hours."   Policies
are typically under user control, so being able to know that you can do
something to address the problem is key.

The difference between "captive portal" and "user needs to check account
status" is that in the one case, you have no (anticipated) business
relationship with the operator of the network, whereas in the case of
account status, you do.   Or in any case, the network is claiming you do.
So what the user would be expected to do is different--in the case of a
captive portal, they might have to use some out-of-band mechanism to
discover the URL they should visit to sign up, whereas in the case of a
relationship with an ISP, they already presumably know the ISP's web site,
and hopefully have a secure URL they can use to access it.

Of course we can't do anything about that, and there is some security
exposure in the case, for example, that they have an HTTP URL and an
attacker wants to trick them into using it.   Ideally the ISP would already
have asserted that it only is accessible through TLS, and the browser would
already have cached that.

On Tue, Jun 7, 2016 at 5:55 AM, Hubert Kario <[e-mail]> wrote:

> On Monday 06 June 2016 13:21:12 Ted Lemon wrote:
> > I've posted a new document to the datatracker that adds some TLS alert
> > codes that can be sent to indicate that a particular TLS request has
> > been blocked by the network.   This attempts to address the problem
> > of notifying the user of what went wrong when a site is blocked,
> > without creating a channel that can be used by a hostile network to
> > attack a user.
>
> why separate malicious_site and policy_violation? Why not provide just a
> single administratively_prohibited? I don't see a difference to the
> user, in both cases the site will remain unavailable when retrying
> connection and in both cases if the user thinks it's a mistake he or she
> will need to contact the network administrator.
>
> I don't understand the account_attention_* alerts. What account does the
> user need to log in? In what scenarios would they be used? How is it
> different from the captive_portal?
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic