I am trying to troubleshoot an issue where connection is reset.
When i captured the TCP packets in wireshark, I see that Version is shown as SSL2.0 and then after Handshake Message Type, it shows TLS 1.2.
Actually my server only accepts TLS 1.2.
Please help me to understand if client initiated SSL v2.0 or TLS 1.2?
SSLv2 Record Layer: Client Hello
[Version: SSL 2.0 (0x0002)]
Length: 257
Handshake Message Type: Client Hello (1)
Version: TLS 1.2 (0x0303)
Cipher Spec Length: 216
Session ID Length: 0
Challenge Length: 32
Cipher Specs (72 specs)
Challenge
Related
I am working with IBM on trying to find the cause for some handshake errors we are receiving randomly when connecting with certain endpoints. This is happening on an IBM i system using the GSKit SSL APIs. The IBM is acting as the client.
The error we are receiving during the handshake is 415 (Bad Peer).
In the trace we show this response from the remote server:
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Illegal Parameter)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Illegal Parameter (47)
If we remove TLS 1.3 from the communications, the errors do not occur. If we add it back in, then the errors pop up communicating with Google and GoDaddy.
This only seemed to start happening recently after new SSL Certificates were installed at the endpoints. And, as I said, it's random. If I encounter the error, I can make the same request again without any error.
We weren't sure if it was because of how certain servers on their farms are configured differently from others, or if updates are propagating through them... but it's very odd.
We have isolated 2 ciphers that seem to be the issue. When removed, the errors seem to stop. They are:
*ECDHE_RSA_AES_256_GCM_SHA384 - this one seems to cause problems with Google
*AES_256_GCM_SHA384 - this one seems to cause problems with GoDaddy
The tech at IBM said that if we could somehow get in touch with someone at either place and recreate the issue, it would be a great help to figure out what is going on. Just hoping we can make that happen... if anyone knows anyone on the SSL support side of GoDaddy or Google that would be willing to work with myself and IBM to resolve this, it would be great.
Or, if anyone knows why it's happening, we're all ears. Right now the only option we have is turning off TLS v1.3 or removing these two ciphers. (and there may be more that affect other endpoints that we just don't know about yet).
TIA!
UPDATE
According to my tech, they are not following the RFC properly:
RFC 5246 (the last sentence):
The cipher suite list, passed from the client to the server in the
ClientHello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's
preference (favorite choice first). Each cipher suite defines a key
exchange algorithm, a bulk encryption algorithm (including secret key
length), a MAC algorithm, and a PRF. The server will select a cipher
suite or, if no acceptable choices are presented, return a handshake
failure alert and close the connection. If the list contains cipher
suites the server does not recognize, support, or wish to use, the
server MUST ignore those cipher suites, and process the remaining
ones as usual.
UPDATE 2
Here is a handshake that fails:
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 549
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 545
Version: TLS 1.2 (0x0303)
Random: 16ab36ccafcb18074cf7ce0296745cb87a4ef732402fbdc273790f082d4844d1
Session ID Length: 0
Cipher Suites Length: 18
Cipher Suites (9 suites)
Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 486
Extension: supported_versions (len=9)
Type: supported_versions (43)
Length: 9
Supported Versions length: 8
Supported Version: TLS 1.3 (0x0304)
Supported Version: TLS 1.2 (0x0303)
Supported Version: TLS 1.1 (0x0302)
Supported Version: TLS 1.0 (0x0301)
Extension: renegotiation_info (len=1)
Type: renegotiation_info (65281)
Length: 1
Renegotiation Info extension
Extension: ec_point_formats (len=2)
Type: ec_point_formats (11)
Length: 2
EC point formats Length: 1
Elliptic curves point formats (1)
EC point format: uncompressed (0)
Extension: signature_algorithms (len=22)
Type: signature_algorithms (13)
Length: 22
Signature Hash Algorithms Length: 20
Signature Hash Algorithms (10 algorithms)
Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
Extension: signature_algorithms_cert (len=20)
Type: signature_algorithms_cert (50)
Length: 20
Signature Hash Algorithms Length: 18
Signature Hash Algorithms (9 algorithms)
Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
Extension: supported_groups (len=12)
Type: supported_groups (10)
Length: 12
Supported Groups List Length: 10
Supported Groups (5 groups)
Supported Group: secp256r1 (0x0017)
Supported Group: secp384r1 (0x0018)
Supported Group: x25519 (0x001d)
Supported Group: secp521r1 (0x0019)
Supported Group: x448 (0x001e)
Extension: key_share (len=71)
Type: key_share (51)
Length: 71
Key Share extension
Client Key Share Length: 69
Key Share Entry: Group: secp256r1, Key Exchange length: 65
Group: secp256r1 (23)
Key Exchange Length: 65
Key Exchange: 047fbc26145d5067052eff17103285a7bdc30952cdbcea601491a6a08eca7d424484a9cb…
Extension: server_name (len=20)
Type: server_name (0)
Length: 20
Server Name Indication extension
Extension: extended_master_secret (len=0)
Type: extended_master_secret (23)
Length: 0
Extension: psk_key_exchange_modes (len=2)
Type: psk_key_exchange_modes (45)
Length: 2
PSK Key Exchange Modes Length: 1
PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1)
Extension: pre_shared_key (len=283)
Type: pre_shared_key (41)
Length: 283
Pre-Shared Key extension
Identities Length: 230
PSK Identity (length: 224)
Identity Length: 224
Identity: 000017719425bdded0ac21c8cd61318334f131527b4ef48f21ba8116523cf71681ae51fa…
Obfuscated Ticket Age: 68965835
PSK Binders length: 49
PSK Binders
The server then responds with
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Illegal Parameter)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Illegal Parameter (47)
IBM released an APAR with PTF for V7R3 and V7R4.
The APAR number is MA49492
Regards Michael
You can review encryption protocols that Google Front End supports when communicating with clients in this whitepaper.
In this whitepaper, you will find more detail on encryption in transit for Google Cloud, including Google Cloud Platform and Google Workspace.
From table 1, you can check that the cipher ECDHE_RSA_AES_256_GCM_SHA384, which is having trouble connecting with Google, is not listed as compatible.
I have found this documentation from IBM that lists the supported CipherSpecs (I’m not quite sure if this applies to your IBM product). Also, there’s a troubleshooting TLS guide from IBM.
It is important to understand this information is not a comprehensive source for troubleshooting information, but rather a guide to aid in common problem resolution.
UPDATE
It's unclear if IBM's GSKit SSL APIs are generating the error, or if it is allowing the user to send invalid packets and then reporting the error.
Unsupported TLS 1.2 ciphers would be ignored in the handshake as stated here, but I believe there is just 5 ciphers in TLS 1.3 (see RFC 8446 - Cipher Suites and OpenSSL - Ciphersuites), and ECDHE_RSA_AES_256_GCM_SHA384 is not in them, so it would be strange if IBM's product allowed an invalid cipher to be requested.
The 1.3 cipher specs work fine with Google servers, like:
echo | openssl s_client -tls1_3 -connect SERVER:443 -ciphersuites TLS_CHACHA20_POLY1305_SHA256 | grep "New, TLSv1.3, Cipher"
As mentioned above, ECDHE_RSA_AES_256_GCM_SHA384 is not in the list of TLS 1.2 cipher specifications.
UPDATE 2
From the whitepaper, I noted:
TLS in the GFE is implemented with BoringSSL. Table 1 shows the encryption protocols that GFE supports when communicating with clients.
Protocols
Authentication
Key exchange
Encryption
Hash Functions
TLS 1.34
RSA 2048
Curve25519
AES-128-GCM
SHA384
TLS 1.2
ECDSA P-256
P-256 (NIST secp256r1)
AES-256-GCM
SHA256
The supported values above don't match with the Cipher Suite list provided shown on the handshake packet capture, note the different SHA values:
TLS_AES_128_GCM_SHA256 (0x1301)
TLS_AES_256_GCM_SHA384 (0x1302)
The values used are AES128 with SHA256, and AES256 with SHA384 but BoringSSL supports AES128 with SHA384 for TLS 1.3 and AES256 with SHA256 for TLS 1.2.
Looking at some more IBM docs for z/OS, I'm seeing a discrepancy with 0x1302 which showcases AES256 with SHA256.
For TLS V1.3, the following is allowed in the evaluated configurations:
Ciphers:
1301 - TLS_AES_128_GCM_SHA256
1302 - TLS_AES_256_GCM_SHA256
How are the SSL certificates used? Is it possible to share the link for those docs?
Throubleshoot
I would recommend to try the following:
Find out what is causing the randomness. Maybe there could be some propagation delay on your IBM system or the SSL distribution management.
Try changing 1302 from TLS_AES_256_GCM_SHA384 to TLS_AES_256_GCM_SHA256 and verify if matching z/OS docs works
Try changing 1301 from TLS_AES_128_GCM_SHA256 to TLS_AES_128_GCM_SHA384 and verify if matching BoringSSL works
I have a very simple httpd-setup with SSLSessionCache directive set so that sessions are available also after a graceful restart (in shared memory).
I then connect to the server with openssl s_client and the -sess_out parameter so i have a sessionfile.
Next step is to gracefully restart apache.
Then after that, connect again with openssl s_client this time using the sessionfile with the -sess_in parameter.
This works perfectly with TLSv1.2.
But with TLSv1.3 mod_ssl somehow falls back to a full handshake. SSL_session_reused() returns false. If i do exactly the same test, but don't gracefully restart between the requests, it works and SSL_session_reused() returns true.
We can see this also if we trace ssl messages:
without a graceful restart (correct behavior)
CLT0-0 send:
Version: TLS 1.3 (772)
Length: 512
Content-Type: Handshake (22)
Message-Type: ClientHello (1)
CLT0-0 receive:
Version: TLS 1.3 (772)
Length: 128
Content-Type: Handshake (22)
Message-Type: ServerHello (2)
Server extension (43): supported versions
Server extension (51): key share
Server extension (41): pre shared key
CLT0-0 receive:
Version: TLS 1.3 (772)
Length: 6
Content-Type: Handshake (22)
Message-Type: EncryptedExtensions (8)
CLT0-0 receive:
Version: TLS 1.3 (772)
Length: 52
Content-Type: Handshake (22)
Message-Type: Finished (20)
CLT0-0 send:
Version: TLS 1.3 (772)
Length: 1
Content-Type: ChangeCipherSpec (20)
CLT0-0 send:
Version: TLS 1.3 (772)
Length: 52
Content-Type: Handshake (22)
Message-Type: Finished (20)
Here we see the client sends the "pre shared key" extension in his ClientHello. The Server responds then with his ServerHello which also contains the pre shared key extension and continues directly with the EncryptedExtensions and a Finish message. No Certificate and CertificateVerify message...
with a graceful restart (wrong behavior)
CLT0-0 send:
Version: TLS 1.3 (772)
Length: 512
Content-Type: Handshake (22)
Message-Type: ClientHello (1)
CLT0-0 receive:
Version: TLS 1.3 (772)
Length: 122
Content-Type: Handshake (22)
Message-Type: ServerHello (2)
Server extension (43): supported versions
Server extension (51): key share
CLT0-0 receive:
Version: TLS 1.3 (772)
Length: 6
Content-Type: Handshake (22)
Message-Type: EncryptedExtensions (8)
CLT0-0 receive:
Version: TLS 1.3 (772)
Length: 1738
Content-Type: Handshake (22)
Message-Type: Certificate (11)
CLT0-0 receive:
Version: TLS 1.3 (772)
Length: 264
Content-Type: Handshake (22)
Message-Type: CertificateVerify (15)
CLT0-0 receive:
Version: TLS 1.3 (772)
Length: 52
Content-Type: Handshake (22)
Message-Type: Finished (20)
CLT0-0 send:
Version: TLS 1.3 (772)
Length: 1
Content-Type: ChangeCipherSpec (20)
CLT0-0 send:
Version: TLS 1.3 (772)
Length: 52
Content-Type: Handshake (22)
Message-Type: Finished (20)
The client sends the same. But the Server responds then with his ServerHello which does NOT contain the "pre shared key" extension. Then a Certificate and CertificateVerify message as in the initial 1st handshake...
Also i see strange behavior related to the OpenSSL callbacks that mod_ssl registers:
mod_ssl registers all callbacks for adding, removing and getting a session (https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_sess_set_get_cb.html). The ssl-options, so that openssl doesn't use its internal cache are correctly set as well. But now with TLSv1.3 i never ever fall into the "get session"-callback, but always into the "new session" callback, even in the scenarion where i leave the graceful restart and SSL_session_reused returns true. I've had a look at the openssl code and indeed, in TLSv1.3 this callback never gets invoked. so i wonder if this might be a cause of incorrect behavior...
I think this is a very common use-case ("Allow to resume ssl-sessions after graceful restart") and should work with TLSv1.3 as it does with 1.2.
Any help is much appreciated!
UPDATE
This seems to be related to the SSLSessionTickets directive. With "SSLSessionTickets off" resumption works. If SessionTickets are enabled it doesn't work.
Is it possible if i only enabled TLS 1.2 in the IIS Application?
It keeps showing the below errors when i applied only TLS 1.2.
If there are TLS 1.0, 1.1, 1.2, the IIS application did work. but the properties shown are TLS 1.0 and not TLS 1.2
In the TLS handshake the server will choose the best protocol supported by the client. Given that the connection only results in TLS 1.0 if your client is connecting to a server which support TLS 1.0...TLS 1.2 it looks like your (unknown) client only supports TLS 1.0. In this case it is no surprise that it will fail if the server has only TLS 1.2 enabled.
I am trying to enable TLS 1.2 on Tomcat on Spring-boot 1.2.1. Android 5.0 is failing to connect to the default SSL settings, due to an SSL handshake failure. Android 4.4, iOS, Firefox, and Chrome all connect to the default version. I think this is because of a mismatch in the TLS protocols supported in Android 5.0 and the spring boot tomcat defaults (TLS v1?).
I imagine I want to change this application.properties setting:
server.ssl.protocol=TLS
but I have not located the other acceptable strings (or if there are any, even). There is no enumeration that I can find by searching on "protocol" in spring boot github.
I have tried "TLSv1.2", but this appears to have no effect.
The current SSL configuration in application.properties is:
server.ssl.key-store = chainedcertificates.p12
server.ssl.key-store-password = secret
server.ssl.key-store-type = PKCS12
How do you enable TLS 1.2 in spring boot?
If it matters, I am using Java 1.7. The documentation for this seems to indicate it should support TLS 1.2.
Tomcat 8 seems to have support present. I am not sure how to check exactly which version is running in spring boot.
You may experience an SSL handshake error due to the default ciphers that spring boot includes. It is recommended that you define a set of ciphers. We had a similar issue, and the way we fixed it was by using SSLScan on the caller and then scanning our system to see if there were any matches. This lead us to find out that there were no matches and helped us define a list of ciphers we should support.
Using SSLScan these are the default ciphers spring boot will use:
Preferred TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve P-256 DHE 256
Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256 DHE 1024 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA256 DHE 1024 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA DHE 1024 bits
To enable TLS 1.2 and to define the cipher list please do the following:
#enable/diable https
server.ssl.enabled=true
#ssl ciphers
server.ssl.ciphers=TLS_RSA_WITH_AES_128_CBC_SHA256, INCLUDE_ANY_OTHER_ONES_YOU_NEED_TO_SUPPORT
# SSL protocol to use.
server.ssl.protocol=TLS
# Enabled SSL protocols.
server.ssl.enabled-protocols=TLSv1.2
For a list of of ciphers you can use https://testssl.sh/openssl-rfc.mapping.html and https://msdn.microsoft.com/en-us/library/windows/desktop/mt813794(v=vs.85).aspx
TLS 1.2 is enabled by default in spring-boot 1.2.1. This can be verified by running the following from the command line
openssl s_client -connect serverAddress:port
which outputs
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA384
So my problem must be something separate.
I'm using Java 8, Netty 5 Alpha.
I added the certificates from Comodo to the keystore, and according to a test website suggested by my certificate provider they are installed correctly.
But if I try to connect using Firefox, Chrome, or curl, I get errors.
From curl -v I see that it gets the correct header, but then SSLv3, TLS alert, Server hello (2):. This seems to correspond with debug messages from Java:
SEND TLSv1.2 ALERT: warning, description = close_notify
WRITE: TLSv1.2 Alert, length = 32
fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack?
Firefox: SSL received a record that exceeded the maximum permissible length.
From openssl s_client -connect ...:
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-DES-CBC3-SHA
verify error:num=19:self signed certificate in certificate chain
SSL handshake has read 5982 bytes and written 531 bytes
I've read elsewhere about NullPointerExceptions somewhere causing internal Java security stuff to fail. But there's no clear solutions.