-----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
