Problem: Multiple Web Browsers do not do not validate CN on certificates.

From: Simson L. Garfinkel (simsong_at_nitroba.com)
Date: 05/07/03

  • Next message: Jouko Pynnonen: "Windows Media Player directory traversal vulnerability"
    Date: Wed, 7 May 2003 13:06:56 -0400 (EDT)
    To: bugtraq@securityfocus.com
    
    

    Problem: Multiple Web Browsers do not do not validate CN on certificates.

    Effected Versons:
             Safari 1.0 Beta (v60)
             Safari 1.0 Beta 2 (v73)
             Konqueror Embedded (unknown version; common browser on Open Zaurus)
             [NOTE: Konquror 3.0.5 does not exhibit the problem.]

    Both versions of Safari were tested on MacOS 10.2.5 and 10.2.6.

    While doing work for an article on PKI, Jesse Burns and I discovered
    that Apple's Safari web browser does not validate the Common Name (CN)
    field on X.509 certificates that are downloaded to the client at the
    start of SSL/TLS sessions. This bug is particularly annoying because
    there is no way that we can find inside Safari to view the contents of
    a certificate; double-clicking on the "lock" icon does nothing.

    We are divided on whether or not this is a serious bug: Jesse feels
    that it is sufficient reason that people should stop using
    Safari until it is fixed. Simson feels that PKI has been deployed so poorly and is so
    meaningless that it really doesn't matter if Safari validates
    certificiates or not.

    Test vectors:
         1. https://www.sandstorm.net/
         2. https://bugreporter.apple.com/

    Regarding Test Vector #1:

    Sandstorm's home page is web-hosted at Vineyard.NET, a small ISP on
    Martha's Vineyard. Because Vineyard.NET multi-homes its clients, the
    IP address 204.17.195.91 is shared by both www.sandstorm.net and
    Vineyard.NET's administrative server, www.vineyard.net. However,
    because VIneyard.NET has enabled SSL only for its own internal use and
    not for its customers, 204.17.195.91:443 points to www.vineyard.net,
    and the certficiate at 204.17.195.91:443 is Vineyard.NET's.

    Regarding Test Vector #2:

    A "GET /" at https://bugreporter.apple.com/ retrieves a JavaScript
    document that executes the following:

    <!--
     function time() {
     setTimeout("window.location.replace('https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa')",10)
     }

    This does a second GET at a new domain; the certificate at
    https://bugreporter.apple.com/ actually has the common name of
    bugreport.apple.com.

    Internet Explorer 5.2.2 (5010.1) on MacOS did not exhibit the problem;
    it reported that the common name on the certificate did not match the
    entered DNS address with both of the two test vectors. The same
    behavior was seen with Internet Explorer 5.5 on Windows. The same
    behavior was seen with Opera 7.10 on Windows.

    Apple Computer has been been notified of this bug.

    Simson L. Garfinkel Jesse Burns
    MIT Laboratory for Computer Science jesse@ex.com
    simsong@lcs.mit.edu

    Here is the full www.sandstorm.net certificate:

    [simsong@r2 scan] 346 % openssl s_client -connect www.sandstorm.net:443
    CONNECTED(00000003)
    depth=0 /C=US/ST=Massachusetts/L=Vineyard Haven/O=Vineyard.NET, Inc./OU=Terms of use at www.verisign.com/rpa (c)00/CN=www.vineyard.net
    verify error:num=20:unable to get local issuer certificate
    verify return:1
    depth=0 /C=US/ST=Massachusetts/L=Vineyard Haven/O=Vineyard.NET, Inc./OU=Terms of use at www.verisign.com/rpa (c)00/CN=www.vineyard.net
    verify error:num=27:certificate not trusted
    verify return:1
    depth=0 /C=US/ST=Massachusetts/L=Vineyard Haven/O=Vineyard.NET, Inc./OU=Terms of use at www.verisign.com/rpa (c)00/CN=www.vineyard.net
    verify error:num=21:unable to verify the first certificate
    verify return:1

    ---
    Certificate chain
     0 s:/C=US/ST=Massachusetts/L=Vineyard Haven/O=Vineyard.NET, Inc./OU=Terms of use at www.verisign.com/rpa (c)00/CN=www.vineyard.net
       i:/C=US/O=RSA Data Security, Inc./OU=Secure Server Certification Authority
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    MIIDnjCCAwugAwIBAgIQHyalcXUsMbWBPlciU6wzLDANBgkqhkiG9w0BAQUFADBf
    MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4x
    LjAsBgNVBAsTJVNlY3VyZSBTZXJ2ZXIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
    HhcNMDIwNTE2MDAwMDAwWhcNMDMwNTIxMjM1OTU5WjCBqzELMAkGA1UEBhMCVVMx
    FjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxFzAVBgNVBAcUDlZpbmV5YXJkIEhhdmVu
    MRswGQYDVQQKFBJWaW5leWFyZC5ORVQsIEluYy4xMzAxBgNVBAsUKlRlcm1zIG9m
    IHVzZSBhdCB3d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMDEZMBcGA1UEAxQQd3d3
    LnZpbmV5YXJkLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA9YUotSBh
    TN3F4S2+TahP7F98/M+Cp0hMPaxX47sZXdg6fhr61ibVaRKgs9E27bCD1jh7ccqv
    bTf5h9Mrf89FO7CAadJH49B/H28hvWLhqQYhInO52iCTl80AwGaYJqrdIIrkDEg1
    Vd5DEkdcNeBvj88lPpnQU7fNV9GwkFY/SlMCAwEAAaOCARAwggEMMAkGA1UdEwQC
    MAAwCwYDVR0PBAQDAgWgMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwudmVy
    aXNpZ24uY29tL1JTQVNlY3VyZVNlcnZlci5jcmwwRAYDVR0gBD0wOzA5BgtghkgB
    hvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v
    cnBhMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAZBgpghkgBhvhFAQYP
    BAsWCTgzNjc2MDI1NjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6
    Ly9vY3NwLnZlcmlzaWduLmNvbTANBgkqhkiG9w0BAQUFAAN+AA4ve/eHVmuL/nZO
    aJZ50O4QDrbot146DvQFLre1AUy9TjFEQw0wj3j/qEAToNPZjcx55ADGWqukJMt4
    P5IDu6402J82bAQ1TrUF/+JUARUpBUX18SNk7DsPXjvM7NK0sclb6BEq0sHNujd1
    AJzRaAHaBKQRsDEJCGxAyFsf
    -----END CERTIFICATE-----
    subject=/C=US/ST=Massachusetts/L=Vineyard Haven/O=Vineyard.NET, Inc./OU=Terms of use at www.verisign.com/rpa (c)00/CN=www.vineyard.net
    issuer=/C=US/O=RSA Data Security, Inc./OU=Secure Server Certification Authority
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 1454 bytes and written 314 bytes
    ---
    New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
    Server public key is 1024 bit
    SSL-Session:
        Protocol  : TLSv1
        Cipher    : EDH-RSA-DES-CBC3-SHA
        Session-ID: 
        Session-ID-ctx: 
        Master-Key: 4AD7B59E9D9D3E8953B17B293153A7D104C6CC023E7EC5877FFCAB5D9DD16695F8E867C47D5A656842A352E3EB568F8C
        Key-Arg   : None
        Start Time: 1052273380
        Timeout   : 300 (sec)
        Verify return code: 21 (unable to verify the first certificate)
    ---
    ^C
    

  • Next message: Jouko Pynnonen: "Windows Media Player directory traversal vulnerability"

    Relevant Pages

    • Re: Unable to use stunnel with tin...
      ... Looks like you got an odd version of stunnel. ... was getting the certificate written correctly. ... Next verify you can connect to the server. ...
      (comp.os.linux.setup)
    • RE: Verifying X509Certificate signature
      ... issue--with that sort of data I know what data to pass to Verify. ... As you said that you want some information about verifying X509 certificate ... Microsoft MSDN Online Support Lead ...
      (microsoft.public.dotnet.framework.aspnet.security)
    • Re: Are ++ and -- operators really more efficient
      ... But you still need a way to verify that it's the right key. ... the signature contains a URL indicating ... where the certificate can be found. ... (This idea that public keys represent principals -- ...
      (comp.lang.c)
    • Re: how can we restrict what certificate WSE will use?
      ... > X509SecurityTokenManager to verify the request is from a trusted client. ... > certificate to build a valid signature and encrypted data section. ...
      (microsoft.public.dotnet.framework.webservices.enhancements)
    • RE: Verifying X509Certificate signature
      ... I've got that you actually want to verify the signed certificate. ... Joe has mentioned, this is something related to verify the certificate ... cert store to retrieve key info in cert and do some RSA signing and ...
      (microsoft.public.dotnet.framework.aspnet.security)