- From: Chris Palmer <palmer@google.com>
- Date: Fri, 27 Jun 2014 16:58:54 -0700
- To: Yan Zhu <yan@eff.org>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, blink-dev <blink-dev@chromium.org>, security-dev <security-dev@chromium.org>, dev-security@lists.mozilla.org
On Fri, Jun 27, 2014 at 4:38 PM, Yan Zhu <yan@eff.org> wrote: >> * (https, *, *) >> * (wss, *, *) >> * (*, localhost, *) >> * (*, 127/8, *) >> * (*, ::1/128, *) >> * (file, *, —) >> * (chrome-extension, *, —) >> >> This list may be incomplete, and may need to be changed. Please discuss! > > What are your thoughts on private address space IPs? > https://w3c.github.io/webappsec/specs/mixedcontent/#private-address-space Note that UAs should increasingly disprefer IP addresses in X.509 certs as CNs or as SANs, and IIRC the CABF's Baseline Requirements no longer allow CAs to issue such certs, and if the origin is remote then it can only be secure with the help of TLS or something like it. So, sort of: "That shouldn't be happening." But, also, it seems like a bad idea to let http://192.168.0.106 access powerful features when you're on the hotel wifi. > An example of this would be a router admin interface on 192.168.1.1 that > can be accessed either over plain HTTP or HTTPS with a self-signed cert, > which offers little protection from network attackers anyway. Right. But: * Do such routers need access to fancy things like Service Workers or Missile Launch Control Panel? * They are computationally indistinguishable from a dubious person's web server on the hotel wifi. * I have another idea for how to handle authetnication for Internet Of Things, but that's another thread entirely and we shan't go there just yet. :)
Received on Friday, 27 June 2014 23:59:21 UTC