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 <
ch...@christopherschultz.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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
(-Djavax.net.debug=ssl: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
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYwEBVAAoJEBzwKT+lPKRYHzkP/1O2jPMu6Z9MBdnCF6LD7FQl
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
