search

postmanlabs / postman-app-support

Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster.
https://www.postman.com
5.81k stars 839 forks source link

Request execution error: SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE [v7.25.1+] #8612

Open thetreythomas opened 4 years ago

thetreythomas commented 4 years ago

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:

Postman Error

To Reproduce Steps to reproduce the behavior:

  1. Update to 7.26 from 7.25.3
  2. 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):

codenirvana commented 4 years ago

@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

thetreythomas commented 4 years ago

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.
codenirvana commented 4 years ago

@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 help@getpostman.com.

thetreythomas commented 4 years ago

@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.

thetreythomas commented 4 years ago

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.

codenirvana commented 4 years ago

@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:

  1. curl -v -k https://postman-echo.com
  2. openssl s_client -state -connect postman-echo.com:443 | openssl x509 -text

Replace postman-echo.com with your API endpoint.

thetreythomas commented 4 years ago

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
thetreythomas commented 4 years ago

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 = ssl-certificates@vmware.com, 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 = ssl-certificates@vmware.com, 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 = ssl-certificates@vmware.com, 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
thetreythomas commented 4 years ago

@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.

tygore587 commented 4 years ago

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?

numaanashraf commented 4 years ago

@tygore587 It’d be great if you could share this endpoint and request with us at help@postman.com with any additional details like client certificates, if applicable.

tygore587 commented 4 years ago

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?

numaanashraf commented 4 years ago

@tygore587 We recommend filing another issue here.

ingenuity2k commented 4 years ago

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.

roamin-ronin commented 4 years ago

Issue is the same for me.

artsiompeshko commented 4 years ago

+1

ccstorm-nl commented 4 years ago

Issue persists with version 7.27 (just upgraded and tested) Scenario at hand: locally run Azure Functions call

thetreythomas commented 4 years ago

@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?

ayeenmkhan commented 4 years ago

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

ingenuity2k commented 4 years ago

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?

ayeenmkhan commented 4 years ago

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.

numaanashraf commented 4 years ago

@ayeenmkhan It’d be great if you could share your endpoint (if it is publicly accessible) and request with us at help@postman.com 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.

ingenuity2k commented 4 years ago

@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.

ayeenmkhan commented 4 years ago

@ingenuity2k When I am sending a request using curl I am getting the following response: image

raghuramratan commented 4 years ago

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

Umhcisco commented 4 years ago

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"

lkhore commented 4 years ago

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

tghorui commented 4 years ago

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:

BernhardMaier commented 4 years ago

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

xk0der commented 4 years ago

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

lkhore commented 4 years ago

So is it not possible to support old Cipher Suites in new postman.

On Thu, Aug 6, 2020 at 9:47 AM Amit Singh notifications@github.com wrote:

Thank you @thetreythomas https://github.com/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)

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 https://github.com/codenirvana

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/postmanlabs/postman-app-support/issues/8612#issuecomment-669673645, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFZFSKKLTCZ3GATU54B5XTR7IVFPANCNFSM4NZOFFHA .

thetreythomas commented 4 years ago

@lkhore - This issue has been raised to the Postman engineering team. Hopefully soon it will be added back.

bsantos09 commented 4 years ago

Any update on this? I'm having this issue

xaviergm commented 4 years ago

EDIT: I tried to access the wrong port (8085). After i tried it with the correct one (8086), it worked... mea culpa...

This comment really helped me! Thank you!

QAnders commented 4 years ago

We too where stuck on this after we had to update our certificate (due to expiry). The server requires Client Authentication and we previously had PEM files for the private (no passphrase) and public key. Desperate and trying everything I instead added the PFX as cert and the passphrase for it and then it worked!

I've double checked that the keys are the same in the PEM and the PFX but clearly something in the PFX helps sorting this out...

bvivek77 commented 4 years ago

This is due to MITM.

mccannt commented 4 years ago

Thanks for all the input everyone. We are still working to resolve this soon.

richvim commented 3 years ago

If you're here from google, it's likely because you changed a test endpoint to a local development URL without changing the protocol from https to http, as your local service isn't running through an SSL endpoint.

So make sure you change https://{{endpoint_url}}/api/blah to http://localhost:1234/api/blah.

It would be nice if Postman gave a little hint about this.

samwexus commented 3 years ago

Here's what worked for me:

  1. Convert the .crt or .pem file to .pfx format
  2. Open Postman > Settings > Certificates > Add Certificate
  3. Enter Hostname and Include all 3 Certificate.crt, Private.key and Certificate.pfx files
mattpodolak commented 3 years ago

I'm also suddenly facing this issue Error: write EPROTO 1233805176:error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER:../../third_party/boringssl/src/ssl/tls_record.cc:242: with API calls to a local endpoint using https that previously had no issues.

SSL certificate validation is OFF in settings

xyclos commented 3 years ago

Thanks for all the input everyone. We are still working to resolve this soon.

Does this indicate that this has been determined to be an issue in postman and the cause has been identified? Any news with this issue?

mccannt commented 3 years ago

@xyclos Yes, I believe we have found the source of the issue and are working to resolve it. There are some dependencies around this we need to address to fix the issue. Hang tight.

halfluke commented 3 years ago

I had :BAD_ALERT:../../third_party/boringssl/src/ssl/tls_record.cc:573 in an assessment when proxying postman through burp, and I solved thanks to an expert colleague, by disabling TLSv1.3 on the burp listener itself

brandon1024 commented 3 years ago

This has impacted me as well. I couldn't for the life of me get postman to establish a connection with our service, but I am able to get it working with other tools (curl, Soap UI).

I have also found the documentation around configuring certificates really vague.

cptbirdman commented 3 years ago

I had this same problem and then I realized I had to the wrong port. Had one port for HTTP and one for HTTPS and no proxy and I was hitting the HTTP port with an HTTPS request. Obvious mistake, not the first time I've made it.

bellet663 commented 3 years ago

Is there a solution for this? Still getting "EPROTO 513935640:error:10000412:SSL routines:OPENSSL_internal:SSLV3_ALERT_BAD_CERTIFICATE:../../third_party/boringssl/src/ssl/tls_record.cc:587:SSL alert number 42" Version 7.36.1 Thanks!

bellet663 commented 3 years ago

@lkhore - This issue has been raised to the Postman engineering team. Hopefully soon it will be added back.

Any word yet. Any help would be greatly appreciated. Getting this with Version 7.36.1

bellet663 commented 3 years ago

@xyclos Yes, I believe we have found the source of the issue and are working to resolve it. There are some dependencies around this we need to address to fix the issue. Hang tight.

Hello, has this been resolved? Thanks

tarekahf commented 3 years ago

I am getting this error only when I test the POST request from Postman for web:

Error: write EPROTO 2038819368:error:100000f0:SSL routines:OPENSSL_internal:UNSUPPORTED_PROTOCOL:../../third_party/boringssl/src/ssl/handshake_client.cc:581:

POST https://testforms.xyz.com/soap/services/AppLib/Processes/CalcDistanceByGoogle?wsdl Error: write EPROTO 2038819368:error:100000f0:SSL routines:OPENSSL_internal:UNSUPPORTED_PROTOCOL:../../third_party/boringssl/src/ssl/handshake_client.cc:581: Console: Network Request Headers Content-Type: text/xml SOAPAction: invoke User-Agent: PostmanRuntime/7.26.8 Accept: / Cache-Control: no-cache Postman-Token: 1e7df269-9bfd-40a6-bed0-d3eb0b0d3639 Host: testforms.nationwideappraisals.com Accept-Encoding: gzip, deflate, br Connection: keep-alive Request Body

25 Lanark Rd, Markham, ON L3R 9Y7 80 Micro Ct, Markham, ON L3R 9Z5 https://web.nxyz.com/

When I use the Postman desktop app from Windows 10, it works fine without any error.

The web service is WSDL Based and hosted on Adobe LiveCycle Server - Processes.

Please help.

Tarek

strawp commented 3 years ago

I had :BAD_ALERT:../../third_party/boringssl/src/ssl/tls_record.cc:573 in an assessment when proxying postman through burp, and I solved thanks to an expert colleague, by disabling TLSv1.3 on the burp listener itself

Based on this it seems the issue is with the implementation of TLS 1.3 used by Postman?

In my case, I was talking to an API which required client certs for authentication (which were added to Burp), Burp was carrying out the requests fine but in most (but not all) cases PM wasn't able to parse the response which Burp served. In a lot of cases, if I kept hammering the "Send" button then every so often a request would get through.

Anyway, disabling 1.3 on Burp's listener fixed it for me.