tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Durga Srinivasu Karuturi <>
Subject Re: Logging TLS Session Failures
Date Thu, 09 Mar 2017 12:04:08 GMT
Our application meaning on RHEL machine within JVM with embedded tomcat
(with single web-app)

Okay, tomcat may not have this information on handshake failures.

I need to see little higher level for capturing these failures.

Thanks for answers so far.

Durga Srinivasu

On Thu, Mar 9, 2017 at 3:44 PM, André Warnier (tomcat) <>

> On 09.03.2017 09:34, Durga Srinivasu Karuturi wrote:
>> This is one of the requirement from FIPS/CC certification.
>> Thanks,
>> Durga Srinivasu
> Durga,
> 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:

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