SSL/TLS analysis of the Internet's top 1,000,000 websites

> On ECDHE's side, handshakes almost always use the P-256 curve. Again, this makes sense, since Internet Explorer, Chrome and Firefox only support P256 at the moment. But according to recent research public by DJB & Lange, this might not be the safest choice.

Not only is it not safe, but it's also 3x slower than DJB's own 256-bit Curve25519:

https://www.imperialviolet.org/2010/12/21/eccspeed.html

All the browsers should hurry up and support it already. Also maybe it's time to consider using NaCl, or some other alternative to OpenSSL, which seems hopeless.

Regarding the TLS 1.0 and 1.2 but not 1.1 sites, I think it's related to this:

Changes between 1.0.1a and 1.0.1b [26 Apr 2012]

- OpenSSL 1.0.0 sets SSL_OP_ALL to 0x80000FFFL and OpenSSL 1.0.1 and 1.0.1a set SSL_OP_NO_TLSv1_1 to 0x00000400L which would unfortunately mean any application compiled against OpenSSL 1.0.0 headers setting SSL_OP_ALL would also set SSL_OP_NO_TLSv1_1, unintentionally disablng TLS 1.1 also. Fix this by changing the value of SSL_OP_NO_TLSv1_1 to 0x10000000L Any application which was previously compiled against OpenSSL 1.0.1 or 1.0.1a headers and which cares about SSL_OP_NO_TLSv1_1 will need to be recompiled as a result.

I would like for someone with knowledge to create an example apache config and keep it up to date.

One would think that someone from the apache project might be well suited for it.

It seems to me that browsers ought to pop up a security warning for any site that tries to use an insecure cipher like RC4 or 3DES so the user is at least aware. I say that simply because it's possible that even if a site supports something more secure, what's to stop a MITM from reporting differently during the protocol negotiation?