SSL connection terminated by chromium
Reported by
tanglim...@gmail.com,
Nov 30 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3280.0 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Access a Dlink Switch DGS-1210-28MP/ME's management page 2. It's hard to complete all the http request and get the whole pages 3. Capture the packet you will see lots of RST packet from chromium What is the expected behavior? The management page should display completely and normally What went wrong? I am recently using the chromium to access my switch's management page, and find it's hard to get the whole page, sometimes, it is stuck for half an hour and won't stop connecting. And the meantime, if I use firefox, not matter what version I use, everything seems fine. The topology of my test is: PC(192.168.199.22)----->Switch(192.168.199.1) I captured both packet of chromium and firefox. for chromium, please refer to chromium_fail.pcapng, filter with SSL and check ,you will see lots of RST packet which send out by chromium to terminate the connection positively. Sometimes some session is successful but sometime's they are not, it seems totally by random. But with firefox, no even single RST packet found during the SSL negotiation, the web page will show up completely in a short time. you can refer to attached firefox_success.pcapng. I tried with chrome, the behavior is the same, and seems no matter what version of chrome and chromium i use, this issue happens. Did this work before? No Chrome version: 64.0.3280.0 Channel: canary OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version:
,
Dec 1 2017
Thank you for providing more feedback. Adding requester "ckrasic@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 2 2017
I *think* what's happening here is a combination of the error handling for an invalid CA, and a limit on how many sockets we'll have open to the same host. The TCP resets follow a pattern of client sending ClientHello, server responding with ServerHello, ChangeCipherSpec, Finished, client responding with ChangeCipherSpec and Finished, immediately followed by a FIN from the client. The server then sends encrypted application data, to which the client responds with a RST. This matches Chrome completing a TLS handshake, and then checking the validity of the certificate, finding it's invalid, and closing the connection. Looking through the netlog, I see a series of SSL_CONNECT_JOBs that start out with about half of them failing with ERR_CERT_AUTHORITY_INVALID, and the other half succeeding. Eventually, all of them are failing with ERR_CERT_AUTHORITY_INVALID. From looking at the URL_REQUESTs (and associated HTTP_STREAM_JOBs), I see the requests hanging waiting for a socket (the last event in the HTTP_STREAM_JOB is SOCKET_POOL_STALLED_MAX_SOCKETS_PER_GROUP. I assume that the reporter clicked through some interstitial to connect to the router. I don't know why that is remembered for some but not all connections. This is what I want to look at next in investigating this issue. One observation that I made is that in both Chrome and Firefox, all of the connections appear to be resumptions. I don't know if that factors into the bug here.
,
Dec 4 2017
Hi, thanks for the analyse, for the last point you mentioned, I think it may because I have accessed the switch before and just refresh the page when I do packet capture, so you see the connections are resumptions. But as I test, even if you clear all the caches and access the switch's main page again, this issue still happens. What I do during the test is: 1. Open chrome and input url, then enter. 2. Start to capture the packet and do nothing. 3. stop the packet capture. If i keep refreshing the page, eventually it will show the complete page because of the cache mechanism I think. If you have any question about this issue, please feel free to ask me. Thanks.
,
Dec 4 2017
Note: To ensure good traces, please 1) Close all open tabs and windows, such that you have a single tab open 2) Navigate to about:blank 3) Restart Chrome 4) Start the capture (e.g. open chrome://net-export) 5) Enter the URL and press enter 6) Stop the capture That is, please start the capture before you enter the URL.
,
Dec 5 2017
Hi rsleevi: Just do again with the procedure you provided. The PC running chrome is 192.168.199.22, and switch is 192.168.199.1 Please check the packet capture and netlog dump attached.Tell me if you have any problem on them.
,
Dec 8 2017
any update about this issue?
,
Dec 8 2017
I suspect this is issue #488043. There are a lot of bugs around the certificate click-through logic and how socket pools work.
,
Dec 12 2017
Hi all, I add this parameter to chrome "--ignore-certificate-errors", and then everything seems fine. This confirm that the issue is caused by the invalid certification handle logic, just for your reference.
,
Dec 12
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||
►
Sign in to add a comment |
||||
Comment 1 by ckrasic@chromium.org
, Nov 30 2017