(PUP-2177) Change Crypto Spec in accordance to bettercrypto.org

We provide an Apache vhost configuration for users that want to run a
Puppet master using Apache and Passenger. The configuration was added in
d85d73c (five years ago, roughly) and set the SSLProtocol and
SSLCipherSuite directives using the assumptions about cryptography at
the time. As part of PUP-2582 commit 05af20b70 updated the SSL cipher
suite and protocol settings to remove some of the most vulnerable
ciphers, but still contained some relaxed settings to ensure
compatibility with as many platforms as possible.

-- Summary

This commit updates the SSLProtocol and SSLCipherSuite directives to
ensure we only use secure ciphers while continuing to function on all
supported platforms. The most notable difference is that this change
switches the cipher selection from a blacklist where all ciphers are
added and then selectively removed, to a whitelist where only known safe
ciphers are allowed. The cipher suite has been selected using the
guidelines laid out by the Applied Crypto Hardening paper[0].

-- Overall cipher selection

This cipher suite was chosen by selecting for the following criteria:

  * TLS 1.0, 1.1, 1.2
  * Perfect forward secrecy/ephemeral Diffie Hellman where possible
  * Preferring strong MACs (SHA-2) where possible
  * GCM as the authenticated encryption scheme where possible
  * Always falling back to reasonably acceptable schemes for maximum
    platform compatibility

The resulting cipher suite has the following implications:

TLSv1.2 is preferred over TLSv1.0, but is still provides reasonable
ciphers with TLSv1.0.

-- Key exchange

Ephemeral Diffie Hellman and Ephemeral Elliptic Curve Diffie Hellman are
used for key exchange. EDH is preferred over EECDH due to ongoing
concerns with potential weaknesses in elliptic curve cryptography, but
is still included due to the performance benefits of EECDH over EDH.[1]
Non-ephemeral Diffie Hellman is not used to ensure perfect forward
secrecy. If EDH or EECDH are not available, key exchange will be done
using RSA for compatibility with legacy SSL libraries.

-- Authentication

RSA is used for authentication as it works in most of today's setups and
modern implementations are resistant to attack for the foreseeable future.

-- Encryption

AES256 and CAMELLIA256 count as very strong ciphers at the moment, but
if these algorithms are not available then AES128 or CAMELLIA128 will be
used as fallbacks since they are still reasonably strong. CAMELLIA is
preferred over AES due to the decision by NSS to prefer CAMELLIA, with
the following rationale:

    National ciphers such as Camellia are listed before international ciphers
    such as AES and RC4 to allow servers that prefer Camellia to be able to
    negotiate Camellia without having to disable AES and RC4, which are needed
    for interoperability with clients that don't yet implement Camellia.[2]

-- Message Authentication (MAC)

Message authentication prefers AEAD with GCM, and then falls back to
SHA256. If ECDHE is used SHA384 will be used when available. If no
better option is available SHA1 will be used.

-- Fallback

When no better cipher is available, CAMELLIA128-SHA and then AES128-SHA
(with RSA for authentication) will be used, for cases such as OpenSSL
0.9.8 which does not provide support for ECC and TLSv1.1 or above.

-- Blacklisted algorithms

On top of the algorithms blacklisted in 05af20b7, ECDSA has been
disabled due to outstanding concerns about weaknesses to cache timing
attacks.[3]

[0] "Applied Crypto Hardening": https://bettercrypto.org/static/applied-crypto-hardening.pdf
[1] "A Note on Elliptic Curve Cryptography" "Applied Crypto Hardening section 3.7"
[2] "Document the policy for the order of cipher suites in SSL_ImplementedCiphers.": https://bugzilla.mozilla.org/show_bug.cgi?id=430875
[3] "How to design an elliptic-curve signature system" http://blog.cr.yp.to/20140323-ecdsa.html

Thanks to Aaron Zauner <azet@azet.org> and bettercrypto.org for
generating and submitting the updated cipher suite.