tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Savard <daniel.sav...@gmail.com>
Subject Re: TLS/SSL Elliptic Curve support problem with Tomcat 7.0.72
Date Thu, 10 Nov 2016 01:31:40 GMT
2016-11-09 16:11 GMT-05:00 Christopher Schultz <chris@christopherschultz.net
>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Daniel,
>
> You don't seem to have received a response about this...
>
> On 10/11/16 2:13 PM, Daniel Savard wrote:
> > I have a problem which evades me for a too long time. I am just
> > unable to find out what is wrong. I have a Tomcat 7.0.72 (version
> > doesn't matter the problem exists with 7.0.68 and 7.0.70 as well)
> > with Oracle JDK 1.8.0_102 (the version doesn't matter much neither
> > since the problem manifests with 1.8.0_92, 1.8.0_77 as well).
> >
> > My Tomcat is unable to complete its TLSv1.2 handshaking protocol. I
> > am getting this in my log when enabling SSL debug:
> >
> > [snip]
> >
> > The key message seems to be: Extension elliptic_curves, curve
> > names: {unknown curve 29,
> > java.security.spec.ECParameterSpec@2b839e7c,
> > java.security.spec.ECParameterSpec@55e0b1ed}
>
> That seems okay to me: Java understands 2 of the 3 curves supported by
> the client. Curve 0x19 is secp521r1 which is not mentioned by the NSA
> Suite B publication, so it's often not implemented.
>
> > I should get something with a list of recognized curves.
>
> It looks like 2 of them are recognized.
>
> > Later, when the server will complete the handshaking with a fatal
> > error, it will obviously fail agreeing on the curve and share
> > parameters. Like this:
> >
> > -------------------------
> >
> > ****** ECDH ServerKeyExchangeSignature Algorithm
> > SHA512withRSAServer key: com.rsa.cryptoj.o.fn@a9c1e230***
> > ServerHelloDone
> >
> > --------------------------
>
> It "will", or it /does/?
>
> > Where I should get the name of the curve and the parameters for the
> > shared secret.
>
> If the runtime doesn't implement the curve, you can't use it. The
> question is why the client and the server won't use the two curves
> they *do* agree on.
>
> Which client is this? Many clients (e.g. Google Chrome, MSIE/Edge)
> don't support curve #19. I use Mozilla Firefox, which currently does
> support curve #19. Does your TLS site work with Firefox? Apple Safari
> also supports curve #19.
>
> > Since I have some other instances on the same server running just
> > fine. I wonder what I should look for. What can lead to this
> > failure?
> >
> > Yes, I have the Unlimited JCE Policy installed and working for
> > other instances of Tomcat 8. Both Tomcat 8 and Tomcat 7 on this
> > server share the very same JDK.
>
> The JCE security policy probably isn't affecting this.
>
> > In the Firefox browser, the message is as follow: Unsupported
> > elliptic curve. Error code: SEC_ERROR_UNSUPPORTED_ELLIPTIC_CURVE
> > Which is the most descriptive message among the three following
> > browsers: IE 11, Chrome and Firefox. IE11 and Chrome are
> > complaining about TLS protocol error without saying anything about
> > the cause of the error.
>
> Can you post your <Connector> configuration?
>
> - -chris
>

 Hi Chris,

thanks for replying. I struggled a while with this problem to find out (I
wasn't able to append a comment to let people know) the application seems
to behave oddly. I don't have the source code for this application, it is a
commercial application and it requires some file for encryption purpose.
Usually, we are using the default. But it seems someone else decide to
tamper with this file and changed it for another one which seems to make
the application change the JVM JCE setup somehow. Anyway, I didn't
investigated further after I discovered restoring the old file makes the
problem disappear. I missed that file when I scanned the webapps filesystem
and compared the checksum file by file with a working environment because
that specific file is located outside the webapps filetree. The file itself
is encrypted/encoded, so I can't easily check the content and didn't invest
time to find out anyway.

Regards,
-----------------
Daniel Savard

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message