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. 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. ----------------- Daniel Savard
