Socket hangup while sending request (in app version 7.3.0 to 7.3.2) #6886
Comments
|
I noticed that you only have 7.2.2 offered to download on the web, and that the most recent Canary build is 7.3.2, which I just installed and encountered the exact same error. Did the wrong build get promoted to the wrong branch? I'm uninstalling 7.3.2 and reinstalling 7.2.2 and not updating. |
|
After removing 7.3.2 and installing 7.2.2, I'm back to normal. If I |
|
Hey @thetreythomas Could you open the Postman Console(View -> Show Postman Console) from 7.3.2 or 7.3.2-canary and send us a screenshot of the errors you are seeing? |
|
@kamalaknn Here's a screenshot. I had reinstalled 7.2.2. I went through the update again to 7.3.2 and ran into the issue.
|
|
Hey @thetreythomas could you give some insights into which TLS version your server is using. I have a hunch that this issue could be related to nodejs/node#21088 In the 7.3.x version of the app, we updated the underlying version of the platform which now comes with node v10. |
|
@saswatds - Our application previously supported SSLv3, TLSv1.0, TLSv1.1, and TLSv1.2. Roughly five versions back we changed that to use only TLSv1.2. |
|
@thetreythomas Can you try sending the failing request using curl with The verbose logs for SSL connection will help us debug this issue. |
|
Hello, we've got the same problem here at Renault with requests on some intern services. (Postman version 7.3.1 & 7.3.2) |
|
@codenirvana Here you go. Let me know if you need anything else. C:\Users\trey\Downloads\curl-7.65.1_3-win64-mingw\curl-7.65.1-win64-mingw\bin>curl -kv https://10.211.61.86:8086/api/PT/v1/system/agentinfo -H "Authorization: Basic <REDACTED>" -H "Content-Type: application/json"
* Trying 10.211.61.86:8086...
* TCP_NODELAY set
* Connected to 10.211.61.86 (10.211.61.86) port 8086 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / DHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=Texas; L=Round Rock; O=Dell
* start date: Jul 5 15:33:06 2016 GMT
* expire date: Jul 3 15:33:06 2026 GMT
* issuer: C=US; ST=Texas; L=Round Rock; O=Dell
* SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET /api/PT/v1/system/agentinfo HTTP/1.1
> Host: 10.211.61.86:8086
> User-Agent: curl/7.65.1
> Accept: */*
> Authorization: Basic <REDACTED>
> Content-Type: application/json
>
* Mark bundle as not supporting multiuse
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: PowerTools-Agent/1.9.0-371
< Content-Type: application/json
< Content-Length: 823
<
{
"ptagentversion": "1.9.0-371",
"uptime": "58352 seconds ( 16 hours 12 minutes 32 seconds )",
"process_id": "127215",
"ism_version": "3.4.0.ESXi6-1471",
"host_epoch_time": "1562771980.701527 (secs.usecs)",
"model": "DP4400",
"name": "dpappliance-esx",
"mfr": "Dell Inc.",
"domain": "dpappliance-esx.idpa.local",
"servicetag": "XXXXXXX",
"os": "VMWare ESXi",
"os_version": "6.5.0 build-10719125",
"rest_endpoints": "https://10.211.61.86:8086",
"locked_down_mode": "false",
"TPM Present": "false",
"MarvellLibraryVersion": "5.0.13.1099",
"libstorelib.so": "07.07",
"libstorelibir-3.so": "4.03-0",
"idrac_pass_thru_ip": "169.254.0.1",
"idrac_ethernet_ip": "10.211.61.64",
"status": {
"idraccache": "OK",
"agent": "OK"
}
}* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256): |
|
Just update to v7.3.3 and getting a similar error. |
shamasis
changed the title
|
@thetreythomas @antoinemaschiR @SXS73 Thanks for reporting this issue and helping us triage and debug this. From our initial investigation, it seems this issue is caused by Postman not handling TLS renegotiations initiated by the server, which leads to an error in the request flow and the ‘Could not get any response’ screen. This is a regression in Postman v7.3 and earlier versions of Postman handles the TLS renegotiation scenario is a spec-compliant way. In Postman v7.3, we had upgraded the version of Electron (https://github.com/electron/electron - an open-source Desktop application framework we use) from v1.8 to v4.2. From v4.0 onwards, Electron has switched the internal TLS library used from OpenSSL to BoringSSL (Google’s fork of OpenSSL used by Chrome). From our investigation so far, it seems BoringSSL has some differences in configuration and defaults compared to OpenSSL - TLS renegotiations being one of them. BoringSSL disables TLS renegotiation by default, while OpenSSL allows this for TLS protocols that support it. We’re currently working on moving back to Electron v3.x (which do not include the BoringSSL switch) and running some internal tests - we were able to verify that the TLS renegotiation works as expected on Electron v3.x. We’re working on getting this build out to our early-access Canary soon, which would be followed by a rollout to production. We’re also working with the Electron community to patch this issue in Electron versions 4.x and above which would also address the following issue on the Electron project - electron/electron#18380 |
|
@numaanashraf - Thanks for the very quick and detailed bug analysis! |
|
@thetreythomas The fix for this issue is available on our canary channel (7.3.4-canary01) https://www.getpostman.com/downloads/canary The same will be available on the production channel in the next release (7.3.4). Will update the thread. |
|
@harryi3t @numaanashraf - Just updated my Canary build to 7.3.4 and everything works as it should. Looks good! |
|
Thanks for the quick fix here guys !
I had a quick question, is it possible to clone your environments from
Postman Stable to Canary ? Or would it make sense to switch to a 7.2.2 or
something like that?
Thanks,
Shreyash
…On Tue, Jul 16, 2019, 6:36 PM Trey ***@***.***> wrote:
@harryi3t <https://github.com/harryi3t> @numaanashraf
<https://github.com/numaanashraf> - Just updated my Canary build to 7.3.4
and everything works as it should. Looks good!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6886?email_source=notifications&email_token=ALB4REGQJKXJ33XVVTFR763P7ZEPJA5CNFSM4H7JZ622YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2COZXY#issuecomment-512027871>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALB4REEJ3EJR3TTVZS4XMC3P7ZEPJANCNFSM4H7JZ62Q>
.
|
|
@SXS73 - I log into both the normal build and Canary build using my registered Postman account, and all my collections, environments, etc.. are there for both. I've never had them not be synced up. |
|
@SXS73 They both use the same data. The only difference would be in the |
|
@thetreythomas @antoinemaschiR @SXS73 We've pushed a fix for this in the latest version of the Postman app |
|
@codenirvana - Everything looks good on my end. Been running fine on 7.3.4 since yesterday around lunch time. |
|
have the same problem |
|
Could not connect to localhost:3000 |
|
I see the same issue for Postman version 9.8.3 when I try to access MTLS URL. |
|
@KKaranja @alchemist123 @jasAtPing This could be a different issue. In-case you are still facing it, can you please open a new issue? |
Describe the bug
Just updated to 7.3.2. After Postman restarted I tried the same API call I was using before the update and get the error message below:
To Reproduce
Steps to reproduce the behavior:
Expected behavior
For Postman to work like it did before the update :)
App information (please complete the following information):
Additional context
I have other API tools on my system. All others have no problems connecting to my API.
From the renderer-requester.log file
The text was updated successfully, but these errors were encountered: