Re: Vulnerability on Apache Tomcat Default Files

2020-08-05 Thread FANG YAP
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

2020-08-05 Thread James H. H. Lampert

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

2020-08-05 Thread calder
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
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImp

Correction, Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40

2020-08-05 Thread James H. H. Lampert

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

2020-08-05 Thread James H. H. Lampert

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 java.lang.reflect.Method.invok

RE: Connector works fine with Firefox, but not on speaking terms with Chrome!

2020-08-05 Thread jonmcalexander
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 (0xc

Re: Connector works fine with Firefox, but not on speaking terms with Chrome!

2020-08-05 Thread James H. H. Lampert

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 Ch

RE: Connector works fine with Firefox, but not on speaking terms with Chrome!

2020-08-05 Thread jonmcalexander


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

2020-08-05 Thread James H. H. Lampert

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!

2020-08-05 Thread jonmcalexander
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!

2020-08-05 Thread calder
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!

2020-08-05 Thread James H. H. Lampert

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