New issue
Advanced search Search tips

Issue 662318 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Cannot connect to https://127.0.0.1

Reported by pradyumn...@gmail.com, Nov 4 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.87 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Start a local https server listening on port 443 on 127.0.0.1
2. Open chrome and enter https://127.0.0.1 in the address bar

What is the expected behavior?
The site should open

What went wrong?
Got an error "127.0.0.1 unexpectedly closed the connection"

Notes:
1. Enabling #allow-insecure-localhost in chrome://flags does not change the situation.
2. It opens fine in IE.

Did this work before? N/A 

Chrome version: 54.0.2840.87  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0
 
Labels: TE-NeedsTriageHelp
Labels: Needs-Feedback
Please provide a net internals log. Here are the instructions: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Thanks.
net-internals-log (1).json
361 KB View Download
Yeah, sadly the netlog is just saying the same thing as the error message, just at a lower level, that the server refused the connection.

Would you be willing to get two tcpdumps, one of each of IE and Chrome trying to do the same thing?


tcpdump (windump) and wireshark can't sniff loopback traffic (this being 127.0.0.1)

http://www.winpcap.org/pipermail/windump/2010-March/001032.html
https://wiki.wireshark.org/CaptureSetup/Loopback

If there's a Chrome build that gives verbose logs or something, I can try it out.

Comment 6 by mmenke@chromium.org, Nov 11 2016

All connection attempts failed after exactly 1 second (well, one failed after 1.001 seconds, but close enough).  This seems rather suspicious.  What security software are you running?  Could you try temporarily disabling it?
It's McAfee Enterprise; I tried again with its Host IPS, Network IPS and Firewall disabled, but the issue remains the same.
I enabled further debugging on the server side, and it shows that Chrome chose to send a small set of Cipher suites in its Client Hello, whereas IE sent a larger set. There wasn't a common cipher between the server and Chrome's suite, which is why the handshake failed.

In IE's case:
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA]

The handshake resulted in the selection of TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 from that list.

In Chrome's case:
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, Unknown 0xcc:0xa9, Unknown 0xcc:0xa8, Unknown 0xcc:0x14, Unknown 0xcc:0x13, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA]

Resulted in javax.net.ssl.SSLHandshakeException: no cipher suites in common

Please close this issue if Chrome has chosen to restrict its set of ciphers to these by design.

Comment 9 by eroman@chromium.org, Nov 18 2016

Cc: davidben@chromium.org
Components: Internals>Network>SSL
Ah, probably your server is configured with a DSA (self-signed?) certificate. We haven't supported DSA for ages and it's even completely forbidden as of TLS 1.3. How did you generate the certificate? DSA certificates are basically nonexistent.
Project Member

Comment 11 by sheriffbot@chromium.org, Nov 25 2016

Labels: -Needs-Feedback Needs-Review
Owner: shivanisha@chromium.org
Thank you for providing more feedback. Adding requester "shivanisha@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: WontFix (was: Unconfirmed)

Sign in to add a comment