+palmer, sleevi
Limiting the cipher suites which are acceptable for subresources seems
brittle. User agents should simply refuse to accept insecurely configured
SSL, rather than asking sites to keep up to date with the latest
understanding of the crypto landscape.
This feels like something that might be better suited to HSTS/PKP than CSP.
In particular, some sort of flag on those headers that would prevent
mixed-pinning might be a valuable addition.
-mike
--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
On Tue, Sep 9, 2014 at 11:03 AM, Frederik Braun <fbraun@mozilla.com> wrote:
> On 08.09.2014 22:54, Erlend Oftedal wrote:
> > Hi
> >
> > Reading the chapter this blog
> > post
> http://marc.durdin.net/2014/09/risks-with-third-party-scripts-on-internet-banking-sites/
> made
> > me think about the problem of using third party scripts where the
> > SSL/TLS is poorly configured, and how we could deal with that.
>
> You can reduce the risk of trusting third party scripts with
> http://www.w3.org/TR/SRI/ ;-)
>
>