If you deal with Credit Cards on the Internet, then it is very likely that you will have to conform to the Payment Card Industry Data Security Standards (PCI-DSS). You can get the standards specification, the self assessment questionnaire, or find instructions on exactly what you need to do to conform on the PCI-Security Standards Council website.
Depending on the nature of your business, and indeed how much money you see, you may need to perform network vulnerability assessments every quarter. These assessments are performed against the servers hosting your ‘payment application’ ie. your web server.
You will find a complete list of all companies that are recognised by the PCI on their website here (PDF) and most will offer some kind of free limited network assessment (such as 5 free scans for up to 3 IPs per device)
So, you’ve run your network vulnerability assessment on your IIS6 server. Great. But now you received a “NOT COMPLIANT” report as a result of failing the following two tests:
- “Deprecated SSL Protocol Usage”
- “Weak Supported SSL Ciphers Suites”
Let’s look at each one in turn and how to solve them.
Deprecated SSL Protocol Usage - The remote service encrypts traffic using a protocol with known weaknesses
The report may also give you the following information to put the fear of your god into you - “The remote service accepts connections encrypted using SSL 2.0, which reportedly suffers from several cryptographic flaws and has been deprecated for several years. An attacker may be able to exploit these issues to conduct man-in-the-middle attacks or decrypt communications between the affected service and clients.”
You can confirm the reports findings by typing your hostname or IP into this handy utility - http://www.serversniff.net/sslcheck.php which will generate a report such as the picture below
The report is showing you that both SSL2 and SSL3 are enabled, and all the ciphers currently exposed by the server.
OK- So we want to remove SSL2 from this list. Unfortunately the only fix I know for this is by modifying some keys in your registry. There is a Microsoft Support article (187498) herewhich describes the following registry modifications.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\Multi-Protocol Unified Hello\Server]
What is happening here is that you are explicitly turning off PCT 1.0, SSL 2.0 and explicitly turning on SSL 3.0, TLS 1.0.
Running the report again on http://www.serversniff.net/sslcheck.php should present results something like below:
Right, now lets get rid of those weak ciphers.
Weak Supported SSL Ciphers Suites - The remote service supports the use of weak SSL ciphers
Again, another hard hitting description may be given - “The remote host supports the use of SSL ciphers that offer either weak encryption or no encryption at all”
OK. Here’s registry fix number 2.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168]
This time we are explicity turning off the ciphers identified in the Network Vulnerability report, leaving only the strong ones switched on.
Running the http://www.serversniff.net/sslcheck.php report again shows a completely new picture:
NOTE: I do hope this post helps you out but please note that I do not accept any responsibility for your actions. This post details what worked for me, YMMV. Take care, Backup first, and don’t blame me if it goes pear shaped. As Microsoft Support says :
Important This post contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows
DotNetOpenAuth, previously named DotNetOpenID, is getting so close to it’s next major release 3.0. Beta 2 sees a massive security review being completed and testing of the complete library of OAuth and OpenID protocols for .Net.
Major enhancements since beta 1:
- Much more stable
- Classic ASP support
- Tamper protection of callback arguments
- ASP.NET State Server and other serialized session stores support
Check out the version changes page on our wiki for a complete list.
You can download Beta 2 from Google Code and Ohloh.
Please leave feedback on the new version here as a comment or at the firstname.lastname@example.org mailing list. Questions? Send them to the same mailing list, or post them at StackOverflow.com and tag them with “dotnetopenid”.
So, What’s the story? OASIS…No, Not the band, The Organization for the Advancement of Structured Information Standards have released their draft Information Card specification…or more exactly :
the Identity Metasystem Interoperability specification which prescribes a subset of the mechanisms defined in WS-Trust 1.2, WS-Trust 1.3, WS-SecurityPolicy 1.1, WS-SecurityPolicy 1.2, and WS-MetadataExchange to facilitate the integration of Digital Identity into an interoperable token issuance and consumption framework using the Information Card Model
I’m on my third reading now – nothing quite like reading a spec whilst sitting with a fine sized glass lovely shiraz at two in the afternoon on a rainy Sunday. You to can join me by getting your alcohol of choice and a copy of the specification at
The full announcement is available to view here where you can also find the document and related files.
* I’ve just written “What’s the story” and thanks to my son who’s aged 2 and can’t go to bed without watching 2 episodes, I now have the theme tune of Balamory “What’s the story in Balamory” running around my head.