Re: Can Tomcat log handshake failures, and where?
On August 2, 2019 5:23:58 PM UTC, Mark Boon 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 >Sent: Wednesday, July 31, 2019 8:47 AM >To: users@tomcat.apache.org >Subject: Re: Can Tomcat log handshake failures, and where? > >On 30/07/2019 08:28, Mark Thomas wrote: > > > >> 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-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
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 Sent: Wednesday, July 31, 2019 8:47 AM To: users@tomcat.apache.org Subject: Re: Can Tomcat log handshake failures, and where? On 30/07/2019 08:28, Mark Thomas wrote: > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can Tomcat log handshake failures, and where?
On 30/07/2019 08:28, Mark Thomas wrote: > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can Tomcat log handshake failures, and where?
Christopher, No, I don't need to log THAT failure. But I do need to log handshake failures where the failure to connect was a server-side decision. So (apparently) I do need to log cases like a handshake failure in case both sides couldn't agree on a cipher, as detailed in my question. As much as I'd like to declare handshake failures "not my problem", it doesn't help us sell to governments that require this case to be logged. And it's not as if it's technically impossible, as clearly it can be reported by setting javax.net.debug=ssl:handshake. But I want to log just the failure, and not the fire-hose amount of information this gives me for every successful handshake. Mark From: Christopher Schultz Sent: Tuesday, July 30, 2019 8:13 AM To: users@tomcat.apache.org Subject: Re: Can Tomcat log handshake failures, and where? -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 7/29/19 17:45, Mark Boon wrote: > Apparently for compliance reasons we're required to log any failed > connection attempt. So I'd like to know if and how I can get > Tomcat to emit such information. I'd try to get some clarification on that requirement. For example, if a client tries to connect and they have a network error on their end (e.g. ISP fails), are you somehow required to log THAT failure? TLS handshake failures should fall under the category of "not my problem" and you really shouldn't have to log them. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl1AXq4ACgkQHPApP6U8 pFjMIA//ctjGwEnC+yRH5awk/uPx8eaiUy63/MVOVf45NAPOs9DoCsHd3X27Mzek lKhwxfc4q8OZICfWyv+nk/VD/aAUwc1LV4ju2tq/1Qe87QQ/KnOs1ySsgTywkOE8 YEoDzVRhKw5mMBjS3Avkw+xTi5eWpUpi/fhStUuntRme+9F0JtXyuRj4V8lkpssa MOg0krWOd4jn0ngxZ1MkCx8Ybh0keKcBpyDBo3jqeZ8PUA4jTYAeVXN5eah7Hi2A kpNWi4ny7f988ZDbufXiYJxP7J3DiZ71+peKxr1NS1CDXrCBMg0xO4j9rcxjJpCY pIaJrttzJzBMjQrmUAPPfrgIYo4LCiwX6K5YFDzifFucBMCtYtHiBZBEjjLh5JJR HKU0jU0pMjru6HaKab76O85nTjMrl5P9ouvbxTPUNxtlEreFH+4cNUyf4CKlOjt2 zkK9RXeJwzpmOSlK2BmW6sC9UpCeFrpIvzBTCdhZ2EGA/ORaMK0Evz+VMSWbTvhs GMi1DIDIZh1X0Vzed9gncNKibjKMwwdEnly5MybI4qXfoPGv8Z+l6T6pjQd6hA+P c2iKjSiPdUHVSoL8iwYzVa7Yqrs+2rqnqVRA/RzX5IU5Jqj6C7A7dPxMWAirAowX M3/4CoqcK+LXqnTY/yZNQqquWrf155KHNTDuRry2CexaBNmL80A= =+jM7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can Tomcat log handshake failures, and where?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 7/29/19 17:45, Mark Boon wrote: > Apparently for compliance reasons we're required to log any failed > connection attempt. So I'd like to know if and how I can get > Tomcat to emit such information. I'd try to get some clarification on that requirement. For example, if a client tries to connect and they have a network error on their end (e.g. ISP fails), are you somehow required to log THAT failure? TLS handshake failures should fall under the category of "not my problem" and you really shouldn't have to log them. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl1AXq4ACgkQHPApP6U8 pFjMIA//ctjGwEnC+yRH5awk/uPx8eaiUy63/MVOVf45NAPOs9DoCsHd3X27Mzek lKhwxfc4q8OZICfWyv+nk/VD/aAUwc1LV4ju2tq/1Qe87QQ/KnOs1ySsgTywkOE8 YEoDzVRhKw5mMBjS3Avkw+xTi5eWpUpi/fhStUuntRme+9F0JtXyuRj4V8lkpssa MOg0krWOd4jn0ngxZ1MkCx8Ybh0keKcBpyDBo3jqeZ8PUA4jTYAeVXN5eah7Hi2A kpNWi4ny7f988ZDbufXiYJxP7J3DiZ71+peKxr1NS1CDXrCBMg0xO4j9rcxjJpCY pIaJrttzJzBMjQrmUAPPfrgIYo4LCiwX6K5YFDzifFucBMCtYtHiBZBEjjLh5JJR HKU0jU0pMjru6HaKab76O85nTjMrl5P9ouvbxTPUNxtlEreFH+4cNUyf4CKlOjt2 zkK9RXeJwzpmOSlK2BmW6sC9UpCeFrpIvzBTCdhZ2EGA/ORaMK0Evz+VMSWbTvhs GMi1DIDIZh1X0Vzed9gncNKibjKMwwdEnly5MybI4qXfoPGv8Z+l6T6pjQd6hA+P c2iKjSiPdUHVSoL8iwYzVa7Yqrs+2rqnqVRA/RzX5IU5Jqj6C7A7dPxMWAirAowX M3/4CoqcK+LXqnTY/yZNQqquWrf155KHNTDuRry2CexaBNmL80A= =+jM7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can Tomcat log handshake failures, and where?
On 29/07/2019 22:45, Mark Boon wrote: > We're using Tomcat 8.5 + Java 8. > > When I do something like openssl s_client -cipher ECDHE-RSA-NULL-SHA > -connect :443 > (where obviously ECDHE-RSA-NULL-SHA is not specified in my cipher list on the > Tomcat server) the message on the client side is > > 140701349295768:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 > alert handshake failure:s23_clnt.c:769: > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 7 bytes and written 139 bytes > --- > New, (NONE), Cipher is (NONE) > > But I don't see anything logged by Tomcat on the server side. Not to stdout, > not to catalina,out or any other log file we have. Debug level logging for the appropriate endpoint should log the exception associated with a handshake failure. There is going to be a lot of other logging though. Enabling debug logging for an Endpoint may have a performance impact. > Apparently for compliance reasons we're required to log any failed connection > attempt. So I'd like to know if and how I can get Tomcat to emit such > information. > I can pass in -Djavax.net.debug=ssl:handshake but that seems rather overkill. > The output for failed handshakes is OK, but for successful handshakes it's > enormous. > > I would actually have expected something to be logged in the access log we > have specified in the AccessLogValve specification in server.xml. But it > seems that only reports access events after a successful SSL handshake has > taken place. 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. Mark > > Does anyone know any other method? > > Thanks, in advance. > > Mark Boon > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
