Thanks Chris, your comment were very valuable. Most were confirmations of my own findings which is needed after many hours of investigation when doubt kicks in. As you suggested I took a trip down the socketFactory road but realised that just sending a plain mail shouldn't be that complicated. I finally debugged down to the socket layer and found out that there was an old mail jar in the cp and when I cleaned up and updated the javax.mail to the latest and greatest the client did what I expected. So as you said, nothing to do with Tomcat and my code was correct but as usual, keep your libs tidy!
Thanks again for you time and insight. Curt > On 15 Apr 2020, at 21:01 , Christopher Schultz <ch...@christopherschultz.net> > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Curt, > > Marking [OT] since Tomcat is not responsible for sending email. > Responses in-line. > > On 4/14/20 06:48, Curt Johansson wrote: >> Hi, I have a written a webapplication deployed in Tomcat 8.5.31 >> that sends mail using Apache-commons email client. This is working >> fine but the mail server will be configured to accept only TLSv1.2 >> in the future so I have to make sure the client can open a TLSv1.2 >> connection. > > This is a good idea even if the mail server doesn't change it's > policy. (Which it should!) > >> Tomcat is configured to use Java 8 (version 1.8.0_241-b07) so as >> far as I can understand TLS1.2 should be enabled by default (as >> would 1.0 and 1.1). > Exactly what is enabled by default is dictated by your exact version > of Java. Latter-day version of Java 8 -- including _241 -- should > indeed enable TLSv1 - TLSv1.2 by default. > >> I've search the web and there is a lot of information on how to >> enable SSL/TLS for incoming requests but little is found on >> outgoing calls. The only explicit finding basically said that >> outgoing requests are independent of the configuration of the HTTPS >> connector for incoming requests, only the Java version and its >> security configuration affects this. > > It depends upon the email library you are using. For example, javamail > uses a property "mail.smtp.ssl.socketFactory" that you can pass-into > the API when creating your mail Session to connect to a server. > Instantiate an instance of an SSLSocketFactory subclass which > customizes the protocols and cipher suites your software is willing to > accept. > > Details: > https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-sum > mary.html > > I have less experience with commons-email (and found it sorely lacking > when I tried to use it years ago), but it looks like it uses javamail > under the covers, so perhaps the same technique will work, there. > >> Using Wireshark I've been testing all scenarios I could think of >> >> different Java implementations (Oracle JDK 1.8.0_241-b07, OpenJDK 8 >> [1.8.0_192], adoptopenjdk-8) setting the property >> crypto.policy=unlimited in the java.security file of the jre (for >> all alternatives above) > > This is usually good idea, anyway, but only allows higher bit-levels > for bulk encryption algorithms. It won't limit/unlimit the use of > specific TLS protocol versions. > >> setting the application argument >> -Djdk.tls.client.protocols="TLSv1.2" (seems to be ignored) > > This is used for HttpURLConnection, so will be ignored for SMTP(S). > >> configuring a HTTPS connector with secure="true" SSLEnabled="true" >> (just in case) > > This won't help, as it only configures Tomcat's <Connector>. > >> the server accepts "strict" TLS on port 465 and STARTTLS sessions >> on another port and I tried them both programatically added Bouncy >> Castle security provider as preferred added Bouncy Castle security >> provider as preferred by configuration replaced the list of default >> security providers with Bounch Castle >> >> and they all result in the same clientHello message beeing sent >> requesting a TLS1.0 session. The cipher suits are only 15 >> (including the renegotiation suite) and there are only SHA suites. > My initial guess is that: > > 1. You are using the platform-defaults for everything > 2. Another piece of code is changing the platform defaults somewhere > > Tomcat never changes any platform defaults, so if I'm right, the > problem lies elsewhere. > > The good news is that you can supply your own SSLSocketFactory which > ignores platform defaults! > >> I wrote a simple standalone client with the same email code and >> the same java version and this works as expected (strict TLS and >> STARTTLS), generating a clientHello message requesting a TLSv1.2 >> session with 29 cipher suites including SHA256 and SHA384 based >> suites. > That's good: it specifically proves that your own code isn't messing > something up. > >> I enabled the logging of TLS and got a heap of information which I >> briefly scanned but my impression was that I got the same (or >> similar) information from the Wireshark output. > Unless you understand the protocol at the byte-level, Java's SSL debug > mode is not very helpful. > >> I've debugged the code down through the layers to where the SUN >> specific code creates the connection but I couldn't step into that >> code to figure things out. >> >> Before I try to find the source for the connection creation maybe >> someone with a better insight can see some obvious way to analyse >> and solve this problem. As the code works outside of Tomcat >> >> and the Java part is the same it seem to me that there is >> something in the configuration of Tomcat that affects what >> TLS-version that is available. > Are you creating your own javax.mail.Session object? If so, how? If > not, would it be a problem to create your own? If so, you should be > able to stuff an appropriate SSLSocketFactory into the properties when > you construct it. > > Unfortunately, the JDK doesn't come with a class that allows you to do > that. You have to write the code yourself. > > You are welcome to borrow code from my "ssltest" tool which was > originally adapted from code in Apache Tomcat. If you look at > SSLUtils.getSSLSocketFactory, you'll see how to create one of these > yourself. > > Hope that helps, > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6XWg0ACgkQHPApP6U8 > pFjNQg//TDX/DYlqOQCvM2Je07xg79swKJGq9BTV88Pv9+7fkx4uC6N+piSl8Bfc > SMUN8yzweDo10PAYqrCpl1yL5kaRnRHOdyWDtnz4xnIoVeZ2URFSiKz5shpts6H0 > ucxe91NbhmD/AZbqmTzqHrEOfEptcuDd+YMUC9SoIaTZ1XkQvDbG0jqywsXZQh4w > 6D8bRVRZdaUUQfCBxmlaMAAiWrTWpmMttp4JSS2J68j4XC3ksP2T/VirWPgCiZQV > PEXMCfj90IcRkikNSFMsQzsNxlYnnULfHnkr1IekqxPeYp9krP25fEBJIiHKEYlf > xJBdQu9xmGUlinox5oce2umoP9SUA7uiLSeHD/DOwgQ+n2ZhKQCp4iOHEnD0tAma > mHJlNojVVv9cB+bDEOGUtiSMXaiNMqTWZBYgi7VHkDzx/bExuPhNBMQB47eQqzvP > bmfHjW3pGr6obzMXMFsuWCn0WhpcIYVCBZMLqLbWV1ytDg23Da8a1EKUxQy2HFs1 > MWZNnNZNlemKUBhToqHeu7fYNPM21pymi2uJ1+kJ0qL/Y3Wu6yFH7AbxCJsgv48m > x7s1vJx6KQqTGFYBNsv4jh+FPRPJEC0C9+uAmS2s00m4z4GT8b3D8NoPH+WFOYQK > 3IMTBssDmXE4UkOuxfUNSjCzcShhtOIjfVTlm35VZJgUYqItkkc= > =r7cL > -----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
