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