Title: Removing CBC ciphers specific to SSLv3
Tags: ssl;openssl
Question: I need to disable SSLv3 specific CBC ciphers as a temporary solution to the POODLE vulnerability as there are legacy applications that need to use SSLv3. After consulting the OPENSSL docs, it seems like there are shared ciphers between SSLv3 and TLSV1 such as:
SSL_DHE_RSA_WITH_DES_CBC_SHA
DHE-RSA-DES-CBC-SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
DHE-RSA-DES-CBC-SHA
My question is, is there a way to disable for example, DHE-RSA-DES-CBC-SHA specifically for SSLv3 and will this action effect TLSv1?
I'm using nginx, Varnish and Apache with OPENSSL
Comment: I'm using nginx, Varnish and Apache with OPENSSL

Comment: Could you please provide what platform you're working with?


Here is another answer: The canonical answer is https://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerability and prefers to exclude the protocol SSLv3, not ciphers.
Preliminarily, the two distinct ciphersuites you name use original DES, retronymed single-DES, and are insecure in ALL protocol versions. Original DES was replaced and withdrawn a decade ago. (More exactly FIPS46-3 was superseded by FIPS197 AES in 2001, then withdrawn in 2005, and triple-DEA only, NOT single-DEA, was republished as SP800-67 in 2004 as approved but not standard.) They are classified as LOW in openssl's cipher configuration, and along with EXPORT (even less secure) and eNULL (totally insecure) should never be configured unless you have to deal with a seriously obsolete system that can't be upgraded, replaced, or front-ended, like maybe one of the older Mars landers.
To your question, there aren't really SSLv3-specific CBC ciphers, although there kind of are non-SSLv3 ones. In openssl the configuration of allowed ciphersuites and protocols is separate and nearly independent; AFAICS the only constraints are that ciphers using new TLSv1.2 features (authenticated encryption GCM or SHA-2 hashes) can't be chosen in any older protocol, and a few ciphers used in SSLv2 but not assigned SSLv3+ codes because they were already insecure in 1996 can't be used in SSL3+. Even according to standards, the only differences for ciphers between SSL3 and TLS1 or 1.1 are:
the 40-bit EXPORT ciphers were officially deleted by 1.1 -- but openssl still supports them anyway in 1.1 and 1.2 as an extension. But they were and are insecure and you shouldn't use them unless you time-travel back to the 1990s and are subject to the legal restrictions in some places then.
the Fortezza key-exchange added to appease the USgovt during the &quot;crypto is a weapon&quot; period, and never used by anyone but maybe NSA, was deleted by TLS1. It is not implemented by openssl in any protocol.
the first batch of ECC ciphers in https://www.rfc-editor.org/rfc/rfc4492 officially apply only to TLS1+ because they rely on extensions in the ClientHello and https://www.rfc-editor.org/rfc/rfc3546 for extensions couldn't modify SSL3, but openssl &gt;=1.0.0 (or some 0.9.8 if tweaked) implements them in SSL3 by treating the extensions as defaulting to &quot;no restriction&quot; -- but only if the peer agrees, which peers other than deliberately nobbled recent openssl probably won't. This is the only possibly useful cipher difference. Assuming an RSA cert&amp;privatekey, you could use ECDHE-RSA and hope it only works on TLS1+.
This is why the commandline openssl ciphers -v [$cipherstring] utility shows SSLv3 as the &quot;version&quot; for most ciphers; it means SSLv3 AND UP.
TL-DR: IF your SSL3-only clients don't negotiate ECC ciphers (and most very old clients probably don't although nobbled newer ones may) AND ALL your TLS1+ clients DO (which is much less certain) and assuming the common case of an RSA cert&amp;privatekey, you could enable ECDHE-RSA-(3DES or AES)-CBC but disable DHE-RSA-anything-CBC and RSA-anything-CBC. This also gives you Perfect Forward Secrecy.
If you want you could also enable RC4 for all SSL3+, with PFS or not, but there are concerns there too:
https://security.stackexchange.com/questions/32497/tls-rc4-or-not-rc4
https://crypto.stackexchange.com/questions/10955/which-stream-cipher-can-we-replace-the-rc4-in-the-ssl/
http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx
Are your &quot;legacy applications&quot; web or something else? If web can't you get a half-decent browser? If a custom app can't be caused to repeatedly resend the same sensitive data AFTER attacker data it isn't &quot;biteable&quot; in the first place.

Here is another answer: This configuration should be done in your web server. OpenSSL only allows you to specify ciphers programatically, as said in this SE answer.
Since you said you're using Apache and nginx (web cache Varnish does not support SSL), I found these pages talking about the same matter, although they are directed at BEAST:
Configuring Apache-Nginx and OpenSSL
Hardening Your Webserver's OpenSSL Cipher Suites
This one is about the SSL termination that allows varnish to cache your content:
Very important P.S.:
PS1 - Don't forget to use HSTS
PS2 - Always set the "Secure" flag on cookies generated inside encrypted connections. Forgetting this is a very easy way to leak information to attackers.

{'source': 'StackExchangeDataset', 'subset': 'superuser.com', 'metadata': {'AnswerCount': 2, 'CommentCount': 2, 'ContentLicense': 'CC BY-SA 3.0', 'CreationDate': '2014:00:10/29/14', 'FavoriteCount': None, 'PostTypeId': 1, 'Tags': '<ssl><openssl>', 'Title': 'Removing CBC ciphers specific to SSLv3', 'ViewCount': 2165, 'id': 833814, 'user_AboutMe': None, 'user_AccountId': None, 'user_DisplayName': None, 'user_Reputation': None, 'user_Views': None, 'user_id': None}}