Confirmed users
529
edits
Security/Server Side TLS: Difference between revisions
Jump to navigation
Jump to search
Version 3.4: ulfr: added note about session resumption, HSTS and HPKP
(Version 3.4: ulfr: added note about session resumption, HSTS and HPKP) |
|||
| Line 11: | Line 11: | ||
|- | |- | ||
| <span style="color:green;">'''READY'''</span> || | | <span style="color:green;">'''READY'''</span> || | ||
* Version 3.4: ulfr: added note about session resumption, HSTS and HPKP | |||
* Version 3.3: ulfr: fix SHA256 prio, add POODLE details, update various templates | * Version 3.3: ulfr: fix SHA256 prio, add POODLE details, update various templates | ||
* Version 3.2: ulfr: Added intermediate compatibility mode, renamed other modes | * Version 3.2: ulfr: Added intermediate compatibility mode, renamed other modes | ||
| Line 60: | Line 61: | ||
* Elliptic curves: '''secp256r1, secp384r1, secp521r1''' (at a minimum) | * Elliptic curves: '''secp256r1, secp384r1, secp521r1''' (at a minimum) | ||
* Certificate signature: '''SHA-256''' | * Certificate signature: '''SHA-256''' | ||
* HSTS: '''max-age=15724800''' | |||
== <span style="color:orange;">'''Intermediate'''</span> compatibility (default) == | == <span style="color:orange;">'''Intermediate'''</span> compatibility (default) == | ||
| Line 220: | Line 222: | ||
... | ... | ||
</pre> | </pre> | ||
= Session Resumption = | |||
Session Resumption is the ability to reuse the session secrets previously negotiated between a client and a server for a new TLS connection. This feature greatly increases the speed establishment of TLS connections after the first handshake, and is very useful for connections that use Perfect Forward Secrecy with a slow handshake like DHE. | |||
Session Resumption can be performed using one of two methods: | |||
# session identifier: When establishing a first session, the server generates an arbitrary session ID sent to the client. On subsequent connections, the client sends the session ID in the CLIENT HELLO message, indicating to the server it wants to reuse an existing state. If the server can find a corresponding state in its local cache, it reuse the session secrets and skips directly to exchanging encrypted data with the client. If the cache stored on the server is compromised, session keys from the cache can be used to decrypt past and future sessions. | |||
# session tickets: Storing a cache on the server might be problematic for systems that handle very large numbers of clients. Session tickets provide an alternative where the server sends the encrypted state (ticket) to the client instead of storing it in its local cache. The client can send back the encrypted state to the server in subsequent connections, thus allowing session resumption. This method requires symmetric keys on the server to encrypt and decrypt session tickets. If the keys are compromised, an attacker obtains access to session keys and can decrypt past and future sessions. | |||
Session resumption is a very useful performance feature of TLS, but also carries a significant amount of risk. Most servers do not purge sessions or ticket keys, thus increasing the risk that a server compromise would leak data from previous (and future) connections. | |||
The current recommendation for web servers is to enable session resumption and benefit from the performance improvement, but to restart servers daily when possible. This ensure that sessions get purged and ticket keys get renewed on a regular basis. | |||
= HSTS: HTTP Strict Transport Security = | |||
[[https://tools.ietf.org/html/rfc6797 HSTS]] is a HTTP header sent by a server to a client, indicating that the current site must only be accessed over HTTPS until expiration of the HSTS value is reached. | |||
The header format is very simple, composed only of a '''max-age''' parameter that indicates when the directive should expire. max-age is expressed in seconds. A typical value is 15724800 seconds, or 6 months. | |||
<pre> | |||
Strict-Transport-Security: max-age=15724800 | |||
</pre> | |||
HSTS is becoming more and more of a standard, but should only be used when the site's operators are confident that HTTPS will be available continuously for the duration of max-age. Once the HSTS header is sent to client, HTTPS cannot be disabled on the site until the last client has expired its HSTS record. | |||
= HPKP: Public Key Pinning Extension for HTTP = | |||
HPKP is an '''experimental''' HTTP header sent by a server to a client, to indicate that some certificates related to the site should be pinned in the client. The client would thus refuse to establish a connection to the server if the pining does not comply. | |||
Due to its experimental nature, HPKP is currently '''not''' recommended on production sites. More informations can be found on the [[https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning MDN description page]]. | |||
= Recommended Server Configurations = | = Recommended Server Configurations = | ||