chromium 65 release build，OpenSSL SSL error, reason: 1040，but debug is OK
Reported by
lbgbob87...@gmail.com,
Apr 16 2018
|
|||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36 Example URL: https://codereview.chromium.org Steps to reproduce the problem: 1. chromium build release on windows 2. navigate any website such as https://*** 3. can not navigate, error ERR_SSL_PROTOCOL_ERROR What is the expected behavior? https websites can navigate normally What went wrong? the error log info as below: openssl_ssl_util.cc(71)] OpenSSL SSL error, reason: 1040, name: error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? Yes Chrome version: 65.0.3325.146 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 29.0 r0 debug is OK，Where did it go wrong?
,
Apr 16 2018
Are you running any antivirus software? Can you attach a chrome://net-export log as documented at https://www.chromium.org/for-testers/providing-network-details ?
,
Apr 18 2018
,
Apr 18 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 18 2018
@dtapu...@chromium.org Components: -Blink Internals>Network>SSL what does it mean?
,
Apr 18 2018
Unable to reproduce the issue on chromium version 65.0.3325.0 using windows-10 with steps mentioned below: 1) Launched chromium build and navigated to URL: https://www.google.com 2) Able to navigate to the google page successfully, didn't observed nay error message @Reporter: Please find attached screenshot for your reference and try to test this issue by creating new person with no apps and extensions in it and let us know if the issue still persists. Thanks!
,
Apr 19 2018
(Please ignore comment #7. Apps and extensions would not affect the stack at that level.) Thanks for the log! I see you've set --ignore-ssl-errors. Note that's not actually a valid Chrome command-line flag. It's just being ignored. The log also shows you connecting through a proxy, presumably your antivirus, and getting a handshake_failure alert back. While the certificate seems plausible, the alert is unencrypted and may come from the proxy or the server. I'm not able to reproduce this on my end. Could you attach a NetLog with the antivirus off? When you say debug is okay, do you mean a debug build of Chromium at the same revision?
,
Apr 20 2018
Thanks for your feedback! @davidben@chromium.org. Year, --ignore-ssl-errors flag is really invalid. It's just for testing. I tried without proxy and antivirus, it's also not ok. Debug build is the same version and code, just set is_debug=false in gn command for generate build files, when set is_debug=true, it's ok. I debug and analyze logs, the reason for the error is call SSl_do_handshake() function of boringssl, and it's return -1, net_error -107(SSL_PROTOCOL_ERROR). and other SSL_***() function alse return -1, net_error -107. the certificate information seems ok, no error found. the SSL verion is TLS1_2. So I guess is it the library of boringssl issue, or is there a complie option about boringssl when build in release mode? remark: NetLog produced in chromium 68，the same issue as chromium 65.
,
Apr 20 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 20 2018
(By invalid, I didn't just mean insecure and a bad idea. I meant it's not actually a command-line flag that Chromium parses at all. It's just ignoring you. Of course, if we did parse it, that would certainly be insecure and a bad idea!) SSL_do_handshake is returning -1 because we are receiving an error from the other side. So that's to be expected, given what we're receiving from the server or proxy. I don't believe we have anything that will behave differently in debug or release mode like that. The attached NetLog shows you still using a proxy, actually. Are you sure you've disabled that?
,
Apr 21 2018
I'm sure that I had disabed the proxy. But in debug it really ok, so I have no idea about this.
,
Apr 21 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 23 2018
By analysis log, the reason for the error is produced warnings of SSL3_RT_ALERT when call ssl3_open_handshake() function in boringssl component. Can find the reason through this error information above?
,
Apr 23 2018
Your NetLog showed the proxy was still in use. It was not disabled. Can you get a fresh NetLog with --no-proxy-server? Again, yes, the server or proxy is responding with an alert. There's nothing to dig into the code w.r.t. what error-handling is going on because the error is being triggered remotely.
,
Apr 24 2018
How to confirm that the proxy has been closed, or how to close it?, my system is win10, the proxy uses shadowsocks. But in the same environment, other browsers(such as chrome..) are normal, even in debug mode. How do you explain this? I think that the server is constant, the problem maybe the client side, what situation will the client can cause this SSL3_RT_ALERT alert?
,
Apr 24 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 25 2018
I dig into the code and find that the SSL3_RT_ALERT error is:
in handshake_client.cc(1060) function of do_read_server_key_exchange, and in it call ssl_public_key_verify() return sig_ok=false, the reason is that it's inner call ECDSA_do_verify() function in ecdsa.c file, code is:
if (BN_ucmp(X, sig->r) != 0) {
OPENSSL_PUT_ERROR(ECDSA, ECDSA_R_BAD_SIGNATURE);
goto err; // err = 0
}
while X and sig->r is not equll ?
By the way, I have not recieved the hs-wait of ss_open_change_cipher_spec ?
I check the boringssl library wiht google.org code and no difference.
davidben@chromium.org, can you tell me where is go wrong ?
,
Apr 25 2018
No. Again, that is not the codepath that your NetLog shows us hitting. Again, the alert is coming from the server or some misbehaving entity on your network, not the client. See id:548 in your most recent log:
t=34199 [st=99] SOCKET_BYTES_RECEIVED
--> byte_count = 7
t=34199 [st=99] SSL_ALERT_RECEIVED
--> hex_encoded_bytes =
02 28 .(
t=34199 [st=99] SSL_READ_ERROR
--> error_lib = 16
--> error_reason = 1040
--> file = "../../third_party/boringssl/src/ssl/tls_record.cc"
--> line = 601
--> net_error = -107 (ERR_SSL_PROTOCOL_ERROR)
--> ssl_error = 1
t=34199 [st=99] SOCKET_CLOSED
An "alert" is literally just an SSL error code. Just about every possible protocol failure would result in one of those. The codepath you have found is if the server had a bug and failed to sign its ServerKeyExchange correctly. That is not what is going on in your NetLog. The NetLog shows the handshake getting past that point.
The new NetLog does at least show you successfully disabled the proxy, so that cause is finally ruled out. Though given the error is now coming from the server or network, I'm not sure what to suggest trying next...
,
Apr 26 2018
ECDSA_R_BAD_SIGNATURE, the Server Key Exchange verify failed.
,
Apr 26 2018
Where are you getting ECDSA_R_BAD_SIGNATURE from? Again, that is not what your NetLog shows. It sounds like you are trying to diagnose something unrelated to the logs you have provided. In that case, we really cannot help you if you do not attach the right logs.
,
Apr 26 2018
Please attach the *correct* logs.
,
Apr 27 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 27 2018
I'm getting the ECDSA_R_BAD_SIGNATURE from server message. I attach the release and debug NetLogs for compare. It shows that the signature is invalid. NetLog info:
--release--NetLog--
********************************************************************
"scts": [
{
"extensions": "",
"hash_algorithm": "SHA-256",
"log_id": "h3W/51l8+IxDmV+9827/Vo1HVjb/SrVgwbTq/16ggw8=",
"origin": "Embedded in certificate",
"signature_algorithm": "ECDSA",
"signature_data": "MEUCIBttpzpQzcC7R/kiK6NYIQ+ZlHexitGvHNzYQHs1PK7cAiEA1oz5KqmKalvPivrnUIhf6GELLB3MsbckTrMCuDKPHYg=",
"timestamp": "1522725965578",
"verification_status": "Invalid signature",
"version": 0
},
{
"extensions": "",
"hash_algorithm": "SHA-256",
"log_id": "u9nfvB+KcbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e0YU=",
"origin": "Embedded in certificate",
"signature_algorithm": "ECDSA",
"signature_data": "MEUCIQCYToCsZy2f8yb6c/tzccP2f+xgV78UnmfbcWSIvatP2gIgYskmXUXaxSYD+y7hhPt2JzlHvfcgwmVmJz0dA4mghMg=",
"timestamp": "1522725966148",
"verification_status": "Invalid signature",
"version": 0
}
]
"ct_compliance_status": "NOT_ENOUGH_SCTS"
********************************************************************
--debug--NetLog--
********************************************************************
"scts": [
{
"extensions": "",
"hash_algorithm": "SHA-256",
"log_id": "h3W/51l8+IxDmV+9827/Vo1HVjb/SrVgwbTq/16ggw8=",
"origin": "Embedded in certificate",
"signature_algorithm": "ECDSA",
"signature_data": "MEUCIBttpzpQzcC7R/kiK6NYIQ+ZlHexitGvHNzYQHs1PK7cAiEA1oz5KqmKalvPivrnUIhf6GELLB3MsbckTrMCuDKPHYg=",
"timestamp": "1522725965578",
"verification_status": "Verified",
"version": 0
},
{
"extensions": "",
"hash_algorithm": "SHA-256",
"log_id": "u9nfvB+KcbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e0YU=",
"origin": "Embedded in certificate",
"signature_algorithm": "ECDSA",
"signature_data": "MEUCIQCYToCsZy2f8yb6c/tzccP2f+xgV78UnmfbcWSIvatP2gIgYskmXUXaxSYD+y7hhPt2JzlHvfcgwmVmJz0dA4mghMg=",
"timestamp": "1522725966148",
"verification_status": "Verified",
"version": 0
}
]
"ct_compliance_status": "COMPLIES_VIA_SCTS"
********************************************************************
I verified these certificate and it's equal, no difference. Is there something of the signature algorithm go wrong? It's too weird.
,
Apr 27 2018
Interesting. That signature verification failure would not cause this error. I don't believe that certificate. Something *additional* is going wrong. That said, that those two SCTs with the same inputs give different validities is certainly concerning. Given that release and debug differ, this honestly seems like a compiler bug. I see this is a custom developer build and not an official build. Does the error occur with Google Chrome? What compiler are you using? Have you applied any patches or is this the unmodified upstream repository? Please build the boringssl_crypto_tests target in both debug and release. Does it pass?
,
May 2 2018
Thank you very much, davidben@chromium.org. Just finished the May Day holiday. Your analysis of the clues is correct. It's really a compiler bug. When I analyzed the above information of #Comment 27 and #Comment 28, I also think that it's the compile problem. I analyzed the compilation differences between debug and release, only the optimizations is suspicious. When I close this option in release, and it's normal work. That's amazing. But I'm not clear why this optimization will affect SSL related, and I will have time later for further analysis. It maybe the issue of SSL algorithm part or the optimizer itself. Thanks again. Hope your work goes well and have a nice day.
,
May 2 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 2 2018
|
|||||||||||||||
►
Sign in to add a comment |
|||||||||||||||
Comment 1 by dtapu...@chromium.org
, Apr 16 2018