You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mark Boon <mb...@vmware.com.INVALID> on 2019/08/02 17:23:58 UTC
Re: Can Tomcat log handshake failures, and where?
Hi Mark,
Well, anything is 100% better than nothing. Is this "127.0.0.1 - - [31/Jul/2019:16:45:16 +0100] "-" 400 -" going to be followed by any reason or error-code that can point to the reason of failure? Anything that distinguishes it from a 'regular' 400 error originating after the handshake? I'd have to pass it by the compliance experts, but maybe even just this would be enough to convince them I don't need to use the javax.net.debug=ssl:handshake sledge-hammer.
What version will this be in?
Mark Boon
________________________________
From: Mark Thomas <ma...@apache.org>
Sent: Wednesday, July 31, 2019 8:47 AM
To: users@tomcat.apache.org <us...@tomcat.apache.org>
Subject: Re: Can Tomcat log handshake failures, and where?
On 30/07/2019 08:28, Mark Thomas wrote:
<snip/>
> Generally, processing needs to get as far as presenting a request line
> before something is added to the access logs. We could look at expanding
> the access logging to include connections that are dropped earlier but
> that might be a sufficiently invasive change that it needs to wait until
> Tomcat 10.
I've done some work on this and it looks promising. The end result is
entries like this in the access log for a failed TLS handshake:
127.0.0.1 - - [31/Jul/2019:16:45:16 +0100] "-" 400 -
127.0.0.1 - - [31/Jul/2019:16:45:16 +0100] "-" 400 -
127.0.0.1 - - [31/Jul/2019:16:45:17 +0100] "-" 400 -
127.0.0.1 - - [31/Jul/2019:16:45:17 +0100] "-" 400 -
Does this meet your requirement?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Can Tomcat log handshake failures, and where?
Posted by Mark Thomas <ma...@apache.org>.
On August 2, 2019 5:23:58 PM UTC, Mark Boon <mb...@vmware.com.INVALID> wrote:
>Hi Mark,
>
>Well, anything is 100% better than nothing. Is this "127.0.0.1 - -
>[31/Jul/2019:16:45:16 +0100] "-" 400 -" going to be followed by any
>reason or error-code that can point to the reason of failure?
No. I'm working with what I can do with the access log format.
> Anything
>that distinguishes it from a 'regular' 400 error originating after the
>handshake?
The lack of request line in the access log and the zero execution time tell you processing didn't get as far as a parsed request line but there are several ways you could end up with an entry like this.
The next step would be to add an option to log handshake failure exceptions at INFO rather than DEBUG.
> I'd have to pass it by the compliance experts, but maybe
>even just this would be enough to convince them I don't need to use
>the javax.net.debug=ssl:handshake sledge-hammer.
>
>What version will this be in?
Next 9.0.x and 8.5.x releases.
Mark
>
>Mark Boon
>________________________________
>From: Mark Thomas <ma...@apache.org>
>Sent: Wednesday, July 31, 2019 8:47 AM
>To: users@tomcat.apache.org <us...@tomcat.apache.org>
>Subject: Re: Can Tomcat log handshake failures, and where?
>
>On 30/07/2019 08:28, Mark Thomas wrote:
>
><snip/>
>
>> Generally, processing needs to get as far as presenting a request
>line
>> before something is added to the access logs. We could look at
>expanding
>> the access logging to include connections that are dropped earlier
>but
>> that might be a sufficiently invasive change that it needs to wait
>until
>> Tomcat 10.
>
>I've done some work on this and it looks promising. The end result is
>entries like this in the access log for a failed TLS handshake:
>
>127.0.0.1 - - [31/Jul/2019:16:45:16 +0100] "-" 400 -
>127.0.0.1 - - [31/Jul/2019:16:45:16 +0100] "-" 400 -
>127.0.0.1 - - [31/Jul/2019:16:45:17 +0100] "-" 400 -
>127.0.0.1 - - [31/Jul/2019:16:45:17 +0100] "-" 400 -
>
>Does this meet your requirement?
>
>Mark
>
>---------------------------------------------------------------------
>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