This is the web server's openssl cipher configuration:

SSLCipherSuite "HIGH+EDH+AESGCM:HIGH+EECDH+AESGCM:HIGH+EDH:HIGH+EECDH:+SHA256:-TLSv1:-SHA:!SEED:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:@STRENGTH:+TLSv1:+SSLv3:+SSLv2:EDH+RC4:EECDH+RC4"My goals are to only support cipher suites incorporating ephemeral key agreement, give a strong preference to TLSv1.2 (and higher), and offer RC4 for TLSv1.0 and SSLv3 clients (also as long as they support ephemeral key agreement). I was inspired to dig into OpenSSL's cipher list from this other page.

The list of cipher suites starts off empty, and the SSLCipherSuite string is interpretted left-to-right to add, remove, and rearrange the list.

- HIGH+EDH+AESGCM

Start the list with only cipher suites that OpenSSL considers "high", use authenticated ephemeral Diffie Hellman (DH) key agreement, and incorporate AES-GCM. - HIGH+EECDH+AESGCM

Next, append cipher suites that OpenSSL considers "high", use authenticated ephemeral Elliptic Curve Diffie Hellman (ECDH) key agreement, and incorporate AES-GCM. - HIGH+EDH

Now append the rest of the "high" suites using ephemeral DH that weren't already pulled in via HIGH+EDH+AESGCM. - HIGH+EECDH

And append the rest of the "high" suites using ephemeral ECDH that weren't already pulled in via HIGH+EECDH+AESGCM. - +SHA256

Move cipher suites using SHA256 to the end of the list (least preferred). (At this point, the list only includes suites incorporating SHA384 and SHA256.) - -TLSv1

BEAST countermeasure: Remove any TLSv1 (or older) suites, but don't ban them completely. Later, we'll pull in RC4 suites (with ephemeral DH and ECDH key agreement) for TLSv1 & SSLv3 clients. - -SHA

- !SEED:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

Ban these, and don't let them come back in. In theory, we could put these ! rules anywhere in the SSLCipherSuite string. - @STRENGTH

Sort the current cipher suites by their encryption key sizes, with the biggest keys first. - +TLSv1:+SSLv3:+SSLv2

Then move TLSv1 suites to the end. And after that, move SSLv3 suites. And after those, move the SSLv2 suites. (Actually at this point, we don't have any TLSv1 or lesser suites, because of the -TLSv1 and -SHA rules above. But I leave this rule in so that if I ever did want to include older suites, these rules will ensure they're placed at the end.) Note: In my current version of OpenSSL, the TLSv1 and SSLv3 lists are identical. Also, while SSLv2 is listed in "man ciphers", running "openssl ciphers -V 'SSLv2'" returns nothing. - EDH+RC4:EECDH+RC4

Begrudgingly include RC4 suites, but only those suites that include ephemeral DH or ephemeral ECDH.

tensor(pts/0):/etc/apache2> openssl ciphers -V 'HIGH+EDH+AESGCM:HIGH+EECDH+AESGCM:HIGH+EDH:HIGH+EECDH:+SHA256:-TLSv1:-SHA:!SEED:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:@STRENGTH:+TLSv1:+SSLv3:+SSLv2:EDH+RC4:EECDH+RC4' 0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD 0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 0xC0,0x11 - ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 0xC0,0x07 - ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 tensor(pts/0):/etc/apache2> openssl ciphers 'HIGH+EDH+AESGCM:HIGH+EECDH+AESGCM:HIGH+EDH:HIGH+EECDH:+SHA256:-TLSv1:-SHA:!SEED:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:@STRENGTH:+TLSv1:+SSLv3:+SSLv2:EDH+RC4:EECDH+RC4' DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA tensor(pts/0):/etc/apache2>

Note: I'm still slightly wary of Elliptic Curve's, so I don't mind that the slightly slower EDH suites are listed before EECDH suites, within each grouping of encryption key size and hash size. My simple rationale is if EC's are faster to compute, then they're also faster to brute-force.

At the moment (2014-08-01), the web server scores an A+ according to https://www.ssllabs.com/ssltest/analyze.html?d=ad5ey.net with the caveat that I don't care to support ancient operating systems such as Windows XP.

Yep, I've had my domains "DNSSEC-ified" for a few years now, so adding DANE wasn't too painful. For background, for those of us that are wary of the huge vulnerability due to SSL/TLS clients trusting too many different Certificate Authorities, DANE is the spec for providing hashes (or whole copies...) of your SSL/TLS certificates in your DNSSEC zones.

Though the standard gives sites the option of using CA-signed or self-signed certificates, I've used flags in my TLSA records indicating my CA-signed certificates should be trusted even without CA verification as long as the records are validated via DNSSEC.