Re: Vulnerability on Apache Tomcat Default Files
Hi Chris, Did that as well, but the scanner still flagged but it is to say is a false positive result in their scan? Regards with Thanks, Fang On Wed, 5 Aug 2020, 04:21 Christopher Schultz, wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Fang, > > On 8/3/20 23:10, FANG YAP wrote: > > I have an issue on the subject mentioned as the vulnerability scan > > flagged out. > > > > Plugin: 12085 Plugin Text: Apache Tomcat Default Files Protocol: > > TCP Port: 8080 > > > > Apache Tomcat 8.5.55 (x64-bit machines) > > > > In my app folder (located in the webapp folder) I already had the > > necessary error pages. Also indicated the error jsp file in the > > app's web.xml. How to know what should be shown when they(user) > > enter the wrong site for tomcat? > > > > Should it be showing this page below or it should show my custom > > error page set in app's web.xml? HTTP 404 No Found The webpage > > cannot be found.. Most likely causes:... - There might be a typing > > error in the address - If you clicked on a link, it may be out of > > date > > > > What you can try: . > > This doesn't look like a vuln to me. Your scanner is being overzealous. > > But if you want to replace the 404 Not Found page when you request > /noapp and your application is deployed to /myapp then you can't fix > the problem in "myapp". You have to make other arrangements. > > The easiest thing to do is deploy a ROOT application with all errors > (including 404) pointing to a custom error page. You can do this in > your ROOT application's WEB-INF/web.xml file. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8pwxQACgkQHPApP6U8 > pFieCA//T/Vr3DXF0AFJGPwo++x81iwy80VOSfRL6v0NNOxlKkBa7dPaUJuKYr+F > GzXaYf/FBH50dAVIfjkTtJQGvfCeEz9aqsYMCPpyzeFjtzU0FqUOrAmHJEzuBAYQ > 85Vy5MOsncDb/QhW9wMi0Vt5ffc3p4ZavF8fU1D4zJk5ecDXZtz45H4MlOp06KH0 > sUJX2wLPtWUuBLt9AvgxgXwqAmq1XJBulLAUcR8gUVkhmxB8KS/peR/eKcf11Nlk > FalhVIgHK2BkXouvaXMawbix6qt7+sd+AfmcW4dXcoiDLkuMz0MAx/FBxXP4nELF > +P5egFRE+wdTXLRr436ydhjGxhSw9nS9LiSpgSWLWBMw29/oSo+jhVQtuuVH133m > 9IWWYgneWGvXEo02MmmMbt1pZ0KVPeWVhjTDpo48xfutbRCAZCK1xwtUzz96wy2E > PRpEscyjQQzEJ11Rglu3gi/bq/YIKZLZd4n5qH2c0Z11mff2KXD5sDbZsEKRGCDR > i8EEPMss5RaRF7JyqjDU+r1FvbLDMSxOb3YeX/MvuKTPvqHuSkvNLMeKIKHxOZfC > hwLWYY9Cu9ARUj3LYpaDj8DGFf4Jotn4LREOhhlaC4XZZQ2yPIOaimvQKtOjmdqF > E9Dgqed9lutJ9n3vQysppaijUo9oEQ14pxeU+TKK6/JBcjD/sN4= > =YcwV > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40
On 8/5/20 5:04 PM, calder wrote: Caused by: java.security.KeyStoreException: Cannot store non-PrivateKeys If you pasted the full stack trace, then here we have the last "caused by", showing one issue at sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:261) at sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56) at sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117) at sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70) at java.security.KeyStore.setKeyEntry(KeyStore.java:1140) at org.apache.tomcat.util.net .SSLUtilBase.getKeyManagers(SSLUtilBase.java:313) at org.apache.tomcat.util.net .SSLUtilBase.createSSLContext(SSLUtilBase.java:239) at org.apache.tomcat.util.net .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:98) ... 20 more That is inded the full stack trace, or at least as much of it as went into catalina.out. And all the differences in domain names and filenames are accounted for, canceling each other out, leaving only the "unwanted update" as the biggest single difference between the two instances. Looking at the Manager, I see that in addition to Tomcat being updated from 8.5.40 to 8.5.57, the JVM was evidently updated from 1.8.0_201-b09 to 1.8.0_252-b09. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40
On Wed, Aug 5, 2020, 18:46 James H. H. Lampert
wrote:
> Ladies and Gentlemen:
>
> I've now proceeded to the "real" server, with the Tomcat portion of the
> procedure refined to give me plenty of "undo" capability. And it turns
> out I need it.
>
> It seems that with the unwanted update to 7.0.57 that happened on
> launching the test spot instances, the Let's Encrypt certs worked just
> fine.
>
> But applying the procedure to the *real* development instance (7.0.40)
> blew up in my face, failing to open the connectors. Here is an excerpt
> from catalina.out, showing the stacktraces.
>
> > 05-Aug-2020 23:00:52.038 WARNING [main]
> org.apache.catalina.startup.SetAllPropertiesRule.begin
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'bufferSize' to '1024' did not find a matching property.
> > 05-Aug-2020 23:00:52.085 WARNING [main]
> org.apache.catalina.startup.SetAllPropertiesRule.begin
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'bufferSize' to '1024' did not find a matching property.
> > 05-Aug-2020 23:00:52.189 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Server version:
> Apache Tomcat/8.5.40
> > 05-Aug-2020 23:00:52.189 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Server built:
> May 2 2019 18:02:51 UTC
> > 05-Aug-2020 23:00:52.194 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Server number:
> 8.5.40.0
> > 05-Aug-2020 23:00:52.194 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log OS Name:
> Linux
> > 05-Aug-2020 23:00:52.194 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log OS Version:
> 4.14.121-85.96.amzn1.x86_64
> > 05-Aug-2020 23:00:52.194 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Architecture:
> amd64
> > 05-Aug-2020 23:00:52.195 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Java Home:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.43.amzn1.x86_64/jre
> > 05-Aug-2020 23:00:52.195 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log JVM Version:
> 1.8.0_201-b09
> > 05-Aug-2020 23:00:52.195 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:
> Oracle Corporation
> > 05-Aug-2020 23:00:52.195 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE:
> /usr/share/tomcat8
> > 05-Aug-2020 23:00:52.196 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME:
> /usr/share/tomcat8
> > 05-Aug-2020 23:00:52.196 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Dcatalina.base=/usr/share/tomcat8
> > 05-Aug-2020 23:00:52.196 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Dcatalina.home=/usr/share/tomcat8
> > 05-Aug-2020 23:00:52.197 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djava.endorsed.dirs=
> > 05-Aug-2020 23:00:52.197 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djava.io.tmpdir=/var/cache/tomcat8/temp
> > 05-Aug-2020 23:00:52.197 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument:
> -Djava.util.logging.config.file=/usr/share/tomcat8/conf/logging.properties
> > 05-Aug-2020 23:00:52.197 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> > 05-Aug-2020 23:00:52.198 INFO [main]
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based
> Apache Tomcat Native library which allows optimal performance in production
> environments was not found on the java.library.path:
> [/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib]
> > 05-Aug-2020 23:00:52.422 INFO [main]
> org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> ["https-jsse-nio-8443"]
> > 05-Aug-2020 23:00:52.848 SEVERE [main]
> org.apache.catalina.core.StandardService.initInternal Failed to initialize
> connector [Connector[HTTP/1.1-8443]]
> > org.apache.catalina.LifecycleException: Failed to initialize component
> [Connector[HTTP/1.1-8443]]
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
> > at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
> > at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
>
Correction, Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40
I wrote: . . . It seems that with the unwanted update to 7.0.57 that happened on launching the test spot instances, the Let's Encrypt certs worked just fine. But applying the procedure to the *real* development instance (7.0.40) blew up in my face, failing to open the connectors. Here is an excerpt from catalina.out, showing the stacktraces. . . . Oops. I'm so used to installing and running 7.0.xx on AS/400s that I mistyped the above. Of course, I meant 8.5.57 and 8.5.40, respectively, as given in the subject line and the rest of my post. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40
Ladies and Gentlemen:
I've now proceeded to the "real" server, with the Tomcat portion of the
procedure refined to give me plenty of "undo" capability. And it turns
out I need it.
It seems that with the unwanted update to 7.0.57 that happened on
launching the test spot instances, the Let's Encrypt certs worked just fine.
But applying the procedure to the *real* development instance (7.0.40)
blew up in my face, failing to open the connectors. Here is an excerpt
from catalina.out, showing the stacktraces.
05-Aug-2020 23:00:52.038 WARNING [main]
org.apache.catalina.startup.SetAllPropertiesRule.begin
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'bufferSize'
to '1024' did not find a matching property.
05-Aug-2020 23:00:52.085 WARNING [main]
org.apache.catalina.startup.SetAllPropertiesRule.begin
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'bufferSize'
to '1024' did not find a matching property.
05-Aug-2020 23:00:52.189 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Server version:
Apache Tomcat/8.5.40
05-Aug-2020 23:00:52.189 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Server built:
May 2 2019 18:02:51 UTC
05-Aug-2020 23:00:52.194 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Server number:
8.5.40.0
05-Aug-2020 23:00:52.194 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log OS Name:
Linux
05-Aug-2020 23:00:52.194 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log OS Version:
4.14.121-85.96.amzn1.x86_64
05-Aug-2020 23:00:52.194 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Architecture:
amd64
05-Aug-2020 23:00:52.195 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Java Home:
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.43.amzn1.x86_64/jre
05-Aug-2020 23:00:52.195 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log JVM Version:
1.8.0_201-b09
05-Aug-2020 23:00:52.195 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:
Oracle Corporation
05-Aug-2020 23:00:52.195 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE:
/usr/share/tomcat8
05-Aug-2020 23:00:52.196 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME:
/usr/share/tomcat8
05-Aug-2020 23:00:52.196 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line argument:
-Dcatalina.base=/usr/share/tomcat8
05-Aug-2020 23:00:52.196 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line argument:
-Dcatalina.home=/usr/share/tomcat8
05-Aug-2020 23:00:52.197 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line argument:
-Djava.endorsed.dirs=
05-Aug-2020 23:00:52.197 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line argument:
-Djava.io.tmpdir=/var/cache/tomcat8/temp
05-Aug-2020 23:00:52.197 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line argument:
-Djava.util.logging.config.file=/usr/share/tomcat8/conf/logging.properties
05-Aug-2020 23:00:52.197 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line argument:
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
05-Aug-2020 23:00:52.198 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based
Apache Tomcat Native library which allows optimal performance in production
environments was not found on the java.library.path:
[/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib]
05-Aug-2020 23:00:52.422 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing
ProtocolHandler ["https-jsse-nio-8443"]
05-Aug-2020 23:00:52.848 SEVERE [main]
org.apache.catalina.core.StandardService.initInternal Failed to initialize
connector [Connector[HTTP/1.1-8443]]
org.apache.catalina.LifecycleException: Failed to initialize component
[Connector[HTTP/1.1-8443]]
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:639)
at org.apache.catalina.startup.Catalina.load(Catalina.java:662)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
RE: Connector works fine with Firefox, but not on speaking terms with Chrome!
Good job with those tests and good luck with the real site! Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: James H. H. Lampert Sent: Wednesday, August 5, 2020 3:39 PM To: Tomcat Users List Subject: Re: Connector works fine with Firefox, but not on speaking terms with Chrome! Jon Mcalexander wrote: > Most likely then you need to find a cypher list that is valid for TLSv1.2. > Such as below: > > ACCEPTABLE > > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 > TLS_RSA_WITH_AES_256_GCM_SHA384 > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_RSA_WITH_AES_256_CBC_SHA256 > TLS_RSA_WITH_AES_128_CBC_SHA256 > > IDEAL > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > TLS_RSA_WITH_AES_256_GCM_SHA384 > TLS_RSA_WITH_AES_128_GCM_SHA256 I came up with a couple of things to try, while I was at lunch. First, I did a quick SSLLabs scan on the server. That told me that "sslEnabledProtocols" in an SSLHostConfig was indeed wrong. And it told me that all simulated Chrome handshakes failed, but most other simulated handshakes were fine. Then (directly violating the "change only one variable at a time" principle) I set it back to "protocols," *and* cut out the cipher list entirely. That worked just fine. The weird part is that so far as I can tell, the cipher list looks *exactly* like the cipher list in the original Java Keystore version of the connector I compared the cipher lists given in the SSLLabs reports for three cases: the new connector with the old cipher list, the new connector with no cipher list at all, and (using the live version of the server) the old connector with the old cipher list, and the results were remarkable: test, no cipher list TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) WEAK128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH secp521r1 (eq. 15360 bits RSA) FS128 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02d) 128 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031) 128 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026) WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a) WEAK256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH secp521r1 (eq. 15360 bits RSA) FS256 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e) 256 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xc032) 256 test, with old cipher list TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) WEAK128 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026) WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
Re: Connector works fine with Firefox, but not on speaking terms with Chrome!
Jon Mcalexander wrote: Most likely then you need to find a cypher list that is valid for TLSv1.2. Such as below: ACCEPTABLE TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 IDEAL TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 I came up with a couple of things to try, while I was at lunch. First, I did a quick SSLLabs scan on the server. That told me that "sslEnabledProtocols" in an SSLHostConfig was indeed wrong. And it told me that all simulated Chrome handshakes failed, but most other simulated handshakes were fine. Then (directly violating the "change only one variable at a time" principle) I set it back to "protocols," *and* cut out the cipher list entirely. That worked just fine. The weird part is that so far as I can tell, the cipher list looks *exactly* like the cipher list in the original Java Keystore version of the connector I compared the cipher lists given in the SSLLabs reports for three cases: the new connector with the old cipher list, the new connector with no cipher list at all, and (using the live version of the server) the old connector with the old cipher list, and the results were remarkable: test, no cipher list TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) WEAK128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH secp521r1 (eq. 15360 bits RSA) FS 128 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02d) 128 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031) 128 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026) WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a) WEAK256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH secp521r1 (eq. 15360 bits RSA) FS 256 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e) 256 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xc032) 256 test, with old cipher list TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) WEAK128 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026) WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a) WEAK256 original connector, with old cipher list TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 The test with no cipher list produced (I think) five matches with your "acceptable" list, two of which were also on your "ideal" list. The test with the old cipher list on the new connector produced only 12 of the 18 on the "no cipher list" test, none of which were on either of your lists. And the original connector produced what appears to be a completely different list in the report, with nothing in common with the other two, or with your lists, and yet it is TLS 1.2-only, and it seems to get along just fine with
RE: Connector works fine with Firefox, but not on speaking terms with Chrome!
-Original Message- From: James H. H. Lampert Sent: Wednesday, August 5, 2020 1:06 PM To: Tomcat Users List Subject: Re: Connector works fine with Firefox, but not on speaking terms with Chrome! On 8/5/20 10:43 AM, calder wrote: > certificateVerificationh="none" > > there's one issue (misspelling), though may not be a contributing > factor. > Corrected; no effect. > Jon McAlexander wrote: > I believe that > > protocols="TLSv1.2"> > > should be > > sslEnabledProtocol="TLSv1.2" > My understanding of the instructions is that "protocols" is correct for an > SSLHostConfig, whereas "sslEnabledProtocols" is correct > for a Connector > without an SSLHostConfig. At any rate, I tried "protocols," > "sslEnabledProtocol," and "sslEnabledProtocols"; no effect. Firefox still > likes it just fine (and so does Safari), but Chrome chokes on > it (and if > there's a diagnostic to tell me the gory details of WHY it's choking on it, I > don't know where to find it). And both Chrome > > and Firefox like the new LE > cert just fine in httpd. > If it will help, the real domain is > https://test.wintouch.net > -- > JHHL Most likely then you need to find a cypher list that is valid for TLSv1.2. Such as below: ACCEPTABLE TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 IDEAL TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector works fine with Firefox, but not on speaking terms with Chrome!
On 8/5/20 10:43 AM, calder wrote: certificateVerificationh="none" there's one issue (misspelling), though may not be a contributing factor. Corrected; no effect. Jon McAlexander wrote: I believe that protocols="TLSv1.2"> should be sslEnabledProtocol="TLSv1.2" My understanding of the instructions is that "protocols" is correct for an SSLHostConfig, whereas "sslEnabledProtocols" is correct for a Connector without an SSLHostConfig. At any rate, I tried "protocols," "sslEnabledProtocol," and "sslEnabledProtocols"; no effect. Firefox still likes it just fine (and so does Safari), but Chrome chokes on it (and if there's a diagnostic to tell me the gory details of WHY it's choking on it, I don't know where to find it). And both Chrome and Firefox like the new LE cert just fine in httpd. If it will help, the real domain is https://test.wintouch.net -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Connector works fine with Firefox, but not on speaking terms with Chrome!
I believe that protocols="TLSv1.2"> should be sslEnabledProtocol="TLSv1.2" Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: calder Sent: Wednesday, August 5, 2020 12:43 PM To: Tomcat Users List Subject: Re: Connector works fine with Firefox, but not on speaking terms with Chrome! On Wed, Aug 5, 2020, 12:22 James H. H. Lampert wrote: > I've now managed to get an experimental copy of our development AWS > EC2 instance working with a cert from Let's Encrypt, and I've got > Tomcat to launch with a modified connector that uses the LE certs > rather than a Java Keystore file. > > It looks great from Firefox (except for the still-unanswered riddle of > the unwanted Tomcat update), but from Chrome, I get (domain name > "changed to protect the innocent"): > > > This site can’t provide a secure connection > > > > test.foo.net uses an unsupported protocol. > > > > ERR_SSL_VERSION_OR_CIPHER_MISMATCH > > > > Unsupported protocol > > > > The client and server don't support a common SSL protocol version or > cipher suite. > > The modified connector looks like this: > > protocol="org.apache.coyote.http11.Http11NioProtocol" > compression="on" compressionMinSize="2048" > noCompressionUserAgents="gozilla, traviata" > > > compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json" > maxThreads="1000" socket.appReadBufSize="1024" > socket.appWriteBufSize="1024" bufferSize="1024" SSLEnabled="true" > scheme="https" secure="true"> > > ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AE > S_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, > > > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_CBC_S > HA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, > > > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_S > HA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, > > > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA2 > 56,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, > > > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_ > SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" > certificateVerificationh="none" there's one issue (misspelling), though may not be a contributing factor. sslProtocol="TLS" > protocols="TLSv1.2"> >certificateFile="/etc/tomcat8/test.foo.net.crt" > certificateKeyFile="/etc/tomcat8/test.foo.net.key" > > certificateChainFile="/etc/tomcat8/test.foo.net.issuer.crt"/> > > > > > Can anybody shed any light on what I did wrong? > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector works fine with Firefox, but not on speaking terms with Chrome!
On Wed, Aug 5, 2020, 12:22 James H. H. Lampert wrote: > I've now managed to get an experimental copy of our development AWS EC2 > instance working with a cert from Let's Encrypt, and I've got Tomcat to > launch with a modified connector that uses the LE certs rather than a > Java Keystore file. > > It looks great from Firefox (except for the still-unanswered riddle of > the unwanted Tomcat update), but from Chrome, I get (domain name > "changed to protect the innocent"): > > > This site can’t provide a secure connection > > > > test.foo.net uses an unsupported protocol. > > > > ERR_SSL_VERSION_OR_CIPHER_MISMATCH > > > > Unsupported protocol > > > > The client and server don't support a common SSL protocol version or > cipher suite. > > The modified connector looks like this: > > protocol="org.apache.coyote.http11.Http11NioProtocol" > compression="on" compressionMinSize="2048" > noCompressionUserAgents="gozilla, traviata" > > > compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json" > maxThreads="1000" socket.appReadBufSize="1024" > socket.appWriteBufSize="1024" bufferSize="1024" SSLEnabled="true" > scheme="https" secure="true"> > > ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, > > > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, > > > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, > > > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, > > > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" > certificateVerificationh="none" there's one issue (misspelling), though may not be a contributing factor. sslProtocol="TLS" > protocols="TLSv1.2"> >certificateFile="/etc/tomcat8/test.foo.net.crt" > certificateKeyFile="/etc/tomcat8/test.foo.net.key" > > certificateChainFile="/etc/tomcat8/test.foo.net.issuer.crt"/> > > > > > Can anybody shed any light on what I did wrong? >
Connector works fine with Firefox, but not on speaking terms with Chrome!
I've now managed to get an experimental copy of our development AWS EC2 instance working with a cert from Let's Encrypt, and I've got Tomcat to launch with a modified connector that uses the LE certs rather than a Java Keystore file. It looks great from Firefox (except for the still-unanswered riddle of the unwanted Tomcat update), but from Chrome, I get (domain name "changed to protect the innocent"): This site can’t provide a secure connection test.foo.net uses an unsupported protocol. ERR_SSL_VERSION_OR_CIPHER_MISMATCH Unsupported protocol The client and server don't support a common SSL protocol version or cipher suite. The modified connector looks like this: protocol="org.apache.coyote.http11.Http11NioProtocol" compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json" maxThreads="1000" socket.appReadBufSize="1024" socket.appWriteBufSize="1024" bufferSize="1024" SSLEnabled="true" scheme="https" secure="true"> ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" certificateVerificationh="none" sslProtocol="TLS" protocols="TLSv1.2"> certificateFile="/etc/tomcat8/test.foo.net.crt" certificateKeyFile="/etc/tomcat8/test.foo.net.key" certificateChainFile="/etc/tomcat8/test.foo.net.issuer.crt"/> Can anybody shed any light on what I did wrong? -- James H. H. Lampert - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
