postman-app-support
postman-app-support copied to clipboard
postmanlabs
Request execution error: SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE [v7.25.1+]
Describe the bug When making an API request, I receive the error below:
Error: write EPROTO 2771201016:error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:../../third_party/boringssl/src/ssl/tls_record.cc:587:SSL alert number 40 2771201016:error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO:../../third_party/boringssl/src/ssl/handshake.cc:588:
To Reproduce Steps to reproduce the behavior:
- Update to 7.26 from 7.25.3
- Perform an API call
Expected behavior Using build 7.25.3, these API calls that are now failing with 7.26.0 work just fine.
I read through the release notes for 7.26.0, and I didn't really see anything that would create an SSL issue. Were there any build dependencies that got updated from one version to the next?
These API calls are going over HTTPs, but using Basic Auth and no certs. I have the SSL cert verification turned off.
App information (please complete the following information):
- Native App
- Postman Version 7.26.0
- OS: Windows 64bit
@thetreythomas is the requesting server requires SSLv3 protocol?
To verify this, could you send this request using curl with the -v flag and share the verbose info (remove the sensitive details)?
e.g, curl -v https://postman-echo.com/get
I am making these request to ESXi 6.5 U3, 6.7, and 7.0 machines, and the app serving the APIs is TLS 1.2. Checking on the SSLv3 information.
* Trying 100.80.152.109...
* TCP_NODELAY set
* Connected to 100.80.152.109 (100.80.152.109) port 8086 (#0)
* schannel: SSL/TLS connection with 100.80.152.109 port 8086 (step 1/3)
* schannel: checking server certificate revocation
* schannel: using IP address, SNI is not supported by OS.
* schannel: sending initial handshake data: sending 156 bytes...
* schannel: sent initial handshake data: sent 156 bytes
* schannel: SSL/TLS connection with 100.80.152.109 port 8086 (step 2/3)
* schannel: encrypted data got 1758
* schannel: encrypted data buffer: offset 1758 length 4096
* schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted.
* Closing connection 0
* schannel: shutting down SSL/TLS connection with 100.80.152.109 port 8086
* schannel: clear security context handle
curl: (77) schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted.
@thetreythomas With Postman v7.25.3, we upgraded our underlying SSL library which might be the cause of this.
But, I am confused that the request was working fine for you in v7.25.3 but failing in v7.26.0.
Is it possible for you to share the endpoint which we can use to reproduce this issue? You can also share it with us at [email protected].
@codenirvana My thoughts exactly, why does it work in 7.25.3, but not 7.26.0.
Unfortunately, these are all internal lab machines that can access the internet, but are protected by a firewall.
I VPN in, connect to a jump box that is running Postman, that is on the same network as all my test servers. And there are no apps like ngrok that work on ESXi.
The user who reported this to me, he wasn't sure what version he was running before updating to 7.26.
I had him reinstall 7.25,0 and it works. I then had him install 7.25.3, and it gives the same error as 7.26.
@thetreythomas Looks like a part of the curl log is missing in https://github.com/postmanlabs/postman-app-support/issues/8612#issuecomment-641336498.
To help us debug this issue better could you share the verbose log (remove the sensitive details) for the following commands:
curl -v -k https://postman-echo.comopenssl s_client -state -connect postman-echo.com:443 | openssl x509 -text
Replace postman-echo.com with your API endpoint.
This is from the curl -v -k
λ curl -v -k https://100.80.152.110:8086/api/PT/v1/agent/info
* Trying 100.80.152.110...
* TCP_NODELAY set
* Connected to 100.80.152.110 (100.80.152.110) port 8086 (#0)
* schannel: SSL/TLS connection with 100.80.152.110 port 8086 (step 1/3)
* schannel: disabled server certificate revocation checks
* schannel: verifyhost setting prevents Schannel from comparing the supplied target name with the subject names in server certificates.
* schannel: using IP address, SNI is not supported by OS.
* schannel: sending initial handshake data: sending 147 bytes...
* schannel: sent initial handshake data: sent 147 bytes
* schannel: SSL/TLS connection with 100.80.152.110 port 8086 (step 2/3)
* schannel: encrypted data got 1758
* schannel: encrypted data buffer: offset 1758 length 4096
* schannel: sending next handshake data: sending 318 bytes...
* schannel: SSL/TLS connection with 100.80.152.110 port 8086 (step 2/3)
* schannel: encrypted data got 226
* schannel: encrypted data buffer: offset 226 length 4096
* schannel: SSL/TLS handshake complete
* schannel: SSL/TLS connection with 100.80.152.110 port 8086 (step 3/3)
* schannel: stored credential handle in session cache
* Server auth using Basic with user 'root'
> GET /api/PT/v1/agent/info HTTP/1.1
> Host: 100.80.152.110:8086
> Authorization: Basic xxxxxxxxxxxxxxxxxxxx
> User-Agent: curl/7.55.1
> Accept: */*
>
* schannel: client wants to read 102400 bytes
* schannel: encdata_buffer resized 103424
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: encrypted data got 1509
* schannel: encrypted data buffer: offset 1509 length 103424
* schannel: decrypted data length: 17
* schannel: decrypted data added: 17
* schannel: decrypted data cached: offset 17 length 102400
* schannel: encrypted data length: 1463
* schannel: encrypted data cached: offset 1463 length 103424
* schannel: decrypted data length: 6
* schannel: decrypted data added: 6
* schannel: decrypted data cached: offset 23 length 102400
* schannel: encrypted data length: 1428
* schannel: encrypted data cached: offset 1428 length 103424
* schannel: decrypted data length: 2
* schannel: decrypted data added: 2
* schannel: decrypted data cached: offset 25 length 102400
* schannel: encrypted data length: 1397
* schannel: encrypted data cached: offset 1397 length 103424
* schannel: decrypted data length: 25
* schannel: decrypted data added: 25
* schannel: decrypted data cached: offset 50 length 102400
* schannel: encrypted data length: 1343
* schannel: encrypted data cached: offset 1343 length 103424
* schannel: decrypted data length: 2
* schannel: decrypted data added: 2
* schannel: decrypted data cached: offset 52 length 102400
* schannel: encrypted data length: 1312
* schannel: encrypted data cached: offset 1312 length 103424
* schannel: decrypted data length: 12
* schannel: decrypted data added: 12
* schannel: decrypted data cached: offset 64 length 102400
* schannel: encrypted data length: 1271
* schannel: encrypted data cached: offset 1271 length 103424
* schannel: decrypted data length: 2
* schannel: decrypted data added: 2
* schannel: decrypted data cached: offset 66 length 102400
* schannel: encrypted data length: 1240
* schannel: encrypted data cached: offset 1240 length 103424
* schannel: decrypted data length: 16
* schannel: decrypted data added: 16
* schannel: decrypted data cached: offset 82 length 102400
* schannel: encrypted data length: 1195
* schannel: encrypted data cached: offset 1195 length 103424
* schannel: decrypted data length: 2
* schannel: decrypted data added: 2
* schannel: decrypted data cached: offset 84 length 102400
* schannel: encrypted data length: 1164
* schannel: encrypted data cached: offset 1164 length 103424
* schannel: decrypted data length: 14
* schannel: decrypted data added: 14
* schannel: decrypted data cached: offset 98 length 102400
* schannel: encrypted data length: 1121
* schannel: encrypted data cached: offset 1121 length 103424
* schannel: decrypted data length: 2
* schannel: decrypted data added: 2
* schannel: decrypted data cached: offset 100 length 102400
* schannel: encrypted data length: 1090
* schannel: encrypted data cached: offset 1090 length 103424
* schannel: decrypted data length: 3
* schannel: decrypted data added: 3
* schannel: decrypted data cached: offset 103 length 102400
* schannel: encrypted data length: 1058
* schannel: encrypted data cached: offset 1058 length 103424
* schannel: decrypted data length: 2
* schannel: decrypted data added: 2
* schannel: decrypted data cached: offset 105 length 102400
* schannel: encrypted data length: 1027
* schannel: encrypted data cached: offset 1027 length 103424
* schannel: decrypted data length: 2
* schannel: decrypted data added: 2
* schannel: decrypted data cached: offset 107 length 102400
* schannel: encrypted data length: 996
* schannel: encrypted data cached: offset 996 length 103424
* schannel: decrypted data length: 936
* schannel: decrypted data added: 936
* schannel: decrypted data cached: offset 1043 length 102400
* schannel: encrypted data length: 31
* schannel: encrypted data cached: offset 31 length 103424
* schannel: server closed the connection
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 1043
* schannel: decrypted data buffer: offset 0 length 102400
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: PowerTools-Agent/2.1.0-44
< Content-Type: application/json
< Content-Length: 936
<
{
"ptagentversion": "2.1.0-44",
"uptime": "134862 seconds ( 1 day 13 hours 27 minutes 42 seconds )",
"process_id": "2157363",
"ism_version": "3.5.1.ESXi6-1949",
"system_uuid": "5f0b13d3-3d4f-1bce-fdfa-e4434b1a4a00",
"host_epoch_time": "1591823495.299248 (secs.usecs)",
"model": "VxRail E560",
"name": "localhost",
"mfr": "",
"domain": "localhost.pgstorage.local",
"servicetag": "",
"os": "VMWare ESXi",
"os_version": "6.7.0 build-14320388",
"rest_endpoints": "https://100.80.152.110:8086",
"locked_down_mode": "false",
"TPM Present": "false",
"MarvellLibraryVersion": "5.0.13.1108",
"libstorelibir-3.so": "16.10-0",
"libstorelibit.so": "07.05",
"idrac_pass_thru_ip": "169.254.0.25",
"idrac_ethernet_ip": "100.80.101.166",
"host_pass_thru_ip": "169.254.0.26",
"status": {
"idraccache": "OK",
"agent": "OK"
}
}* Closing connection 0
* schannel: shutting down SSL/TLS connection with 100.80.152.110 port 8086
* schannel: clear security context handle
From the openssl s_client -state -connect postman-echo.com:443 | openssl x509 -text
λ openssl s_client -state -connect 100.80.152.110:443 | openssl x509 -text
SSL_connect:before SSL initialization
SSL_connect:SSLv3/TLS write client hello
SSL_connect:SSLv3/TLS write client hello
SSL_connect:SSLv3/TLS read server hello
depth=0 C = US, ST = California, L = Palo Alto, O = "VMware, Inc", OU = VMware ESX Server Default Certificate, emailAddress = [email protected], CN = localhost.pgstorage.local, unstructuredName = "1594564625,564d7761726520496e632e"
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = California, L = Palo Alto, O = "VMware, Inc", OU = VMware ESX Server Default Certificate, emailAddress = [email protected], CN = localhost.pgstorage.local, unstructuredName = "1594564625,564d7761726520496e632e"
verify error:num=21:unable to verify the first certificate
verify return:1
SSL_connect:SSLv3/TLS read server certificate
SSL_connect:SSLv3/TLS read server key exchange
SSL_connect:SSLv3/TLS read server done
SSL_connect:SSLv3/TLS write client key exchange
SSL_connect:SSLv3/TLS write change cipher spec
SSL_connect:SSLv3/TLS write finished
SSL_connect:SSLv3/TLS write finished
SSL_connect:SSLv3/TLS read change cipher spec
SSL_connect:SSLv3/TLS read finished
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
Removed...
Signature Algorithm: sha256WithRSAEncryption
Issuer: O = VMware Installer
Validity
Not Before: Jul 12 14:37:06 2020 GMT
Not After : Jan 11 14:37:06 2032 GMT
Subject: C = US, ST = California, L = Palo Alto, O = "VMware, Inc", OU = VMware ESX Server Default Certificate, emailAddress = [email protected], CN = localhost.pgstorage.local, unstructuredName = "1594564625,564d7761726520496e632e"
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
Removed...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Alternative Name:
DNS:localhost.pgstorage.local
Signature Algorithm: sha256WithRSAEncryption
Removed...
-----BEGIN CERTIFICATE-----
Removed...
-----END CERTIFICATE-----
SSL3 alert write:warning:close notify
@codenirvana - Just checking in, seeing if you need anything else from my side.
Any idea what could be causing this?
7.26.0 is being auto updated. So we had to have everyone install 7.25.0, and then rename squirrel.exe so the auto-updates would put them right back to 7.26.0.
I have the same issue trying to access the api of one of my websites. It is public facing, so maybe I can help so you can debug the issue more?
@tygore587 It’d be great if you could share this endpoint and request with us at [email protected] with any additional details like client certificates, if applicable.
Oh I checked again (because google brings me here), I have another issue with requests, not the same, but also with ssl, sorry :/ But I also can send you an email with details or should I open a new issue here?
Google led me here, although my err message was slightly different.
Error: write EPROTO 140421695491864:error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER:../../third_party/boringssl/src/ssl/tls_record.cc:242:
The issue was that I was trying to POST to https, when that api actually only supports http. Just leaving this as a note for other folks who might run into the same issue.
Issue persists with version 7.27 (just upgraded and tested) Scenario at hand: locally run Azure Functions call
@numaanashraf and @codenirvana - As mentioned in #8598, with the comment "I suspect the problem is postman not catering for sha256WithRSAEncryption", below are all the algorithms our API client can use:
ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-SHA: DHE-RSA-AES128-SHA:
This change happened a little before your change in 7.25.2 with TLS 1.3.
Maybe there is a connection there?
Google led me here, although my err message was slightly different.
Error: write EPROTO 140421695491864:error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER:../../third_party/boringssl/src/ssl/tls_record.cc:242:The issue was that I was trying to POST to https, when that api actually only supports http. Just leaving this as a note for other folks who might run into the same issue.
I am getting the same exact problem in my API call..... Didn't under what is the actual problem. Appreciated if Anyone can help
Google led me here, although my err message was slightly different.
Error: write EPROTO 140421695491864:error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER:../../third_party/boringssl/src/ssl/tls_record.cc:242:The issue was that I was trying to POST to https, when that api actually only supports http. Just leaving this as a note for other folks who might run into the same issue.I am getting the same exact problem in my API call..... Didn't under what is the actual problem. Appreciated if Anyone can help
Did you read my comment? Have you checked whether your endpoint actually supports SSL calls?
Google led me here, although my err message was slightly different.
Error: write EPROTO 140421695491864:error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER:../../third_party/boringssl/src/ssl/tls_record.cc:242:The issue was that I was trying to POST to https, when that api actually only supports http. Just leaving this as a note for other folks who might run into the same issue.I am getting the same exact problem in my API call..... Didn't under what is the actual problem. Appreciated if Anyone can help
Did you read my comment? Have you checked whether your endpoint actually supports SSL calls?
Yes, I read every single comment. Yes, my endpoint supports the SSL call. But how can verify that? I am facing this issue suddenly from the last two days, before that everything is to work fine.
@ayeenmkhan It’d be great if you could share your endpoint (if it is publicly accessible) and request with us at [email protected] with any additional details like client certificates, if applicable. We are actively triaging this issue, and we'd like to understand why your specific request/endpoint is failing.
@ayeenmkhan You could try sending the same request using another tool, e.g. curl. That way you could potentially figure out whether Postman is causing the issue or if there's an actual problem with your SSL certificate.
To validate your SSL cert, you could for example use openssl x509 -in certificate.crt -text -noout.
@ingenuity2k When I am sending a request using curl I am getting the following response:
I am facing the same error as 'Error: 140502547660968:error:10000066:SSL routines:OPENSSL_internal:BAD_ALERT:../../third_party/boringssl/src/ssl/tls_record.cc:573:'
Postman Version: 7.27.1
I am also getting the same issue with making requests with Postman. Postman version is v7.28.0. OpenSSL version: 1.1.1g Here you have the error:
GET https://192.168.56.101/restconf/ Error: write EPROTO 576832344:error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:../../third_party/boringssl/src/ssl/tls_record.cc:587:SSL alert number 40 576832344:error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO:../../third_party/boringssl/src/ssl/handshake.cc:588: Request Headers Content-Type: application/yang-data+json Accept: application/yang-data+json Authorization: Basic Y2lzY286Y2lzY28xMjMh User-Agent: PostmanRuntime/7.26.1 Postman-Token: b99222f2-ef93-4ad5-a082-d4f92139e002 Host: 192.168.56.101 Accept-Encoding: gzip, deflate, br Connection: keep-alive"
I am also getting the same issue.
GET https://****** Error: write EPROTO 1786418760:error:1000011e:SSL routines:OPENSSL_internal:SERVER_ECHOED_INVALID_SESSION_ID:../../third_party/boringssl/src/ssl/handshake_client.cc:646: Request Headers Authorization: Basic = User-Agent: PostmanRuntime/7.26.2 Accept: / Host: 14.98.122.230:9991 Accept-Encoding: gzip, deflate, br Connection: keep-alive
I am also facing the same issue. Is there any update for this open issue? Error: Error: write EPROTO 1172063992:error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER:../../third_party/boringssl/src/ssl/tls_record.cc:242:
Same here, using Postman v7.29.1 Error: write EPROTO 1802223064:error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER:../../third_party/boringssl/src/ssl/tls_record.cc:242:
EDIT: I tried to access the wrong port (8085). After i tried it with the correct one (8086), it worked... mea culpa...
Thank you @thetreythomas for reaching out to our direct support channel to provide further information.
I'm sharing my findings here, hoping it helps others who may be facing similar issues.
I found a difference in Ciphers presented by Postman 7.29.0 compared to an older version.
7.29.0 Ciphers These would be presented during the handshake for the server to negotiate.
Cipher Suites (18 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_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
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_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Potential Workaround If you are running into an issue similar to the one reported here, check your Servers configuration to enable the supported ciphers, you may need to change the accepted ciphers priority/ordering as well.
That should fix the issue unless you have any legacy software which does not support the newer more strong ciphers.
For reference the older version Cipher Suites list (captured on 7.25.0)
Cipher Suites (46 suites)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
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_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)
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_256_CCM_8 (0xc0af)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CCM (0xc0ad)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CCM_8 (0xc0a3)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CCM (0xc09f)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (0xc0ae)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CCM (0xc0ac)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CCM_8 (0xc0a2)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CCM (0xc09e)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
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_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
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_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_256_CCM_8 (0xc0a1)
Cipher Suite: TLS_RSA_WITH_AES_256_CCM (0xc09d)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_128_CCM_8 (0xc0a0)
Cipher Suite: TLS_RSA_WITH_AES_128_CCM (0xc09c)
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)
cc: @codenirvana
