|
|
| Line 15: |
Line 15: |
| | '''Additional Guidance:''' [https://www.us-cert.gov/ncas/tips/ST18-006 Website Security | US-CERT] | | '''Additional Guidance:''' [https://www.us-cert.gov/ncas/tips/ST18-006 Website Security | US-CERT] |
| | <br><br> | | <br><br> |
| − |
| |
| − | ===HTTP/2===
| |
| − | HTTP/2 (finalized in 2015) is a backwards-compatible update to HTTP/1.1 (finalized in 1999) that is optimized for the modern web.
| |
| − |
| |
| − | HTTP/2 includes many features that can drastically speed up website performance, and emerged from the advancements Google demonstrated with SPDY in 2009.
| |
| − |
| |
| − | While HTTP/2 does not require the use of encryption in its formal spec, every major browser that has implemented HTTP/2 has only implemented support for encrypted connections, and no major browser is working on support for HTTP/2 over unencrypted connections.
| |
| − |
| |
| − | This means that in practice, ''the major performance benefits of HTTP/2 first require the use of HTTPS''.
| |
| − | * [https://http2.github.io/faq/ HTTP/2 Working Group FAQ]
| |
| − | * [https://tools.ietf.org/html/rfc7540 RFC 7540], the final spec
| |
| − | <br>
| |
| − |
| |
| − | ===Next Steps: TLS 1.3===
| |
| − | TLS 1.3 differs from TLS 1.2 and earlier versions of TLS in several substantial ways, in addition to the cipher suite changes; these changes result in it not being directly compatible with the earlier versions of TLS. The following is a list of the major functional differences between TLS 1.2 and TLS 1.3. It is not intended to be exhaustive and there are many minor differences. <ref>Internet Engineering Task Force (IETF) TLS 1.3 Internet-Draft</ref>
| |
| − | <br />
| |
| − | * The list of supported symmetric algorithms has been pruned of all algorithms that are considered legacy. Those that remain all use Authenticated Encryption with Associated Data (AEAD) algorithms. The ciphersuite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with the key derivation function and HMAC.
| |
| − | * A 0-RTT mode was added, saving a round-trip at connection setup for some application data, at the cost of certain security properties.
| |
| − | * Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
| |
| − | * All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtension message allows various extensions previously sent in clear in the ServerHello to also enjoy confidentiality protection from active attackers.
| |
| − | * The key derivation functions have been re-designed. The new design allows easier analysis by cryptographers due to their improved key separation properties. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.
| |
| − | * The handshake state machine has been significantly restructured to be more consistent and to remove superfluous messages such as ChangeCipherSpec (except when needed for middlebox compatibility).
| |
| − | * Elliptic curve algorithms are now in the base spec and new signature algorithms, such as ed25519 and ed448, are included. TLS 1.3 removed point format negotiation in favor of a single point format for each curve.
| |
| − | * Other cryptographic improvements including the removal of compression and custom DHE groups, changing the RSA padding to use RSASSA-PSS, and the removal of DSA.
| |
| − | * The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation.
| |
| − | * Session resumption with and without server-side state as well as the PSK-based ciphersuites of earlier TLS versions have been replaced by a single new PSK exchange.
| |
| − | * Updated references to point to the updated versions of RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280).
| |
| − | <br />
| |
| − | For a complete list of major differences, see the [https://tools.ietf.org/html/draft-ietf-tls-tls13-28 Transport Layer Security (TLS) Protocol Version 1.3 specification], section 1.3.
| |
| − | <br />
| |
Additional Considerations of HTTPS
Website Security
To protect GC electronic networks, devices and information, the following is a non-exhaustive list of security considerations that can be implemented in a layered manner to support a defence-in-depth approach for web services and minimize opportunities for cyber attacks:
- Deploy modern operating systems (OS) and applications that are maintained with supported, up-to-date, and tested versions of software.
- Actively manage software vulnerabilities, including fixing known vulnerabilities quickly following a timely patch maintenance policy for OS and applications, and taking other mitigating steps, where patches can’t be applied.
- Implement appropriate host-based protections to protect systems against both known and unknown malicious activity.
- Minimize available services and control connectivity by removing or disabling all non-essential ports and services as well as removing unnecessary accounts from systems.
- Enable system logging to improve the ability to detect and identify anomalous behaviours, perform system monitoring, and to assist with incident response and forensic analysis of compromised systems.
- Carefully control and manage privileges assigned to users and administrators. Provide a reasonable (but minimal) level of system privileges and rights needed for their role.
- Use strong authentication mechanisms (for example, multi-factor authentication) where possible to protect from unauthorized access.
- Design web services so that they are protected from common security vulnerabilities such as SQL injection and others described in widely-used publications such as the Open Web Application Security * Project (OWASP) Top 10.
For more information on best practices, refer to Communications Security Establishment’s (CSE’s) IT security advice and guidance.
Additional Guidance: Website Security | US-CERT
