You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "James H. H. Lampert" <ja...@touchtonecorp.com> on 2019/05/29 18:57:27 UTC
Outbound SSL?
We have a customer that is running our Tomcat-based webapp, and it is
apparently having trouble accessing a Google web service.
The error message they're getting is:
> Unable to find acceptable protocols. isFallback=false,
> modes=[ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
> TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_2, TLS_1_1,
> TLS_1_0], supportsTlsExtensions=true),
> ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
> TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_0],
> supportsTlsExtensions=true), ConnectionSpec()], supported
> protocols=[TLSv1]
Is this something that could be caused by a Tomcat configuration issue?
--
James H. H. Lampert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: AW: Outbound SSL?
Posted by George Stanchev <Ge...@microfocus.com>.
What is your webapp using as HTTP client that handles the SSL?
-----Original Message-----
From: James Lampert <ja...@touchtonecorp.com>
Sent: Friday, May 31, 2019 3:41 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: AW: Outbound SSL?
This just keeps getting weirder and weirder.
I extracted the actual request
> https://maps.googleapis.com/maps/api/geocode/json?key=<REDACTED>&addre
> ss=<REDACTED>
from where it had been logged to catalina.out, and built a simple program to feed it to Scott Klement's HTTPAPI, an open-source HTTP interface for OS/400-native programs. It has a rather rich debugging capability.
Once I got it working on our box, I sent it over to the "problem" box.
And it worked perfectly: it got what appears to be the expected response.
Of course, it's doing all of this natively, rather than through Java.
We also know that Tomcat is running under a 64-bit Java 7 JVM on that box. And we also know that we've got this product running in Java 6, 7, and 8, on IBM Midrange boxes, WinDoze boxes, and Linux boxes, without the problem occurring.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: Outbound SSL?
Posted by James Lampert <ja...@touchtonecorp.com>.
This just keeps getting weirder and weirder.
I extracted the actual request
> https://maps.googleapis.com/maps/api/geocode/json?key=<REDACTED>&address=<REDACTED>
from where it had been logged to catalina.out, and built a simple
program to feed it to Scott Klement's HTTPAPI, an open-source HTTP
interface for OS/400-native programs. It has a rather rich debugging
capability.
Once I got it working on our box, I sent it over to the "problem" box.
And it worked perfectly: it got what appears to be the expected
response.
Of course, it's doing all of this natively, rather than through Java.
We also know that Tomcat is running under a 64-bit Java 7 JVM on that
box. And we also know that we've got this product running in Java 6,
7, and 8, on IBM Midrange boxes, WinDoze boxes, and Linux boxes,
without the problem occurring.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: Outbound SSL?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 5/31/19 13:50, André Warnier (tomcat) wrote:
> On 31.05.2019 18:12, James H. H. Lampert wrote:
>> Thanks.
>>
>> We think that the customer has solved the cipher problem,
>> because, at least as of when I checked on Wednesday, that error
>> message was no longer appearing.
>>
>> Yet they're still not connecting. I can *ping*
>> maps.googleapis.com from their box, with no trouble whatsoever,
>
> That is perhaps because "ping" does not use TCP/IP, it uses
> another protocol called ICMP, which is (a) connection-less and (b)
> not usually blocked by firewalls. At least, this shows that the DNS
> part is working correctly, and that the customer's host has a
> "route" to that server. But for example, if the server (or a
> firewall) blocked connections to the port which the webapp is
> trying to reach, you would still get the problem below. (Or if the
> server simply is not listening on that port).
+1
James, what if you:
$ openssl s_client -connect maps.googleapis.com:443
Do you get a connection? If so, there is some other issue with the
software and we'll have to dig-in. If that does NOT connect, then it
is probably a network / firewall problem.
That's the same IPv6 address that I get when I do "host
maps.googleapis.com" so at least you aren't having DNS intercepted or
something like that.
You may also need to go through an HTTP proxy to get to the outside.
You might want to ask the client is they require an HTTP proxy.
Hmm. Intermittent connection failures, sometimes with cipher-suite
mismatches and other weird things? Maybe they are one of those
companies who MitM everything and their MitM box is badly
configured... or they are playing with it.
I'm putting the certificate actually presented by maps.googleapis.com
to a clean source below. If you can connect with "openssl s_client"
then check to see that they are the same. If the company is MitM'ing,
then tell them to (a) stop it and (b) fix that component to that it
works properly.
> But when the webapp tries to connect, it gets
>>> java.net.ConnectException: Failed to connect to
>>> maps.googleapis.com/2607:f8b0:4009:807:0:0:0:200a:443
>>
>> And the really weird part is that none of the messages in the
>> resulting stacktrace appear to refer to any of our classes, or to
>> any classes that appear to have anything to do with Tomcat.
>>
>
> This is not so weird, if that webapp (as is likely) contains its
> own classes to make the connection that /it/ tries to make to the
> Google server.
Or, like a lot of software, using something like Apache http-client.
The package name for that starts with org.apache.http and there can be
miles of stack frames in their traces. (IMO http-client has become far
too complicated to be of use to casual programmers. I honestly can't
believe it's that complicated to make an HTTP request. Spoiler alert:
it's not.)
Would you be willing to post some (or all!) of the stack trace?
> The problem seems to be with the webapp, and you would have more
> luck trying to get information from whoever supplied that webapp.
> Maybe it has some parameter to increase its log level, which may
> tell you in the log the details of why it cannot establish a TCP
> connection with the Google server. (Who knows, the customer server
> IP may even be blacklisted by Google..)
That's an interesting thought, but Google doesn't usually do that
without a really good reason.
- -chris
FYI, Google's certificate from maps.googleapis.com
- -----BEGIN CERTIFICATE-----
MIIJgjCCCGqgAwIBAgIQcK7vFJuw8fXplnyGbKi9QTANBgkqhkiG9w0BAQsFADBU
MQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMSUw
IwYDVQQDExxHb29nbGUgSW50ZXJuZXQgQXV0aG9yaXR5IEczMB4XDTE5MDUxNDEz
MjkxM1oXDTE5MDgwNjEzMjAwMFowajELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNh
bGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxEzARBgNVBAoMCkdvb2ds
ZSBMTEMxGTAXBgNVBAMMECouZ29vZ2xlYXBpcy5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC6XmMJ8cxe0oZB9J7hVKGmxaVUTDv68JPrhWeKpnd0
fXrUFGJsP9XREfdRQV+K30pwSFFfbHA/nZCvwPpsp63uuLq+NBXZ7bqylRKyafbL
ThBzkv/2U8SSPQuriQAAkJOS7c+wDfx8eugSzDq1NEmbRAAvYcphszy2LLD8GpZm
2ueogwYDnojcolZ2n34nXPq6ae8BQSxJzbhirzBknNapRuos/knu3KNWq/a/LgPx
SVa1yN6OcBoWWRKcVYz74mGEbVA9kwAmA2xhGd/lXHg7lotjRgBWHv1Bt+QumRFE
XCPIWeFcY/eSVqcNK0RUydp5UnMpvSYd/QfQ2sZAk3pNAgMBAAGjggY4MIIGNDAT
BgNVHSUEDDAKBggrBgEFBQcDATCCBQ0GA1UdEQSCBQQwggUAghAqLmdvb2dsZWFw
aXMuY29tghQqLmNsaWVudHM2Lmdvb2dsZS5hZYIUKi5jbGllbnRzNi5nb29nbGUu
YXSCFCouY2xpZW50czYuZ29vZ2xlLmJlghQqLmNsaWVudHM2Lmdvb2dsZS5jYYIU
Ki5jbGllbnRzNi5nb29nbGUuY2iCFCouY2xpZW50czYuZ29vZ2xlLmNsghcqLmNs
aWVudHM2Lmdvb2dsZS5jby5pZIIXKi5jbGllbnRzNi5nb29nbGUuY28uaWyCFyou
Y2xpZW50czYuZ29vZ2xlLmNvLmlughcqLmNsaWVudHM2Lmdvb2dsZS5jby5qcIIX
Ki5jbGllbnRzNi5nb29nbGUuY28ua3KCFyouY2xpZW50czYuZ29vZ2xlLmNvLm56
ghcqLmNsaWVudHM2Lmdvb2dsZS5jby51a4IXKi5jbGllbnRzNi5nb29nbGUuY28u
dmWCFyouY2xpZW50czYuZ29vZ2xlLmNvLnphghUqLmNsaWVudHM2Lmdvb2dsZS5j
b22CGCouY2xpZW50czYuZ29vZ2xlLmNvbS5hcoIYKi5jbGllbnRzNi5nb29nbGUu
Y29tLmF1ghgqLmNsaWVudHM2Lmdvb2dsZS5jb20uYnKCGCouY2xpZW50czYuZ29v
Z2xlLmNvbS5jb4IYKi5jbGllbnRzNi5nb29nbGUuY29tLmVnghgqLmNsaWVudHM2
Lmdvb2dsZS5jb20ua3eCGCouY2xpZW50czYuZ29vZ2xlLmNvbS5teIIYKi5jbGll
bnRzNi5nb29nbGUuY29tLm9tghgqLmNsaWVudHM2Lmdvb2dsZS5jb20ucGWCGCou
Y2xpZW50czYuZ29vZ2xlLmNvbS5waIIYKi5jbGllbnRzNi5nb29nbGUuY29tLnFh
ghgqLmNsaWVudHM2Lmdvb2dsZS5jb20uc2GCGCouY2xpZW50czYuZ29vZ2xlLmNv
bS5zZ4IYKi5jbGllbnRzNi5nb29nbGUuY29tLnRyghgqLmNsaWVudHM2Lmdvb2ds
ZS5jb20udHeCGCouY2xpZW50czYuZ29vZ2xlLmNvbS51YYIYKi5jbGllbnRzNi5n
b29nbGUuY29tLnZughQqLmNsaWVudHM2Lmdvb2dsZS5jeoIUKi5jbGllbnRzNi5n
b29nbGUuZGWCFCouY2xpZW50czYuZ29vZ2xlLmRrghQqLmNsaWVudHM2Lmdvb2ds
ZS5lc4IUKi5jbGllbnRzNi5nb29nbGUuZmmCFCouY2xpZW50czYuZ29vZ2xlLmZy
ghQqLmNsaWVudHM2Lmdvb2dsZS5pZYIUKi5jbGllbnRzNi5nb29nbGUuaXOCFCou
Y2xpZW50czYuZ29vZ2xlLml0ghQqLmNsaWVudHM2Lmdvb2dsZS5qcIIUKi5jbGll
bnRzNi5nb29nbGUubmyCFCouY2xpZW50czYuZ29vZ2xlLm5vghQqLmNsaWVudHM2
Lmdvb2dsZS5wbIIUKi5jbGllbnRzNi5nb29nbGUucHSCFCouY2xpZW50czYuZ29v
Z2xlLnJvghQqLmNsaWVudHM2Lmdvb2dsZS5ydYIUKi5jbGllbnRzNi5nb29nbGUu
c2WCGCouY2xvdWRlbmRwb2ludHNhcGlzLmNvbYIWY2xvdWRlbmRwb2ludHNhcGlz
LmNvbYIOZ29vZ2xlYXBpcy5jb20waAYIKwYBBQUHAQEEXDBaMC0GCCsGAQUFBzAC
hiFodHRwOi8vcGtpLmdvb2cvZ3NyMi9HVFNHSUFHMy5jcnQwKQYIKwYBBQUHMAGG
HWh0dHA6Ly9vY3NwLnBraS5nb29nL0dUU0dJQUczMB0GA1UdDgQWBBRxYcRmw0SF
vmev8mHK0IMW61SDjTAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFHfCuFCaZ3Z2
sS3ChtCDoH6mfrpLMCEGA1UdIAQaMBgwDAYKKwYBBAHWeQIFAzAIBgZngQwBAgIw
MQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC5wa2kuZ29vZy9HVFNHSUFHMy5j
cmwwDQYJKoZIhvcNAQELBQADggEBADFtwqRJHYeFt+B/7uOBke7lBTW1GDgNIaeY
CbawFVNeSOWjlCAn0oloHc07PTfyMs9VAQOTCKAZYnpSDhPubrzIGJJUyZN1tmI8
TKD0p7PpGmeRfw/QRvg5Hh5wEMM3syivNB3u3/iNIPBRpjdL8iFdv4Yd9qonW4hn
LZCIG6SMw+B5Pq7A7EV52+2xmKEtRspNiMAbSkDwWSmfxTVRdY6CH7/Jn6ORg/Nt
YWyNTQvMmQ7GisyfqRj81PVHDTxkNlaB7h/DvdYKN+I+xDpC+g+YdeClT6xUTnEK
tzah3TCyR7OLwb3R2B86xrqcjbed1bov+MCMvUUXt3k+q0z1430=
- -----END CERTIFICATE-----
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzxlYQACgkQHPApP6U8
pFiO0A//Z/5+Rk3Sm8Lo1BtGx02qFxOZkNWH0J9GZavTIlQ52hcAgwoP2EWAYYBV
BYaYSqZa6KmZv6XIuz+naf/L4/bdeTLuoV5qL8dWtaHvERyhoz3hpbHyAjxCKgnx
4L0xktkEpQSufkRIVN1vX0tLLMyhCYWPYlf4KnHqZZVGxZ5RB0LUoLviyqockHUv
PYajQZHmR2YmY8P6zoK0e1s30piwhLhDT3ss/uM/Vq5hQAepDk8K/vn9zNVaazvl
GDRINYLXTqruU1847SEqH8bk9d69UW8Qt6ufJ8qnsMEYnNxuOiGaXakeYw1hJ6TW
Eg7/QZl6y1i7eDMqxgCXI89lgGeYR/peskt4Q8nLxbcCyOgAVexjBqpvYuogqzl2
O2MQmCAxwCbald+l/gRNPiXXSIwAl01NuY29xxaT+y1lMa+KoD+UPXHbFk+60Yfx
G5wKNL+GhIDMWR8GOP2/7Lq+XdxngtEhzUij2nmJvK5sh1HSeesusYnaorN3g1Gv
LyBMdOOUb8xz+/dUpZD6Bq71X+nrS6wulr2Ulbw2Si4Vfu9Z2CSxOOQY9ggq2b8b
O5B1vbXqWAUEPTOKx98qxGW6E2+zjjtip4yYL834zrao+RRsVkKca79vgTRwpcN8
E+ad+BwB5j/ZynkPQDRHh76/TsxetWAXScQJq1/5gaY3z23SDmk=
=uLTj
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: Outbound SSL?
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 31.05.2019 18:12, James H. H. Lampert wrote:
> Thanks.
>
> We think that the customer has solved the cipher problem, because, at least as of when I
> checked on Wednesday, that error message was no longer appearing.
>
> Yet they're still not connecting. I can *ping* maps.googleapis.com from their box, with no
> trouble whatsoever,
That is perhaps because "ping" does not use TCP/IP, it uses another protocol called ICMP,
which is (a) connection-less and (b) not usually blocked by firewalls.
At least, this shows that the DNS part is working correctly, and that the customer's host
has a "route" to that server.
But for example, if the server (or a firewall) blocked connections to the port which the
webapp is trying to reach, you would still get the problem below. (Or if the server simply
is not listening on that port).
But when the webapp tries to connect, it gets
>> java.net.ConnectException: Failed to connect to
>> maps.googleapis.com/2607:f8b0:4009:807:0:0:0:200a:443
>
> And the really weird part is that none of the messages in the resulting stacktrace appear
> to refer to any of our classes, or to any classes that appear to have anything to do with
> Tomcat.
>
This is not so weird, if that webapp (as is likely) contains its own classes to make the
connection that /it/ tries to make to the Google server.
I believe that someone mentioned before, that Tomcat does not contain any class for making
outbound connections to another server.
The connection is thus (probably, at a lower level) made by classes belonging to the JVM
which you are using to run Tomcat (like the "java.net.ConnectException" above). In any
case, Tomcat itself has no role in it.
The problem seems to be with the webapp, and you would have more luck trying to get
information from whoever supplied that webapp. Maybe it has some parameter to increase
its log level, which may tell you in the log the details of why it cannot establish a TCP
connection with the Google server.
(Who knows, the customer server IP may even be blacklisted by Google..)
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: Outbound SSL?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
Thanks.
We think that the customer has solved the cipher problem, because, at
least as of when I checked on Wednesday, that error message was no
longer appearing.
Yet they're still not connecting. I can *ping* maps.googleapis.com from
their box, with no trouble whatsoever, But when the webapp tries to
connect, it gets
> java.net.ConnectException: Failed to connect to maps.googleapis.com/2607:f8b0:4009:807:0:0:0:200a:443
And the really weird part is that none of the messages in the resulting
stacktrace appear to refer to any of our classes, or to any classes that
appear to have anything to do with Tomcat.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Outbound SSL?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Peter,
On 6/1/19 03:27, Peter Kreuser wrote:
> Crazy enough, but Google maps provides ciphers even for Java 6.
>
> https://www.ssllabs.com/ssltest/analyze.html?d=maps.google.com&s=216.5
8.195.78&latest
>
> So this would be the only strange but obvious difference. The list
> has EVEN ECDH, GCM, AES 256.
That's for Google Maps public web site, not the API. It would not
surprise me to learn that the API is more restrictive in what it will
accept.
[checks]
Oh, wow. Yeah, they support a log of old funky stuff.
But they also support TLSv1.3, so that's nice :)
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlz1kkIACgkQHPApP6U8
pFivkg//euo8E9SD+2D6svh/M2gqFf2rz5ReqREM2YbLtvIoL9LrORxgfMES76SX
thqW96PMJT6qPesQ6vSmi2u2YQp/u8veYpu/hx0FPTkZJ+2fvWrlLWzy6WnwWFx7
HnuknVtdohbqLcI4l7rnz98Is9hCYv/NMFdTX7b65hSx0hGUEbosu3OW+Dr99qtG
eZCpD+vD+ngbp1zRZeH0lfOnmKksDDuN0KrxqG+uTN+KNCXzL6zkg+elWHRagIlQ
I2uNTYnwqbSM5Et8NGr+8WjNYk5mFtetJJeT4pBtiCJj7Dl18pJ37WLj/OvYkVRw
4aDdkp0lCKCHtH9b2YQgUNiFOC8Y1o7oQFk9lS4UNlQy/7uQbWZK1OLxFBPabmv7
yXbYQ7zghVaKFYpLVzneFnkIMO53c2x2uk91HvOYF/bwYKmi2B7Yd7r+UR1oqI4W
UbGFOJ7DOGrt0tYlpxzLjRqzQMrSpBnlTDpKs7kmRtxqRXao5hWmBwGbWxfzxluL
XB8aqJO7vnb2rhWw2Jx1WQuOK6XBKQ6hPjDfLPQLSh041ebLdVBvtep9G+J6XBQ+
6M+5xb72NqBIPkRQO5MnubzNclmfUhmVGUaThGONDd3yuX28qo678A3kRkOFHyba
hC4lk1SgRW366rp7EMpI81r4gIZI8+44ZJIVNqSEL9BPTBgWUws=
=3eKL
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: Outbound SSL?
Posted by Peter Kreuser <lo...@kreuser.name>.
Chris, James
> Am 01.06.2019 um 02:30 schrieb Christopher Schultz <ch...@christopherschultz.net>:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> James,
>
>> On 5/31/19 18:41, James H. H. Lampert wrote:
>>> On 5/31/19, 3:34 AM, bernd.schatz@daimler.com wrote:
>>> You can run a small java program on your jvm to print out the
>>> supported And default protocols. Yet, I didn’t find a better
>>> way.
>>>
>>> e.g. ==>
>>> https://confluence.atlassian.com/stashkb/list-ciphers-used-by-jvm-679
> 609085.html
>>>
>>
>>>
>> If I set the same JAVA_HOME as Tomcat was launched under, and
>> compile and run "Ciphers.java" from the above site, on the customer
>> box, I get:
>>
>>> Default Cipher SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SH *
>>> SSL_DHE_DSS_WITH_AES_128_CBC_SHA *
>>> SSL_DHE_DSS_WITH_AES_128_CBC_SHA256
>>> SSL_DHE_DSS_WITH_AES_128_GCM_SHA256 *
>>> SSL_DHE_DSS_WITH_AES_256_CBC_SHA *
>>> SSL_DHE_DSS_WITH_AES_256_CBC_SHA256
>>> SSL_DHE_DSS_WITH_AES_256_GCM_SHA384 SSL_DHE_DSS_WITH_DES_CBC_SHA
>>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA *
>>> SSL_DHE_RSA_WITH_AES_128_CBC_SHA *
>>> SSL_DHE_RSA_WITH_AES_128_CBC_SHA256
>>> SSL_DHE_RSA_WITH_AES_128_GCM_SHA256 *
>>> SSL_DHE_RSA_WITH_AES_256_CBC_SHA *
>>> SSL_DHE_RSA_WITH_AES_256_CBC_SHA256
>>> SSL_DHE_RSA_WITH_AES_256_GCM_SHA384 SSL_DHE_RSA_WITH_DES_CBC_SHA
>>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
>>> SSL_DH_anon_WITH_AES_128_CBC_SHA
>>> SSL_DH_anon_WITH_AES_128_CBC_SHA256
>>> SSL_DH_anon_WITH_AES_128_GCM_SHA256
>>> SSL_DH_anon_WITH_AES_256_CBC_SHA
>>> SSL_DH_anon_WITH_AES_256_CBC_SHA256
>>> SSL_DH_anon_WITH_AES_256_GCM_SHA384 SSL_DH_anon_WITH_DES_CBC_SHA
>>> * SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA *
>>> SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
>>> SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 *
>>> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA *
>>> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
>>> SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
>>> SSL_ECDHE_ECDSA_WITH_NULL_SHA *
>>> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA *
>>> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256
>>> SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256 *
>>> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA *
>>> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>>> SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>>> SSL_ECDHE_RSA_WITH_NULL_SHA *
>>> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA *
>>> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
>>> SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 *
>>> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA *
>>> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
>>> SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
>>> SSL_ECDH_ECDSA_WITH_NULL_SHA *
>>> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA *
>>> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256
>>> SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256 *
>>> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA *
>>> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384
>>> SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384 SSL_ECDH_RSA_WITH_NULL_SHA
>>> SSL_ECDH_anon_WITH_AES_128_CBC_SHA
>>> SSL_ECDH_anon_WITH_AES_256_CBC_SHA SSL_ECDH_anon_WITH_NULL_SHA
>>> SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5
>>> SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA SSL_KRB5_WITH_DES_CBC_MD5
>>> SSL_KRB5_WITH_DES_CBC_SHA SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
>>> SSL_RSA_FIPS_WITH_DES_CBC_SHA *
>>> SSL_RSA_WITH_AES_128_CBC_SHA *
>>> SSL_RSA_WITH_AES_128_CBC_SHA256 SSL_RSA_WITH_AES_128_GCM_SHA256 *
>>> SSL_RSA_WITH_AES_256_CBC_SHA *
>>> SSL_RSA_WITH_AES_256_CBC_SHA256 SSL_RSA_WITH_AES_256_GCM_SHA384
>>> SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_NULL_MD5
>>> SSL_RSA_WITH_NULL_SHA SSL_RSA_WITH_NULL_SHA256 *
>>> TLS_EMPTY_RENEGOTIATION_INFO_SCSV
>
> Other than the fact that none of those start with TLS_ like all modern
> cipher suites do, the above looks okay.
>
Crazy enough, but Google maps provides ciphers even for Java 6.
https://www.ssllabs.com/ssltest/analyze.html?d=maps.google.com&s=216.58.195.78&latest
So this would be the only strange but obvious difference. The list has EVEN ECDH, GCM, AES 256.
>> FOR COMPARISON PURPOSES, what we get on our box is:
>>> Default Cipher * SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA *
>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA *
>>> SSL_DHE_DSS_WITH_AES_128_CBC_SHA *
>>> SSL_DHE_DSS_WITH_AES_256_CBC_SHA *
>>> SSL_DHE_DSS_WITH_DES_CBC_SHA *
>>> SSL_DHE_DSS_WITH_RC4_128_SHA *
>>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA *
>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA *
>>> SSL_DHE_RSA_WITH_AES_128_CBC_SHA *
>>> SSL_DHE_RSA_WITH_AES_256_CBC_SHA *
>>> SSL_DHE_RSA_WITH_DES_CBC_SHA
>>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
>>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
>>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
>>> SSL_DH_anon_WITH_AES_128_CBC_SHA
>>> SSL_DH_anon_WITH_AES_256_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA
>>> SSL_DH_anon_WITH_RC4_128_MD5 SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5
>>> SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA
>>> SSL_KRB5_EXPORT_WITH_RC4_40_MD5 SSL_KRB5_EXPORT_WITH_RC4_40_SHA
>>> SSL_KRB5_WITH_3DES_EDE_CBC_MD5 SSL_KRB5_WITH_3DES_EDE_CBC_SHA
>>> SSL_KRB5_WITH_DES_CBC_MD5 SSL_KRB5_WITH_DES_CBC_SHA
>>> SSL_KRB5_WITH_RC4_128_MD5 SSL_KRB5_WITH_RC4_128_SHA *
>>> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA *
>>> SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 *
>>> SSL_RSA_EXPORT_WITH_RC4_40_MD5 *
>>> SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA *
>>> SSL_RSA_FIPS_WITH_DES_CBC_SHA *
>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA *
>>> SSL_RSA_WITH_AES_128_CBC_SHA *
>>> SSL_RSA_WITH_AES_256_CBC_SHA * SSL_RSA_WITH_DES_CBC_SHA
>>> SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA *
>>> SSL_RSA_WITH_RC4_128_MD5 * SSL_RSA_WITH_RC4_128_SHA
>
> Almost all of the above cipher suites are useless.
>
> Anything starting with SSL_*_DSS uses DSS authentication which is used
> by exactly nobody. Same thing with KRB5 -- nobody is being KErberos
> for TLS/SSL. Everyone uses either RSA or Elliptic Curve certificates.
>
> Anything containing _anon_, EXPORT, FIPS, RC4, or MD5 should be
> eliminated as providing weak or actually-useless security.
>
> Anything containing NULL means that there is no encryption. Duh.
>
> So we are left with this list:
>
>> * SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA *
>> SSL_DHE_RSA_WITH_AES_128_CBC_SHA *
>> SSL_DHE_RSA_WITH_AES_256_CBC_SHA *
>> SSL_DHE_RSA_WITH_DES_CBC_SHA *
>> SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA *
>> SSL_RSA_FIPS_WITH_DES_CBC_SHA *
>> SSL_RSA_WITH_3DES_EDE_CBC_SHA * SSL_RSA_WITH_AES_128_CBC_SHA
>> * SSL_RSA_WITH_AES_256_CBC_SHA *
>> SSL_RSA_WITH_DES_CBC_SHA
>
> All of those use SHA1 signatures which are no longer considered
> secure. That means that basically none of these cipher suites are
> acceptable for a modern security posture.
>
+1 however that’s not James’ problem, I think. Customer box is the first list of ciphers.
> Here's what we have enabled at $work for production:
>
> Supported Protocol Cipher
> Accepted TLSv1.2 TLS_RSA_WITH_AES_256_CBC_SHA
> Accepted TLSv1.2 TLS_RSA_WITH_AES_256_CBC_SHA256
> Accepted TLSv1.2 TLS_RSA_WITH_AES_128_CBC_SHA256
> Accepted TLSv1.2 TLS_RSA_WITH_AES_128_GCM_SHA256
> Accepted TLSv1.2 TLS_RSA_WITH_AES_256_GCM_SHA384
> Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
> Accepted TLSv1.2 TLS_RSA_WITH_AES_128_CBC_SHA
> Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> Accepted TLSv1.1 TLS_RSA_WITH_AES_256_CBC_SHA
> Accepted TLSv1.1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> Accepted TLSv1.1 TLS_RSA_WITH_AES_128_CBC_SHA
> Accepted TLSv1.1 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> Accepted TLSv1 TLS_RSA_WITH_AES_256_CBC_SHA
> Accepted TLSv1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> Accepted TLSv1 TLS_RSA_WITH_AES_128_CBC_SHA
> Accepted TLSv1 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>
> There are some cipher suites in there with _SHA at the end. Those are
> in there for ancient browsers that simply can't do modern protocols,
> and they are prioritized to the bottom of the list.
>
> But everything else is pretty good IMO.
>
> SSLLabs/Qualys still complains about every one of those except these two
> :
>
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>
> ... calling the others "weak". I think that's because they consider
> anytning that isn't using ECDHE+GCM to be "weak". Well, it's the best
> we can do right now without going up to TLSv1.3.
>
> Anyhow, if the client (or the server) is being run with any decent
> kind of TLS configuration, then the second list of supported cipher
> suites shown above will simply not be able to connect.
>
> Assuming that you are using the built-in Java JSSE provider, then the
> problem is that your Java version is just too old: you need a newer
> version of Java to get better cipher suites.
>
> You never said what version(s) of Java you are using. You also didn't
> mention whether or not you had installed the "Unlimited Strength
> Cipher" patch that you really should install for older versions of
> Java. You have to re-install that patch every time you upgrade Java
> (until you get to a recent version, where they removed that stupid
> cipher strength limitation).
>
James, the Java version would really help.
Then, even if good ciphers provided by Java, are they used in the connection? If the setter does limit the cipher choice, or the protocol (IIRC that was the error message), bam, your locked out. Are those parameters configurable (in a settings file)?
Peter
> Hope that helps,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzxxyoACgkQHPApP6U8
> pFhn8Q/9F/9bU3pTFeooxzR6oSCCy2J99jJWPP2gjtItszlA5qdimz8O+/kq9WiX
> mOEpmmzj1VvBODIcoaHW/p+nIFKuC2BuStWCrJo4VQ+7bL6ci4O5GkcifZLUKSuI
> Z6zAO22ZcbazmFW4spLZzpUVOtrZpYrWDG9Qwij/F8MGnFlUq1P0sTVbXwZ254cQ
> hRelsKxQMgd6yUrd4WLgJ81BZe4GPdLt1JjRTeF1j9wGUC++zNjNGsdJ/xYPh+ZN
> WbtpvklJ3N9o4F6S1FYr7c0IcQqsdk0cY6MizQyip9OrZBEfyKJ7y7kSfgIWZ8VR
> hCP6HHddOqR4mevaUXaCE4PFx8rzuDlroCrTwaiIkGoQkQfEkOWitZ+R8XQvUlt0
> d4GKetbP0xokXCLv3akmjCMqtxOgwgv3W2go/GvEwv2pqZMPQ36GxMr9TcHoUSLc
> TaZOVvUtc+OaKTijKQGvM4wOBEtK72xtpK7Z993aORx9ZwWCFTuGeaq3PYNX9Hps
> H6tvpM/FoMb6mnmDnCvJ+qANKh/T7MCyWCd3KKISmuyH4UPJJlXiqg5ipIXojqYU
> xzGV34kuM18F+zmNtBjhCrK9ULNFkxmsyrFXAcdB7f5ezTlwb7RKP/EI6vaeElAp
> m48mnUps58dzMkd/Ejd6vWQ7gSr1P++4kBESVXAbybgEqRdlnLc=
> =UCiO
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: AW: Outbound SSL?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
James,
On 5/31/19 18:41, James H. H. Lampert wrote:
> On 5/31/19, 3:34 AM, bernd.schatz@daimler.com wrote:
>> You can run a small java program on your jvm to print out the
>> supported And default protocols. Yet, I didn’t find a better
>> way.
>>
>> e.g. ==>
>> https://confluence.atlassian.com/stashkb/list-ciphers-used-by-jvm-679
609085.html
>>
>
>>
> If I set the same JAVA_HOME as Tomcat was launched under, and
> compile and run "Ciphers.java" from the above site, on the customer
> box, I get:
>
>> Default Cipher SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SH *
>> SSL_DHE_DSS_WITH_AES_128_CBC_SHA *
>> SSL_DHE_DSS_WITH_AES_128_CBC_SHA256
>> SSL_DHE_DSS_WITH_AES_128_GCM_SHA256 *
>> SSL_DHE_DSS_WITH_AES_256_CBC_SHA *
>> SSL_DHE_DSS_WITH_AES_256_CBC_SHA256
>> SSL_DHE_DSS_WITH_AES_256_GCM_SHA384 SSL_DHE_DSS_WITH_DES_CBC_SHA
>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA *
>> SSL_DHE_RSA_WITH_AES_128_CBC_SHA *
>> SSL_DHE_RSA_WITH_AES_128_CBC_SHA256
>> SSL_DHE_RSA_WITH_AES_128_GCM_SHA256 *
>> SSL_DHE_RSA_WITH_AES_256_CBC_SHA *
>> SSL_DHE_RSA_WITH_AES_256_CBC_SHA256
>> SSL_DHE_RSA_WITH_AES_256_GCM_SHA384 SSL_DHE_RSA_WITH_DES_CBC_SHA
>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
>> SSL_DH_anon_WITH_AES_128_CBC_SHA
>> SSL_DH_anon_WITH_AES_128_CBC_SHA256
>> SSL_DH_anon_WITH_AES_128_GCM_SHA256
>> SSL_DH_anon_WITH_AES_256_CBC_SHA
>> SSL_DH_anon_WITH_AES_256_CBC_SHA256
>> SSL_DH_anon_WITH_AES_256_GCM_SHA384 SSL_DH_anon_WITH_DES_CBC_SHA
>> * SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA *
>> SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
>> SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 *
>> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA *
>> SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
>> SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
>> SSL_ECDHE_ECDSA_WITH_NULL_SHA *
>> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA *
>> SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256
>> SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256 *
>> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA *
>> SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>> SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>> SSL_ECDHE_RSA_WITH_NULL_SHA *
>> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA *
>> SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
>> SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 *
>> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA *
>> SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
>> SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
>> SSL_ECDH_ECDSA_WITH_NULL_SHA *
>> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA *
>> SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256
>> SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256 *
>> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA *
>> SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384
>> SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384 SSL_ECDH_RSA_WITH_NULL_SHA
>> SSL_ECDH_anon_WITH_AES_128_CBC_SHA
>> SSL_ECDH_anon_WITH_AES_256_CBC_SHA SSL_ECDH_anon_WITH_NULL_SHA
>> SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5
>> SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA SSL_KRB5_WITH_DES_CBC_MD5
>> SSL_KRB5_WITH_DES_CBC_SHA SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
>> SSL_RSA_FIPS_WITH_DES_CBC_SHA *
>> SSL_RSA_WITH_AES_128_CBC_SHA *
>> SSL_RSA_WITH_AES_128_CBC_SHA256 SSL_RSA_WITH_AES_128_GCM_SHA256 *
>> SSL_RSA_WITH_AES_256_CBC_SHA *
>> SSL_RSA_WITH_AES_256_CBC_SHA256 SSL_RSA_WITH_AES_256_GCM_SHA384
>> SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_NULL_MD5
>> SSL_RSA_WITH_NULL_SHA SSL_RSA_WITH_NULL_SHA256 *
>> TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Other than the fact that none of those start with TLS_ like all modern
cipher suites do, the above looks okay.
> FOR COMPARISON PURPOSES, what we get on our box is:
>> Default Cipher * SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA *
>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA *
>> SSL_DHE_DSS_WITH_AES_128_CBC_SHA *
>> SSL_DHE_DSS_WITH_AES_256_CBC_SHA *
>> SSL_DHE_DSS_WITH_DES_CBC_SHA *
>> SSL_DHE_DSS_WITH_RC4_128_SHA *
>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA *
>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA *
>> SSL_DHE_RSA_WITH_AES_128_CBC_SHA *
>> SSL_DHE_RSA_WITH_AES_256_CBC_SHA *
>> SSL_DHE_RSA_WITH_DES_CBC_SHA
>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
>> SSL_DH_anon_WITH_AES_128_CBC_SHA
>> SSL_DH_anon_WITH_AES_256_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA
>> SSL_DH_anon_WITH_RC4_128_MD5 SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5
>> SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA
>> SSL_KRB5_EXPORT_WITH_RC4_40_MD5 SSL_KRB5_EXPORT_WITH_RC4_40_SHA
>> SSL_KRB5_WITH_3DES_EDE_CBC_MD5 SSL_KRB5_WITH_3DES_EDE_CBC_SHA
>> SSL_KRB5_WITH_DES_CBC_MD5 SSL_KRB5_WITH_DES_CBC_SHA
>> SSL_KRB5_WITH_RC4_128_MD5 SSL_KRB5_WITH_RC4_128_SHA *
>> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA *
>> SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 *
>> SSL_RSA_EXPORT_WITH_RC4_40_MD5 *
>> SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA *
>> SSL_RSA_FIPS_WITH_DES_CBC_SHA *
>> SSL_RSA_WITH_3DES_EDE_CBC_SHA *
>> SSL_RSA_WITH_AES_128_CBC_SHA *
>> SSL_RSA_WITH_AES_256_CBC_SHA * SSL_RSA_WITH_DES_CBC_SHA
>> SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA *
>> SSL_RSA_WITH_RC4_128_MD5 * SSL_RSA_WITH_RC4_128_SHA
Almost all of the above cipher suites are useless.
Anything starting with SSL_*_DSS uses DSS authentication which is used
by exactly nobody. Same thing with KRB5 -- nobody is being KErberos
for TLS/SSL. Everyone uses either RSA or Elliptic Curve certificates.
Anything containing _anon_, EXPORT, FIPS, RC4, or MD5 should be
eliminated as providing weak or actually-useless security.
Anything containing NULL means that there is no encryption. Duh.
So we are left with this list:
> * SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA *
> SSL_DHE_RSA_WITH_AES_128_CBC_SHA *
> SSL_DHE_RSA_WITH_AES_256_CBC_SHA *
> SSL_DHE_RSA_WITH_DES_CBC_SHA *
> SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA *
> SSL_RSA_FIPS_WITH_DES_CBC_SHA *
> SSL_RSA_WITH_3DES_EDE_CBC_SHA * SSL_RSA_WITH_AES_128_CBC_SHA
> * SSL_RSA_WITH_AES_256_CBC_SHA *
> SSL_RSA_WITH_DES_CBC_SHA
All of those use SHA1 signatures which are no longer considered
secure. That means that basically none of these cipher suites are
acceptable for a modern security posture.
Here's what we have enabled at $work for production:
Supported Protocol Cipher
Accepted TLSv1.2 TLS_RSA_WITH_AES_256_CBC_SHA
Accepted TLSv1.2 TLS_RSA_WITH_AES_256_CBC_SHA256
Accepted TLSv1.2 TLS_RSA_WITH_AES_128_CBC_SHA256
Accepted TLSv1.2 TLS_RSA_WITH_AES_128_GCM_SHA256
Accepted TLSv1.2 TLS_RSA_WITH_AES_256_GCM_SHA384
Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Accepted TLSv1.2 TLS_RSA_WITH_AES_128_CBC_SHA
Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Accepted TLSv1.1 TLS_RSA_WITH_AES_256_CBC_SHA
Accepted TLSv1.1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Accepted TLSv1.1 TLS_RSA_WITH_AES_128_CBC_SHA
Accepted TLSv1.1 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Accepted TLSv1 TLS_RSA_WITH_AES_256_CBC_SHA
Accepted TLSv1 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Accepted TLSv1 TLS_RSA_WITH_AES_128_CBC_SHA
Accepted TLSv1 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
There are some cipher suites in there with _SHA at the end. Those are
in there for ancient browsers that simply can't do modern protocols,
and they are prioritized to the bottom of the list.
But everything else is pretty good IMO.
SSLLabs/Qualys still complains about every one of those except these two
:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
... calling the others "weak". I think that's because they consider
anytning that isn't using ECDHE+GCM to be "weak". Well, it's the best
we can do right now without going up to TLSv1.3.
Anyhow, if the client (or the server) is being run with any decent
kind of TLS configuration, then the second list of supported cipher
suites shown above will simply not be able to connect.
Assuming that you are using the built-in Java JSSE provider, then the
problem is that your Java version is just too old: you need a newer
version of Java to get better cipher suites.
You never said what version(s) of Java you are using. You also didn't
mention whether or not you had installed the "Unlimited Strength
Cipher" patch that you really should install for older versions of
Java. You have to re-install that patch every time you upgrade Java
(until you get to a recent version, where they removed that stupid
cipher strength limitation).
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzxxyoACgkQHPApP6U8
pFhn8Q/9F/9bU3pTFeooxzR6oSCCy2J99jJWPP2gjtItszlA5qdimz8O+/kq9WiX
mOEpmmzj1VvBODIcoaHW/p+nIFKuC2BuStWCrJo4VQ+7bL6ci4O5GkcifZLUKSuI
Z6zAO22ZcbazmFW4spLZzpUVOtrZpYrWDG9Qwij/F8MGnFlUq1P0sTVbXwZ254cQ
hRelsKxQMgd6yUrd4WLgJ81BZe4GPdLt1JjRTeF1j9wGUC++zNjNGsdJ/xYPh+ZN
WbtpvklJ3N9o4F6S1FYr7c0IcQqsdk0cY6MizQyip9OrZBEfyKJ7y7kSfgIWZ8VR
hCP6HHddOqR4mevaUXaCE4PFx8rzuDlroCrTwaiIkGoQkQfEkOWitZ+R8XQvUlt0
d4GKetbP0xokXCLv3akmjCMqtxOgwgv3W2go/GvEwv2pqZMPQ36GxMr9TcHoUSLc
TaZOVvUtc+OaKTijKQGvM4wOBEtK72xtpK7Z993aORx9ZwWCFTuGeaq3PYNX9Hps
H6tvpM/FoMb6mnmDnCvJ+qANKh/T7MCyWCd3KKISmuyH4UPJJlXiqg5ipIXojqYU
xzGV34kuM18F+zmNtBjhCrK9ULNFkxmsyrFXAcdB7f5ezTlwb7RKP/EI6vaeElAp
m48mnUps58dzMkd/Ejd6vWQ7gSr1P++4kBESVXAbybgEqRdlnLc=
=UCiO
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: Outbound SSL?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 5/31/19, 3:34 AM, bernd.schatz@daimler.com wrote:
> You can run a small java program on your jvm to print out the supported
> And default protocols.
> Yet, I didn’t find a better way.
>
> e.g. ==> https://confluence.atlassian.com/stashkb/list-ciphers-used-by-jvm-679609085.html
If I set the same JAVA_HOME as Tomcat was launched under, and compile
and run "Ciphers.java" from the above site, on the customer box, I get:
> Default Cipher
> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SH
> * SSL_DHE_DSS_WITH_AES_128_CBC_SHA
> * SSL_DHE_DSS_WITH_AES_128_CBC_SHA256
> SSL_DHE_DSS_WITH_AES_128_GCM_SHA256
> * SSL_DHE_DSS_WITH_AES_256_CBC_SHA
> * SSL_DHE_DSS_WITH_AES_256_CBC_SHA256
> SSL_DHE_DSS_WITH_AES_256_GCM_SHA384
> SSL_DHE_DSS_WITH_DES_CBC_SHA
> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
> * SSL_DHE_RSA_WITH_AES_128_CBC_SHA
> * SSL_DHE_RSA_WITH_AES_128_CBC_SHA256
> SSL_DHE_RSA_WITH_AES_128_GCM_SHA256
> * SSL_DHE_RSA_WITH_AES_256_CBC_SHA
> * SSL_DHE_RSA_WITH_AES_256_CBC_SHA256
> SSL_DHE_RSA_WITH_AES_256_GCM_SHA384
> SSL_DHE_RSA_WITH_DES_CBC_SHA
> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
> SSL_DH_anon_WITH_AES_128_CBC_SHA
> SSL_DH_anon_WITH_AES_128_CBC_SHA256
> SSL_DH_anon_WITH_AES_128_GCM_SHA256
> SSL_DH_anon_WITH_AES_256_CBC_SHA
> SSL_DH_anon_WITH_AES_256_CBC_SHA256
> SSL_DH_anon_WITH_AES_256_GCM_SHA384
> SSL_DH_anon_WITH_DES_CBC_SHA
> * SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
> * SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
> SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> * SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
> * SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> SSL_ECDHE_ECDSA_WITH_NULL_SHA
> * SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA
> * SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256
> SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> * SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA
> * SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> SSL_ECDHE_RSA_WITH_NULL_SHA
> * SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA
> * SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
> SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
> * SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA
> * SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
> SSL_ECDH_ECDSA_WITH_NULL_SHA
> * SSL_ECDH_RSA_WITH_AES_128_CBC_SHA
> * SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256
> SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256
> * SSL_ECDH_RSA_WITH_AES_256_CBC_SHA
> * SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384
> SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384
> SSL_ECDH_RSA_WITH_NULL_SHA
> SSL_ECDH_anon_WITH_AES_128_CBC_SHA
> SSL_ECDH_anon_WITH_AES_256_CBC_SHA
> SSL_ECDH_anon_WITH_NULL_SHA
> SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5
> SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA
> SSL_KRB5_WITH_DES_CBC_MD5
> SSL_KRB5_WITH_DES_CBC_SHA
> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
> SSL_RSA_FIPS_WITH_DES_CBC_SHA
> * SSL_RSA_WITH_AES_128_CBC_SHA
> * SSL_RSA_WITH_AES_128_CBC_SHA256
> SSL_RSA_WITH_AES_128_GCM_SHA256
> * SSL_RSA_WITH_AES_256_CBC_SHA
> * SSL_RSA_WITH_AES_256_CBC_SHA256
> SSL_RSA_WITH_AES_256_GCM_SHA384
> SSL_RSA_WITH_DES_CBC_SHA
> SSL_RSA_WITH_NULL_MD5
> SSL_RSA_WITH_NULL_SHA
> SSL_RSA_WITH_NULL_SHA256
> * TLS_EMPTY_RENEGOTIATION_INFO_SCSV
FOR COMPARISON PURPOSES, what we get on our box is:
> Default Cipher
> * SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
> * SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
> * SSL_DHE_DSS_WITH_AES_128_CBC_SHA
> * SSL_DHE_DSS_WITH_AES_256_CBC_SHA
> * SSL_DHE_DSS_WITH_DES_CBC_SHA
> * SSL_DHE_DSS_WITH_RC4_128_SHA
> * SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
> * SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> * SSL_DHE_RSA_WITH_AES_128_CBC_SHA
> * SSL_DHE_RSA_WITH_AES_256_CBC_SHA
> * SSL_DHE_RSA_WITH_DES_CBC_SHA
> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
> SSL_DH_anon_WITH_AES_128_CBC_SHA
> SSL_DH_anon_WITH_AES_256_CBC_SHA
> SSL_DH_anon_WITH_DES_CBC_SHA
> SSL_DH_anon_WITH_RC4_128_MD5
> SSL_KRB5_EXPORT_WITH_DES_CBC_40_MD5
> SSL_KRB5_EXPORT_WITH_DES_CBC_40_SHA
> SSL_KRB5_EXPORT_WITH_RC4_40_MD5
> SSL_KRB5_EXPORT_WITH_RC4_40_SHA
> SSL_KRB5_WITH_3DES_EDE_CBC_MD5
> SSL_KRB5_WITH_3DES_EDE_CBC_SHA
> SSL_KRB5_WITH_DES_CBC_MD5
> SSL_KRB5_WITH_DES_CBC_SHA
> SSL_KRB5_WITH_RC4_128_MD5
> SSL_KRB5_WITH_RC4_128_SHA
> * SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
> * SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
> * SSL_RSA_EXPORT_WITH_RC4_40_MD5
> * SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
> * SSL_RSA_FIPS_WITH_DES_CBC_SHA
> * SSL_RSA_WITH_3DES_EDE_CBC_SHA
> * SSL_RSA_WITH_AES_128_CBC_SHA
> * SSL_RSA_WITH_AES_256_CBC_SHA
> * SSL_RSA_WITH_DES_CBC_SHA
> SSL_RSA_WITH_NULL_MD5
> SSL_RSA_WITH_NULL_SHA
> * SSL_RSA_WITH_RC4_128_MD5
> * SSL_RSA_WITH_RC4_128_SHA
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: Outbound SSL?
Posted by be...@daimler.com.
Hi,
> -----Ursprüngliche Nachricht-----
> Von: Peter Kreuser <lo...@kreuser.name>
> Gesendet: Donnerstag, 30. Mai 2019 07:22
> Outbound SSL is usually handled by the underlying Java VM.
... and the problem occurs often if you use different jdks, like openjdk and ibmjdk.
You can run a small java program on your jvm to print out the supported
And default protocols.
Yet, I didn’t find a better way.
e.g. ==> https://confluence.atlassian.com/stashkb/list-ciphers-used-by-jvm-679609085.html
--
Mit freundlichen Grüßen / Kind Regards/ नमस्ते(Namaste)
Bernd Schatz
ITI/FT - CoC Enterprise Platforms Services (PAI)
HPC Z252
Gebäude VDZ Ost 1.OG
Plieninger Str. 150
70567 Stuttgart
Bernd Schatz
Büro: +49 711 17 41463
Mobile: +49 151 5862 6591
FAX: +49 711 17 7904 1252
mailto:bernd.schatz@daimler.com
https://matter.i.daimler.com
Re: Outbound SSL?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Peter and James,
On 5/30/19 01:22, Peter Kreuser wrote:
> James,
>
> Outbound SSL is usually handled by the underlying Java VM.
Yep. Tomcat doesn't have any code to make outgoing TLS connections.
>> Am 29.05.2019 um 20:57 schrieb James H. H. Lampert
>> <ja...@touchtonecorp.com>:
>>
>> We have a customer that is running our Tomcat-based webapp, and
>> it is apparently having trouble accessing a Google web service.
>>
>> The error message they're getting is:
>>
>>> Unable to find acceptable protocols. isFallback=false,
>>> modes=[ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM
_SHA256,
>>>
>>>
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
>>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
>>> TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA,
>>> TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA],
>>> tlsVersions=[TLS_1_2, TLS_1_1, TLS_1_0],
>>> supportsTlsExtensions=true),
>>> ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
,
>>>
>>>
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
>>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
>>> TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA,
>>> TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA],
>>> tlsVersions=[TLS_1_0], supportsTlsExtensions=true),
>>> ConnectionSpec()], supported protocols=[TLSv1]
>
> These are the ciphers and protocols requested. Are these two
> different services? If that is from server and client the ciphers
> are OK and protocols also overlap.
I don't think that's a list of the server, client supported protocols.
There is also an empty one at the end (TLSv1, no cipher suites).
> What strikes me though is the difference in TLS versions and
> supported protocols.
>
>> Is this something that could be caused by a Tomcat configuration
>> issue?
>
> Not really Tomcat. Java. Unless you set specific values on the
> connection. Or on the commandline.
>
> Could you please let us know the Java version and maybe the
> Connection settings? JAVA_OPTS?
It would also be a good idea to run good 'ole SSLLabs server test
against the service. If it's an internal service or one that can't be
scanned by Qualys, then you can try this tool which is roughly equivalen
t:
https://github.com/ChristopherSchultz/ssltest
Then check the capabilities of the client you are working with.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzwCo0ACgkQHPApP6U8
pFggbBAAtRZu9HL2h45cWeml1QA8vpMiq5aZTBvNAR+h6YuqRTsMwHPTC0SAJ3S+
COPsihXZe0xFSbYh8SjeZoxQSiZnP9Nu6r2EBSwlzOfNGaGBw7Bev9Ga2Mhbwg40
GJbwED9D4DIZ+5ALBRVJzrxgnl/zXeI5cbKVIgA3VtomFZtjGqxTmaRPX7O2dRoU
4GBQzBQIOHia1ppdWOYDtJ+1lqMMd8kuONTrUeEGAi/WjKvZ+IMhFzAtnKwh7MNO
HzLnNy7f5c33wNjnLArJF0t406AOF+qm6izfFKQBJrmpX2SRiCgH8UcpClTlHj9u
lnNevGM7YyY9f43BC64XZ2Wugpw0fUPvypyCmv7VkYvra17wOwl6qj2loj/eVB4b
tuYvECogZZvGLiNDdXyZO/PKIATVJiVmFP1W/k7dHDLBN4hkn88REZj9IugWO9iU
/NuPkLVcDC5S2YXMSk7MPlsxAAA6kpaXhf7dsDpIC7KrrrIyDt2gJsJNlU1o6v7L
uL4HHyI+nVPGPqLCAsd4MNjt3j9lvhDqCxdnSoFUnhGJypLh9RttzhpBoKA7zN2T
56i84UkDoVYs+HWExZ6F4H8kgqm1/ZhwHuhdQK/pyl/B1uNi6TIjN5z/TbdIp9ZR
SwrEKJ94od3dYG2w8lAbG18FDn154fh7/ZgvhIb3rWxs1YbSkgw=
=Xqgz
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Outbound SSL?
Posted by Peter Kreuser <lo...@kreuser.name>.
James,
Outbound SSL is usually handled by the underlying Java VM.
> Am 29.05.2019 um 20:57 schrieb James H. H. Lampert <ja...@touchtonecorp.com>:
>
> We have a customer that is running our Tomcat-based webapp, and it is
> apparently having trouble accessing a Google web service.
>
> The error message they're getting is:
>
>> Unable to find acceptable protocols. isFallback=false,
>> modes=[ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
>> TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_2, TLS_1_1,
>> TLS_1_0], supportsTlsExtensions=true),
>> ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
>> TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_0],
>> supportsTlsExtensions=true), ConnectionSpec()], supported
>> protocols=[TLSv1]
These are the ciphers and protocols requested. Are these two different services? If that is from server and client the ciphers are OK and protocols also overlap.
What strikes me though is the difference in TLS versions and supported protocols.
> Is this something that could be caused by a Tomcat configuration issue?
>
Not really Tomcat. Java. Unless you set specific values on the connection.
Or on the commandline.
Could you please let us know the Java version and maybe the Connection settings? JAVA_OPTS?
> --
> James H. H. Lampert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Outbound SSL?
Posted by Donald J <do...@gmx.us>.
Tomcat can be setup in 2 modes =
JSSE (Java) or APR (OpenSSL)
If Java, turn Java debug log on and -Djavax.net.debug=ssl
> Sent: Wednesday, May 29, 2019 at 1:57 PM
> From: "James H. H. Lampert" <ja...@touchtonecorp.com>
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> Subject: Outbound SSL?
>
> We have a customer that is running our Tomcat-based webapp, and it is
> apparently having trouble accessing a Google web service.
>
> The error message they're getting is:
>
> > Unable to find acceptable protocols. isFallback=false,
> > modes=[ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
> > TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
> > TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
> > TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_2, TLS_1_1,
> > TLS_1_0], supportsTlsExtensions=true),
> > ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
> > TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
> > TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
> > TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_0],
> > supportsTlsExtensions=true), ConnectionSpec()], supported
> > protocols=[TLSv1]
>
> Is this something that could be caused by a Tomcat configuration issue?
>
> --
> James H. H. Lampert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org