Re: CSP: Minimum cipher strength

The general problem of mixed-* within HTTPS is a horse that has been to the
glue factory many times.

It's at every level. EV certificates, for example, does not offer a
meaningful demarcation of security, because it's entirely within the same
origin as DV. Adam Barth discussed this years ago (which I suppose is the
web security equivalent of "Simpsons did it") in
http://seclab.stanford.edu/websec/origins/fgo.pdf , which you can find
referenced in a variety of attacks against EV (EV stripping, JS injection,
etc). The solution to resolve this was more or less what you're proposing
now - a new scheme (HTTPSEV), which means a new origin, which means all the
lovely mixed content protections / same origin policies apply.

In more recent years, this has come up again with "mixed-HSTS" and
"mixed-HPKP" discussions (which, unlike Mike, I don't think are a good
place to express these sorts of policies), which themselves then became
part of Joe Bonneau's overall secure-links scheme (see
http://www.secure-links.org/ )

Ultimately, I agree with Mike - the solution to solve this (generally) is
for UAs to start deprecating things. We're already seeing this with SHA-1 (
*cough
<http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html>*
), and I think it's very likely we'll start seeing with both TLS versions
and cipher configurations (that we haven't already is more due to oversight
than lack of enthusiasm)

On Wed, Sep 10, 2014 at 12:57 AM, Mike West <mkwst@google.com> 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>
> 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/ ;-)
>>
>>
>