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

Re: CSP: Minimum cipher strength

From: Ángel González <angel@16bits.net>
Date: Tue, 09 Sep 2014 01:02:16 +0200
Message-ID: <1410217336.1539.8.camel@16bits.net>
To: public-webappsec@w3.org
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.
> 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?
I see it quite hard to define.

Ciphersuite A thought to be twice as secure than B today may get
considered weaker tomorrow, on discovery of attack Z.

Responsible sysadmins react by tweaking the server preferences to the
state-of-the-attacks and level-of-client-bugfixes, which is already
complex enough (you have to take into account, older browser
compatibility, what is available on previous TLS versions…).

I'm not sure that adding yet another constraint of «maybe some of your
clients are further restricting the ciphersuites that can be used with
your site» is beneficial (the CSP restriction should only restrict the
set of ciphersuites allowed by your browser, but I wouldn't be surprised
if a new attack brought it down to zero).
What will happen? Will the sysadmins use the more secure ciphersuite (if
it might mean even breaking some client websites) or stay with unsafe
ones for compatibility?

It _may_ be possible to define appropiately (and the idea is cool), but
seems a difficult task.
Received on Monday, 8 September 2014 23:02:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:40 UTC