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: [OT] TLSv1.3 in TC8.5 + Azul Java 8
Chris, We have done several product releases on Azul, also running our SaaS instances without any issues. Granted, we're Windows-only product but I know other products within my company that switched to it from Oracle's Java that have not had any issues. When Oracle changed its license agreement for Java last year we were given two vendors that are allowed to be used - Azul and AdoptOpenJDK. Azul so far has been more consistent and timely in its releases where we found AOJ somewhat lagging (they had issues with certificates, file signatures and DLL properties identifying the vendor in the past) . We do use AOJ for Java+OpenJ9 VM distros though... George -Original Message- From: Christopher Schultz Sent: Thursday, August 01, 2019 5:48 PM To: users@tomcat.apache.org Subject: Re: [OT] TLSv1.3 in TC8.5 + Azul Java 8 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George, On 8/1/19 16:42, George Stanchev wrote: > As of recently Azul has backported the JSSE from Java 11 into Java > 8 [1] and it is currently offering TLSv1.3 support in its Java 8 > distro [2]. Good for them. It's too bad Oracle is so conservative with its policies. I have Azul on my list of "things to look into when I retire and my house is totally clean and my kids are finally out of the house" so of course, I'll never get around to it. I'm curious about your (and others') experiences with it. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl1DeiwACgkQHPApP6U8 pFipBA//fOTHrORxRD5OZqfigFAf7cACtsoYuJlAvh255BiJfybNg0pnBlDoIROE DCLt2Q2QQcBWUG/eeBIopdv7xeEaVaLNMl6on8CHqSdwetL9RQle1MWBG7ECexT5 ekNdspdBXb8FHatmyxfeuP80fzhJSJka+w44FdIl6tgR4WhlUnNuiYgjx2YGrycu BFyGJEmanlm96JUoAMfUqzPYd7+dxvhFR3reFo5XMq7efw9EFy31IONYRpKgIYnL PkYdZigGrHEtDS1DavasDTdgTC61uncaSDcbR68KMDPfgjC7NYk2v3/SZH6A0HBN rxWt7ADGhuioTf62e6LBxd14BveHJjtbpOsfDbKk/wIGH0U3W39MOsixgPVjJl+Y 0Tza6h3aEF8tRxTrEpQPvk4jvqDQ7uwBPvgerXfEuarECoj5zuTllzvCjPjxe9h5 vdzZNi5BwBNr3rXLRFT4nYuLMPP7bJURNZUbSxrwqVpepVDPkWWZ2Y9AGr4zT0Ld S967tDXrCsgCy8Gh5MnLcUIe9Fso8tslLMueTy227amY7lK5SvKpFeLMp9sAGPqc NAsoCYsv6V6jpM4kbDSw5QzQKqsF/dKgJgnEGqEORDbwTOUwQeV6AYbsvyFovaT0 EkVfc8A8KLf74qD3Y6Hz0AZuACVVUac3H9D2ctDPfUUca+ndYOo= =lseS -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
Re: Apache Tomcat Native Library - compatibility clarification needed?
Hi. Not a full response but an additional source. On 02.08.2019 11:12, Polina Georgieva wrote: Hi all, Would you please clarify the compatibility restrictions (if any) between the Apache Tomcat Native Lib and its dependencies on one hand and between Apache Tomcat server and the native lib. My questions are based on the information available here: http://tomcat.apache.org/native-doc/ You may also want to look at these pages : http://tomcat.apache.org/whichversion.html http://tomcat.apache.org/migration.html 1) Is it possible (or at all advisable) to build the tc-native once and then use it on a system that is not necessarily with the same versions of dependencies or JVM as the ones it was built with? Or for productive systems it is recommend always to compile on the actual system that the lib will be running on. I’m specifically interested for Linux environment. Again, not a full response, but some info : For most Linux distributions, there exist a software package manager which allows to install a pre-determined version of tomcat, including the tc-native library, and they are guaranteed to work together and with the installed OS and the installed java JVM version. (Because the "packagers" of these distributions normally make sure that this is so). The only catch is that these versions are not necessarily always the latest available tomcat versions per the tomcat website. Some Linux distributions are better than others in terms of staying up-to-date, but generally-speaking anything related to security is pretty well followed-up. If you want to always run the latest version as per the official tomcat website, then the "download" page of that website is your best choice, and whatever links you find there will always be for versions compatible with one another. But be aware in that case, that the standard layout of the files of the official tomcat website download package, is probably different from the layout of the packaged tomcats available from your Linux distribution, and that in case of updates, you will not be able to switch so easily from one to the other method. The "migration" page cited above provides additional information on that topic. 2) Are there strict requirements for the dependencies versions, meaning Tomcat Native Lib version X works only with APR version Y, OpenSSL version Z, etc. ? 3) Are there any strict compatibility mapping between the native lib version and the Tomcat server version? In other words could every Tomcat version work smoothly with the latest tc-native version? Thanks a lot! Regards, Polina - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat Native Library - compatibility clarification needed?
On 02/08/2019 10:12, Polina Georgieva wrote: > Hi all, > > Would you please clarify the compatibility restrictions (if any) between > the Apache Tomcat Native Lib and its dependencies on one hand and between > Apache Tomcat server and the native lib. My questions are based on the > information available here: http://tomcat.apache.org/native-doc/ > > 1) Is it possible (or at all advisable) to build the tc-native once and > then use it on a system that is not necessarily with the same versions of > dependencies or JVM as the ones it was built with? Or for productive > systems it is recommend always to compile on the actual system that the lib > will be running on. I’m specifically interested for Linux environment. The specific JVM version isn't that important. It will certainly work with any current JVM and probably any JVM back at least as far as Java 1.3. You should be fine building it with one JVM and using it with another. Generally, you want to compile against the versions of OpenSSL and APR that you plan to use. > 2) Are there strict requirements for the dependencies versions, meaning > Tomcat Native Lib version X works only with APR version Y, OpenSSL version > Z, etc. ? OpenSSL Needs to be one of the currently supported versions. We tend to remove the workarounds for features not present in older versions once they are no longer supported. APR We try and build with the latest version. 1.7.x and 1.6.x should both be fine. It will probably work with 1.5.x as well and maybe further back too. > 3) Are there any strict compatibility mapping between the native lib > version and the Tomcat server version? In other words could every Tomcat > version work smoothly with the latest tc-native version? You should be able to use the current Tomcat-Native library with any previous Tomcat version. The converse is not true. Each Tomcat version has a minimum required Tomcat Native version and a minimum recommended version. You'll see log errors/warnings if you start Tomcat with a version of the Native library that does not meet these minimums. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Apache Tomcat Native Library - compatibility clarification needed?
Hi all, Would you please clarify the compatibility restrictions (if any) between the Apache Tomcat Native Lib and its dependencies on one hand and between Apache Tomcat server and the native lib. My questions are based on the information available here: http://tomcat.apache.org/native-doc/ 1) Is it possible (or at all advisable) to build the tc-native once and then use it on a system that is not necessarily with the same versions of dependencies or JVM as the ones it was built with? Or for productive systems it is recommend always to compile on the actual system that the lib will be running on. I’m specifically interested for Linux environment. 2) Are there strict requirements for the dependencies versions, meaning Tomcat Native Lib version X works only with APR version Y, OpenSSL version Z, etc. ? 3) Are there any strict compatibility mapping between the native lib version and the Tomcat server version? In other words could every Tomcat version work smoothly with the latest tc-native version? Thanks a lot! Regards, Polina
