Subject: [hrpc] HTTP status code for "access blocked to protect you against malware/phishing/etc"?

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Nov 2017 12:37:28 +0100

We have 451 for "unavailable for legal reasons" but I find
<https://www.iana.org/assignments/http-status-codes/http-status-codes.xml>
no code for "Unavailable because we have blocked access to this
malware/phishing/bad site".  Since there are many network middleboxes
which do this sort of blocking, would it be a good idea to have a
specific status code?

The only draft I've found about this specific idea is
<https://datatracker.ietf.org/doc/draft-lemon-tls-blocking-alert/>,
but it is TLS-specific.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Nov 2017 06:57:17 -0500

On Nov 20, 2017, at 6:37 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> <https://datatracker.ietf.org/doc/draft-lemon-tls-blocking-alert/ <https://datatracker.ietf.org/doc/draft-lemon-tls-blocking-alert/>>,
> but it is TLS-specific.

I stopped pushing this after David Oran pointed out that there's no way to authenticate who is making the claim about why the content was blocked.   I think this is a bit of a flaw in the 451 code idea as well—if it's not signed by whoever is claiming authority to do the block, it can be used to tell the end user something that is not true and can be turned into an attack on whomever the blocking is attributed to.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Nov 2017 16:33:39 +0100

On Mon, Nov 20, 2017 at 06:57:17AM -0500,
 Ted Lemon <[email-masked]> wrote 
 a message of 81 lines which said:

> I stopped pushing this after David Oran pointed out that there's no
> way to authenticate who is making the claim about why the content
> was blocked.  I think this is a bit of a flaw in the 451 code idea
> as well—if it's not signed by whoever is claiming authority to do
> the block, it can be used to tell the end user something that is not
> true and can be turned into an attack on whomever the blocking is
> attributed to.

It seems to me there are three cases:

1) plain HTTP (no TLS). All bets are off, anything can be modified,
status code or not, and it is not 451-specific.

2) HTTPS to some place you trust, either the origin server (but they
won't tell you the'yre serving malware) or a proxy you're configured
to trust (I know most of these proxies are crap
<https://jhalderm.com/pub/papers/interception-ndss17.pdf>
<http://users.encs.concordia.ca/~mmannan/publications/ssl-interception-ndss2016.pdf>
but it's a different issue).

3) HTTPS intercepted by a proxy you do not trust. Here, it is a
man-in-the-middle attack and it should be detected by HTTPS.

It seems to me that a status code for "intercepted and blocked for
your safety" could be useful for 2) and probably for 1).

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Nov 2017 11:03:51 -0500

> your safety" could be useful for 2) and probably for 1).

In the first case, the point is that if the browser says "this was blocked by FOO," that's going too far, and if you allow whoever blocked it to say why it was blocked, that becomes an attack surface for anyone on-path.

What David suggested was that we need a way to cryptographically sign these messages so that we can validate who sent them.   If we trust that entity, then we can present the information to the user; otherwise not.   If it's the local government, we can trust them in the sense of believing that it was the local government that did the intercept, not someone else, and that can be presented to the user.   Etc.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 21 Nov 2017 11:11:52 +1100

Hi Stephane,

451 was standardised because we found a plausible use case for automated consumption of the status code, and folks were were interested in implementing. I don't see that here yet.

Additionally, there was a general wariness of having a status code for every possible kind of problem that might be encountered; we'd quickly exhaust the status code space if we did so. 

So, if there is such a use case, we should examine satisfying it with the response body and/or a header first.

Cheers,

> On 20 Nov 2017, at 10:37 pm, Stephane Bortzmeyer <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Nov 2017 15:02:17 +1100

I would also add that this is case where the status code would be
inserted by a client-side intermediary in the common case.  Not the
origin server (or any gateway).  That weakens the justification
somewhat in my view.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 21 Nov 2017 09:35:12 +0100 (CET)

> Il 21 novembre 2017 alle 1.11 Mark Nottingham ha scritto:
> 
> 
>     Hi Stephane,
> 

To me, it would make sense to have a look first at the entire scenario.

First of all, in addition to "blocked for legal reasons" and "blocked for safety reasons" (malware, phishing...), there is a third case which is becoming frequent: "blocked on request of the Internet access contract owner", i.e. voluntary parental control activated by parents on their childrens' connection, companies preventing employees from accessing social networks from the workplace, etc. The difference among the three cases is who decides to block the content (the State, the access provider or the user).

The biggest problem is that, as the Web quickly moves towards HTTPS for all, before being able to return any kind of error code or other message you need to be able to establish the connection, which in the HTTPS case is currently impossible. The only possibility for the intercepting system is to forge a certificate for the destination website, but then, either all clients have been manually configured to accept the intercepting system's root certificate as an additional CA (which is hard to do and only happens in some corporate environments, and also opens up security risks), or the browser will anyway complain that the certificate is invalid and show scary messages that send the user screaming around (and calling support and generating costs for the ISP), and if the original destination pinned the certificate there will be no way, even for a smart user, to get around those messages and see whatever error response was meant to be displayed.

This problem also affects the filtering of undesirable destinations at the DNS query level, which is also becoming common; with HTTP, the DNS resolver would just return a forged answer pointing the client to the IP address of a local web server that would return a human-readable error page, but with HTTPS you end up with the same issues as above.

So what currently happens is either that the HTTPS connection is just left hanging or that the user sees scary messages that they don't understand, and both cases are intransparent and a terrible user experience.

Thus, I would find it desirable, both in terms of human rights and of user experience, that HTTPS-intercepting systems in the middle had a way to declare themselves, prove who they are with a valid certificate (plus DANE, maybe), and send back to the user a clear message on what is being blocked and why - but if, and only if, a secure way for doing so were found. Only then, to me, it makes sense to discuss which codes should be sent back.

Otherwise, as plain old HTTP increasingly disappears, we'll just be stuck in a world of HTTPS servers suddenly becoming unreachable with no explanation.

Regards,

--

Vittorio Bertola
Research & Innovation Engineer

Cell: 	+39 348 7015022
Skype: 	[email-masked]
Email: 	[email-masked] mailto:[email-masked]
 
Twitter: @openexchange http://twitter.com/openexchange - Facebook: OpenXchange https://www.facebook.com/OpenXchange - Web: www.open-xchange.com http://www.open-xchange.com
Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein
Chairman of the Board: Richard Seibt

European Office:
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718
Managing Directors: Frank Hoberg, Martin Kauss

US Office:
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA
 
Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Nov 2017 06:41:58 -0500

Yup, that's pretty much what David and I concluded after he pointed out the
problem with my previous approach. (BTW, I don't want to give anyone the
impression that David's supports this work. I don't know whether he does.
This just came up in a conversation at an IETF Boston local meetup.)

On Nov 21, 2017 03:35, "Vittorio Bertola" <[email-masked]>
wrote:

> 451 was standardised because we found a plausible use case for automated
> consumption of the status code, and folks were were interested in
> implementing. I don't see that here yet.
>
> Additionally, there was a general wariness of having a status code for
> every possible kind of problem that might be encountered; we'd quickly
> exhaust the status code space if we did so.
>
> First of all, in addition to "blocked for legal reasons" and "blocked for
> safety reasons" (malware, phishing...), there is a third case which is
> becoming frequent: "blocked on request of the Internet access contract
> owner", i.e. voluntary parental control activated by parents on their
> childrens' connection, companies preventing employees from accessing social
> networks from the workplace, etc. The difference among the three cases is
> who decides to block the content (the State, the access provider or the
> user).
>
> The biggest problem is that, as the Web quickly moves towards HTTPS for
> all, before being able to return any kind of error code or other message
> you need to be able to establish the connection, which in the HTTPS case is
> currently impossible. The only possibility for the intercepting system is
> to forge a certificate for the destination website, but then, either all
> clients have been manually configured to accept the intercepting system's
> root certificate as an additional CA (which is hard to do and only happens
> in some corporate environments, and also opens up security risks), or the
> browser will anyway complain that the certificate is invalid and show scary
> messages that send the user screaming around (and calling support and
> generating costs for the ISP), and if the original destination pinned the
> certificate there will be no way, even for a smart user, to get around
> those messages and see whatever error response was meant to be displayed.
>
> This problem also affects the filtering of undesirable destinations at the
> DNS query level, which is also becoming common; with HTTP, the DNS resolver
> would just return a forged answer pointing the client to the IP address of
> a local web server that would return a human-readable error page, but with
> HTTPS you end up with the same issues as above.
>
> So what currently happens is either that the HTTPS connection is just left
> hanging or that the user sees scary messages that they don't understand,
> and both cases are intransparent and a terrible user experience.
>
> Thus, I would find it desirable, both in terms of human rights and of user
> experience, that HTTPS-intercepting systems in the middle had a way to
> declare themselves, prove who they are with a valid certificate (plus DANE,
> maybe), and send back to the user a clear message on what is being blocked
> and why - but if, and only if, a secure way for doing so were found. Only
> then, to me, it makes sense to discuss which codes should be sent back.
>
> Otherwise, as plain old HTTP increasingly disappears, we'll just be stuck
> in a world of HTTPS servers suddenly becoming unreachable with no
> explanation.
>
> Regards,
>
> --
>
> *Vittorio Bertola*
> Cell: +39 348 7015022 <+39%20348%20701%205022>
> Email: [email-masked]
>
> Twitter: @openexchange <http://twitter.com/openexchange> - Facebook:
> OpenXchange <https://www.facebook.com/OpenXchange> - Web:
> www.open-xchange.com
> Confidentiality Warning: This message and any attachments are intended
> only for the use of the intended recipient(s), are confidential, and may be
> privileged. If you are not the intended recipient, you are hereby notified
> that any review, retransmission, conversion to hard copy, copying,
> circulation or other use of this message and any attachments is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately by return e-mail, and delete this message and any attachments
> from your system.
>
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
>
>