The best option you have is
This is likely to provide most security, as the AES keylength is maximal and ECDSA keys tend to provide more security than RSA keys, as a 128-bit security level is quite common with ECDSA (field size: 256 bit) whereas 112-bit is the standard with RSA (keylength: 2048 bit).
However in practice
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA may be easier to deploy as RSA certificates are usually a lot cheaper and easier to get.
To get even further you're also fine with
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as a 128-bit key is quite common today and chances are your ECDH group also provides "only" 128-bit security, meaning you can get higher speed without sacrificing security.
As explained in the comments by CodesInChaos you should definitely avoid RC4, which is also officially banned from TLS as per RFC 7465. To repeat what CodesInChaos said:
The CBC-suites are less an issue than RC4 because ...
- modern browsers mitiagate BEAST (CBC-based attack) even on TLS 1.0
- BEAST is an active attack, whereas RC4 already falls due to passive attacks
- BEAST is hard to exploit in practice and relevant features seem to have been removed.
This removes the
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA ciphersuites from the list. You should also avoid 3DES, as it provides "only" 112-bit security, but is significantly slower than AES making it inferior in every aspect, so you shouldn't choose
However, if possible you should migrate to TLS v1.2 (or newer). There you should avoid all cipher suites not finishing with
_SHA384 as the other ones use SHA-1 which is deprecated. Furthermore TLS v1.2 (or newer) allows (v1.3 will force) you to use non-CBC mode ciphers, especially AEAD ciphers, which don't suffer from BEAST or similar attacks. This means that as of now the best choice (in terms of security) for the cipher suite is
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 not being a lot weaker. If possible you should prefer ECDSA (or EdDSA) over RSA although RSA can be sufficiently secure when using appropriate keylengths.