You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are many devices on a typical home LAN that have built-in web servers. These include the configuration pages for routers, security cameras, printers, IP phones, and other devices.
By their self-hosted nature, these devices do not have a valid HTTPS certificate installed on them and are therefore not considered a secure origin. Many current web features are only available to secure origins. (For instance, you cannot install a home screen shortcut to a web page on Android, because that requires a PWA, which requires a Service Worker, which requires a secure origin.)
In practice, we end up with a couple scenarios:
No HTTPS. Device is used without any security of the connection and anyone can simply packet sniff to get the data. Additionally the page hosted on the device has no modern web capability. Insecure, and incapable.
HTTPS, with a certificate you have to install. Large hurdle for users, enables capability, but is highly insecure as the manufacturers are asking users to install root certificates so that their PWA works.
Back in the day, it was easy for a user to trust a self-signed certificate right from the security prompt. This option is no longer available, which undoubtedly makes day-to-day browsing more secure, but hurts the security for local device usage by forcing insecure scenarios. There needs to be some other way to trust a self-signed certificate in certain scenarios.
I want to share with you the printer instruction sheet that prompted this request. This is from an MBrush/PrinCube.
If you can't read the text in the photo, the relevant part is:
Goto Settings > General > About > Certificate Trust Settings. Under "Enable full trust for root certificates," turn on trust for the downloaded certificate.
@aarongustafson Unfortunately, there's a lot more to it. The Service Worker problem is just a specific example. All the new specs require secure contexts for features such as Media Devices API, Web MIDI API, Geolocation API, etc..
Self-signed certificates don't fall into the "secure" context bucket, and therefore it's very difficult (impossible in some cases) for users to use web platform features.
If I were to simplify this request, it would be as-follows:
I want to be able to easily trust self-signed certificates upon initial visit to the page using that certificate.
title: HTTPS security on local devices (routers, cameras, printers, etc.)
date: 2020-12-07T23:24:58.845Z
submitter: PRIVATE
number: 5fceb9cafdfdc42a3f49240a
tags: [ ]
discussion: https://github.com/WebWeWant/webwewant.fyi/discussions/
status: [ discussing || in-progress || complete ]
related:
url:
type: [ article || explainer || draft || spec || note || discussion ]
There are many devices on a typical home LAN that have built-in web servers. These include the configuration pages for routers, security cameras, printers, IP phones, and other devices.
By their self-hosted nature, these devices do not have a valid HTTPS certificate installed on them and are therefore not considered a secure origin. Many current web features are only available to secure origins. (For instance, you cannot install a home screen shortcut to a web page on Android, because that requires a PWA, which requires a Service Worker, which requires a secure origin.)
In practice, we end up with a couple scenarios:
No HTTPS. Device is used without any security of the connection and anyone can simply packet sniff to get the data. Additionally the page hosted on the device has no modern web capability. Insecure, and incapable.
HTTPS, with a certificate you have to install. Large hurdle for users, enables capability, but is highly insecure as the manufacturers are asking users to install root certificates so that their PWA works.
Back in the day, it was easy for a user to trust a self-signed certificate right from the security prompt. This option is no longer available, which undoubtedly makes day-to-day browsing more secure, but hurts the security for local device usage by forcing insecure scenarios. There needs to be some other way to trust a self-signed certificate in certain scenarios.
Brad Isbell
[email protected]
If posted, this will appear at https://webwewant.fyi/wants/5fceb9cafdfdc42a3f49240a/
The text was updated successfully, but these errors were encountered: