- From: Jeffrey Walton <noloader@gmail.com>
- Date: Mon, 8 Sep 2014 18:01:22 -0400
- 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