SSL is dead, long live TLS1.0, er 1.1, er 1.x

So I thought I would post this as I couldn't find a definitive answer anywhere; how to enable HTTPS Strict Transport Security, or HSTS on IIS 7.5 on Windows 2008 r2. It is really, really simple.
Open the iis manager, navigate to the site and go to HTTP Response headers. Add a new HTTP Response header with name of Strict-Transport-Security and Value of max-age=300 like the below;

Then click ok, you will more than likely need to restart iis to get this to work from my experience.

I also thought I might mention how to enable TLS 1.1 and TLS 1.2, save the below as a .reg file and do the old regedit /s file.reg from an elevated prompt to get it imported, then reboot.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000

Another awesome page I found during my travels that needs more publicity is by Qualys, it does a full SSL/TLS implementation test and tells you how you fared;
https://www.ssllabs.com/ssltest/
After this you may want to change your cipher suites, which now in 2008r2 can be done in gpedit. Anyway that is for this quick brain dump.

Definately not outage Virgins

So in case you haven't heard an international budget airline here in Australia has had a major computer issue, see here.
By the sounds of it their outsourced service provider doesn't have redundant kit, as they couldn't simply fail-over. But it gets worse currently going to https://book.virginblue.com.au/FlightInfo.aspx or https://book.virginblue.com.au leaks a lot of information, and leaks a nice juicy standard ASP.Net error page, of the type that the recently discussed Asp.Net oracle padding attack can take great use of, see here.
Ouch and double ouch. Oh and we hear this is not the first outage they have had in as many months...

Revocation, just rolls off the tounge

First an overview, SSL is pretty much the only protection available when banking, shopping etc. It means the user has to look for the https:// up the top rather than the http:// to ensure the session from their browser to the websites server is encrypted in transit (this isn't perfect people can fake some certificates, and security researchers are trying to find its holes all the time). Don't trust the lock or the little green bar that EV certs give you as these can be faked several ways, generally though the https and certificate information can be trusted. Also look at an extension for FireFox called SSL blacklist for FireFox that will notify you if a certificate is bad due to one of many reasons.
One of the interesting things about certificates is of course they have to be able to be revoked, when for some reason they become compromised or some such other reason.
CRL or certificate revocation lists as some are probably aware are basically a list stored on the company that provided the certificates website, basically a list of all the certs that have been revoked. Excellent idea, but look at most certificates details and CRL is hosted on a good ole plain http site eg; http://crl.thawte.com/ThawteSGCCA.crl
YAY, so if you want just own a few crl via DNS poisoning or man in the middle (MITM) a user (can we say web cafe) and serve up a fake crafted CRL to revoke heaps of certificates or just remove your revoked cert for their bank etc. Of course there are a lot of variables here, you need to know the CRL that is going to be requested though if you have MITM'd them you can just serve all of them up, they are usually signed, but not always, you also need to know sites they are going to go to, but you can dynamically do this as well.
Their digital signing doesn't look that good from what I have seen from reading the crl's either, but they are supposed to sign it with their SSL certificate available from their site via a link, so no trust their just sign it with your own cert and serve that up at their site as you are already in the middle.
But the nice thing as far as a denial goes is that most operating systems cache this info (for 24 hours usually), and the Certificate hierarchy is good just blacklist the vendors root certificate.
To do any real damage you still need to get a certificate registered that has been falsely registered, or do a bit of social engineering, blacklist all certs and pop up a page saying the user needs to update their certificates, redirect them to a legit looking site that asks them to install a certificate package full of your own generated root certificates, all SSL sites from then on are readable as you re-sign them with your key on the way through.
Of course SSL isn't a fix for the revocation lists as no one will see that it requests the list from https instead of http, I have even seen some installs of Internet Explorer that have certificate revocation checking turned off, I am not sure if this is default, but bad none-the-less.

Well I hope this long winded odd rant is at least made some people think. It is a very odd setup and I am surprised all CRL's don't require possibly multiple signing by at least two vendors kind of like nuclear launch codes.