W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2014

Re: CSP: Minimum cipher strength

From: Jeffrey Walton <noloader@gmail.com>
Date: Mon, 8 Sep 2014 18:01:22 -0400
Message-ID: <CAH8yC8n-t_fou5JS6L89EFooSZxZX5a8VL=zwPOKy+h36B8+nA@mail.gmail.com>
To: Erlend Oftedal <erlend@oftedal.no>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
> One option could be to put a minimum cipher strength policy into CSP,

Its not a bad idea, but a few thoughts come to mind....

(1) The SSL/TLS parameters are negotiated at a lower layer, long
before a HTTPS fetch is made.

(2) What happens when the primary page violates its own policy?

(3) Weaker/Wounded encryption (like RC4/MD5) are still better than no
encryption. Heck, even export grade ciphers wouldn't really address
the greatest risk (the biggest threat is phishing).

(4) Many organizations don't want to know the hairy details (some hand
waiving). They just want to know the server configuration (i.e.,
advertised protocols and cipher suites) are consistent with one of
their security policies or standard operating procedures. They really
don't want to know what's happening in practice.

Jim Manico of OWASP calls Item (4) "checkbox security". If you don't
believe me, then perform a sec-arch and wait for the "we follow best
practices" answer. And then fire up OpenSSL's s_client or SSLscan and
see how the server is really configured.

> I'm not sure how one would specify this policy, but maybe minimum keylengths for approved algorithms.

You usually provide/convey this with security levels:

  * 2-key 3DES = 80-bits of security
  * 3-key 3DES = 112-bits of security
  * AES-128 = 128-bits of security
  * AES-256 = 256-bits of security
  * DH-1024 = 80-bits of security
  * DH-2048 = 112-bits of security
  * RSA-1024 = 80-bits of security
  * RSA-2048 = 112-bits of security
  * SHA-1 = 80-bits of security
  * SHA-256 = 128-bits of security
    ...

So the organization would decree, "Only ciphers with 128-bits of
security or higher" and "Only TLS 1.2 (or above)". And then the help
desk would get overrun with calls because clients can't connect ;)

> the problem ... where the SSL/TLS is poorly configured, and how we could deal with that.

I think the underlying problem is: risk is democratized, while reward
is privatized. Losses will be passed onto share holders, and the folks
responsible will still be rewarded for a job well done. You can't fix
it with a technology control. But that may be drifting OT, so I won't
go any further ;)

Jeff

On Mon, Sep 8, 2014 at 4:54 PM, Erlend Oftedal <erlend@oftedal.no> wrote:
>
> 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.
>
> One option could be to put a minimum cipher strength policy into CSP, which would cause the browser to not load pages, scripts etc. if the policy was not honoured.
>
> I'm not sure how one would specify this policy, but maybe minimum keylengths for approved algorithms.
>
> What do you think? Would this make any sense? Too difficult to implement or specify the policy?
>
Received on Monday, 8 September 2014 22:01:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC