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

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" <vittorio.bertola@open-xchange.com <mailto:vittorio.bertola@open-xchange.com>> wrote:


> Il 21 novembre 2017 alle 1.11 Mark Nottingham ha scritto:
> 
> 
> 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.
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 <tel:+39%20348%20701%205022>
Skype:	in-skype-ox@bertola.eu <mailto:in-skype-ox@bertola.eu>
Email:	vittorio.bertola@open-xchange.com <mailto:vittorio.bertola@open-xchange.com>
 
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.

_______________________________________________
hrpc mailing list
hrpc@irtf.org <mailto:hrpc@irtf.org>
https://www.irtf.org/mailman/listinfo/hrpc <https://www.irtf.org/mailman/listinfo/hrpc>