The problem is that cio.gov returns "soft" failures for bad SSL handshakes, and SSL Labs cannot properly detect this condition.

When dealing with clients that are connecting from government facilities, HTTPS handshake failures are very common due to buggy decrypting proxies and monitoring equipment, draconian (and sometimes misguided) configuration / policies, and ancient software on client systems (which cannot be upgraded by the users themselves). These handshake failures are typically extremely hard to troubleshoot, especially given that the users generally see excessively vague error messages on handshake failures, and the users generally have no ability to make any changes to their client's SSL configuration without involving their security department. To help improve this situation, this hosting platform has been modified such that bad SSL handshakes return a descriptive HTML error message instead of an SSL alert. (The SSL handshakes always complete "successfully", but if a bad SSL version or a bad cipher suite was negotiated during the handshake, the server will only return an error page and disconnect.) This allows the server to display helpful diagnostic information and instructions to the user, making it significantly easier to troubleshoot and correct HTTPS problems.

Unfortunately, because SSL Labs only checks for SSL alert messages, these "soft" failures are detected as "successes" for bad protocols/ciphers, leading to an entirely inaccurate assessment of the security of the site. I've had a brief discussion with Ivan about this, and I have a number of thoughts about how to move forward from here (by making a number of improvements to the implementation and requesting broader review of the idea and implementation by the broader security community), but I expect it will take some significant time and effort on my part to make real progress on this.

In the mean time ... Up until very recently, we allowed SSL Labs to continue assessing the site incorrectly, and we simply explained the situation to anyone who noticed the bad grade and asked us about it. However, with the recent publication of SSL Labs grades on pulse.cio.gov, the inaccurate grade became highly visible, and led many people to jump to bad conclusions before we had a chance to explain. Blocking SSL Labs entirely causes a blank grade to show up on pulse.cio.gov, which gives us an opportunity to explain the lack of a grade before anyone has jumped to any conclusions.

the problem with this approach is that it allows protocol downgrade attacks, and browsers will still send sensitive data (cookies, form data, etc.) over a downgraded connection before receiving the error page. allowing insecure protocol versions only to send an error page is just as bad as allowing them for normal access.

That is true, but only if the client supports SSLv2. (Or if both the client and server support SSLv3, and the client still supports the "TLS intolerant" fallback, but that's not relevant here since SSLv3 is disabled on the server.)

In the case of government clients, there was a time when we had significant problems with certain network appliances improperly falling back to SSLv2 then failing in really hard to troubleshoot ways, and my thinking was that modern browsers removed SSLv2 support long ago, and any properly configured government client (even those using old browsers) would have had SSLv2 disabled on the client long ago, so the subset of users who are vulnerable to this is very small, and the ability to troubleshoot these stupid network appliances was a valuable trade-off vs the added risk to a few clients that were both old and improperly configured, hence the reason for still supporting SSLv2 handshakes w/ "soft" failures.

However, now that I'm thinking about this again, I agree that this trade-off is probably not a good one for public-facing websites like cio.gov ... and looking through my logs, I don't actually see any of these failures having happened any time recently, so I've now disabled SSLv2 entirely.

Note that I'm still "soft" failing bad cipher suites. Please let me know if you can think of additional problems with this approach.

there's still the issue of using 1024-bit DH... if an attacker does the precomputation to break your DH parameters (currently believed to be in the "would take the NSA a few years" range), they can then easily force clients to use a DHE suite and completely break the security of the connection.

"soft" failing for weak ciphers like RC4 and DES should be okay, since other than the issue with DHE there's no known way to do a cipher suite downgrade against TLS.

That is actually an entirely different problem. We have a requirement to support connections from Java 1.6 and 1.7 clients, and those clients only support 1024-bit DH. We are actively working on forcing those clients to update to Java 1.8, but until that is complete, we're kinda stuck between a rock and a hard place on this one. If that transition isn't complete very soon, my plan is to stand up a separate restricted "legacy" site specifically for those clients so we can fix this on the main site.