scary certificate for www.update.microsoft.com

[Ben Liddicott]

This is a website for issuing updates to Microsoft Windows. It is 
verified by a chain terminating in a certificate Microsoft issued 
themselves.

The SSL Chain of trust is for trusting previously unknown parties. For 
the purposes of updating Windows, Microsoft are not an unknown party. 
Nothing would be added by having Verisign validate the certificate.

Cheers,
Ben

On 18/06/2012 01:12, Tony Naggs wrote:
>
>
> On 17 June 2012 17:57, Roland Perry <lists at internetpolicyagency.com 
> <mailto:lists at internetpolicyagency.com>> wrote:
>
>     In article <4FDE04AF.5000903 at zen.co.uk
>     <mailto:4FDE04AF.5000903 at zen.co.uk>>, Peter Fairbrother
>     <zenadsl6186 at zen.co.uk <mailto:zenadsl6186 at zen.co.uk>> writes
>
>         I think the browsers are looking to check the hostname in the
>         requested URL matches the hostname in the certificate - and it
>         doesn't, 65.55.25.59 != www.update.microsoft.com
>         <http://www.update.microsoft.com>
>
>         Both actions seem like perfectly good behaviour to me.
>
>
>     As a "user" I'd expect the browser to connect the two concepts,
>     it's not as if DNS hasn't been invented yet.
>
>
> Scary certificate test results for Microsoft's Update server SSL 
> certificate - "Overall rating Zero":
>
> As assessed by 
> https://www.ssllabs.com/ssltest/analyze.html?d=www.update.microsoft.com
>
> Several bad features get highlighted in red.
>
> Certificate Information
> Common names www.update.microsoft.com <http://www.update.microsoft.com>
> Alternative names     -
> Prefix handling     Not required for subdomains
> Valid from     Thu May 31 04:36:05 UTC 2012
> Valid until     Sat Aug 31 04:46:05 UTC 2013 (expires in 1 year and 2 
> months)
> Key     RSA / 2048 bits
> Signature algorithm     SHA1withRSA
> Server Gated Cryptography     No
> Weak key (Debian)     No
> Issuer     Microsoft Update Secure Server CA 1
> Next Issuer         Microsoft Root Certificate Authority
> Chain length (size)     2 (3241 bytes)
> Chain issues     Incomplete
> Extended Validation     No
> Revocation information     CRL
> Revocation status     Unchecked (only trusted certificates can be checked)
> Trusted     No  NOT TRUSTED   (Why?)
>
>
> Protocols
> TLS 1.2     No
> TLS 1.1     No
> TLS 1.0     Yes
> SSL 3.0     Yes
> SSL 2.0+ upgrade support     Yes
> SSL 2.0   INSECURE     Yes
>
>
> Cipher Suites (SSLv3+ suites in server-preferred order, then SSLv2 
> suites where used)
> TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)        128
> TLS_RSA_WITH_AES_256_CBC_SHA (0x35)        256
> TLS_RSA_WITH_RC4_128_SHA (0x5)        128
> TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)        168
> TLS_RSA_WITH_RC4_128_MD5 (0x4)        128
> SSL_DES_192_EDE3_CBC_WITH_MD5 (0x700c0)        168
> SSL_RC4_128_WITH_MD5 (0x10080)        128
>
>
> Miscellaneous
> Test date     Sun Jun 17 22:52:25 UTC 2012
> Test duration     22.40 seconds
> Server signature     Microsoft-IIS/7.0
> Server hostname     -
> Session resumption     No (IDs assigned but not accepted)
> BEAST attack     Vulnerable   INSECURE (more info)
> Secure Renegotiation     Supported, with client-initiated 
> renegotiation disabled
> Insecure Renegotiation     Not supported
> Strict Transport Security     No
> TLS version tolerance     0x0304: 0x301; 0x0399: 0x301; 0x0499: 0x301
> PCI compliant     No
> FIPS-ready     No
> Ephemeral DH     Not seen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20120618/8c91b41b/attachment.html>