Console Producer Error after Implementing with TLS/SSL - ssl

I wanted to add TLS/SSL to my kafka setup. To start with, I went through the kafka SSL documenation on main website. I have done the following:
1) Imported the signed certificates to keystore
2) Imported the root CA
3) Verified that the keystore and trust store password are correct by using keytool.
4) Started zookeeper and kafka.
5) Confirmed the following from server.log file:
Registered broker 0 at path /brokers/ids/0 with addresses:
EndPoint(localhost,9092,ListenerName(PLAINTEXT),PLAINTEXT),EndPoint(localhost,9093,ListenerName(SSL),SSL) (kafka.utils.ZkUtils)
my server.properties file have both listeners and advertised.listeners set to the following:
PLAINTEXT://localhost:9092,SSL://localhost:9093
I also have automatic topic creation enabled. When I do:
kafka-console-producer.bat --broker-list localhost:9093 --topic test_ssl --producer.config ....\config\producer.properties
I am getting the following error:
[2017-08-04 16:28:15,265] WARN Error while fetching metadata with correlation id 0 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:15,372] WARN Error while fetching metadata with correlation id 1 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:15,474] WARN Error while fetching metadata with correlation id 2 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:20,302] WARN Error while fetching metadata with correlation id 3 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:20,406] WARN Error while fetching metadata with correlation id 4 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:20,512] WARN Error while fetching metadata with correlation id 5 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
I tried to print out the SSL comms data using openssl
openssl s_client -connect localhost:9093 -debug -tls1 // default kafka broker configs have tlsv1 included
I get the following:
Certificate chain
0 s:/C=GB/ST=Unknown/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=M. Manna
i:/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
1 s:/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
i:/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDfDCCAmQCCQDJKjhOy8KBWjANBgkqhkiG9w0BAQsFADCBlTELMAkGA1UEBhMC
R0IxEzARBgNVBAgMClNvbWUtU3RhdGUxDzANBgNVBAcMBkxvbmRvbjEMMAoGA1UE
CgwDU0FQMRcwFQYDVQQLDA5TQVAgRmllbGRnbGFzczESMBAGA1UEAwwJbG9jYWxo
b3N0MSUwIwYJKoZIhvcNAQkBFhZtb2hhbW1lZC5tYW5uYUBzYXAuY29tMB4XDTE3
MDgwNzA5MDU0MFoXDTE5MDgwNzA5MDU0MFowajELMAkGA1UEBhMCR0IxEDAOBgNV
BAgTB1Vua25vd24xDzANBgNVBAcTBkxvbmRvbjEMMAoGA1UEChMDU0FQMRcwFQYD
VQQLEw5TQVAgRmllbGRnbGFzczERMA8GA1UEAxMITS4gTWFubmEwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+sGslb3XocPzigNOmwi9DRE7U6Gos+k1
ADWCS1UGDXPRuS9JocCc2oZ2GJxwipDpF+xRGmeAXIo77S/4GXFjs+DG1R8kojXn
bth3QRTsI6XAMuWOX3AHd4ob0/WSWsPLkGRggCyqU7qwvhuD+MzXB2Q0isRgab/c
lQl6Bj6ETaYTSY8Q2YjCR0ggL4qpYwO62fUexTB5aJx8JMpEbi0V3NZX/2xpic2m
27NW95j7oxi55Q36sYQNpFxfp9pIft6n3+RYTWIQ0bDV5O4W0TGAGPMDkH+t1K9x
ZZEoLik0aOfHw9sp96LkU5oZGGeWEGt6CmWHZQDiBSAyuTe6IjTpAgMBAAEwDQYJ
KoZIhvcNAQELBQADggEBAC4m+Lpl6pH45VGGvpaolL6PnL5TGcd7FL39C6DxL7Cl
MftcLuG6Egka+eJr/tg+6pdOFfpQjrkeDpeiRIABcLu/VrK99Te7c946QWc8QupC
G/VSQRIHOW6ReBsFf2/wrwT8MWDq2I2GAZSuZ9eTGWggQEwyem6y7C4ujtrcpixq
XwkeE2AU/91O2LlRrP/gW3hwEgD3VruMFhnm/3tTc7ZeLhJPSIE8EMhCk3+j2tgI
ta9J6NZClMxRLgBe1cOH2ru8eGsJtDnT2J+h0m/Ra3t9pD70Amoo84ytE3Iyui8i
kL2gg278c7PF5qosjPkp5sjjvWFypk8iYHTgTidbRCg=
-----END CERTIFICATE-----
subject=/C=GB/ST=Unknown/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=M. Manna
issuer=/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
---
Acceptable client certificate CA names
/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5048 bytes and written 285 bytes
Verification error: self signed certificate in certificate chain
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 59884152B1D0B4716F30AC8E43BAC10EBBE92E6BD771AAAD31046035564F2B30
Session-ID-ctx:
Master-Key: 124F0A4796CCE67A696105F4F88798CFC31E76885DEDF3EB1F702EA565543462AB1CCC9B4E6D726BD7489C17ED77C744
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1502101842
Timeout : 7200 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
Extended master secret: no
---
Even though the above has error in "Self-signed certificate verification" I think this is common if the CA cert is self signed. Possibly, it is working since SSL Handshake has written/read data.
I can confirm from kafka-topics command (also, server.log) that the topic "test_ssl" creation was successful. I hope it's not because of this underscore "_".
If there was a handshake issue, it would have been caught in the logs (I think, unless the logger is turned off), but it looks like my SSL config has been accepted correctly. Just wanted to know if I have missed something which I cannot quite spot here.
Note - I am not using any SSL/TLS with my Zookeeper. Also, because I am starting the TLS tests locally, I am using a common trust store for now (cacerts in jre/lib/security).
-- my client SSL config
advertised.listeners=SSL://localhost:9093
listeners=SSL://localhost:9093
security.protocol=SSL
ssl.truststore.location=$java_path/jre/lib/security/cacerts
ssl.truststore.password=changeit
ssl.keystore.location=/kafka_2.10-0.10.2.1/config/kafka_client.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
-- my server SSL related properties
security.inter.broker.protocol=SSL
ssl.keystore.location=/kafka_2.10-0.10.2.1/config/kafka_server.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
ssl.truststore.location=$java_path/jre/lib/security/cacerts
ssl.truststore.password=changeit
ssl.endpoint.identification.algorithm=HTTPS
ssl.secure.random.implementation=SHA1PRNG
ssl.client.auth=required
fraction of my server logs after startup (with SSL debug enabled):
Using SSLEngineImpl.
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Using SSLEngineImpl.
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
kafka-network-thread-0-ListenerName(SSL)-SSL-0, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
kafka-network-thread-0-ListenerName(SSL)-SSL-0, called closeOutbound()
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
kafka-network-thread-0-ListenerName(SSL)-SSL-0, closeOutboundInternal()
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
[Raw write]: length = 7
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
0000Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
: 15Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
03Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
03 00Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
02 02Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
%% No cached client session
50*** ClientHello, TLSv1.2
I am not sure what configuration I am missing to get this working. I don't think there is anything wrong in my certificate import order since I have confirmed my methods by matching with instructions here.
Regards,

It was just one config - but I wish there was slightly longer explanation on the documentation for this - but still my bad.
documentation
ssl.endpoint.identification.algorithm
I set it to HTTPS - this means that my client will verify my Fully Qualified Domain Name FQDN against one of the following:
1) Common Name (CN)
2) Subject Alternative Name (SAN)
when I created my ceritificate, I was being polite and added my first and last name thinking "That's my first and last names". Since my original certificates didn't have either of the following:
1) localhost as CN
2) localhost as a DNS
The clients couldn't verify the broker's FQDN against the presented certificate's SAN/CN values. I believe this was the reason since I got it to work after issuing a new self-signed SAN certificate (and importing them into client trust store).

Related

SSL handshake failure after ClientHello in Ubuntu 20.04 and Debian 10 (works in Ubuntu 18.04 and Debian 9)

I have been trying to use Oracle Cloud Email Delivery Service. Once configured it provides SMTP credentials which you can use to send email from approved senders.
I am stuck with few interesting scenarios.
It works in Ubuntu 18.04 but fails in docker container(running Debian 10) running on same machine.
I was testing handshake with openssl s_client
echo QUIT | openssl s_client -starttls smtp -crlf -connect smtp.email.ap-mumbai-1.oci.oraclecloud.com:587
This command works fine in Ubuntu 18.04 but fails with handshake failure in docker container running Debian 10
Output from Docker Container
root#06369bfe7c16:/var/www/html# echo QUIT | openssl s_client -starttls smtp -crlf -connect smtp.email.ap-mumbai-1.oci.oraclecloud.com:587
CONNECTED(00000003)
140491098481792:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 199 bytes and written 367 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
root#06369bfe7c16:/var/www/html#
I tried to check openssl versions in both.
18.04 is having openssl version OpenSSL 1.1.1 11 Sep 2018
Docker container is having openssl version OpenSSL 1.1.1d 10 Sep 2019
Can it be something related to versions?
I tried to debug more via Wireshark to see how ClientHello messages are sent -
ClientHello from Ubuntu 18.04 ( which returns in success)
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 339
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 335
Version: TLS 1.2 (0x0303)
Random: e595f987b8d92387f7114d9dee4df7bc3f00b5b082ba0ec8…
Session ID Length: 32
Session ID: 74c873d7894514a047e0763cd14c01fb19a4f238cb9085f2…
Cipher Suites Length: 62
Cipher Suites (31 suites)
Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
Cipher Suite: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xccaa)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 200
Extension: server_name (len=47)
Type: server_name (0)
Length: 47
Server Name Indication extension
Extension: ec_point_formats (len=4)
Type: ec_point_formats (11)
Length: 4
EC point formats Length: 3
Elliptic curves point formats (3)
EC point format: uncompressed (0)
EC point format: ansiX962_compressed_prime (1)
EC point format: ansiX962_compressed_char2 (2)
Extension: supported_groups (len=12)
Type: supported_groups (10)
Length: 12
Supported Groups List Length: 10
Supported Groups (5 groups)
Extension: session_ticket (len=0)
Type: session_ticket (35)
Length: 0
Data (0 bytes)
Extension: encrypt_then_mac (len=0)
Type: encrypt_then_mac (22)
Length: 0
Extension: extended_master_secret (len=0)
Type: extended_master_secret (23)
Length: 0
Extension: signature_algorithms (len=48)
Type: signature_algorithms (13)
Length: 48
Signature Hash Algorithms Length: 46
Signature Hash Algorithms (23 algorithms)
Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
Signature Algorithm: ed25519 (0x0807)
Signature Algorithm: ed448 (0x0808)
Signature Algorithm: rsa_pss_pss_sha256 (0x0809)
Signature Algorithm: rsa_pss_pss_sha384 (0x080a)
Signature Algorithm: rsa_pss_pss_sha512 (0x080b)
Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature Algorithm: SHA224 ECDSA (0x0303)
Signature Algorithm: ecdsa_sha1 (0x0203)
Signature Algorithm: SHA224 RSA (0x0301)
Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
Signature Algorithm: SHA224 DSA (0x0302)
Signature Algorithm: SHA1 DSA (0x0202)
Signature Algorithm: SHA256 DSA (0x0402)
Signature Algorithm: SHA384 DSA (0x0502)
Signature Algorithm: SHA512 DSA (0x0602)
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: 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: key_share (len=38)
Type: key_share (51)
Length: 38
Key Share extension
ClientHello message from Docker Container (which results in handshake failure SSL alert number 40)
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 234
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 230
Version: TLS 1.2 (0x0303)
Random: 20375888f578157f3989533cc8d2c6e5b1db2795dba56ff2…
Session ID Length: 0
Cipher Suites Length: 56
Cipher Suites (28 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
Cipher Suite: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xccaa)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 133
Extension: server_name (len=47)
Type: server_name (0)
Length: 47
Server Name Indication extension
Extension: ec_point_formats (len=4)
Type: ec_point_formats (11)
Length: 4
EC point formats Length: 3
Elliptic curves point formats (3)
EC point format: uncompressed (0)
EC point format: ansiX962_compressed_prime (1)
EC point format: ansiX962_compressed_char2 (2)
Extension: supported_groups (len=12)
Type: supported_groups (10)
Length: 12
Supported Groups List Length: 10
Supported Groups (5 groups)
Extension: session_ticket (len=0)
Type: session_ticket (35)
Length: 0
Data (0 bytes)
Extension: encrypt_then_mac (len=0)
Type: encrypt_then_mac (22)
Length: 0
Extension: extended_master_secret (len=0)
Type: extended_master_secret (23)
Length: 0
Extension: signature_algorithms (len=42)
Type: signature_algorithms (13)
Length: 42
Signature Hash Algorithms Length: 40
Signature Hash Algorithms (20 algorithms)
Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
Signature Algorithm: ed25519 (0x0807)
Signature Algorithm: ed448 (0x0808)
Signature Algorithm: rsa_pss_pss_sha256 (0x0809)
Signature Algorithm: rsa_pss_pss_sha384 (0x080a)
Signature Algorithm: rsa_pss_pss_sha512 (0x080b)
Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature Algorithm: SHA224 ECDSA (0x0303)
Signature Algorithm: SHA224 RSA (0x0301)
Signature Algorithm: SHA224 DSA (0x0302)
Signature Algorithm: SHA256 DSA (0x0402)
Signature Algorithm: SHA384 DSA (0x0502)
Signature Algorithm: SHA512 DSA (0x0602)
This is ServerHello message from Ubuntu 18.04
TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 4345
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 81
Version: TLS 1.2 (0x0303)
Random: 5ecea16938ffb32685dee0d46241ab4533820a178f3766e6…
Session ID Length: 32
Session ID: 5ecea169972b4c49269218eb6d64fbdeedb76539703d48e5…
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Compression Method: null (0)
Extensions Length: 9
Extension: renegotiation_info (len=1)
Extension: extended_master_secret (len=0)
Handshake Protocol: Certificate
Handshake Protocol: Server Key Exchange
Handshake Type: Server Key Exchange (12)
Length: 329
EC Diffie-Hellman Server Params
Curve Type: named_curve (0x03)
Named Curve: secp256r1 (0x0017)
Pubkey Length: 65
Pubkey: 048f81fb0fcd06c8f1d50620af144965cae3dd3804df3454…
Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
Signature Length: 256
Signature: 76bf06d1a887440d01be65938a92094510ae52e031463d58…
Handshake Protocol: Server Hello Done
Server seems to use CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 which happens to be present in Docker Container ClientHello as well.
So What I am missing in this case. I am new to SSL debugging.
If Ciphersuites are matching what could be different so that servers returns handshake failure?
Please provide me directions what can I investigate next.
I have uploaded wireshark captures at https://gofile.io/d/ERJXNe
There is one capture from docker container running Debian-9,(openssl 1.1.0l) which results in handshake success.
Update:
I tried to use openssl s_client in latest Ubuntu 20.04 VM, it fails with handshake failure.
This is one of the issues described in this github comment by David Benjamin:
https://github.com/openssl/openssl/issues/11438#issuecomment-606927855
Basically it is a buggy server. Even though it is perfectly capable of signing signatures using a SHA-2 hash, it will fail if SHA-1 is not in the list of supported signature algorithm hashes supported by the client.
To test this I first tried this:
$ openssl s_client -starttls smtp -crlf -connect smtp.email.ap-mumbai-1.oci.oraclecloud.com:587 -no_tls1_3 -trace -sigalgs "RSA+SHA256"
I received the handshake failure alert that you got. I then retried the same command, but added an additional SHA1 based sigalg:
$ openssl s_client -starttls smtp -crlf -connect smtp.email.ap-mumbai-1.oci.oraclecloud.com:587 -no_tls1_3 -trace -sigalgs "RSA+SHA256:RSA+SHA1"
This second connection succeeds.
You will notice in your traces that your docker contained based version of OpenSSL is not sending any SHA1 based signature algorithms. To work around the problem you need to additionally configure these.
FYI, the server was updated to use a SHA-2 root certificate to resolve this issue. But here's an analysis of the issue and underlying standards:
The actual issue is that the certificate chain for this server has a SHA-1 root certificate, and the client has stated that it doesn't support validation of SHA-1 certificates in the certificate chain. Reading the TLS 1.2 specification (https://www.rfc-editor.org/rfc/rfc5246#section-7.4.1.4.1), the server's behavior is correct under a reasonable interpretation:
The client uses the "signature_algorithms" extension to indicate to
the server which signature/hash algorithm pairs may be used in
digital signatures.
The TLS 1.3 specification has more to say about this situation (https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2.2):
All certificates provided by the server MUST be signed by a signature
algorithm advertised by the client if it is able to provide such a
chain (see Section 4.2.3). Certificates that are self-signed or
certificates that are expected to be trust anchors are not validated
as part of the chain and therefore MAY be signed with any algorithm.
If the server cannot produce a certificate chain that is signed only
via the indicated supported algorithms, then it SHOULD continue the
handshake by sending the client a certificate chain of its choice
that may include algorithms that are not known to be supported by the
client. This fallback chain SHOULD NOT use the deprecated SHA-1 hash
algorithm in general, but MAY do so if the client's advertisement
permits it, and MUST NOT do so otherwise.
With this text, the interpretation depends on the word "use". If it means "use in certificate chain", the server's behavior is correct and the TLS 1.3 spec is self-contradictory. If it means "use to validate certificate chain", then the server's behavior is wrong (under TLS 1.3 rules) and the TLS 1.3 spec is consistent. I'm going to assume the latter is the better interpretation.
So the server follows the TLS 1.2 rules but has not been updated to follow TLS 1.3 rules. As one of the engineers working on the server in question, I consider this a bug since TLS 1.3 supersedes TLS 1.2 but as it's a behavior change between two versions of the standard, it's not a particularly serious bug.

Enovy error - The following ciphers were rejected when tried individually: TLS_AES_128_GCM_SHA256

In istio 1.5.1, when I tried to add a particular cipher suit to the gateway's tls section using this syntax:
minProtocolVersion: TLSV1_3
mode: SIMPLE
cipherSuites: [TLS_AES_128_GCM_SHA256]
I got the following error in the istio-ingress pod's logs:
[Envoy (Epoch 0)] [2020-06-08 15:15:44.033][22][warning][config] [external/envoy/source/common/config/grpc_subscription_impl.cc:87]
gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) 0.0.0.0_443: Failed to initialize cipher suites TLS_AES_128_GCM_SHA256.
The following ciphers were rejected when tried individually: TLS_AES_128_GCM_SHA256
If I remove the cipherSuites line from the tls section, there is no errors, and the same cipher suit appears in the list of valid cipher suits.
Any advise? Thanks
As far as I checked in envoy documentation And BoringSSL documentation
TLS 1.3 ciphers do not participate in this mechanism and instead have a
built-in preference order. Functions to set cipher lists do not affect TLS
1.3, and functions to query the cipher list do not include TLS 1.3
ciphers.
cipher_suites
If specified, the TLS listener will only support the specified cipher list when negotiating TLS 1.0-1.2 (this setting has no effect when negotiating TLS 1.3). If not specified, the default list will be used.
In non-FIPS builds, the default cipher list is:
[ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305]
[ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305]
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
AES128-GCM-SHA256
AES128-SHA
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES256-SHA
AES256-GCM-SHA384
AES256-SHA
In builds using BoringSSL FIPS, the default cipher list is:
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
AES128-GCM-SHA256
AES128-SHA
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES256-SHA
AES256-GCM-SHA384
AES256-SHA
Additionally take a look at this github issue.

Go https client issue - remote error: tls: handshake failure

I am hitting this error 'remote error: tls: handshake failure':
~/go/bin/aci-tls 10.0.0.201 user pass
2016/12/20 18:12:04 post error: Post https://10.0.0.201/api/aaaLogin.json: remote error: tls: handshake failure
Code is basic HTTPS client: https://play.golang.org/p/cqPT0oR__q
OpenSSL is happy with this https server:
$ openssl s_client -connect 10.0.0.201:443
(snip)
SSL handshake has read 1383 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
(snip)
Tested on:
$ go version
go version go1.7.4 linux/386
C:\>go version
go version go1.7.4 windows/amd64
gotlsscan says:
lab#ubu:~$ go version
go version go1.8beta2 linux/386
lab#ubu:~$ ~/go/bin/gotlsscan -host 10.0.0.201 | grep -v NOT
Testing SSL30 (DISABLED)
Testing TLS1.0
Testing TLS1.1
Testing TLS1.2
lab#ubu:~$
lab#ubu:~$ ~/go/bin/gotlsscan -insecure -host 10.0.0.201 | grep -v NOT
Testing SSL30 (DISABLED)
Testing TLS1.0
Testing TLS1.1
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA [OK]
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA [OK]
Testing TLS1.2
How can I further troubleshoot this issue?
The server for some reason doesn't accept the TLS1.2 handshake, nor does it properly fall back to TLS1.1. You can force the client to use only TLS1.1 and the compatible cipher suites with
cfg := &tls.Config{
CipherSuites: []uint16{
tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
tls.TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
},
PreferServerCipherSuites: true,
InsecureSkipVerify: true,
MinVersion: tls.VersionTLS11,
MaxVersion: tls.VersionTLS11,
}

Why can I connect TLSv1 if OpenSSL only support SSLv2 and SSLv3?

I am using openssl-0.9.8e-7.el5.
openssl ciphers -v shows support only for SSLv2 and SSLv3 cipher types.
However, if I test this connection using tls 1.0 it connects successfully:
openssl s_client -connect hostname:15000 -tls1
CONNECTED(00000003)
SSL handshake has read 2136 bytes and written 413 bytes
...
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
How does it show Protocol is TLSv1 yet OpenSSL itself only supports SSL 3 and 2?
SSLv3 cipher suites are usable with protocol versions SSLv3 and up, i.e also TLS1.x. The version of the cipher suite only tells you the minimal protocol version.
This also means that if you disable SSLv3 and SSLv2 ciphers suites you effectively disable not only SSLv3 but also TLS 1.0 and TLS 1.1, since new cipher suites were only introduced with TLS 1.2.

Why is nginx selecting the SSL versions & ciphers it is selecting?

I have an nginx server with the following in it's configuration:
ssl_protocols SSLv3;
I'm not really able to change this right now (though it probably will soon). ssl_ciphers is not present anywhere in the config.
When Chrome connects to this server, everything works fine. However, inspecting the SSL handshake with Wireshark reveals
Secure Sockets Layer
TLSv1 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 178
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 174
Version: TLS 1.2 (0x0303)
Random
Session ID Length: 0
Cipher Suites Length: 74
Cipher Suites (37 suites)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
Cipher Suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002)
Cipher Suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
Cipher Suite: TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c)
Cipher Suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 59
Extension: server_name
Extension: elliptic_curves
Extension: ec_point_formats
Extension: signature_algorithms
<followed by>
Secure Sockets Layer
TLSv1 Record Layer: Handshake Protocol: Multiple Handshake Messages
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 4073
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 76
Version: TLS 1.0 (0x0301)
Random
Session ID Length: 32
Session ID: 69e68f6d99482e742e576877c9debdd38aa1bed1a33f5067...
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Compression Method: null (0)
Extensions Length: 4
Extension: server_name
Handshake Protocol: Certificate
Handshake Type: Certificate (11)
Length: 3985
Certificates Length: 3982
Certificates (3982 bytes)
Handshake Protocol: Server Hello Done
Handshake Type: Server Hello Done (14)
Length: 0
To me, it appears that TLSv1.0 got negoiated there. How is that even possible?
When attempting to connect with Firefox, however, more insanity ensues:
Secure Sockets Layer
SSLv3 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 187
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 183
Version: TLS 1.2 (0x0303)
Random
Session ID Length: 0
Cipher Suites Length: 46
Cipher Suites (23 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 96
Extension: server_name
Extension: renegotiation_info
Extension: elliptic_curves
Extension: ec_point_formats
Extension: SessionTicket TLS
Extension: next_protocol_negotiation
Extension: status_request
Extension: signature_algorithms
<followed by>
Secure Sockets Layer
SSLv3 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: SSL 3.0 (0x0300)
Length: 106
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 102
Version: SSL 3.0 (0x0300)
Random
Session ID Length: 32
Session ID: c985d4892896c5d553215fe3e60a2d616994ede1ed6ad715...
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Compression Method: null (0)
Extensions Length: 30
Extension: server_name
Extension: renegotiation_info
Extension: ec_point_formats
Extension: next_protocol_negotiation
<followed by>
Secure Sockets Layer
SSLv3 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)
And Firefox then displays a ssl_error_cipher_disallowed_for_version. Given that nginx seems to have selected SSLv3.0 but with a TLS cipher, I agree with Firefox's error, but why did nginx do this?
More information about this bug: https://code.google.com/p/chromium/issues/detail?id=425979