Slashdot Mirror

Don't use that Javascript API then.

If you treat secure context gated APIs as if they do not exist, then your NAS's HTTP interface won't be able to use the Presentation API, which allows streaming videos stored on the NAS to second screen devices such as a Chromecast. Nor will your NAS be able to include an app that allows offline editing with sync once you return home, as Service Workers are for secure contexts only. There are even hints that the Fullscreen API itself will be made for secure contexts only in order to plug a phishing vulnerability.

You know, the kinds of people who are capable of setting up a CA to self sign certs and add their root certificate of their dev machine to their browser anyway.

A manufacturer of a network appliance containing a web server, such as a router or NAS, would need to automate the provision of a domain name and certificate to each person who buys such an appliance. A developer who makes a web application available for download and installation on a user-owned single-board computer, such as a Raspberry Pi, would need to automate the provision of a domain name and certificate to each person who installs said web application.

In a well-engineered system, [obtaining a FQDN through a DDNS service] would be excusable.

No it wouldn't. Not without asking consent first.

"If you do not consent, return this product to the seller per the seller's return policy."

Security for a device like HDHomeRun is rather pointless. Nobody is asking for HTTPS certificates.

Several JavaScript APIs are available only to HTTPS scheme or localhost (127/8, not 192.168/16) per the Secure Contexts specification. Among JavaScript APIs related to video recording or streaming, the Presentation API is already restricted to secure contexts, and browser makers plan to restrict the Fullscreen API similarly to deter phishing attacks that involve spoofing the window manager and browser.

To send encrypted all it needs is a TLS stack and a root certificate. It doesn't need an FQDN or any such bullshit.

Obtaining the certificate needs an FQDN. The CAB Forum's Baseline Requirements forbid issuing in private TLDs, such as .local used by mDNS. Otherwise, you'll have to run your own CA, issue a certificate to the device, and install your CA's root certificate into the web browser on every device from which you plan to view. Some popular mobile browsers don't make that very convenient.

Why do home devices need to have trusted SSL certs?

Because Service Workers and several other web platform APIs are restricted to secure contexts per W3C's spec. For example, a browser may restrict the Fullscreen API or Presentation API to secure contexts as a mitigation against phishing by replicating the chrome of the operating system and web browser. In such a browser, the web interface of a NAS on which video is stored will not be able to present the video in the full screen.

Are your family and friends even going to CARE to try to connect to your network if the internet is down.

Yes, because with the Internet down, at least you have some entertainment stored on your NAS that visitors can view together. This could, for example, include a mirror of Wikipedia's best articles (those in GA, A, and FA classes).

There were plans at some time to make even the Fullscreen API secure-only

Of course you could just have plaintext HTTP enabled on your NAS for media access.

That's possible but impractical once browsers make HTTPS mandatory for using the Fullscreen API in documents served from anywhere but localhost. (The LAN is not localhost.) From the Secure Contexts spec, section 4.3 "Risks associated with non-secure contexts":

The ability to manipulate a user agent’s native UI in some way which removes, obscures, or manipulates details relevant to a user’s understanding of their context. [FULLSCREEN] is a good example.

A proof of concept for phishing using the Fullscreen API exists.

Do I need to watch cat videos over SSL?

TLS ensures that you're watching only the cat video, not the cat video followed by an ad inserted by a man in the middle, nor the cat video followed by a full-screen phishing form inserted by a man in the middle.

Why are you encrypting traffic within your own private network?

To avoid loss of functionality once the Fullscreen API becomes limited to secure contexts. Browsers no longer support sensitive JavaScript APIs over cleartext HTTP. There are plans to make Fullscreen API unavailable over cleartext HTTP because of demonstrated phishing attacks. Without the Fullscreen API, streaming video from a home NAS will be limited to a window.

I think that has something to do with browser publishers deprecating the Fullscreen API on cleartext HTTP sites to make it harder for a man in the middle to impersonate your device's operating system. (Search keyword "secure contexts".). Do the pages an where embedded YouTube video falls to go full screen use HTTPS or cleartext HTTP?

Finally, you get to use new HTML5 features. A lot of the newer features are only available to encrypted sites

Say I want to run a web server on a private network, such as a home NAS, and allow HTML5 playback of videos stored on this NAS. But there has been talk of restricting the Fullscreen API to secure contexts because of the potential for phishing. So how would I go about encrypting a server that doesn't have its own domain name, especially if I want visitors to my home to be able to see the videos in the full screen but not a scary self-signed certificate warning?