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: Usi
