Changes

Security/Server Side TLS

9,911 bytes added, 12:05, 19 June 2015

push version 3.7

<tdvalign="top"><div style="float:left;" class="toclimit-3">__TOC__</div></td>

{| class="wikitable"

|-

|}

[[File:OpSec.png|~~right~~center|300px]]

</td>

</tr></table>

* Versions: '''TLSv1, TLSv1.1, TLSv1.2'''

* RSA key size: '''2048'''

* DH Parameter size: '''2048''' (see [[Security/~~Server Side TLS~~Server_Side_TLS#DHE_and_Java|DHE and Java]] for details)

* Elliptic curves: '''secp256r1, secp384r1, secp521r1''' (at a minimum)

* Certificate signature: '''SHA-256'''

* Versions: '''SSLv3, TLSv1, TLSv1.1, TLSv1.2'''

* RSA key size: '''2048'''

* DH Parameter size: '''1024'''(see [[#Pre-defined_DHE_groups|Pre-defined DHE groups]])

* Elliptic curves: '''secp256r1, secp384r1, secp521r1'''

* Certificate signature: '''SHA-1''' (windows XP pre-sp3 is incompatible with sha-256)

</source>

== Pre-defined DHE groups ==

In order to lower the burden of system administrators, several servers provide pre-computed DH groups. Unfortunately, the [[https://weakdh.org|logjam] report showed that it is very likely that a state-level adversary may have broken the most widely used 1024-bit DH group, Oakley group 2, standardized in [[https://tools.ietf.org/html/rfc2409#section-6.2|rfc2409]].

For this reason, the use of this group is considered unsafe and you should either:

* use a larger group, with a minimum size of 2048-bit, as recommended in the intermediate and modern configurations ;

* keep using a 1024-bit DH group if you need to (see [[#DHE_and_Java]]), but move away from Oakley group 2 and use a custom DH group instead, generated via the openssl dhparam 1024 command ;

* disable DHE altogether, relying on ECHDE for PFS if you don't support legacy clients lacking ECDHE support (see [[#DHE_and_ECHDE_support]]).

It is currently assumed that standardized 2048 bits DH groups provide sufficient security to resist factorization attacks. However, the careful administrator should generate a random DH group instead of using a

standardized one when setting up a new server, as advised by the [[https://weakdh.org|logjam]] authors.

== DHE and ECDHE support ==

Most modern clients that support both ECDHE and DHE typically prefer the former, because ECDHE provides faster handshakes than DHE ([[http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html]], [[http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html]]).

Unfortunately, some widely used clients lack support for ECDHE and must then rely on DHE to provide perfect forward secrecy:

* Android < 3.0.0

* Java < 7

* OpenSSL < 1.0.0

Note that schannel on Windows XP technically support DHE, but only with DSA keys, making it unusable on the internet in practice.

== DHE and Java ==

Java 6 and 7 do not support Diffie-Hellman parameters larger than 1024 bits. If your server expects to receive connections from java 6 clients and wants to enable PFS, it must provide a DHE parameter of 1024 bits.

If keeping the compatibility with Java < 7 is a necessity, thus preventing the use of large DH keys, three solutions are available:

* using custom 1024-bit DH parameters, different from Oakley group 2 ;

* if the software used does not support custom DH parameters, like Apache HTTPd < 2.2.30, it is possible to keep using the 1024-bit DH Oakley group 2, knowing these clients will be at risk from a state-level adversary ;

* it is also possible to completely disable DHE. This means that clients not supporting ECDHE will be reverting to static RSA, giving up Forward Secrecy.

The case of Java 7 is a bit different. Java 7 supports ECDHE ciphers, so if the server provides ECDHE and prioritizes it before DHE ciphers using server side ordering, then Java 7 will use ECDHE and not care about the size of the DHE parameter. In this situation, the server can use 2048 bits DHE parameters for all other clients.

PreferServerCipherSuites: true,

CipherSuites: []uint16{

tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,

tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,

tls.~~TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256~~TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, tls.TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,

tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,

tls.TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,

~~tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,~~

~~tls.TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,~~

tls.TLS_RSA_WITH_AES_128_CBC_SHA,

tls.TLS_RSA_WITH_AES_256_CBC_SHA,

tls.TLS_RSA_WITH_3DES_EDE_CBC_SHA},

}

</source>

== F5 BIG-IP ==

BIG-IP uses SSL profiles which may be applied to one or multiple 'virtual servers' (VIPs). SSL profiles may use F5's default recommended cipher suites or may be manually configured to explicitly state which, and in what order, they are applied. SSL profiles can make use of multiple key types and support alternate key chains for each type (RSA, DSA and ECDSA). This can be performed either via the management web interface or via the TMOS command line (console or SSH).

=== Configuring Recommended Cipher-suites ===

To create a new SSL profile to conform to the '''Modern Compatibility''' cipher suite use the tmsh create profile command as follows...

<pre>

tmsh create /ltm profile client-ssl moz_modern ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:

ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE+AES-GCM:

ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-CBC-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:

ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-CBC-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:

DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!EXPORT:!DES:!RC4:!3DES:!MD5

</pre>

Note that Null ciphers are automatically rejected and are only made available if explicitly allowed by the F5 administrator.

Currently DHE-RSA-AES128-SHA256 & DHE-RSA-AES256-SHA256 are not available in TMOS v11.6.x. This is expected to be resolved in an upcoming hotfix and the next major release of TMOS. The full list of support ciphers is available here: https://support.f5.com/kb/en-us/solutions/public/13000/100/sol13163.html

To apply this new profile to an existing virtual server use either the management web interface or the following command line:

<pre>tmsh modify /ltm virtual my_virtual_server profiles add { moz_modern }</pre>

Any subsequenty changes to the SSL profile do not need to be manually re-applied to the LTM virtual server.

=== OCSP Stapling ===

Using the '''modify''' command allows us to easily add settings to our new SSL profile. Adding OCSP stapling is a 3 step process. First we must create a DNS resolver for outbound queries. Secondly we create our OCSP Stapling profile making use of this DNS resolver. Finally we add the OCSP Stapling profile to our SSL profile.

'''1. Creating the DNS resolver'''

This command creates a DNS resolver for all domains (.) and uses Googles public DNS servers

<pre>tmsh create net dns-resolver myResolver forward-zones add { . { nameservers add { 8.8.8.8:53 } nameservers add { 8.8.4.4:53 } } }</pre>

'''2. Creating the OCSP Stapling profile'''

The following command is used to create an OCSP stapling profile called '''myOCSP''' with our new DNS resolver '''myResolver'''

<pre>tmsh create ltm profile ocsp-stapling-params myOCSP dns-resolver myResolver trusted-ca ca-bundle.crt</pre>

'''3. Applying the OCSP Stapling profile to the DNS profile'''

Using the '''modify''' command we will replace the default certificate and key in our existing SSL profile with the same default cert/key but, this time, making using of our new OCSP profile.

<pre>tmsh modify ltm profile client-ssl moz_modern cert-key-chain replace-all-with { default { cert default.crt key default.key ocsp-stapling-params myOCSP } }</pre>

=== Session Resumption ===

To enable session resumption using Session Tickets enable the option in the SSL profile via the management web interface or use the '''session-ticket enabled''' parameter when creating the profile at the command line. Again, we can use the '''modify''' command to append this to our existing '''moz_modern''' SSL profile.

For example:

<pre>tmsh modify /ltm profile client-ssl moz_modern session-ticket enabled</pre>

=== Viewing the config ===

To confirm the configuration of your new SSL profile and to ensure that it is correctly applied to your virtual server use the '''list''' command.

View your SSL profile:

<pre>tmsh list ltm profile client-ssl moz_modern</pre>

Which outputs all configuration paratmers of the profile called '''moz_modern''':

<source>ltm profile client-ssl moz_modern {

app-service none

cert-key-chain {

default {

cert default.crt

key default.key

ocsp-stapling-params myOCSP

}

ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE+AES-GCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-CBC-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-CBC-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!EXPORT:!DES:!RC4:!3DES:!MD5

inherit-certkeychain true

session-ticket enabled

}

</source>

And to check it is correctly applied to your virtual server:

<pre>list ltm virtual vs_myWebsite</pre>

Which should list the SSL profile by name:

<source>ltm virtual vs_myWebsite {

destination 10.0.0.100:https

ip-protocol tcp

mask 255.255.255.255

pool pool_webServers

profiles {

http { }

http2 { }

manual_profile { }

moz_modern {

context clientside

}

spdy { }

tcp { }

wan-optimized-compression { }

}

rules { }

source 0.0.0.0/0

source-address-translation {

type automap

}

vs-index 4

}

</source>

=== Enabling HSTS ===

iRules are F5's flexible scripting language and can be used to easily enable HSTS for any TLS website. The standard HTTP should have redirection configured to send users to the HTTPS site. The following simple iRule is then applied to the HTTPS virtual server to insert the HSTS header enabling the maximum allowed age and including sub domains.

when HTTP_RESPONSE {

HTTP::header insert Strict-Transport-Security "max-age=15768000; includeSubDomains"

}

</source>

Ulfr

Confirm

529

edits

Changes

Security/Server Side TLS

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

How to Contribute

MozillaWiki

Around Mozilla

Tools