Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm trying to work out the best approach to choosing which cipher suites to provide, and what the issues might be.

It's my understanding that during the SSL handshake, the client will (normally) choose the most secure algorithms which are supported by both ends. But what are the implications of making low strength algorithms available? The negotiation surely cannot be encrypted, therefore could a MITM force a connection to the weakest common cipher suite?

share|improve this question
add comment

2 Answers 2

up vote 6 down vote accepted

The client suggests but the server chooses. The client sends a list of the cipher suites that it supports (and is willing to use). This list is supposed to be ordered by preference. The server responds by choosing one cipher suite in this list. Well-behaved servers try to follow the preferences of clients, but that's not really mandatory. Ultimately, the server chooses.

At the end of the handshake, Finished messages are sent, which are encrypted and MACed with the negotiated secrets. The contents of these messages are hash values computed over the complete handshake messages, including the list of cipher suites supported by the client. This means that a MitM cannot alter that list without being caught at some point.

(However, this is not entirely true in the presence of TLS FalseStart: the client could be convinced to send his request with the weakest cipher suite that it supports. But the real weakness here would be that the client is then willing to support a weak cipher suite, not that a MitM attacker has some level of control in the choice of the cipher suite. Even with FalseStart, the external alteration by the attacker will be detected by the server and the request will not be honoured, let alone responded to.)

(SSLv2 did not include the list of cipher suites in its Finished messages and it has been much touted as one of the "big flaws" of SSLv2.)

share|improve this answer
add comment

If you are concerned with resource usage and you do not have AES-NI enabled CPU along with supported software, use RC4. Google uses RC4 for most if not all services. If you have AES-NI support all along the hardware and software chain, then use AES-256.

share|improve this answer
1  
I should hve mentioned that the availability of hardware is not really a constraint. I know how to probe what other sites are using - but I'd prefer to make informed choices rather than just copying them. –  symcbean Sep 11 '12 at 20:43
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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