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
Certificates
When obtaining an X.509 certificate for your server, you MUST make sure that:
Furthermore, you SHOULD:
Furthermore, you SHOULD:
Ciphers
Use Secure Cipher Suites. When configuring your server with a list of acceptable ciphers, you MUST:
and understand
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.
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.