-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Daniel,
On 7/1/16 6:28 PM, Daniel Savard wrote: > 2016-07-01 16:21 GMT-04:00 Christopher Schultz > <ch...@christopherschultz.net >> : > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> Greg, >> >> On 7/1/16 3:03 AM, Greg Beresnev wrote: >>> Thanks Daniel - any idea which cipher in particular needs to >>> be absent in order for the SHA-1-based >>> connection/authentication was rejected/failed? >> >> I'm afraid Daniel may have confused the issue, because the >> certificate-signing algorithm is completely independent of any >> cipher suites that you may use for the encrypted TLS connection. >> >> FWIW, at $work, we typically filter-out anything that looks like >> this: >> >> NULL|_anon_|_DHE_|EXPORT|RC4|MD5|SHA$ >> >> But there's no way I know of to reject the local server >> certificate if it doesn't meet some kind of criteria. >> >> I checked, and Nagios's check_http utility does NOT have a check >> for anything about a certificate other than it's expiration date. >> This seems like a good thing to add to that tool (along with >> complaining about support for certain protocols like SSLv3). >> >> There are other tools you could use, such as Mark's suggestion >> of using Qualys's ssltest site. >> >> > In fact, to enforce SHA-2 (which is the same as SHA-256) you just > have to switch to TLSv1.2 and nothing less. As per the RFC 5246 > https://tools.ietf.org/html/rfc5246 SHA-2 is mandatory, paragraph > 1.2. I think you are misreading that RFC: there is no requirement in TLSv1.2 that certificates must be signed using SHA-2. What it says is that all new cipher suites defined by TLSv1.2 use SHA256, not that the old cipher suites cannot be used. For example, Microsoft.com will happily establish a TLSv1.2 connection using any of the following ciphers: SSL_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA For example (ECDHE-RSA-AES128-SHA is what OpenSSL calls TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA): $ openssl s_client -cipher ECDHE-RSA-AES128-SHA \ -connect microsoft.com:443 [...] - --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-SHA > Chris, you are right, the cipher suite is something different from > the HMAC for the certificate itself. However, if the user wants to > ban the SHA-1 from the negociated symmetric encryption algorithm, > he will have to set a proper cipher suite to exclude anything > without SHA-256 and more from the accepted ciphers. You have to > experiment with the openssl cipher command to find out a proper > combination. There are hashing algorithms supported which are neither SHA-1 nor SHA-256, so everyone should be aware of that, too. Obvious examples are the other SHA-2 hashes (SHA384, SHA512). I thought there were others, but it appears I was thinking of PGP (RIPEMD-160 came to mind). Section 7.4.1.4.1 defines the signature algorithms to be NULL, MD5, SHA1, SHA224, SHA256, SHA384, and SHA512. Greg only mentioned that he wants to enforce the use of better-than-SHA1 certificate-signing algorithms, presumably for both server certificates as well as client certificates. The easiest way to do that is to revoke all certificates that used SHA-1 as the signing algorithm, or, better yet, revoke the certificate that was used to sign all of those client-certificates and create a new certificate to sign using the SHA256 algorithm. Mark's suggestion of using the X509UsernameRetrieverClassName is probably the best way to implement this, because you can just extend the default X509UsernameRetriever, check the certificate for whatever requirements you have, and then delegate the "real work" to the superclass (which is pretty trivial, since it's just grabbing the CN from the certificate). - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXd/1tAAoJEBzwKT+lPKRYxs0P/021QUjfxCbjsHWmhZeUW2NV BBKcDx6X4bdZDWLe9m39KW8ryufSFusxIAmq0h4k7KQ8B2i7tfqZqrOkyjzXE4DV 6YB0KYvPujnQzPW75GjQeWq3xPqp/iM4pwIaNHwliTlQDrVT5azcKym6b0jXIcp1 GM+bxdXFgy1L3E4sGiR0Ip5h8c45T0OTLLvFGn6MpKTnpeNsmFtqtAFZ6zmrIwUA +zGfpZC7YOKMgbeBSQx2b5C+08UHi7kCy3DiXOpwjmdYfYv5OHxLgy0hRGpjPW2v EZqnLpvuTWNBB7VqYju8jIUxg7IjkgjVQ+0Bat5ucBO6GgAZ7VzvHMD0cTPmyTj+ ASOFITX59YPY1N4hGz+dGhUE/0mTxsUuVmGFlkmtL3HkDBe0hYLij2RSO4KCsW9x HyW2OlwF+ORLMG8nSdkiwVFHcZ6kB+k+wa+JGWQrU7yU12CvjJ80QiY9c9MJEw0r HYuWew0SzVXfjPaE97LVqD1eh3p9IPyq9H7LC7yJAd5N8Yt+nTKDrBH3IY3Wudsz qvM0HRpf6X/nEfNfLRn4bGxi5mjZlYRg4iwQuOxgMpwws5NMRgae6X9T9UEYyagq khkio0i898nb2YAk4hfn47vSpX3ECZqMSo59ZwaTx2qk0CgyviD429iR/wjOBvGg 5gmz1HTlgll3PKbVTyDU =s0e0 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
