Page tree
Skip to end of metadata
Go to start of metadata

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 SURFnet (or another European NREN), you can use the GÉANT Trusted Certificate Service for obtaining server certificates at a flat fee.

Please note that

  • this document may become out-of-date whenever new vulnerabilities in the TLS protocol or one of its associated technologies are discovered. If you spot such info, we appreciate a message.
  • we may periodically scan hosts connected to SURFconext for known vulnerabilities in their TLS implementation or configuration.
  • this page deals with TLS configuration of your HTTP server only, similar recommendations hold for SAML Security. See also the OWASP SAML Security Cheat Sheet.

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:

  • your key is generated using a good random number generator.
  • your key is 2048 bits long (when using RSA as the public key algorithm)

Certificates

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

  • The certificate's subject matches the FQDN of the server as listed in its SAML 2.0 metadata.
  • For IdP's, the server's domain name is owned by the SURFconext member organization, and the certificate lists the organization name in its subject organization component (O). This means the certificate is obtained through Organization Validation (OV) or, preferably, Extended Validation (EV). 
  • The certificate is valid. Certificates that have expired cannot be trusted, for example because they are removed from certificate revocation lists. Install procedures to make sure certificates are renewed in time.
  • All hostnames that point to your server are contained in the certificate, either as CN attribute in the certificate's subject DN, or as subjectAlternativeName in the certificates X.509v3 extension.
  • The certificate is trusted by all common browsers by using a well-known Certification Authority (CA), i.e. one that has its root certificate embedded in such browsers.
  • The certificate chain is installed correctly, i.e. all intermediate CA certificates are sent by your server in the TLS handshake, and in the right order.

Furthermore, you SHOULD:

  • prefer a CA that uses a modern signature hash algorithmpreferably from the SHA2 family, instead of the soon obsolete SHA-1 hash algorithm.

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. Start planning an upgrade to your platform as soon as possible if this is the case.
  • 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, but it's typically still necessary in practice. 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 in 2020. In order to support older clients, you may need to continue to support TLS v1.0 and TLS v1.1 for now. However, you should plan to retire TLS v1.0.
  • disable TLS v1.1 if possible. This can be maintained for compatibility with older browsers but think about phasing this out as browser support for TLS v1.0 and TLS v1.1 will be dropped in 2020.
  • 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
  • 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

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

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).
  • RC4 is insecure.
  • 3DES is slow and weak.
You SHOULD:
  • use only cipher suites that do not contain RC4 (See also RFC 7465).
  • prefer ciphers in Galois/Counter Mode (GCM) by listing them first

SURFdrive 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.


  • No labels