Thanks folks, appreciate your time and suggestions! On 3 Jul 2016 3:44 a.m., "Christopher Schultz" <ch...@christopherschultz.net> wrote:
> -----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 > >
