- From: Chen, Zhigao <zhigao.chen@sap.com>
- Date: Sun, 14 Sep 2014 04:22:53 +0000
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>, "mkwst@google.com" <mkwst@google.com>
- Message-ID: <29C2E60D3C16F94C851BB9DBED03302A20BD8B96@DEWDFEMB12A.global.corp.sap>
Dear Mike and all, We have a cloud application (a HTTPS public origin) that needs to access some local resources. The access is through a few REST APIs provided by a local HTTPS server (only listening on localhost with a self-signed certificate). The cloud app script sends cross domain XHRs from browser to the local server for the resources. The localhost server has CORS and client authentication mechanism to verify the requests. The system is working in today's browsers. However, it seems the following requirements in the Mixed Content draft will break the system. - (Section 5.2.6 & 5.2.9.1) Requests to private origins from public origins MUST not generate network traffic (including traffic on loopback interfaces), and MUST instead return a synthetically generated network error response. - (Section 5.3.5.2) If the response is only weakly TLS-protected (self-signed certificate is exemplified as weak TLS protection), return blocked. 1. Can we relax the first requirement to allow requests to a private origin over loopback interface? I think it is better to leave the cloud application to decide what origins are allowed and disallowed by using CSP. Section 5.4 treats 127.0.0.1 as an authenticated origin. 2. Self-signed certificates are commonly used in corporates. This can be a big impact. Since a user already grant the trust by manually importing the certificate into his browser trusted store, does browser have to be so restrictive? I can't use a real certificate, since "localhost" is not a fully qualified Common Name. Hope you can consider the feedback and welcome your suggestion. Regards, Zhigao
Received on Monday, 15 September 2014 10:35:08 UTC