On Thu, Aug 25, 2016 at 5:09 PM, Jacob Champion <champio...@gmail.com> wrote:
> On 08/25/2016 02:37 PM, Yann Ylavic wrote: > >> I find this CipherSuite quite evolutive and unsurprising (key exchange >> algorithms don't change or are introduced too often, that's an >> euphemism :), if a cipher proves to be weak, add it to the :!END and >> be done (like RC4 and 3DES recently). >> > > To be clear, I'm not arguing that forward-facing cipherstrings don't have > advantages. They absolutely do, and I don't disagree with your points. > > Contrarywise with the exhaustive list method, if you upgrade e.g. from >> openssl 1.0 to 1.1 you have to figure out what the new strong ciphers >> are before adding them (like CHACHA/POLY1305, or CHACHA-GCM with >> libreSSL, or ..). >> > > (Note that ChaCha/Poly is handled here already. But your point still > stands.) > > I suspect that it's a matter of preference at this point. Since this is > the "strong cipher recommendation", where it is (IMO) more important to ban > weak ciphers than to enable the absolute latest and greatest, I'd rather > have to do work on an upgrade to expand a whitelist than run the risk of > missing an item in a blacklist. But that's just me. > > Anyone else feel strongly one way or another? My 2c... Exclusion lists are far preferable to allow lists. .conf files seem to persist for a decade and longer. There is no anticipating what will be added to the list of unwise ciphers a year from now, but that goes for an explicit list or for an exception list. Our how-to should illustrate that specific ciphers *can* be selected. But the specifics should be up to the underlying crypto support library. Users will keep their underlying crypto library more up-to-date than the httpd server in the majority of cases. SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4 SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4 are our current default config recommendations (and Tomcat's, FWIW). Very shortly, !SHA1 is going to be added to that list. This ends at year end AIUI, and it becomes most difficult to obtain a commercial non-SHA256 signed cert. SSLHonorCipherOrder on In our default config, the client has no choice. We will enforce the ciphers and their priority in negotiation. Any modern OpenSSL (1.0.2, 1.1.0 are the only two which matter, 1.0.1 goes away at year end) is going to elect the strongest possible ciphers offering forward secrecy by default. Because httpd is not a crypto provider, but a crypto consumer, I think we should leave the prioritization of ciphers to the administrator (if they want to customize their list) or the crypto library. They are in the best position to downgrade the priority of a newly-weakend cipher at the entire system- wide scope.
