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