- From: Frederik Braun <fbraun@mozilla.com>
- Date: Wed, 10 Sep 2014 10:27:54 +0200
- To: public-webappsec@w3.org
What if the User Agent was to remember the current strength (implicitly obtained?) and never to accept a weaker setup in the future? On 10.09.2014 09:57, Mike West wrote: > +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 <mailto: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 > <mailto:fbraun@mozilla.com>> wrote: > > On 08.09.2014 22 <tel:08.09.2014%2022>: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/ ;-) > >
Received on Wednesday, 10 September 2014 08:28:24 UTC