New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: Verified
Owner:
Closed: May 2009
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment
link

Issue 11646: Chrome crashes upon TLS bad_certificate alert message

Reported by surugiu....@gmail.com, May 8 2009

Issue description

Chrome Version       : 2.0.177.1 (Official Build 14854)
URLs (if applicable) : http://www.cdep.ro
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: not tested
  Firefox 3.x: works, SSL error is returned
         IE 7: works, SSL error is returned
         IE 8: not tested

What steps will reproduce the problem?
1. Go to http://www.cdep.ro
2. On the bottom-right of the page, when you click on the USB stick which 
is actually a link Chrome crashes and asks for a restart
3.

What is the expected result?
Return a SSL error instead of crashing the program.

What happens instead?
Chrome crashes

Please provide any additional information below. Attach a screenshot if
possible.
 

Comment 1 by ukai@chromium.org, May 12 2009

Labels: -OS-All OS-Windows
Status: Started
It reproduces on Windows only.
It seems SSLClientSocketWin might miss setting ssl_cert when ssl negotiation failed.

Comment 2 by ukai@chromium.org, May 13 2009

 Issue 11848  has been merged into this issue.

Comment 3 by wtc@chromium.org, May 13 2009

Fumitoshi:

Thanks a lot for tracking down this crash and proposing a
fix in http://codereview.chromium.org/113330.

I found that the server https://www.cdep.ro/ requests
SSL client authentication, and since Chromium doesn't
send a client certificate, the server sends an SSL
bad_certificate alert message, which Windows Schannel
maps to the error code SEC_E_CERT_UNKNOWN:
http://msdn.microsoft.com/en-us/library/dd721886%28VS.85%29.aspx

Chromium then maps the Windows error code SEC_E_CERT_UNKNOWN
to the Chromium error code ERR_CERT_INVALID.  This confuses
our SSL error handling code because it thinks the server
certificate is invalid, but it is the (missing) client
certificate that is invalid.

So we should fix this bug by paying attention to the
context when we map Windows error codes.  Windows error
codes should only be mapped to Chromium's (server)
certificate error codes when we are verifying the
server certificate.  I already have a patch.

Below is an SSL packet trace I captured.  Note that
the server is also TLS-intolerant, so the packet
trace shows a downgrade to SSL 3.0 after the server
responded with an illegal_parameter alert message
to our TLS 1.0 (SSL 3.1) client_hello message.

Note the bad_certificate alert message from the
server at the end of the SSL packet trace.

C:\tmp>ssltap -sx -p 8443 -l www.cdep.ro:443
Looking up "www.cdep.ro"...
Proxy socket ready and listening
Connection #1 [Wed May 13 14:22:08 2009]
Connected to www.cdep.ro:443
--> [
(92 bytes of 87)
SSLRecord { [Wed May 13 14:22:08 2009]
   0: 16 03 01 00  57                                   |....W
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 87 (0x57)
   handshake {
   0: 01 00 00 53                                      |...S
      type = 1 (client_hello)
      length = 83 (0x000053)
         ClientHelloV3 {
            client_version = {3, 1}
            random = {...}
   0: 4a 0b 3a 00  d7 d1 db 4e  ec 65 fe b1  fc 83 31 b8  | J.:....N.e....1.
  10: 54 db 5d 49  67 7f 5c 4b  55 bd 4d 51  33 cd 35 1b  | T.]Ig⌂\KU.MQ3.5.
            session ID = {
                length = 0
                contents = {..}
            }
            cipher_suites[12] = {
                (0x002f) TLS/RSA/AES128-CBC/SHA
                (0x0035) TLS/RSA/AES256-CBC/SHA
                (0x0005) SSL3/RSA/RC4-128/SHA
                (0x000a) SSL3/RSA/3DES192EDE-CBC/SHA
                (0xc013) TLS/ECDHE-RSA/AES128-CBC/SHA
                (0xc014) TLS/ECDHE-RSA/AES256-CBC/SHA
                (0xc009) TLS/ECDHE-ECDSA/AES128-CBC/SHA
                (0xc00a) TLS/ECDHE-ECDSA/AES256-CBC/SHA
                (0x0032) TLS/DHE-DSS/AES128-CBC/SHA
                (0x0038) TLS/DHE-DSS/AES256-CBC/SHA
                (0x0013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
                (0x0004) SSL3/RSA/RC4-128/MD5
            }
            compression[1] = { 00 }
            extensions[18] = {
              extension type elliptic_curves, length [8] = {
   0: 00 06 00 17  00 18 00 19                          |........
              }
              extension type ec_point_formats, length [2] = {
   0: 01 00                                            |..
              }
            }
         }
   }
}
]
<-- [
(7 bytes of 2)
SSLRecord { [Wed May 13 14:22:08 2009]
   0: 15 03 01 00  02                                   |.....
   type    = 21 (alert)
   version = { 3,1 }
   length  = 2 (0x2)
   fatal: illegal_parameter
   0: 02 2f                                            |./
}
]
Read EOF on Server socket. [Wed May 13 14:22:08 2009]
Read EOF on Client socket. [Wed May 13 14:22:11 2009]
Connection 1 Complete [Wed May 13 14:22:11 2009]
Connection #2 [Wed May 13 14:22:11 2009]
Connected to www.cdep.ro:443
--> [
(56 bytes of 51)
SSLRecord { [Wed May 13 14:22:11 2009]
   0: 16 03 00 00  33                                   |....3
   type    = 22 (handshake)
   version = { 3,0 }
   length  = 51 (0x33)
   handshake {
   0: 01 00 00 2f                                      |.../
      type = 1 (client_hello)
      length = 47 (0x00002f)
         ClientHelloV3 {
            client_version = {3, 0}
            random = {...}
   0: 4a 0b 3a 03  53 d3 00 75  bf 53 f3 84  3f c4 4d c8  | J.:.S..u.S..?.M.
  10: 19 94 e9 9a  20 71 75 32  74 33 27 28  82 7c a4 b1  | .... qu2t3'(.|..
            session ID = {
                length = 0
                contents = {..}
            }
            cipher_suites[4] = {
                (0x0005) SSL3/RSA/RC4-128/SHA
                (0x000a) SSL3/RSA/3DES192EDE-CBC/SHA
                (0x0013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
                (0x0004) SSL3/RSA/RC4-128/MD5
            }
            compression[1] = { 00 }
         }
   }
}
]
<-- [
(63 bytes of 58)
SSLRecord { [Wed May 13 14:22:12 2009]
   0: 16 03 00 00  3a                                   |....:
   type    = 22 (handshake)
   version = { 3,0 }
   length  = 58 (0x3a)
   handshake {
   0: 02 00 00 36                                      |...6
      type = 2 (server_hello)
      length = 54 (0x000036)
         ServerHello {
            server_version = {3, 0}
            random = {...}
   0: 4a 0b 36 c8  9a 50 e8 bd  bf b1 d2 17  58 ab 97 9d  | J.6..P......X...
  10: 6f 96 5b 3e  e7 05 ec ef  98 17 a2 4a  aa 0e a0 70  | o.[>.......J...p
            session ID = {
                length = 16
                contents = {..}
   0: d9 6c 84 8f  9b ac 05 e6  ce f5 d3 18  6b 4d 10 ed  | .l..........kM..
            }
            cipher_suite = (0x0005) SSL3/RSA/RC4-128/SHA
            compression method = 00
         }
   }
}
]
<-- [
(3474 bytes of 3469)
SSLRecord { [Wed May 13 14:22:12 2009]
   0: 16 03 00 0d  8d                                   |.....
   type    = 22 (handshake)
   version = { 3,0 }
   length  = 3469 (0xd8d)
   handshake {
   0: 0b 00 0d 89                                      |....
      type = 11 (certificate)
      length = 3465 (0x000d89)
         CertificateChain {
            chainlength = 3462 (0x0d86)
            Certificate {
               size = 1354 (0x054a)
               data = { saved in file 'cert.001' }
            }
            Certificate {
               size = 1271 (0x04f7)
               data = { saved in file 'cert.002' }
            }
            Certificate {
               size = 828 (0x033c)
               data = { saved in file 'cert.003' }
            }
         }
   }
}
]
<-- [
(2077 bytes of 2063, with 9 left over)
SSLRecord { [Wed May 13 14:22:12 2009]
   0: 16 03 00 08  0f                                   |.....
   type    = 22 (handshake)
   version = { 3,0 }
   length  = 2063 (0x80f)
   handshake {
   0: 0d 00 08 0b                                      |....
      type = 13 (certificate_request)
      length = 2059 (0x00080b)
         CertificateRequest {
            certificate types[1] = { 01 }
            certificate_authorities[2055] = {
   OU=Class 1 Public Primary Certification Authority,O="VeriSign, Inc.",C=US
   OU=Class 2 Public Primary Certification Authority,O="VeriSign, Inc.",C=US
   OU=Class 3 Public Primary Certification Authority,O="VeriSign, Inc.",C=US
   OU=Secure Server Certification Authority,O="RSA Data Security, Inc.",C=US
   CN=GTE CyberTrust Root,O=GTE Corporation,C=US
   CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corpo
ration,C=US
   CN=Entrust.net Secure Server Certification Authority,OU=(c) 1999 Entrust.net
Limited,OU=www.entrust.net/CPS incorp. by ref. (limits liab.),O=Entrust.net,C=US

   CN=Entrust.net Certification Authority (2048),OU=(c) 1999 Entrust.net Limited
,OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),O=Entrust.net
   CN=Entrust.net Secure Server Certification Authority,OU=(c) 2000 Entrust.net
Limited,OU=www.entrust.net/SSL_CPS incorp. by ref. (limits liab.),O=Entrust.net
   CN=certSIGN Demo CA Class 1,OU=certSIGN Demo CA Class 1,O=certSIGN,C=RO
   CN=certSIGN CA Class 2,OU=certSIGN CA Class 2,O=certSIGN,C=RO
   OU=certSIGN ROOT CA,O=certSIGN,C=RO
   CN=certSIGN Non-Repudiation CA Class 4,OU=certSIGN Non-Repudiation CA Class 4
,O=certSIGN,C=RO
   CN=certSIGN Enterprise CA Class 3,OU=certSIGN Enterprise CA Class 3,O=certSIG
N,C=RO
   CN=certSIGN Qualified CA Class 3,OU=certSIGN Qualified CA Class 3,O=certSIGN,
C=RO
   CN=Camera Deputatilor
   OU=Autoritatea de Certificare Root STS,O=STS,C=RO
   OU=Autoritatea de Certificare STS,O=STS,C=RO
   OU=Autoritatea de Certificare STS Clasa 1,O=STS,C=RO
            }
         }
   }
}
(2077 bytes of 4)
SSLRecord { [Wed May 13 14:22:12 2009]
   0: 16 03 00 00  04                                   |.....
   type    = 22 (handshake)
   version = { 3,0 }
   length  = 4 (0x4)
   handshake {
   0: 0e 00 00 00                                      |....
      type = 14 (server_hello_done)
      length = 0 (0x000000)
   }
}
]
--> [
(215 bytes of 2, with 208 left over)
SSLRecord { [Wed May 13 14:22:12 2009]
   0: 15 03 00 00  02                                   |.....
   type    = 21 (alert)
   version = { 3,0 }
   length  = 2 (0x2)
   warning: no_certificate
   0: 01 29                                            |.)
}
(215 bytes of 132, with 71 left over)
SSLRecord { [Wed May 13 14:22:12 2009]
   0: 16 03 00 00  84                                   |.....
   type    = 22 (handshake)
   version = { 3,0 }
   length  = 132 (0x84)
   handshake {
   0: 10 00 00 80                                      |....
      type = 16 (client_key_exchange)
      length = 128 (0x000080)
         ClientKeyExchange {
            message = {...}
         }
   }
}
(215 bytes of 1, with 65 left over)
SSLRecord { [Wed May 13 14:22:12 2009]
   0: 14 03 00 00  01                                   |.....
   type    = 20 (change_cipher_spec)
   version = { 3,0 }
   length  = 1 (0x1)
   0: 01                                               |.
}
(215 bytes of 60)
SSLRecord { [Wed May 13 14:22:12 2009]
   0: 16 03 00 00  3c                                   |....<
   type    = 22 (handshake)
   version = { 3,0 }
   length  = 60 (0x3c)
            < encrypted >
}
]
<-- [
(7 bytes of 2)
SSLRecord { [Wed May 13 14:22:12 2009]
   0: 15 03 00 00  02                                   |.....
   type    = 21 (alert)
   version = { 3,0 }
   length  = 2 (0x2)
   fatal: bad_certificate
   0: 02 2a                                            |.*
}
]
Read EOF on Server socket. [Wed May 13 14:22:12 2009]
Read EOF on Client socket. [Wed May 13 14:22:16 2009]
Connection 2 Complete [Wed May 13 14:22:16 2009]

Comment 4 by bugdro...@gmail.com, May 14 2009

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=16026 

------------------------------------------------------------------------
r16026 | wtc@chromium.org | 2009-05-13 18:06:05 -0700 (Wed, 13 May 2009) | 15 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_socket_win.cc?r1=16026&r2=16025

If Schannel's InitializeSecurityContext calls return
certificate errors, do not map them to our (server)
certificate errors because the errors are referring to the
(missing) client certificate.  If we incorrectly handle
them as server certificate errors, we will crash because
we can't get the server certificate from Schannel when the
handshake fails.

Fumitoshi Ukai of Google tracked down the bug and proposed
an alternative fix.

R=rvargas,ukai
BUG= http://crbug.com/11646 
TEST=Visit https://www.cdep.ro/.  Chromium should not crash.
Review URL: http://codereview.chromium.org/113375
------------------------------------------------------------------------

Comment 5 by wtc@chromium.org, May 14 2009

Labels: -Area-Misc Area-BrowserBackend
Status: Fixed
Summary: Chrome crashes upon TLS bad_certificate alert message
Although the certificate of the server https://www.cdep.ro/
is bad (issued by an untrusted CA), that's not why Chrome
crashes.  Chrome crashes because the server sends a TLS
bad_certificate alert message, which Chrome misinterpreted,
so I updated the summary of this bug to reflect that.

Comment 6 by bugdro...@gmail.com, May 14 2009

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=16081 

------------------------------------------------------------------------
r16081 | wtc@chromium.org | 2009-05-14 11:34:07 -0700 (Thu, 14 May 2009) | 17 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/172/src/net/base/ssl_client_socket_win.cc?r1=16081&r2=16080

Backport r16026 from the trunk to the 172 branch.

If Schannel's InitializeSecurityContext calls return
certificate errors, do not map them to our (server)
certificate errors because the errors are referring to the
(missing) client certificate.  If we incorrectly handle
them as server certificate errors, we will crash because
we can't get the server certificate from Schannel when the
handshake fails.

Fumitoshi Ukai of Google tracked down the bug and proposed
an alternative fix.

R=rvargas,mal
BUG= http://crbug.com/11646 
TEST=Visit https://www.cdep.ro/.  Chromium should not crash.
Review URL: http://codereview.chromium.org/115361
------------------------------------------------------------------------

Comment 7 by bugdro...@gmail.com, May 15 2009

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=16144 

------------------------------------------------------------------------
r16144 | ukai@chromium.org | 2009-05-14 20:42:48 -0700 (Thu, 14 May 2009) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache.cc?r1=16144&r2=16143

Assert that HttpNetworkTransaction::GetResponseInfo() should
never return NULL when we get a certificate error.

R=wtc
BUG= 11646 
TEST=access https://www.cdep.ro/

Review URL: http://codereview.chromium.org/113330
------------------------------------------------------------------------

Comment 8 by mberkowitz@chromium.org, May 21 2009

Status: Verified
Verified in Chrome 2.0.181.1 (Official Build 16409) and Chromium 2.0.182.0 (Developer
Build 16485).

Comment 9 by lafo...@chromium.org, May 21 2009

Labels: -Pri-2 Pri-3 Crash-2.0.172.27
This crash was found in 2.0.172.27 and is currently ranked #120 (based on the relative number of reports in the release).  There have been 20 reports from 12 clients.
http://crash/search?query=Chrome+2.0.172.27+net%3A%3AHttpCache%3A%3ATransaction%3A%3AOnNetworkInfoAvailable%28int%29
This crash looks like it has re-appeared in 2.0.172.27

Comment 10 by lafo...@chromium.org, May 22 2009

Labels: Crash-2.0.172.28
This crash was found in 2.0.172.28 and is currently ranked #340 (based on the relative number of reports in the release).  There have been 4 reports from 1 clients.
http://crash/search?query=Chrome+2.0.172.28+net%3A%3AHttpCache%3A%3ATransaction%3A%3AOnNetworkInfoAvailable%28int%29
This crash looks like it has re-appeared in 2.0.172.28

Comment 11 by mal.chro...@gmail.com, Dec 18 2009

Labels: -Area-BrowserBackend Area-Internals

Comment 12 by bugdroid1@chromium.org, Oct 12 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 13 by bugdroid1@chromium.org, Mar 10 2013

Project Member
Labels: -Area-Internals Cr-Internals

Sign in to add a comment