Thanks, Will explore JSSE options.
On Thu, Mar 9, 2017 at 7:18 PM, Jammy Chen <jamm...@gmail.com> wrote: > If you are using JSSE which you mentioned in earlier post, you probably can > only enable debug for all or specially one > -Djavax.net.debug=ssl:record or -Djavax.net.debug=ssl:handshake - but it > will log all sessions > > You could try to register a customized SSL socket factory in JSSE, you may > extend the default sun impl to overwrite the method, catch the exception > and log the failure, and throw it. > > 2017-03-09 20:04 GMT+08:00 Durga Srinivasu Karuturi < > durgasriniv...@gmail.com>: > > > 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. > > > > Thanks, > > Durga Srinivasu > > > > On Thu, Mar 9, 2017 at 3:44 PM, André Warnier (tomcat) <a...@ice-sa.com> > > wrote: > > > > > 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 > > > > > > > > >
