RFC: no "insecure host" interstitial for hosts identified by ip in private ip range
Reported by
mqu...@gmail.com,
Aug 28 2017
|
|||||
Issue descriptionChrome Version : 60.0.3112.101 Presently, Chromium/Chrome presents a security warning and a "this host is insecure" interstitial when visiting a HTTPS page hosted on an IP address in the range of IP addresses reserved for private use without a host name that presents a self-signed certificate matching the IP address being requested. This is a request to consider skipping the interstitial even if keeping the insecure warnings and the red exclamation marks elsewhere in the UI (e.g. address bar) while browsing the site, in light of the fact that it is not possible to obtain an SSL certificate for an IP in the reserved private range, among other reasons. A full discussion of this matter can be found here: https://neosmart.net/blog/2017/lets-stop-punishing-iot-devices-that-embrace-https-shall-we/ Given that this is a host identified by its IP and that the IP resides in the private range, there can - by definition - be no "universal" 192.168.1.1 that can be uniquely identified and trusted. In addition, an entire class of attacks does not apply to such requests (namely anything that involves DNS) because DNS is not involved in this process. By skipping the interstitial, the user experience when visiting HTTPS resources that are served with a self-signed certificate can _at least_ be bearable when compared to that of plain HTTP. The current approach by all major browsers to throw a scary "this page is trying to haxx0r your PC" when visiting HTTPS pages presenting a self-signed certificate _that cannot be verified more than this anyway_ leaves IoT and internet-enabled consumer electronics manufacturers and developers leery of adopting HTTPS, and instead (and you can't blame them) continue to use HTTP as the primary web-facing interface for their devices on home user networks. If it can be asserted that currently the best means of "securing" an IoT resource residing on an IP address in the private range, accessible solely via said IP address, _is_ via a self-signed certificate, then this approach should not be actively punished forcing developers to use HTTP instead. A security interstitial was shown, despite the fact that the self-signed certificate approach is in fact the most secure option available for the resource in question.
,
Aug 28 2017
I believe this is a WontFix, as transport security is relevant regardless of the network you're on, and without authenticity, you cannot build in confidentiality or integrity that is necessary to ensure the origin is 'secure'. However, this is up to Security-UX team.
,
Aug 28 2017
Thanks for replying, @sleevi I agree with you 100% - but certainly no argument can be made that these resources are less secure than pages served over plaintext without SSL. The crux of the matter is that for hosts identified by IP addresses in the RFC1918, there _can_ be no authenticity as it is not possible to obtain a certificate signed by a trusted root CA for an IP address or a host name on a local tld (such as .lan or .local). I beg the security ux team to consider treating https resources with self-signed certificates _only in IP addresses that fall within the ranges described in RFC1918_ to not treat the resource as any less secure than a plain HTTP page.
,
Aug 29 2017
Adding TE-NeedsTriageHelp , as the issue seems to be related to security and ip addresses. Thanks!
,
Sep 1 2017
Assigning to Emily to review / make a decision.
,
Sep 1 2017
fwiw, this request is only to drop the security interstitial. The web page can still be marked insecure and show the insecure warnings in the address bar.
,
Sep 4 2017
Unfortunately, this is working as intended. Chrome can't really determine that it is safe to ignore certificate errors even for hosts in private IP ranges. Depending on the use case, some alternative approaches include: - Install a local CA into the local trust store and use it to generate a certificate. - An IoT device manufacturer might be able to do something like https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ - Use the --ignore-certificate-errors-spki-list flag (https://cs.chromium.org/chromium/src/content/public/common/content_switches.cc?type=cs&q=ignore-certificate-errors-spki-list&sq=package:chromium&l=591) It is generally weird that certificate errors cause stronger security warnings than plain http. Historically I think the reasoning has been that certificate errors are a strong indication of an attack in progress. In practice I'm not sure that's true (I suspect that plain http is frequently intercepted/tampered with, but certificate errors are almost always indicative of a misconfiguration rather than attack), but nevertheless, we're gradually working towards strong security warnings for http as well: https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by zhongyi@chromium.org
, Aug 28 2017Components: Internals>Network>SSL