Who is Eligible?
Active Faculty or Staff
Protocol
For protocols, TLS is the current standard. Preferably the use of TLSv1.2 which adds some newer ciphers.
SSL is no longer considered secure and MUST NOT be used in a secure context. This is typically disabled by default with anything modern, and it should be kept that way. This includes SSLv2 and SSLv3. POODLE leaves us with recommendation to disable SSL. See: CVE-2014-3556
TLS as a whole is considered secure. However there are known attacks on version(s) of the protocol. Avoid versions of the protocols(when possible) or configuration required for the exploit to be used.
TLS 1.0 although not completely weak is discouraged where possible. Some clients require it for compatibility(Source: ssl labs ):
- IE8 on XP
- IE7 on Vista
- IE 10 on Windows 7
- Android 4.3
- IE Mobile 10 / WIn Phone 8.0
- Java 7u25
- Safari 5.1.9 for OSX 10.6.8
- Safari 6.0.4 for OS X 10.8.4
Key Exchange
The key exchange is the method to share the secret key for the encryption. This key is usually for a symmetric cipher of some sort e.g. Symmetric key encryption is faster and requires smaller keys than its asymmetric brethren.
When considering key exchanges the import metrics to consider are:
- Perfect Forward Secrecy
-
If the PKI private key is compromised, a future observer will not be able to decrypt past messages. It extends further so that if even 1 message is compromised, the other messages should not be. See: PFS
-
Overhead & scalability
- A base overhead in the TLS session may be added to negotiate keys. This can become relevant in systems serving 100's of newly established connections.
- Support
- This is always important. We must include enough key exchanges so that the major browsers that UTS supports can connect securely.
Currently the best exchange(security wise) is the ECDHE, i.e. Elliptic Curve Diffie-Hellman with Ephemeral keys, this is due to perfect forward secrecy and its low overhead. ECDHE is supported by all modern browsers in use on the internet. Consider whether the suite's are enabled by default and support the Identity Authentication, i.e. if ECDHE only exists coupled with ECDSA you can't use it with an RSA certificate.
We also include the DHE ciphers for their Perfect Forward Security. This is significantly slower than ECDHE however, and can be disabled in some cases. Diffie-Hellman and its ephemeral form were an order of 2.5-3.1x slower than traditional RSA or the new ECDHE during Key exchange. That makes these Key exchanges less preferable, but not necessarily a big problem if sessions are typically resumed. Source: SSL/TLS & Perfect Forward Secrecy by Vincent Bernat.
Note: DHE ciphers are insecure with default keys less than 2048 bits known as LOGJAM, SEE : CVE-2015-4000. An example of this failure is in the Java 7 JSSE implementation.
Diffie-Hellman without ephemeral keys has no perfect forward secrecy, and is also a very slow exchange compared to ECDH,ECDHE, and RSA. Although DH and ECDH Key exchanges are not insecure, DH and ECDH require a DH certificate; Therefore they cannot typically be used under our current infrastructure. See: RFC 4346 Section 7.4.3 or RFC 5246 Section 7.4.3.
RSA is a simple key exchange that does not provide perfect forward secrecy. It is the fastest of the listed key exchanges, and is one of the older choices. This can be included by default until RSA is broken. This requires that the server's private key not be compromised, if it is then all recorded conversations will be compromised.
Important: Disable any cipher suites with Anonymous Key Exchanges.
Do not Use in a client – server environment:
- PSK (Pre-Shared Keys)
- SRP (Secure Remote Password)
Identity Authentication
This is the method with which the server/client is verified. In a typical use case only the server is verified. Messages between client and server are signed with a public key or private key to verify message and sender authenticity. This is meant to prevent some forms of Man In the Middle Attacks and tampering of message content.
DSA is insecure at 1024 bits and under. Also, with a broken PRNG, or improper implementation, DSA will fail quickly. DSA by specification is meant to only use 1024 bit keys and is thus problematic to expand, See: RFC 2536.
ECDSA also fails in the same manner as DSA concerning PRNGs. ECDSA delivers more security for less bits. ECDSA requires 160 bits for approximately 80 bits of security. ECDSA is much less common than RSA.
KRB5 authentication requires a client to present a certificate as well as the server. This type of authentication is infeasible for general client to server authentication, but is plausible for our internal server to server. Cipher suites offered with KRB5 may force a removal of all KRB5 cipher suites.
Encryption
The encryption of messages is handled via a cipher. Cipher's are how data is hidden from public eyes and these are usually faster than the algorithm used to encrypt the initial Key Exchange, e.g. RSA or DSA. This is where the Key that was exchanged is used. The cipher is faster than RSA/DSA because it can use a singular smaller key, as opposed to public/private key pairs which now require sizes of no less than 2048 bits.
The following cipher modes SHOULD NOT be used due to providing little to no security:
Concerning CBC mode and the BEAST attack: Originally it was recommended to switch to RC4 ciphers, however that is considered to be more insecure than maintaining CBC ciphers. BEAST is an active attack and relies on the client not having a patched client that mitigates this attack, e.g. Safari on Mountain Lion BEAST Mitigations in Mavericks. The common correction that combats this issue is known as the 1/n-1 split, See: Imperial Violet: BEAST Follow Up. Because clients have already mitigated this in modern browsers, it is not necessarily insecure to offer CBC mode ciphers.
The following ciphers are vulnerable and therefore SHOULD NOT be used:
SEED and Camellia are not broken ciphers, however support in major browsers is questionable. SEED is the South Korean standard typically used through Active X controls. Camellia is the Japanese equivalent of AES and provides similar performance and security. Neither of these ciphers need to be disabled, but enabling them does not necessarily contribute to significant gain. When in doubt disable these ciphers.
Optional Inclusion:
- SEED (South Korean support)
- CAMELLIA (Japanese support)
Neither SEED nor Camellia is considered insecure, and in fact Camellia is considered to be on par with AES in every regard security wise. SEED is a 128 bit cipher and as such may be disable to enforce higher security requirements but CAMELLIA has 128,192,256 ciphers like AES.
3DES is not insecure but the 192 and 128 variants do not supply the advertised strengths. This is because Key Option 2 reuses Key 1 as Key 3, each 64 bit key loses 8 bits to parity, shrinking the effective security to 112 bits. Furthermore, there are some plain-text attacks lowering security to 80 bits, see: NIST Mar 2007. Key Option 1 can supply approximately the same amount of security as Key-option 2 because of the “Meet in the middle attack” where it takes 2112 + 256 attempts. Only use 3DES with Key Option 1, i.e. 192 or 168, sometimes referred to as 3TDEA. Further TDES documentation from NIST can be found here.
Of the ciphers that we use the preferences are AES-GCM OR ChaCha20-Poly1305 -> AES-CBC -> 3DES. 3DES is not completely compromised yet so it is fine to be present, but should be phased out. No modern browsers(see the list of exceptions) REQUIRE 3DES as they typically have an AES replacement. ChaCha20 is not supported in all major browsers yet, thus that alone is not enough for server side ciphers.
Browsers requiring 3DES (Source: ssl labs ):
Message Authentication Code
This is the method for which a message is verified for authenticity. It is a method to confirm that a message has not been tampered with and utilizes a Hashing function. These hashing functions may be more secure than their standard counterpart, such as HMAC, however it is important to remove broken hashing functions. An example is the MD5 hashing algorithm: it is known to have collision attacks and as such should be removed although the cipher implementations are more secure.
MAC algorithms to not use:
MAC algorithms to avoid when possible:
Removing SHA1 cipher suites may not be feasible for maintaining compatibility. If the information must be encrypted to a higher standard however, then absolutely remove the SHA1 algorithms.
Recommendations
This section contains the above information into table(s) for quick reference. For detailed explanation see the above sections.
Protocol
|
Protocol Rules
|
|
Protocol
|
Use
|
|
SSLv2
|
NO
|
|
SSLv3
|
NO
|
|
TLSv1
|
MAYBE(For Compatibility)
|
|
TLSv1.1
|
YES
|
|
TLSv1.2
|
YES
|
Key Exchange
The Key Exchange is the method the method of exchanging the cipher's key. This typically immediately follows the protocol in a cipher suite: e.g. TLS_DHE_RSA... means DHE is Key exchange. Occasionally Key Exchange and Authentication fields are combined, such as in the case of TLS_RSA_WITH... where Kx and Auth are both RSA.
Ordered by Rank
|
Key Exchange
|
|
Exchange Algorithm
|
Usable
|
|
ECDHE
|
YES
|
|
DHE
|
YES
|
|
RSA
|
YES
|
|
ECDH
|
MAYBE; Requires Special Cert
|
|
DH
|
MAYBE; Requires Special Cert
|
|
KRB5
|
MAYBE; Requires Client Cert
|
|
PSK
|
NO
|
|
SRP
|
NO
|
Identity Authentication
This lists acceptable authentication methods. This is Identity authentication. This is typically the third field in a cipher Suite: e.g. TLS_ECDHE_ECDSA... where ECDSA is Authentication method. Sometimes this field is combined with Key Exchange because they are both the same, e.g.: TLS_RSA_WITH... where RSA is Kx and Auth.
In Order Of Preference:
|
Identity Authentication
|
|
Algorithm
|
Usable
|
Cert Key Size
|
|
RSA
|
YES
|
>= 2048
|
|
ECDSA
|
YES
|
>= 256
|
|
DSA
|
MAYBE(Key Sizes > 1024 is out of RFC)
|
>= 2048
|
|
KRB5
|
MAYBE
|
?
|
Cipher
This lists Ciphers that we can use; Ciphers are denoted in the section right after the WITH in a cipher suite: e.g. TLS_RSA_WITH_AES... means AES is the cipher.
|
Cipher (Encryption)
|
|
Cipher
|
Use
|
Required Key Size (bits)
|
|
RC4
|
NO
|
X
|
|
3DES
|
MAYBE(Key Option 1 only)
|
168
|
|
AES-CBC
|
YES
|
128, 192, 256
|
|
AES-GCM
|
YES
|
128, 192, 256
|
|
DES
|
NO
|
X
|
|
Camellia
|
YES
|
>= 128
|
|
RC2
|
NO
|
X
|
|
SEED
|
YES
|
128
|
|
IDEA
|
MAYBE
|
>= 128
|
|
NULL
|
NO
|
X
|
Message Authentication Code
This lists MACs that we can use; They are typically denoted last in a Cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA where SHA is the MAC.
Ordered by preference:
|
MAC
|
|
Exchange Algorithm
|
Usable
|
|
SHA512
|
YES
|
|
SHA384
|
YES
|
|
SHA256
|
YES
|
|
SHA
|
MAYBE(For Compatibility Only)
|
|
MD5
|
NO
|
|
MD4
|
NO
|
|
MD2
|
NO
|
Additional Support
- OU Technology Center
- 44 Oakland Center
- Rochester, MI 48309-4479
- (248) 370-4357
- Office Hours: M-F 8:00am - 5:00pm