tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jammy Chen <jamm...@gmail.com>
Subject Re: Logging TLS Session Failures
Date Thu, 09 Mar 2017 13:48:17 GMT
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 <
durgasrinivasu@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) <aw@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 <
> >> chris@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-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>
> >>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>

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