- From: Ángel González <angel@16bits.net>
- Date: Tue, 09 Sep 2014 01:02:16 +0200
- 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