tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat)>
Subject Re: Logging TLS Session Failures
Date Thu, 09 Mar 2017 10:14:11 GMT
On 09.03.2017 09:34, Durga Srinivasu Karuturi wrote:
> This is one of the requirement from FIPS/CC certification.
> Thanks,
> Durga Srinivasu


I believe that in your original post, you said :
"We have a requirement in our application to log all TLS session failures."

You should probably have another look a the precise requirements, and the exact definition

of "our application".
Because it may be that the requirements are wrong, as far as you are concerned.

It depends on what is included in "our application".
In the java servlet container (like Tomcat) terminology, an "application" is a webapp.
A webapp runs inside a servlet container.
The servlet container (here Tomcat) runs inside a java JVM.
The java JVM runs inside an OS.
The OS runs inside a host.

In that hierarchy, a webapp only sees a request, when the servlet container has received 
this request on one of its ports, and "delegates" the request to the webapp.
By that time, the webapp does not even know through which interface the request came in, 
nor if that interface required HTTP, HTTPS or whatever other communications protocol.
And if a TLS connection from a browser failed, the webapp is not even called, so it does 
not know anything about it.
Of course the webapp cannot log a failure, if it is never called when that failure happens.

To move one level up : if a TLS connection from a browser fails, Tomcat probably never 
even sees that (because the connection never reaches Tomcat). So Tomcat cannot log this 
failure either. Tomcat is just telling some underlying layer of software (in the JVM, in 
the OS, or in some external library), what kind of connections to accept. But it does  not

manage these connections, it just "gets" a connection when it succeeds.

So if you (your team, your company) is responsible for providing the whole service, 
including the host, the OS, the JVM, the servlet container, and the webapp inside it, then

the requirement may make sense. And then you have to look for the component, at the right

level, which can provide that information. (But it is not the webapp, and it is not Tomcat).

At the other extreme, if you are providing only the web application, then the requirement

does not make sense /for you/, because it is impossible.
It is not that it does not make sense in general, but "as part of the webapp" it does not

make sense.

And that is what Christopher is also telling you (in a lot less words).

> On Wed, Mar 8, 2017 at 11:03 PM, Christopher Schultz <
>> wrote:
>> Hash: SHA256
>> Durga,
>> On 3/8/17 10:02 AM, Durga Srinivasu Karuturi wrote:
>>> We are using JSSE only not APR. Looking for handshake failures.
>>> Yes, using JSSE SSL debug, we are able to get all handshake
>>> ( logs including success cases.
>>> These are still quite bit expense logs and meant for debug
>>> purposes. As you said it might impact performance that's the
>>> reason, trying for any other optimal solution here.
>> I know of no way to be notified about handshake failures on the server
>> side. You may not be able to fulfill this requirement if using Java
>> for your crypto.
>> Honestly, I'm not sure why you care about failed TLS handshakes. Are
>> you trying to implement a NIDS in your application? This is
>> better-handled by a network component specifically-designed for this
>> kind of thing.
>> - -chris
>> Comment: GPGTools -
>> Comment: Using GnuPG with Thunderbird -
>> LMWA6jmO2YjmZFPtJykyUXHuL3beBk/+5cPV275ZApp1brJmmqnxR68P4ZuedOwY
>> pX+dLiBTvmLYmsFoYxxfdvpl44UICwvq6qx/4VsSS0okrz9JYQtmO9d2glYG6bDD
>> onLmqYoivB2N+18jXoT7PAzBZcAhHFbIFPIox4VXjs9za/WQ4Oc+BUecUKpOCc0i
>> yvMz1I9Bo5E+tCMkTsTpbtq/Sk5lF7JozOycda3OVmLpVTf7Xz07luOF0ZaJAY0t
>> VMHvNEOuph9dJxkS6mXlPnqqQwf3Prlwhx/zjWm6HT9prGBMraVb9laq44qMMUcg
>> rDSSgfxZDiSJKDw7bCA3+o3KQfqIqbkLH9nQ2WICS2YAd9jn5tqy5Faf/H7Dd71D
>> mYOdVxXPk5XJPuVOWaK9dVQOEppZ8JWjxxKaofFxFXmQpaiVbSP5FLduRrkvKgJc
>> e9necMTzyxs9RwvpJjQtf10blDc51bL3Y+KjbTgJoPTqAIm8kUgI9VOE5NUs5eip
>> 1MO9ub52ojavC10B+lU3OGggwHp068ozkM491stTZialCaTCmbo7LPZtKzIz0g4j
>> q3JgDS4Y4LVPOoLPjUSfcbzTsxnS2V/SkLhOwQpnvw4lTLrotq5CGPJDQD5ix67j
>> 2WbMcngOqAvk16kPb5u+
>> =F7yo
>> -----END PGP SIGNATURE-----
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message