Re: Tomcat 7 and SHA-1

[Greg Beresnev]

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

Re: Tomcat 7 and SHA-1

[Christopher Schultz]

-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 

Re: Tomcat 7 and SHA-1

[Daniel Savard]

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.

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

Re: Tomcat 7 and SHA-1

[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.

- -chris

> On Fri, Jul 1, 2016 at 4:53 PM, Daniel Savard
>  wrote:
> 
>> 2016-06-30 23:05 GMT-04:00 Greg Beresnev
>> :
>> 
>>> Hi,
>>> 
>>> We're in the process of updating our web application to stop
>>> using SHA-1 certificates and I was wondering if there was some
>>> way to configure
>> Tomcat
>>> (we're on version 7.0.39 - yes, I know, we are pretty
>>> old-school and
>> should
>>> get with the times) to either throw errors or at least log
>>> warnings for
>> the
>>> cases where connection/authentication attempt is being made
>>> using SHA-1 certificate?
>>> 
>> 
>> No.
>> 
>> However, you can select the accepted ciphers to reject anything
>> that doesn't meet your standards.
>> 
>> - Daniel Savard
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXdtDnAAoJEBzwKT+lPKRY/f0QAKK7mUZJxvCqfDm98BlbbbUj
DR5a/CRPvg7O41+tXSEMqnUiDaJIkLpOGeE/wjwECc7Iv8v8TDdcj8yzIlueqHJu
mwIlX370v4FiOH6vut7qgN51kieMTaRHhS3CL5Q37ogJCaRC8V8T9WFJvsJU49gC
M7NiHe4ZV47nlZ3dvUFZ8VunX1BU5DcxQRI0nF6k9R4dvrrUX5AR5A0WN4tv1qAp
Cg/WpuLizcet4GSZmQpk1mVe3J7fCXRQsYMUiJdj2p2mhviI1pZjwe+F4WyOq9gL
EDI2Gel7Mq26aWKiZFrW+JNsAfDFYgJmFFIWj7LY/L1P9vJMy6xK02iE4t3pTg+2
frl4UCXOaInvXdM+ZfZuJLwYeUtyoYWnxIVcbaEtr2VlBVXBBzezpZfjMnVcUPtO
Vyu2VAPKWipoNk0deSX7eHwMX5AiKMfvLvrkYGQnumVxDTf2z6ttxleJJUnNOONW
Q+dD65hamBzSMq8pvcz1cH8mRpuxYxZIguaFYwEN6uJdIoafztc0cXf8kbrDaNBe
Jo3sEKbUuWZJoMA2ZaU0hx1evT648g5VWzyJfwox6RUKesw2JqWSBC/Mn2X0CHit
g71pkQ4iij5WrrbsPgL5aT9zUjLqdn6UGoRu69CsWFSRcHYOUygikajP21ZsNrBy
N3OmO7YGgli4zOq8bkxK
=qqDk
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ***UNCHECKED*** Re: Tomcat 7 and SHA-1

[Mark Thomas]

On 01/07/2016 08:03, 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 recommend using SSLLabs to test your site.

Also, the version of Java you use is important. See this page for details:
https://wiki.apache.org/tomcat/Security/Ciphers

Finally, if you want to limit client certificates, you could add a
custom X509UsernameRetrieverClassName to your Realm and use that to drop
and user certificates using SHA1. It isn't what that class was intended
for but it should work.

Mark


> 
> regards,
> Greg
> 
> 
> On Fri, Jul 1, 2016 at 4:53 PM, Daniel Savard 
> wrote:
> 
>>   2016-06-30 23:05 GMT-04:00 Greg Beresnev :
>>
>>> Hi,
>>>
>>> We're in the process of updating our web application to stop using SHA-1
>>> certificates and I was wondering if there was some way to configure
>> Tomcat
>>> (we're on version 7.0.39 - yes, I know, we are pretty old-school and
>> should
>>> get with the times) to either throw errors or at least log warnings for
>> the
>>> cases where connection/authentication attempt is being made using SHA-1
>>> certificate?
>>>
>>
>> No.
>>
>> However, you can select the accepted ciphers to reject anything that
>> doesn't meet your standards.
>>
>> -
>> Daniel Savard
>>
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 7 and SHA-1

[Greg Beresnev]

Thanks Daniel - any idea which cipher in particular needs to be absent in
order for the SHA-1-based connection/authentication was rejected/failed?

regards,
Greg


On Fri, Jul 1, 2016 at 4:53 PM, Daniel Savard 
wrote:

>   2016-06-30 23:05 GMT-04:00 Greg Beresnev :
>
> > Hi,
> >
> > We're in the process of updating our web application to stop using SHA-1
> > certificates and I was wondering if there was some way to configure
> Tomcat
> > (we're on version 7.0.39 - yes, I know, we are pretty old-school and
> should
> > get with the times) to either throw errors or at least log warnings for
> the
> > cases where connection/authentication attempt is being made using SHA-1
> > certificate?
> >
>
> No.
>
> However, you can select the accepted ciphers to reject anything that
> doesn't meet your standards.
>
> -
> Daniel Savard
>

Re: Tomcat 7 and SHA-1

[Daniel Savard]

  2016-06-30 23:05 GMT-04:00 Greg Beresnev :

> Hi,
>
> We're in the process of updating our web application to stop using SHA-1
> certificates and I was wondering if there was some way to configure Tomcat
> (we're on version 7.0.39 - yes, I know, we are pretty old-school and should
> get with the times) to either throw errors or at least log warnings for the
> cases where connection/authentication attempt is being made using SHA-1
> certificate?
>

No.

However, you can select the accepted ciphers to reject anything that
doesn't meet your standards.

-
Daniel Savard