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 (third party), not for WS client network security auditor (my client)... Why WS client's user could be interesting in those things? May be there are firewall settings that he should adjust?

  • Can you share the way you configured SSL for both Webservices at Websphere and .NET client? Thanks!!! – user5396 Oct 12 '11 at 1:27

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)

  • I like this answer since the fact that through registries is possible to restrict some type of connections explain auditor's questions. Even if I'm not sure that Schannel.dll is used there may be are other ways to restrict client app behavior. I'm satisfied just to come to hear that such practice exists... BTW, as I understand "Man In The Middle" together with SSH downgrade/rollback attack is still possible. – Roman Pokrovskij Jan 25 '11 at 12:41

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.

  • 1
    WTF? If the policy on the server does not allow certain types of cipher to be used then the server admin should disable those ciphers – symcbean Jan 24 '11 at 12:23
  • 1
    @symcbean - you would hope so, but many organisations keep them for purposes of backwards compatibility! An audit nightmare. – Rory Alsop Jan 24 '11 at 15:04
  • FYI - @symcbean Server policy isn't completely effective. If a cipher is disabled in the registry for MSFT's CryptoAPI, I can just ship my own crypto API (BouncyCastle) that ignores those settings and do what I want anyways. – goodguys_activate Mar 10 '12 at 13:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.