SURFconext policy mandates the use of HTTPS URLs on all protocol endpoints. This means the use of TLS for protecting the communication between clients (a user's browser) and servers (a web server hosting IdP or SP software). This document contains a checklist for the correct configuration of such servers. Web server administrators are urged to use this checklist to assess the security of their TLS configuration, as insecure configurations can lead to problems like phishing attacks and disclosure of privacy-sensitive user information.

If you would like to test your server for configuration issues, you can use the Qualys SSL labs server test at: https://www.ssllabs.com/ssltest/. As a rule of thumb, it should have at least a "B" rating on SSLLabs.com (but preferably better, of course). For practical documentation on using openssl-based software, see https://www.feistyduck.com/books/openssl-cookbook/ or the page outlining SSL and TLS Deployment Best Practices. For other software, you can refer to the book https://www.feistyduck.com/books/bulletproof-ssl-tls-and-pki/. Practical configuration examples can be found in a separate blog post.

There are many Certification Authorities (CA's) available. If you are a customer of SURF (or another European NREN), you can use the GÉANT Trusted Certificate Service for obtaining server certificates at a flat fee.

Please note that

The checklist is divided into four sections and uses terminology from RFC 2119 to indicate requirement levels:

Keys

When generating keys for your certificate, you MUST make sure that:

Certificates

 When obtaining an X.509 certificate for your server, you MUST make sure that:

Furthermore, you SHOULD:

Use Secure Protocols

Currently there are five protocols in the SSL/TLS family: SSL v2, SSL v3, TLS v1.0, TLS v1.1, and TLS v1.2. When configuring your server with a list of acceptable SSL/TLS protocol versions, you MUST:
  • Upgrade your server if it does not support TLS v1.2. Upgrade your platform as soon as possible if this is the case. TLS v1.2 or TLS v1.3 should be your main protocol because these versions offer modern authenticated encryption (also known as AEAD). If you don't support TLS v1.2 or TLS v1.3 today, your security is lacking.
  • disable the insecure SSLv2 protocol
    • SSL v2 is insecure and must not be used. This protocol version is so bad that it can be used to attack RSA keys and sites with the same name even if they are on an entirely different servers (the DROWN attack).
  • disable the insecure SSLv3 protocol (only a problem for clients running IE6 on Windows XP - which is EOL)
    • SSL v3 is insecure when used with HTTP (the POODLE attack) and weak when used with other protocols. It’s also obsolete and shouldn’t be used.
  • disable TLS v1.0
    • TLS v1.0 is a legacy protocol that shouldn't be used. Its major weakness (BEAST) has been mitigated in modern browsers, but other problems remain. Browser support for TLS v1.0 and TLS v1.1 will be dropped January 2020. Stop supporting older clients as you need to continue to support TLS v1.0 and TLS v1.1 for this. Retire TLS v1.0.
  • disable TLS v1.1. See the remarks about TLS 1.0 above. Browser support for TLS v1.1 will be dropped dropped January 2020. TLS 1.1 should also be retired.
  • disable compression.
    • The 2012 CRIME attack showed that TLS compression can't be implemented securely. The only solution was to disable TLS compression altogether.
  • disable CBC Ciphers
    • Vulnerabilities like Zombie POODLE, GOLDENDOODLE, 0-Length OpenSSL and Sleeping POODLE were published for websites that use CBC (Cipher Block Chaining) block cipher modes. These vulnerabilities are applicable only if the server uses TLS 1.2 or TLS 1.1 or TLS 1.0 with CBC cipher modes.
    • For clients on Windows 7, upgrade to browsers that support recent ciphers. If you still have Windows 7 in use, take note that support will be dropped by Microsoft January 14, 2020.

Furthermore, you SHOULD:

  • enable the TLS protocol v1.2 and TLS v1.3. Currently these are both without known security issues.
    • Although relativly new TLS v1.3 has some benefits. The performance is improved as is the latency. It has an improved security and obsolete/insecure features like cipher suites, compression etc are removed.
  • enable Forward secrecy
    • Forward secrecy (sometimes also called perfect forward secrecy) is a protocol feature that enables secure conversations that are not dependent on the server’s private key. With cipher suites that do not provide forward secrecy, someone who can recover a server’s private key can decrypt all earlier recorded encrypted conversations. You need to support and prefer ECDHE suites in order to enable forward secrecy with modern web browsers. To support a wider range of clients, you should also use DHE suites as fallback after ECDHE. Avoid the RSA key exchange unless absolutely necessary.
  • Deploy HTTP Strict Transport Security.
    • HTTP Strict Transport Security (HSTS) is a safety net for TLS. It was designed to ensure that security remains intact even in the case of configuration problems and implementation errors.
  • Encrypt Everything

Ciphers

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

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.