Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Use Secure Cipher Suites. When configuring your server with a list of acceptable ciphers, you MUST:

  • exclusively use ciphers with a key length at least 128bits
  • exclude cipher suites that contain MD5 as its hash algorithm
  • set the cipher suite order on the server if TLS 1.0 is enabled (which you should not).

and understand

  • anonymous Diffie-Hellman (ADH) suites do not provide authentication.
  • NULL cipher suites provide no encryption.
  • export cipher suites are insecure when negotiated in a connection, but they can also be used against a server that prefers stronger suites (the FREAK attack).
  • Suites with weak ciphers (112 bits or less) use encryption that can easily be broken are insecure.
  • RC4 is insecure.
  • 64-bit block cipher (3DES / DES / RC2 / IDEA) are weak.
  • Cipher suites with RSA key exchange are weak i.e. TLS_RSA
Futhermore:
  • Prefer to use AEAD (Authenticated Encryption with Associated Data) cipher suites – CHACHA20_POLY1305, GCM and CCM
  • As well as PFS (Perfect Forward Secrecy) ciphers – ECDHE_RSA, ECDHE_ECDSA, DHE_RSA, DHE_DSS, CECPQ1 and all TLS 1.3 ciphers
  • Use only cipher suites that do not contain RC4 (See also RFC 7465).
  • prefer ciphers in Galois/Counter Mode (GCM) by listing them first
Info
titleSURFdrive client compatability

The SURFdrive clients make use of a built-in browser to login via SURFconext. In order to make use of SURFdrive, the IdP must therefore support at least one of the following cipher suites that are supported by the built-in browser:

  • c02b   ECDHE-ECDSA-AES128-GCM-SHA256
  • c02f    ECDHE-RSA-AES128-GCM-SHA256
  • c02c   ECDHE-ECDSA-AES256-GCM-SHA384
  • c030   ECDHE-RSA-AES256-GCM-SHA384
  • c009   ECDHE-ECDSA-AES128-SHA
  • c013   ECDHE-RSA-AES128-SHA
  • c014   ECDHE-RSA-AES256-SHA
  • 009c   RSA-AES128-GCM-SHA256
  • 002f    ECDHE-RSA-AES128-GCM-SHA256
  • 0035   RSA-AES256-SHA

Use strong Key Exchange

For the key exchange, public sites can typically choose between the classic ephemeral Diffie-Hellman key exchange (DHE) and its elliptic curve variant, ECDHE. There are other key exchange algorithms, but they're generally insecure in one way or another. The RSA key exchange is still very popular, but it doesn't provide forward secrecy.

In 2015, a group of researchers published new attacks against DHE; their work is known as the Logjam attack. The researchers discovered that lower-strength DH key exchanges (e.g., 768 bits) can easily be broken and that some well-known 1,024-bit DH groups can be broken by state agencies. To be on the safe side, if deploying DHE, configure it with at least 2,048 bits of security. Some older clients (e.g., Java 6) might not support this level of strength. For performance reasons, most servers should prefer ECDHE, which is both stronger and faster. The secp256r1 named curve (also known as P-256) is a good choice in this case.

Cookies

You should ensure that all valuable cookies your site uses, have the Secure flag set so they cannot leak to plain http. Also where appropriate, make sure the HttpOnly flag is set.

In Shibboleth, you need to enable this explicitly, like this: <Sessions .. handlerSSL="true" cookieProps="https”>. In simpleSAMLphp, see Securing your simpleSAMLphp setup.

For your own application, it depends on the programming language and framework you use.


...