Re: CSP: non-TLS scheme restrictions must allow TLS-enabled schemes automatically

Maybe the better solution is to remove the ability to specify the
"http" scheme?  The site can explain which host names it likes.  Over
"http", these hosts names mean http or https and over "https" they
mean just https.

Adam


On Mon, Jun 27, 2011 at 11:14 AM, Brian Smith <bsmith@mozilla.com> wrote:
> Devdatta Akhawe wrote:
>> Gervase Markham wrote:
>> > Isn't there a risk here? HTTP vhosting exists, but TLS vhosting does
>> > not (really) yet. So the owner of the website which is at
>> > http://www.foo.com/ might find that accessing https://www.foo.com/
>> > actually gives them the HTML content of https://www.bar.com/, which
>> > is > hosted on the same machine, but controlled by someone else
>> > entirely.
>>
>> Wouldn't this throw a certificate error (and with HSTS, die without
>> warning) ?
>
> I think Devdatta is right. Gervase's concern should definitely be added to the security considerations. It is possible that your domain is foo.example.org and somebody else has a wildcard certificate for *.example.org. But, if it hurts when you do that then...don't do that.
>
> We must make sure that CSP composes well with other security mechanisms. Without this change, sites using CSP will break when any of the subresource sources enable HSTS and/or otherwise start redirecting http:// -> https://. This would add risk to deploying HSTS that would slow (in some cases, even prevent) its adoption.
>
> Also, I think most CSP source directives should be of the form *.example.org, so that the linked-to site is free to move a commonly hot-linked resource to a subdomain, especially a CDN. I expect that many sites will do such reorganization as part of the effort of TLS-enabling their sites. It would be helpful to provide this advise in the spec, and to change examples in the spec that use third-party sources to use this style, where it makes sense to do so.
>
> - Brian
>
>

Received on Monday, 27 June 2011 18:22:37 UTC