Make HTTPS (TLS) untrusted warning more subtle for direct private IP-address connections
Categories
(Firefox :: Security, enhancement)
Tracking
()
People
(Reporter: daan, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36 Edg/89.0.774.77
Steps to reproduce:
We are a device manufacturer and we make devices which run a webserver. We value security a lot and cloud is always optional on our devices. This means that the full stack is running on device and customers can use their device by browsing to it's IP address in their local private network. Take for example an IP-camera which has an internal webserver which allows viewing and full setup of the device.
As devices are getting more complex so are the on-board webpages. We use features such as de Media API, Cache API, Service Workers, ... these are only available when using HTTPS.
Not all customers have technical knowledge and therefore we where not enforcing HTTPS when the device was browsed to via it's local IP address. As more and more API's require HTTPS it will be required in the future to enforce HTTPS for the good operation of our devices.
The problem is that when a user browses to his/her device via HTTP there is only a subtle warning (grey lock with red stripe). The user knows that his connection is not secure/not trusted but he/she is not alarmed. When the device is accessed through HTTPS the page is blocked and the user must take several steps and explicitly ignore warnings.
Actual results:
The users browse to a secure HTTPS device directly via an IP-address in a private IP range and is presented with more warnings than when he/she is not using any encryption at all.
Expected results:
I think that the same subtle warning as when the user would browse to the device via HTTP should be shown when using HTTPS only when:
- No DNS is used.
- The certificate is self-signed.
- The address is an IP address from a private IP-range.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Security: PSM' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
I'm not sure about the expected behaviour in this case, But I will mark the status of this enhancement to New so we could receive an official response.
|
||
Comment 3•3 years ago
|
||
+1
This would be incredibly useful for IoT devices on the local network. I'm in a similar position to OP: We have a microscope that can be controlled through a web interface. We are forced to use HTTP and this works for most features (still less secure than using self-signed HTTP certs), but it completely prevents the use Gamepad API so we cannot use joysticks to control the microscope (this works in chrome which doesn't enforce secure contexts yet). I'm sure there are plenty of other examples of these overly strong warnings being detrimental to security as they make it seem like HTTP is better than self-signed HTTPS.
|
||
Comment 4•3 years ago
|
||
I want to have a local version of a webapp, for a place with no internet, how can I have a https conection to a local server?
Seems to me this issue is bigger than Mozilla, and probably part of some some standard specification.
If so, where should this be properly discussed?
(In reply to Tomás Hayes from comment #4)
I want to have a local version of a webapp, for a place with no internet, how can I have a https conection to a local server?
Seems to me this issue is bigger than Mozilla, and probably part of some some standard specification.
If so, where should this be properly discussed?
I'm not fully aware if this is bigger than Mozilla, or any browser manufacturer for this regard, or not. Because I don't think it is part of the TLS standard how browsers should handle these edge cases.
|
|
||
Comment 6•2 years ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:serg, since the bug has recent activity, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Updated•2 years ago
|
Hello,
To give a little direction to this thread
First, OP also has made a post on serverfault.com explaining the greater context
https://serverfault.com/questions/1060268/ssl-for-devices-in-local-network
The basic problem is this. Suppose you are on your private lan, using reserved non-routable IP addresses such as 192.168.1.* and 10...*
If you have internal hosts such as router.lan or homeassistant.lan, if you access them with your browser, you will get various SSL certificate errors.
Mostly, you will get a self-signed certificate error, which cannot be resolved as nobody can own .lan .local hostnames.
One solution is to add the self-signed certificates to your local certificate repository, needs to be done for every computer and every time you reinstall your OS.
Another solution would be to put the public keys in your dns records.
Specifically using the DNSSEC/DANE CERT DNS records in your local DNS server in case of internal hosts.
Doing this will also allow website administrator to bypass let's encrypt entirely. Instead of let's encrypt signing your certificate, you put it in a CERT DNS record directly.
The functionality to validate DANE CERT records used to be part of firefox, but this add-on was broken when an API was deprecated permanently in 2017
Discussion of the broken add-on
https://web.archive.org/web/20180602140716/https://www.dnssec-validator.cz/
various related bugs
https://bugzilla.mozilla.org/show_bug.cgi?id=1450674
https://bugzilla.mozilla.org/show_bug.cgi?id=672600
https://bugzilla.mozilla.org/show_bug.cgi?id=1201841
https://bugzilla.mozilla.org/show_bug.cgi?id=1479423
firefox add-on still in the store ?
https://addons.mozilla.org/en-CA/firefox/addon/dnssec-dane-validator/
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities
https://wiki.mozilla.org/Security/DNSSEC-TLS-details
https://educatedguesswork.org/posts/dns-security-dane/
There is apparently partial support of this already in Firefox 50 ?
https://www.lambdatest.com/web-technologies/dnssec-support-on-firefox-50
Description
•