18

I need to log if a SSL handshake fails while a REST client tries to connect to my application. The application is build using Spring Boot and Java 8 and deployed on Tomcat 8.

In the scenario of SSL handshake failing, since the TLS connection is broken, the logging requirement might have to be done in the Tomcat layer or Java, since Tomcat is using underlying JVM for SSL certificate validation in my case.

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true" scheme="https" secure="true" keystoreFile="keyStore-1.jks" keystorePass="password" keystoreType="jks" truststoreFile="TrustStore.jks" truststorePass="passwrd" truststoreType="jks" clientAuth="want" sslProtocol="TLSv1.2" />

I am aware of enabling the debug level logging.

-Djavax.net.debug=ssl

But this logs a lot of information and will slow down the process. And log the success SSL valdiations also. Is there a way to enable the failure cases alone with minimum logs either at Java or Tomcat level.

I am NOT looking this from a debugging perspective, as the SSL debug logs are very good for that. This requirement is more from a logging and auditing purpose and enabling the debug logs is not a feasible option.A mechanism that logs only the errors happening SSL and not all the hex/cert data.

Manu
  • 1,379
  • 6
  • 24
  • 53
  • When the handshake (plaintext) fails usually you can simply use Wireshark on the host or a computer connected to mirroring port to find out what is going wrong. Set the filter to only record the traffic of the IP of the problematic REST client. Afterwards show the recorded handshake to someone that knows a bit on SSL/TLS or educate yourself... – Robert Mar 17 '17 at 16:56
  • @Robert , i think you got my question wrong. I am aware of using wireshark and analyzing the SSL debug logs to identify the issue from a debugging perceptive. But my requirement is different. I am looking for a way , how i can log the ssl handshake failure. Not from a debugging perceptive, but from a logging and auditing perceptive to be aware of the number of unsuccessful SSL handshakes that were tried to the application, – Manu Mar 18 '17 at 13:15
  • So your main target is to gather statistical data on the TLD connections - how many fail, and how many work (and may be what TLS version and cipher suite client and server agreed on). This is what you want to achieve, right? – Robert Mar 18 '17 at 13:26
  • Yes @Robert. I am mainly looking for logging only SSL handshake failures. – Manu Mar 19 '17 at 21:21
  • it appears that tomcat does not provide any way to customized or add listener to log the handshake errors. However you may try to set logging level of logger "org.apache.tomcat.util.net.NioEndpoint" to "DEBUG" and make sure it has appender which log the events at DEBUG level. In log you should someting "Error during SSL handshake". see [link](http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-coyote/8.0.24/org/apache/tomcat/util/net/NioEndpoint.java/#1517) – skadya Sep 14 '17 at 20:54

3 Answers3

12

Unfortunately, it is not possible likely. And it is not related to Tomcat. Logging of SSL it is not part of standard logging in your application. You could try reduce output with following option:

-Djava.net.debug=handshake

Some others:

  • record - Print a trace of each SSL record (at the SSL protocol level).
  • handshake - Print each handshake message as it is received
  • keygen - Print key generation data for the secret key exchange.
  • session - Print SSL session activity.
  • defaultctx - Print the default SSL initialization information.
  • sslctx - Print information about the SSL context.
  • sessioncache - Print information about the SSL session cache.
  • keymanager - Print information about calls to the key manager.
  • trustmanager - Print information about calls to the trust manager.
  • data - For handshake tracing, print out a hex dump of each message.
  • verbose - For handshake tracing, print out verbose information.
  • plaintext - For record tracing, print out a hex dump of the record.

See docs.

If you really need this and performance is critical for your application, you could instrument SSLSocket (in docs you could read about handshake process) with ASM/Btrace /etc and check the state of handshake inside it. But in that case you wouldn't have debug information - only true/false.

See also Tomcat docs with all available settings. There you can read that there is JSSEImplementation class, which is used in Tomcat. And it is wrapper for JSSE.

egorlitvinenko
  • 2,736
  • 2
  • 16
  • 36
2

I had same issue many times and i cracked it as following way. i had my project setup in intelliJ.

  1. set Debug level of the VM option : -Djavax.net.debug=all (Edit Configurations->VM Options) save and apply.
  2. Run project(App) in debug mode and check the calls between server and client. you will find there will be additional CertificateRequest call from the server to client in console as below for instance.

*** CertificateRequest Cert Types: RSA, DSS, ECDSA Supported Signature Algorithms: SHA512withRSA, Unknown (hash:0x6, signature:0x2), SHA512withECDSA, SHA384withRSA, Unknown (hash:0x5, signature:0x2), SHA384withECDSA, SHA256withRSA, Unknown (hash:0x4, signature:0x2), SHA256withECDSA, SHA224withRSA, Unknown (hash:0x3, signature:0x2), SHA224withECDSA, SHA1withRSA, SHA1withDSA, SHA1withECDSA Cert Authorities:

CN=Symantec Public Class 3, O=Symantec Corporation, C=US

CN=Symantec Class 3 Manage, OU=Symantec Trusted Network, O=Symantec, C=US

[read] MD5 and SHA1 hashes: len = 302

  1. If you can see certificate request with "CN" as above that means you are missing these certs in cacert keystore.

Solution : add missing certs (for our example two certs CN=Symantec Public Class 3 and CN=Symantec Class 3 Manage).

we have to understand the calls between server and client by the SSL Protocol, please check the following link to get more information how server and client communicate.

https://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallProbs

I will give youtube video demo if someone have issue.

I hope this solution will help someone.

Thank You.

Dhaumik
  • 29
  • 2
  • 1
    As the authur stated, they are not interested in solving the logging in a debugging context but a runtime context for auditing. – toddcscar Sep 19 '22 at 19:14
1

I wrote this up years ago, something similar should work in more recent versions of Tomcat.

Sadly, that was in Tomcat 5 or 6. I have the same problem today in Tomcat 9. As soon as I figure it out, I'll let you know what the resolution is. Basically, you want to capture and report the IOException on a handshake failure. That needs to be done in the socket factory.

Keith Boone
  • 11
  • 1