What a programmer should know before their web service's client audit

Question

Situation: I have created a WS client (.net wcf) for the customer that access a third party web service (Websphere). This WS uses HTTPS and I get a certificate from WS vendor. All works fine, I have delivered WS client to customer, customer have ordered their certificate... but suddenly I got mail from customer's security auditor where he asking me about things that I don't understand why he is interesting. So I fill unprepared for such story twist.

If I will understand the goal of security auditor than I will understand what he really want. He is asking about 1) what is the minimal protocol level that supports WS (SSLv2 or SSLv3) requirement? 2) what is the minimal length of the key 128 or 256 bits?

I have heard about SSL rollback attack but this should be interesting for WS admin, not for WS client network security auditor... Why WS client's user could be interesting in those things? May be there are firewall settings that he should adjust?

Answer 1

Security should be ensured on both client and server sides. Because in case of Man In The Middle attack someone can push client to use weak ciphers, like in SSH downgrade attack: http://sites.google.com/site/clickdeathsquad/Home/cds-ssh-mitmdowngrade

I don't know much about WCF but it seems like from within program you can only specify SSL or TLs in ServicePointManager.SecurityProtocol.

Seem like if application is using Microsoft Crypto API the only way to restrict SSL/TLS to use to certain ciphers is to make change to whole system as described in http://support.microsoft.com/kb/245030

And WCF is using MS Crypto API: http://msdn.microsoft.com/en-us/library/ms733806.aspx (if program is not using custom certificate validator)

Answer 2

From what you have said, this would appear to be a common audit issue that would be raised from a compliance based approach to security.

I would expect that the security auditor is looking to identify if your new implementation supports weak SSL cyphers and therefore raise a risk based on this.

If your customer has a PCI/DSS requirement then the audit may look to confirm the following:

PCI DSS Requirements
4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.

For more information, OWASP has a good deal of information on this and advise -

Only Support Strong Cryptographic Ciphers The strength of the encryption used within a TLS session is determined by the encryption cipher negotiated between the server and the browser. In order to ensure that only strong cryptographic ciphers are selected the server must be modified to disable the use of weak ciphers. It is recommended to configure the server to only support strong ciphers and to use sufficiently large key sizes.