The reviewers did review parts of the document in their area of expertise; all
remaining errors in this document are the sole responsibility of the primary authors.

Abstract

Unfortunately, the computer security and cryptology communities have drifted
apart over the last 25 years. Security people don’t always understand the
available crypto tools, and crypto people don’t always understand the real-world
problems.

This guide arose out of the need for system administrators to have an updated,
solid, well researched and thought-through guide for configuring SSL, PGP, SSH
and other cryptographic tools in the post-Snowden age. Triggered by the NSA
leaks in the summer of 2013, many system administrators and IT security officers
saw the need to strengthen their encryption settings. This guide is specifically
written for these system administrators.

As Schneier noted in (Schneier, 2013), it seems that intelligence agencies and
adversaries on the Internet are not breaking so much the mathematics of
encryption per se, but rather use software and hardware weaknesses, subvert
standardization processes, plant backdoors, rig random number generators and
most of all exploit careless settings in server configurations and encryption
systems to listen in on private communications. Worst of all, most communication
on the internet is not encrypted at all by default (for SMTP, opportunistic TLS
would be a solution).

This guide can only address one aspect of securing our information systems:
getting the crypto settings right to the best of the authors' current knowledge.
Other attacks, as the above mentioned, require different protection schemes
which are not covered in this guide. This guide is not an introduction to
cryptography. For background information on cryptography and cryptoanalysis we
would like to refer the reader to the references in appendix Links and
Suggested Reading at the end of this document.

The focus of this guide is merely to give current best practices for
configuring complex cipher suites and related parameters in a copy &
paste-able manner. The guide tries to stay as concise as is possible for such a
complex topic as cryptography. Naturally, it can not be complete. There are many
excellent guides (II & SYM, 2012) and best practice
documents available when it comes to cryptography. However none of them focuses
specifically on what an average system administrator needs for hardening his or
her systems' crypto settings.

This guide tries to fill this gap.

The guide was produced in an open source manner: every step of editing can be
traced back to a specific author via our version control system.

3. How to read this guide

This guide tries to accommodate two needs: first of all, having a handy
reference on how to configure the most common services’ crypto settings and
second of all, explain a bit of background on cryptography. This background is
essential if the reader wants to choose his or her own cipher string settings.

System administrators who want to copy & paste recommendations quickly without
spending a lot of time on background reading on cryptography or cryptanalysis
can do so, by simply searching for the corresponding section in Best Practice.

It is important to know that in this guide the authors arrived at two
recommendations: Cipher string A and Cipher string B. While the former is a
hardened recommendation a latter is a weaker one but provides wider
compatibility. Cipher strings A and B are described in Recommended cipher suites.

However, for the quick copy & paste approach it is important to know that this
guide assumes users are happy with Cipher string B.

While Best Practice is intended to serve as a copy & paste reference,
Theory explains the reasoning behind cipher string B. In particular
Architectural overview explains how to choose individual cipher strings. We advise the
reader to actually read this section and challenge our reasoning in choosing
Cipher string B and to come up with a better or localized solution.

4. Disclaimer

A chain is no stronger than its weakest link, and life is after all a chain.

— William James

Encryption works. Properly implemented strong crypto systems are one of the few
things that you can rely on. Unfortunately, endpoint security is so terrifically
weak that NSA can frequently find ways around it.

The authors can not overstate the importance of these other techniques.
Interested readers are advised to read about these attacks in detail since they
give a lot of insight into other parts of cryptography engineering which need to
be dealt with[1]) ].

This guide does not talk much about the well-known insecurities of trusting a
public-key infrastructure (PKI)[2]. Nor does this
text fully explain how to run your own Certificate Authority (CA).

Most of this zoo of information security issues are addressed in the very
comprehensive book Security Engineering by Ross Anderson (Anderson, 2008).

For some experts in cryptography this text might seem too informal. However, we
strive to keep the language as non-technical as possible and fitting for our
target audience: system administrators who can collectively improve the security
level for all of their users.

Security is a process, not a product.

— Bruce Schneier

This guide can only describe what the authors currently believe to be the best
settings based on their personal experience and after intensive cross checking
with literature and experts. For a complete list of people who reviewed this
paper, see the <acknowledgements>. Even though multiple specialists reviewed
the guide, the authors can give no guarantee whatsoever that they made the
right recommendations. Keep in mind that tomorrow there might be new attacks on
some ciphers and many of the recommendations in this guide might turn out to be
wrong.

We therefore recommend that system administrators keep up to date with recent
topics in IT security and cryptography.

In this sense, this guide is very focused on getting the cipher strings done
right even though there is much more to do in order to make a system more
secure. We the authors, need this document as much as the reader needs it.

4.1. Scope

In this guide, we restricted ourselves to:

Internet-facing services

Commonly used services

Devices which are used in business environments (this specifically excludes

XBoxes, Playstations and similar consumer devices)

OpenSSL

We explicitly excluded:

Specialized systems (such as medical devices, most embedded systems,

industrial control systems, etc.)

Wireless Access Points

Smart-cards/chip cards

5. Methods

For writing this guide, we chose to collect the most well researched facts about
cryptography settings and let as many trusted specialists as possible review
those settings. The review process is completely open and done on a public
mailing list.

The document is available (read-only) to the public Internet on the web page and
the source code of this document is on a public git server, mirrored on
GitHub.com and open for public scrutiny. However, write permissions to the
document are only granted to vetted people. The list of reviewers can be found in <acknowledgements>.

Every write operation to the document is logged via the git version control
system and can thus be traced back to a specific author. We accept git pull
requests on the
github mirror for
this paper.

Public peer-review and multiple eyes checking of our guide is the best strategy
we can imagine at the present moment
[3].

We invite the gentle reader to participate in this public review process. Please
read the CONTRIBUTING document.

II: Best Practice

6. Webservers

6.1. Apache

Note that any cipher suite starting with EECDH can be omitted, if in doubt.
(Compared to the theory section, EECDH in Apache and ECDHE in OpenSSL are
synonyms [4])

6.1.4. References

6.1.5. How to test

6.2. lighttpd

6.2.1. Tested with Versions

lighttpd/1.4.33 with OpenSSL 0.9.8o on Debian Squeeze (note that TLSv1.2 does not work in openssl 0.9.8 thus not all ciphers actually work)

lighttpd/1.4.28-2 with OpenSSL 0.9.8o on Debian Squeeze (note that TLSv1.2 does not work in openssl 0.9.8 thus not all ciphers actually work)

lighttpd/1.4.31, Ubuntu 14.04.2 Trusty with Openssl 1.0.1f

6.2.2. Settings

Listing 3. SSL configuration for lighttpd

$SERVER["socket"]=="0.0.0.0:443"{ssl.engine="enable"ssl.use-sslv2="disable"ssl.use-sslv3="disable"ssl.pemfile="/etc/lighttpd/server.pem"ssl.ca-file="/etc/ssl/certs/server.crt"ssl.cipher-list="EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA"ssl.honor-cipher-order="enable"setenv.add-response-header=("Strict-Transport-Security"=>"max-age=15768000")# six months# use this only if all subdomains support HTTPS!# setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=15768000; includeSubDomains")}

Starting with lighttpd version 1.4.29 Diffie-Hellman and Elliptic-Curve
Diffie-Hellman key agreement protocols are supported. By default, elliptic curve
"prime256v1" (also "secp256r1") will be used, if no other is given. To select
special curves, it is possible to set them using the configuration options
ssl.dh-file and ssl.ec-curve.

6.2.3. Additional settings

As for any other webserver, you might want to automatically redirect http://
traffic toward https://. It is also recommended to set the environment
variable HTTPS, so the PHP applications run by the webserver can easily detect
that HTTPS is in use.

Listing 5. https auto-redirect configuration

$HTTP["scheme"]=="http"{# capture vhost name with regex condition -> %0 in redirect pattern# must be the most inner block to the redirect rule$HTTP["host"]=~".*"{url.redirect=(".*"=>"https://%0$0")}# Set the environment variable properlysetenv.add-environment=("HTTPS"=>"on")}

6.2.4. Additional information

The config option honor-cipher-order is available since 1.4.30, the supported
ciphers depend on the used OpenSSL-version (at runtime). ECDHE has to be
available in OpenSSL at compile-time, which should be default. SSL compression
should by deactivated by default at compile-time (if not, it’s active).

Support for other SSL-libraries like GnuTLS will be available in the upcoming
2.x branch, which is currently under development.

6.3.3. Additional settings

If you decide to trust NIST’s ECC curve recommendation, you can add the
following line to nginx’s configuration file to select special curves:

Listing 7. SSL EC/DH settings for nginx

ssl_ecdh_curvesecp384r1;

You might want to redirect everything to https:// if possible. In Nginx you
can do this with the following setting:

Listing 8. https auto-redirect in nginx

return301https://$server_name$request_uri;

The variable $server_name refers to the first server_name entry in your
config file. If you specify more than one server_name only the first will be
taken. Please be sure to not use the $host variable here because it contains
data controlled by the user.

6.3.4. References

6.3.5. How to test

6.4. Cherokee

6.4.1. Tested with Version

Cherokee/1.2.104 on Debian Wheezy with OpenSSL 1.0.1e 11 Feb 2013

6.4.2. Settings

The configuration of the cherokee webserver is performed by an admin interface
available via the web. It then writes the configuration to
/etc/cherokee/cherokee.conf, the important lines of such a configuration file
can be found at the end of this section.

General Settings

Network

SSL/TLS back-end: OpenSSL/libssl

Ports to listen

Port: 443, TLS: TLS/SSL port

Virtual Servers, For each vServer on tab Security:

Required SSL/TLS Values: Fill in the correct paths for Certificate and Certificate key

6.4.3. Additional settings

For each vServer on the Security tab it is possible to set the Diffie Hellman
length to up to 4096 bits. We recommend to use >1024 bits. More information
about Diffie-Hellman and which curves are recommended can be found in section
A note on Diffie Hellman Key Exchanges.

In Advanced: TLS it is possible to set the path to a Diffie Hellman parameters
file for 512, 1024, 2048 and 4096 bits.

To redirect HTTP to HTTPS, configure a new rule per Virtual Server in the
Behavior tab. The rule is SSL/TLS combined with a NOT operator. As
Handler define Redirection and use /(.*)$ as Regular Expression and
+https://$\{host}/$1+ as Substitution.

6.4.4. References

6.4.5. How to test

6.5. MS IIS

To configure SSL/TLS on Windows Server
IIS Crypto can be used. Simply start
the Programm, no installation required. The tool changes the registry keys
described below. A restart is required for the changes to take effect.

Instead of using the IIS Crypto Tool the configuration can be set using the
Windows Registry. The following Registry keys apply to the newer Versions of
Windows (Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Server
2012 and Windows Server 2012 R2). For detailed information about the older
versions see the Microsoft knowledgebase article
How to restrict the use of certain
cryptographic algorithms and protocols in Schannel.dll.

6.5.2. Settings

When trying to avoid RC4 (RC4 biases) as well as CBC (BEAST-Attack) by using GCM
and to support perfect forward secrecy, Microsoft SChannel (SSL/TLS, Auth,..
Stack) supports ECDSA but lacks support for RSA signatures
(see ECC suite B doubts).

Since one is stuck with ECDSA, an elliptic curve certificate needs to be used.

The configuration of cipher suites MS IIS will use, can be configured in one of
the following ways:

Table Client support shows the algorithms from strongest to weakest
and why they need to be added in this order. For example insisting on SHA-2
algorithms (only first two lines) would eliminate all versions of Firefox, so
the last line is needed to support this browser, but should be placed at the
bottom, so capable browsers will choose the stronger SHA-2 algorithms.

TLS_RSA_WITH_RC4_128_SHA or equivalent should also be added if MS Terminal
Server Connection is used (make sure to use this only in a trusted environment).
This suite will not be used for SSL, since we do not use a RSA Key.

Older Linux systems won’t support SHA2. PuTTY (Windows) does
not support RIPE-MD160. Curve25519, AES-GCM and UMAC are only
available upstream (OpenSSH 6.6p1). DSA host keys have been removed
on purpose, the DSS standard does not support for DSA keys stronger
than 1024bit
[5] which is
far below current standards (see section
#section:keylengths). Legacy systems can use
this configuration and simply omit unsupported ciphers, key exchange
algorithms and MACs.

7.2. Cisco ASA

7.2.1. Tested with Versions

7.2.2. Settings

When the ASA is configured for SSH, by default both SSH versions
1 and 2 are allowed. In addition to that, only a group1
DH-key-exchange is used. This should be changed to allow only SSH
version 2 and to use a key-exchange with group14. The generated RSA
key should be 2048 bit (the actual supported maximum). A
non-cryptographic best practice is to reconfigure the lines to only
allow SSH-logins.

7.3.2. Settings

Same as with the ASA, also on IOS by default both SSH versions 1
and 2 are allowed and the DH-key-exchange only use a DH-group of 768
Bit. In IOS, a dedicated Key-pair can be bound to SSH to reduce the
usage of individual keys-pairs. From IOS Version 15.0 onwards, 4096
Bit rsa keys are supported and should be used according to the
paradigm "use longest supported key". Also, do not forget to disable
telnet vty access.

7.3.3. References

This guide is a basic SSH reference for all routers and switches. Pleaes refer
to the specific documentation of the device and IOS version that you are
configuring.

7.3.4. How to test

Connect a client with verbose logging enabled to the SSH server

$ ssh -vvv switch.example.net

and observe the key exchange in the output.

8. Mailservers

This section documents the most common mail servers. Mail servers may usually
be grouped into three categories:

Mail Submission Agent (MSA)

Mail Transfer Agent (MTA) / Mail Exchanger (MX)

Mail Delivery Agent (MDA)

An email client (mail user agent, MUA) submits mail to the MSA. This is usually
been done using the Simple Mail Transfer Protocol (SMTP). Afterwards, the mail
is transmitted by the MTA over the Internet to the MTA of the receiver. This
happens again via SMTP. Finally, the mail client of the receiver will fetch
mail from an MDA usually via the Internet Message Access Protocol (IMAP) or the
Post Office Protocol (POP).

As MSAs and MTAs both use SMTP as transfer protocols, both functionalities may
often be implemented with the same software. On the other hand, MDA software
might or might not implement both IMAP and POP.

8.1. TLS usage in mail server protocols

Email protocols support TLS in two different ways. It may be added as a
protocol wrapper on a different port. This method is referred to as Implicit
TLS or as protocol variants SMTPS, IMAPS and POP3S. The other method is to
establish a cleartext session first and switch to TLS afterwards by issuing the
STARTTLS command.

SMTP between MTAs usually makes use of opportunistic TLS. This means that an
MTA will accept TLS connections when asked for it but will not require it. MTAs
should always try opportunistic TLS handshakes outgoing and always accept
incoming opportunistic TLS.

8.2. Recommended configuration

We recommend to use the following settings for Mail Transfer Agents:

correctly setup MX, A and PTR RRs without using CNAMEs at all

the hostname used as HELO/EHLO in outgoing mail shall match the PTR RR

enable opportunistic TLS, using the STARTTLS mechanism on port 25

Implicit TLS on port 465 may be offered additionally

use server and client certificates (most server certificates are client
certificates as well)

either the common name or at least an alternate subject name of the
certificate shall match the PTR RR (client mode) or the MX RR (server mode)

do not use self signed certificates

accept all cipher suites, as the alternative would be to fall back to
cleartext transmission

an execption to the last sentence is that MTAs MUST NOT enable SSLv2
protocol support, due to the
DROWN attack.

For MSA operation we recommend:

listen on submission port 587 with mandatory STARTTLS

optionally listen on port 465 with Implicit TLS

enforce SMTP AUTH even for local networks

ensure that SMTP AUTH is not allowed on unencrypted connections

only use the recommended cipher suites if all connecting MUAs support them

For MDA operation we recommend:

listen on the protocol port (143 for IMAP, 110 for POP3) with mandatory STARTTLS

cyrus-imapd loads hardcoded 1024 bit DH parameters using
get_rfc2409_prime_1024() by default. If you want to load your own DH parameters
add them PEM encoded to the certificate file given in tls_cert_file. Do not
forget to re-add them after updating your certificate.

To prevent unencrypted connections on the STARTTLS ports you can set

Listing 16. Force encrypted connections in cyrus

allowplaintext: no

This way MUAs can only authenticate with plain text authentication schemes
after issuing the STARTTLS command. Providing CRAM-MD5 or DIGEST-MD5 methods is
not recommended.

To support POP3/IMAP on ports 110/143 with STARTTLS and POP3S/IMAPS on ports
995/993 check the SERVICES section in cyrus.conf

8.4.4. How to test

8.5. Postfix

8.5.1. Tested with Versions

Table 6. Tested Postfix Versions

Program Version

OS/Distribution/Version

Comment

2.9.6

Debian Wheezy

with OpenSSL 1.0.1e

2.11.0

Ubuntu 14.04.02

with OpenSSL 1.0.1f

3.1.0

Ubuntu 16.04.3 LTS

8.5.2. Settings

Postfix has five internal lists of ciphers, and the possibility to switch
between those with smtpd_tls_ciphers. However, we leave this at its default
value for server to server connections, as many mail servers only support
outdated protocols and ciphers. We consider bad encryption still better than
plain text transmission. For connections to MUAs, TLS is mandatory and the
ciphersuite is modified.

MX and SMTP client configuration:

As discussed in section [smtp_general], because of opportunistic encryption
we do not restrict the list of ciphers or protocols for communication with
other mail servers to avoid transmission in plain text. There are still some
steps needed to enable TLS, all in main.cf:

8.5.4. References

8.5.5. Additional settings

Postfix has two sets of built-in DH parameters that can be overridden with the
smtpd_tls_dh512_param_file and smtpd_tls_dh1024_param_file options. The
“dh512” parameters are used for export ciphers, while the “dh1024” ones are
used for all other ciphers.

The “bit length” in those parameter names is just a name, so one could use
stronger parameter sets; it should be possible to e.g. use the IKE Group14
parameters (see section [DH] without much
interoperability risk, but we have not tested this yet.

This switches Exim to submission mode and allows addition of missing
“Message-ID” and “Date” headers.

It is not advisable to restrict the default cipher list for MSA mode if you
don’t know all connecting MUAs. If you still want to define one please consult
the Exim documentation or ask on the exim-users mailinglist.

The cipher used is written to the logfiles by default. You may want to add

Server mode (incoming):

Don’t forget to add intermediate certificates to the .pem file if needed.

Tell Exim to advertise STARTTLS in the EHLO answer to everyone:

Listing 28. TLS advertise in Exim (Server)

tls_advertise_hosts = *

Listen on smtp(25) port only:

Listing 29. STARTTLS on SMTP in Exim (Server)

daemon_smtp_ports = smtp

It is not advisable to restrict the default cipher list for opportunistic
encryption as used by SMTP. Do not use cipher lists recommended for HTTPS! If
you still want to define one please consult the Exim documentation or ask on
the exim-users mailinglist.

If you want to request and verify client certificates from sending hosts set

Do not limit ciphers without a very good reason. In the worst case you end up
without encryption at all instead of some weak encryption. Please consult the
Exim documentation if you really need to define ciphers.

OpenSSL:

+all is misleading here since OpenSSL only activates the most common
workarounds. But that’s how SSL_OP_ALL is defined.

You do not need to set dh_parameters. Exim with OpenSSL by default uses
parameter initialization with the “2048-bit MODP Group with 224-bit Prime Order
Subgroup” defined in section 2.2 of RFC 5114 (ike23). If you want to set your
own DH parameters please read the TLS documentation of exim.

GnuTLS:

GnuTLS is different in only some respects to OpenSSL:

tls_require_ciphers needs a GnuTLS priority string instead of a cipher list. It
is recommended to use the defaults by not defining this option. It highly
depends on the version of GnuTLS used. Therefore it is not advisable to change
the defaults.

There is no option like openssl_options

Exim string expansion

Most of the options accept expansion strings. This way you can e.g.
set cipher lists or STARTTLS advertisement conditionally. Please follow the
link to the official Exim documentation to get more information.

Limitations:

Exim currently (4.82) does not support elliptic curves with OpenSSL. This means
that ECDHE is not used even if defined in your cipher list. There already is a
working patch to provide support.

8.6.2. How to test

$ openssl s_client -starttls smtp -crlf -connect example.com:25

8.7. Cisco ESA/IronPort

8.7.1. Tested with Versions

Table 8. Tested Cisco ESA/IronPort Versions

Program Version

OS/Distribution/Version

Comment

AsyncOS 7.6.1

AsyncOS 8.5.6

AsyncOS 9.0.0

AsyncOS 9.5.0

AsyncOS 9.6.0

AsyncOS 9.7.0

8.7.2. Settings

Import your certificate(s) using the WEBUI (Network → Certificates).

From AsyncOS 9.0 and up, SSL parameters for inbound SMTP, outbound SMTP and GUI
access can be configured in one step via the WEBUI (System Administration →
SSL Configuration, see figure IronPort Default SSL Settings). For all versions
prior to 9.0, you have to connect to the CLI and configure the SSL parameters
separately, as shown below using inbound SMTP as example.

Starting with AsyncOS 9.0 SSLv3 is disabled by default, whereas the
default cipher set is still RC4-SHA:RC4-MD5:ALL (see figure
IronPort Default SSL Settings).

Figure 1. IronPort Default SSL Settings

After committing these changes in the CLI, you have to activate the use of TLS
in several locations.

For inbound connections, first select the appropriate certificate in the
settings of each listener you want to have TLS enabled on (Network →
Listeners, see figure IronPort Default SSL Settings). Afterwards, for each
listener, configure all Mail Flow Policies which have their Connection Behavior
set to “Accept” or “Relay” to at least prefer TLS (Mail Policies → Mail
Flow Policies, see figure IronPort Default SSL Settings). It is recommended to
also enable TLS in the default Mail Flow Policy, because these settings will be
inherited by newly created policies, unless specifically overwritten. + TLS can
be enforced by creating a new Mail Flow Policy with TLS set to “required”,
creating a new Sender Group defining the addresses of the sending mail servers
for which you want to enforce encryption (Mail Policies → HAT Overview) and
using this new Sender Group in conjunction with the newly created Mail Flow
Policy.

Figure 2. IronPort Listener Settings

Figure 3. IronPort Mail Flow Policy Security Features

TLS settings for outbound connections have to be configured within the
Destination Controls (Mail Policies → Destination Controls). Choose the
appropriate SSL certificate within the global settings and configure TLS to be
preferred in the default profile to enable it for all outbound connections.
After these two steps the Destination Control overview page should look like
figure IronPort Destination Control overview on page . To enforce TLS for a specific
destination domain, add an entry to the Destination Control Table and set “TLS
Support” to “required”.

Figure 4. IronPort Destination Control overview

8.7.3. Limitations

All AsyncOS releases prior to version 9.5 use OpenSSL 0.9.8. Therefore TLS 1.2
is not supported in these versions and some of the suggested ciphers won’t
work. Starting with AsyncOS 9.5 TLS 1.2 is fully
supported.
[8] You can check the supported ciphers on the CLI by
using the option verify from within the sslconfig command:

8.7.4. How to test

$ openssl s_client -starttls smtp -crlf -connect example.com:25

9. Virtual Private Networks

Virtual Private Networks (VPN) provide means of connecting private networks over
external / public transport networks. Since we do not control the transport
networks we have to to take care about data integrity and privacy.

Some providers also offer VPNs for connecting company networks via MPLS or
simular technologies. The provider promises you that nobody else has access to
your data trnfserred over their lines. You have to decide if this promise
does fit to your information security requirements.

Basically there are two ways to ensure the privacy and integrity of the data
sent via external lines. First you could utilize the built-in security of the
Internet Protocol (IPsec). The other way are specific applications that encrypt
the data before sending it over the line.

IPsec is an Internet standard (TODO RFC 6071). This guarantees the
interoperability between implementations of different vendors. You can establish
a secure connection with your customer or your supplier. On the other hand VPN
applications mostly utilize TLS to secury the communication between the
partners.

TODO: Descision criteria IPsec vs. VPN application.

9.1. IPsec

IPsec is the Internet standard to encrypt the transport of data between private
networks.

9.1.1. Technology

We describe only the use the Internet Key Exchange (IKE) version 2 in this dodument.
IKEv1 has some usage and security problems and should not be used any more.
(TODO: reference).

9.1.2. Authentication

IPsec authentication should optimally be performed via RSA signatures, with a
key size of 2048 bits or more. Configuring only the trusted CA that issued the
peer certificate provides for additional protection against fake certificates.

If you need to use Pre-Shared Key (PSK) authentication:

Choose a random, long enough PSK (see below)

Use a separate PSK for any IPsec connection

Change the PSKs regularly

Think aboute a secure way to exchange the PSK. Sending an SMS it not
secure.

For a key composed only of upper- and lowercase letters, numbers, and two
additional characters[9],
table #tab:IPSEC_psk_len gives the minimum lengths in characters.

Cryptographic Suites:

IPSEC Cryptographic Suites are pre-defined settings for all the items of a configuration; they try to provide a balanced security level and make setting up VPNs easier. [10]

When using any of those suites, make sure to enable “Perfect Forward Secrecy“ for Phase 2, as this is not specified in the suites. The equivalents to the recommended ciphers suites in section Recommended cipher suites are shown in table #tab:IPSEC_suites.

Phase 1:

TODO: Phase 1 and 2 are phrases from IKEv1. Re-write for IKEv2.

Alternatively to the pre-defined cipher suites, you can define your own, as
described in this and the next section.

Either choose one of the encryption suites in the properties dialog (figure
[checkpoint_1], or proceed to Custom Encryption..., where you can set
encryption and hash for Phase 1 and 2 (figure [checkpoint_2].

9.2.3. Additional settings

For remote Dynamic IP Gateways, the settings are not taken from the community,
but set in the Global Properties dialog under Remote Access / VPN
Authentication and Encryption. Via the Edit... button, you can configure sets
of algorithms that all gateways support (figure [checkpoint_4]).

Server Configuration

Client Configuration

Client and server have to use compatible configurations, otherwise they can’t
communicate. The cipher and auth directives have to be identical.

9.3.3. Justification for special settings

OpenVPN 2.3.1 changed the values that the tls-cipher option expects from
OpenSSL to IANA cipher names. That means from that version on you will get
Deprecated TLS cipher name warnings for the configurations above. You cannot
use the selection strings from section Recommended cipher suites directly from
2.3.1 on, which is why we give an explicit cipher list here.

In addition, there is a 256 character limit on configuration file line lengths;
that limits the size of cipher suites, so we dropped all ECDHE suites.

The configuration shown above is compatible with all tested versions.

9.3.4. References

9.3.5. Additional settings

Key renegotiation interval

The default for renegotiation of encryption keys is one hour (reneg-sec 3600).
If you transfer huge amounts of data over your tunnel, you might consider
configuring a shorter interval, or switch to a byte- or packet-based interval
(reneg-bytes or reneg-pkts).

Insecure ciphers

Sweet32[12] is an attack on 64-bit block ciphers,
such as 3DES and Blowfish in OpenVPN. The following ciphers are affected,
and should no longer be used:

BF-*

DES* (including 3DES variants)

RC2-*

The following ciphers are not affected:

AES-*

CAMELLIA-*

SEED-*

According to mitigation section on Sweet32
website[13] users users should change the
cipher from the DES or Blowfish to AES (cipher AES-128-CBC). If cipher change
is not possible users can mitigate the attack by forcing frequent rekeying
(reneg-bytes 64000000).

Fixing “easy-rsa”

When installing an OpenVPN server instance, you are probably using easy-rsa to
generate keys and certificates. The file vars in the easyrsa installation
directory has a number of settings that should be changed to secure values:

This will enhance the security of the key generation by using RSA keys with a
length of 4096 bits, and set a lifetime of one year for the server/client
certificates and five years for the CA certificate.

4096 bits is only an example of how to do this with easy-rsa. See also section
Keylengths for a discussion on keylengths.

In addition, edit the pkitool script and replace all occurrences of sha1
with sha256, to sign the certificates with SHA256.

9.3.6. Limitations

Note that the ciphersuites shown by openvpn --show-tls are known, but not
necessarily supported[14].

9.4. PPTP

PPTP is considered insecure, Microsoft recommends to _use a more secure VPN tunnel_[15].

There is a cloud service that cracks the underlying MS-CHAPv2 authentication
protocol for the price of
USD 200[16],
and given the resulting MD4 hash, all PPTP traffic for a user can be decrypted.

9.5. Cisco ASA

The following settings reflect our recommendations as best as possible on the
Cisco ASA platform. These are - of course - just settings regarding SSL/TLS
(i.e. Cisco AnyConnect) and IPsec. For further security settings regarding this
platform the appropriate Cisco guides should be followed.

9.6.3. How to test

9.6.4. References

9.7. tinc

9.7.1. Tested with Versions

Table 13. Tested tinc Versions

Program Version

OS/Distribution/Version

Comment

1.0.23

Gentoo

linked against OpenSSL 1.0.1e

1.0.23

Sabayon

linked against OpenSSL 1.0.1e

Defaults

tinc uses 2048 bit RSA keys, Blowfish-CBC, and SHA1 as default settings and
suggests the usage of CBC mode ciphers. Any key length up to 8192 is supported
and it does not need to be a power of two. OpenSSL Ciphers and Digests are
supported by tinc.

Settings

Generate keys with

$ tincd -n NETNAME -K8192

Old keys will not be deleted (but disabled), you have to delete them manually.
Add the following lines to your tinc.conf on all machines

References

10. PGP/GPG - Pretty Good Privacy

The OpenPGP protocol defines a set of
asymmetric- and symmetric encryption algorithms, signature methods and
compression protocols. GnuPG, a FOSS implementation of the
OpenPGP standard, is widely used for mail encryption.

GnuPG signs a message, encrypts it symmetrically and encrypts the symmetric key
and the hash with Bob’s public key asymmetrically.

Research on SHA-1 conducted back in 2005
(see: SHA-1 Broken)
as well as the first practical successful collision in early 2017
(see: SHAttered) has made clear that collision attacks are
a real threat to the security of the SHA-1 hash function.

Since SHA-1 is defined as a must implementation by the OpenPGP specification,
GnuPG is still using it. Currently settings should be adapted to preferably
avoid using SHA-1.

10.2. Key Generation

Because of lack of forward secrecy (see: [pfs]) in OpenPGP it is preferable to
use large asymmetric keys for long term communication protection. A RSA key of
4096 bits should provide enough confidentiality for the next 10 years
(see: Cryptographic Key Length Recommendation).

Note that we are setting the SSL option cipher_server_preference. This
enforces our cipher order when negotiating which ciphers are used, as the cipher
order of
some
clients chooses weak ciphers over stronger ciphers.

Starting with version 15.03[17], it is possible to use custom
Diffie-Hellman-Parameters. This allows us to negotiate stronger
Diffie-Hellman-keys, and also helps us avoid problems with using common
weak Diffie-Hellman-Parameters. You can generate your own
parameter file by running:

$ openssl dhparam -out dhparams.pem 4096

By default, ejabberd provides an administration website (look for the
ejabberd_http module). Enable TLS protection for it like this:

12.2.6. Additional settings

Older versions of ejabberd (< 2.0.0) need to be
patched
to be able to parse all of the certificates in the CA chain. Specifying a custom
cipher string is only possible starting with version 13.12 (see configuration
for version 14.12 above).

12.2.7. References

12.2.8. How to test

12.3. Chat privacy - Off-the-Record Messaging (OTR)

Off-the-Record Messaging
Protocol works on top of the Jabber protocol. It adds to popular chat clients
(Adium, Pidgin…​) the following properties for encrypted chats:

Authentication

Integrity

Confidentiality

Forward secrecy

It basically uses Diffie-Hellman, AES and SHA1. Communicating over an insecure
instant messaging network, OTR can be used for end to end encryption.

There are no specific configurations required but the protocol itself is worth
to be mentioned.

12.4. Charybdis

There are numerous implementations of IRC servers. In this section, we choose
Charybdis which serves as basis for
ircd-seven, developed and used by
freenode. Freenode is actually the biggest IRC
network[19]. Charybdis is part of the Debian & Ubuntu distributions.

12.5. SILC

SILC is instant messaging protocol publicly released in
2000. SILC is a per-default secure
chat protocol thanks to a generalized usage of symmetric encryption. Keys are
generated by the server meaning that if compromised, communication could be
compromised.

13.4.4. How to test

14. Proxy Solutions

Within enterprise networks and corporations with increased levels of
paranoia or at least some defined security requirements it is common
not to allow direct connections to the public internet.

For this reason proxy solutions are deployed on corporate networks to
intercept and scan the traffic for potential threats within sessions.

For encrypted traffic there are four options:

Block the connection because it cannot be scanned for threats.

Bypass the threat-mitigation and pass the encrypted session to the
client, which results in a situation where malicious content is
transferred directly to the client without visibility to the security
system.

Intercept (i.e. terminate) the session at the proxy, scan there and
re-encrypt the session towards the client (effectively MITM).

Deploy special Certificate Authorities to enable Deep Packet Inspection
on the wire.

While the latest solution might be the most "up to date", it arises a
new front in the context of this paper, because the most secure part of
a client’s connection could only be within the corporate network, if the
proxy-server handles the connection to the destination server in an
insecure manner.

Conclusion: Don’t forget to check your proxy solutions SSL-capabilities.
Also do so for your reverse proxies!

14.1. Bluecoat / Symantec

Blue Coat Systems was a well-known manufacturer of enterprise proxy appliances.
In 2016 it was acquired by Symantec. The products are now known as Symantec
ProxySG and Advanced Secure Gateway (ASG).

The description below is for the original Blue Coat SG Operating System (SGOS).

BlueCoat Proxy SG Appliances can be used as forward and reverse proxies. The
reverse proxy feature is rather under-developed, and while it is possible and
supported, there only seems to be limited use of this feature "in the wild" -
nonetheless there are a few cipher suites to choose from, when enabling SSL
features.

14.2.3. Additional Settings

14.2.4. Enable NPN Support:

bind *:443 ssl crt server.pem npn "http/1.1,http/1.0"

Append the npn command in the frontend configuration of HAProxy.

14.2.5. Enable OCSP stapling:

HAProxy supports since version 1.5.0 OCSP stapling. To enable it you
have to generate the OCSP singing file in the same folder, with the same
name as your certificate file plus the extension .ocsp. (e.g. your
certificate file is named server.crt then the OCSP file have to be named
server.crt.oscp)
To generate the OCSP file use these commands:

Reload HAProxy and now OCSP stapling should be enabled.
Note: This OCSP signature file is only valid for a limited time. The
simplest way of updating this file is by using cron.daily or something
similar.

14.4.4. References

14.4.5. How to test

15. Kerberos

This section discusses various implementations of the Kerberos 5 authentication
protocol on Unix and Unix-like systems as well as on Microsoft Windows.

15.1. Overview

Kerberos provides mutual authentication of two communicating parties, e.g. a
user using a network service. The authentication process is mediated by a
trusted third party, the Kerberos key distribution centre (KDC). Kerberos
implements secure single-sign-on across a large number of network protocols and
operating systems. Optionally, Kerberos can be used to create encrypted
communications channels between the user and service.

15.1.1. Recommended reading

An understanding of the Kerberos protocol is necessary for properly implementing
a Kerberos setup. Also, in the following section some knowledge about the inner
workings of Kerberos is assumed. Therefore we strongly recommend reading the
excellent introduction
Kerberos: An
Authentication Service for Computer Networks first.

No further overview over Kerberos terminology and functions will be provided,
for a discussion and a selection of relevant papers refer to
Kerberos Papers and Documentation.

The Kerberos protocol over time has been extended with a variety of extensions
and Kerberos implementations provide additional services in addition to the
aforementioned KDC. All discussed implementations provide support for trust
relations between multiple realms, an administrative network service
(kerberos-adm, kadmind) as well as a password changing service (kpasswd).
Sometimes, alternative database backends for ticket storage, X.509 and SmartCard
authentication are provided. Of those, only administrative and password changing
services will be discussed.

Protocol versions

Only the Kerberos 5 protocol and implementation will be discussed. Kerberos 4 is
obsolete, insecure and its use is strongly discouraged.

15.1.2. Providing a suitable Setup for secure Kerberos Operations

The aim of Kerberos is to unify authentication across a wide range of services,
for many different users and use cases and on many computer platforms. The
resulting complexity and attack surface make it necessary to carefully plan and
continuously evaluate the security of the overall ecosystem in which Kerberos is
deployed. Several assumptions are made on which the security of a Kerberos
infrastructure relies:

Every KDC in a realm needs to be trustworthy. The KDC’s principal database
must not become known to or changed by an attacker. The contents of the
principal database enables the attacker to impersonate any user or service in
the realm.

Synchronisation between KDCs must be secure, reliable and frequent. An
attacker that is able to intercept or influence synchronisation messages
obtains or influences parts of the principal database, enabling impersonation
of affected principals. Unreliable or infrequent synchronisation enlarges the
window of vulnerability after disabling principals or changing passwords that
have been compromised or lost.

KDCs must be available. An attacker is able to inhibit authentication for
services and users by cutting off their access to a KDC.

Users’ passwords must be secure. Since Kerberos is a single-sign-on mechanism,
a single password may enable an attacker to access a large number of services.

Service keytabs need to be secured against unauthorized access similarly to
SSL/TLS server certificates. Obtaining a service keytab enables an attacker to
impersonate a service.

DNS infrastructure must be secure and reliable. Hosts that provide services
need consistent forward and reverse DNS entries. The identity of a service is
tied to its DNS name, similarly the realm a client belongs to as well as the
KDC, kpasswd and kerberos-adm servers may be specified in DNS TXT and SRV
records. Spoofed DNS entries will cause denial-of-service situations and might
endanger (i_mit_Realm configuration decisions_, 2013) the security
of a Kerberos realm.

Clients and servers in Kerberos realms need to have synchronized clocks.
Tickets in Kerberos are created with a limited, strictly enforced lifetime.
This limits an attacker’s window of opportunity for various attacks such as
the decryption of tickets in sniffed network traffic or the use of tickets
read from a client computer’s memory. Kerberos will refuse tickets with old
timestamps or timestamps in the future. This would enable an attacker with
access to a systems clock to deny access to a service or all users logging in
from a specific host.

Therefore we suggest:

Secure all KDCs at least as strongly as the most secure service in the realm.

Dedicate physical (i.e. non-VM) machines to be KDCs. Do not run any services
on those machines beyond the necessary KDC, kerberos-adm, kpasswd and kprop
services.

Restrict physical and administrative access to the KDCs as severely as
possible. E.g. ssh access should be limited to responsible adminstrators and
trusted networks.

Use DNSSEC. If that is not possible, at least ensure that all servers and
clients in a realm use a trustworthy DNS server contacted via secure network
links.

Use NTP on a trustworthy server via secure network links.

Avoid services that require the user to enter a password which is then checked
against Kerberos. Prefer services that are able to use authentication via
service tickets, usually not requiring the user to enter a password except for
the initial computer login to obtain a ticket-granting-ticket (TGT). This
limits the ability of attackers to spy out passwords through compromised
services.

15.2. Implementations

15.2.1. Cryptographic Algorithms in Kerberos Implementations

The encryption algorithms (commonly abbreviated ’etypes’ or ’enctypes’) in
Kerberos exchanges are subject to negotiation between both sides of an exchange.
Similarly, a ticket granting ticket (TGT), which is usually obtained on initial
login, can only be issued if the principal contains a version of the password
encrypted with an etype that is available both on the KDC and on the client
where the login happens.

This means that the des3-cbc-sha1-kd or rc4-hmac algorithms should not be used,
except if there is a concrete and unavoidable need to do so. Other des3-*,
des-* and rc4-hmac-exp algorithms should never be used.

Along the lines of cipher string B, the following etypes are recommended:
aes256-cts-hmac-sha1-96camellia256-cts-cmacaes128-cts-hmac-sha1-96camellia128-cts-cmac.

In this case, an old unsafe enctype is in use as indicated by the star following the key line.

To upgrade, proceed as follows. First create a new master key for the database
with the appropriate enctype. You will be prompted for a master password that
can later be used to decrypt the database. A stash-file containing this
encryption key will also be written.

root@kdc.example.com:~# kdb5_util add_mkey -s -e aes256-cts-hmac-sha1-96
Creating new master key for master key principal 'K/M@EXAMPLE.COM'
You will be prompted for a new database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:

Verify that the new master key has been successfully created. Note the key
version number (KVNO) of the new master key, in this case 2.

We try to answer the questions by explaining issues with random number
generators (section Random Number Generators), keylengths (section Keylengths),
current issues in ECC (section A note on Elliptic Curve Cryptography), a note
of warning on SHA-1 (section A note on SHA-1) and some comments on Diffie
Hellman key exchanges (section A note on Diffie Hellman Key Exchanges). All of this is important in
understanding why certain choices were made for Cipher String A and
B. However, for most system administrators, the question of
compatibility is one of the most pressing ones. Having the freedom to
be compatible with any client (even running on outdated operating
systems) of course, reduces the security of our cipher strings. We
address these topics in section TODO. All these sections
will allow a system administrator to balance his or her needs for
strong encryption with usability and compatibility.

Last but not least, we finish this chapter by talking about issues in
PKIs (section Public Key Infrastructures), Certificate Authorities
and on hardening a PKI. Note that these last few topics deserve a book
on their own. Hence this guide can only mention a few current topics in
this area.

17. Cipher suites

17.1. Architectural overview

This section defines some terms which will be used throughout this
guide.

A cipher suite is a standardized collection of key exchange algorithms,
encryption algorithms (ciphers) and Message authentication codes (MAC)
algorithm that provides authenticated encryption schemes. It consists of
the following components:

Key exchange protocol

"An (interactive) key exchange protocol is a method whereby parties
who do not share any secret information can generate a shared, secret
key by communicating over a public channel. The main property
guaranteed here is that an eavesdropping adversary who sees all the
messages sent over the communication line does not learn anything
about the resulting secret key." (Katz & Lindell, 2008)
Example: DHE

Authentication

The client authenticates the server by its certificate. Optionally the
server may authenticate the client certificate.
Example: RSA

Cipher

The cipher is used to encrypt the message stream. It also contains the
key size and mode used by the suite.
Example: AES256

Message authentication code (MAC)

A MAC ensures that the message has not been tampered with (integrity).
Example: SHA256

Authenticated Encryption with Associated Data (AEAD)

AEAD is a class of authenticated encryption block-cipher modes which
take care of encryption as well as authentication (e.g. GCM, CCM
mode).
Example: AES256-GCM

There are two common naming schemes for cipher strings – IANA names (see
appendix Links) and the more well known OpenSSL names.
In this document we will always use OpenSSL names unless a specific
service uses IANA names.

17.2. Forward Secrecy

Forward Secrecy or Perfect Forward Secrecy is a property of a cipher suite that
ensures confidentiality even if the server key has been compromised. Thus if
traffic has been recorded it can not be decrypted even if an adversary has got
hold of the server key.

17.3. Recommended cipher suites

18. Recommended cipher suites

In principle system administrators who want to improve their
communication security have to make a difficult decision between
effectively locking out some users and keeping high cipher suite
security while supporting as many users as possible. The web-site
Qualys SSL Labs gives administrators and
security engineers a tool to test their setup and compare
compatibility with clients. The authors made use of ssllabs.com to
arrive at a set of cipher suites which we will recommend throughout
this document.

Caution

these settings can only represent a subjective
choice of the authors at the time of writing. It might be a wise
choice to select your own and review cipher suites based on the
instructions in section [ChoosingYourOwnCipherSuites].

18.1. Configuration A: Strong ciphers, fewer clients

At the time of writing, our recommendation is to use the following set of strong cipher
suites which may be useful in an environment where one does not depend on many,
different clients and where compatibility is not a big issue. An example
of such an environment might be machine-to-machine communication or corporate
deployments where software that is to be used can be defined without restrictions.

We arrived at this set of cipher suites by selecting:

TLS 1.2

Perfect forward secrecy / ephemeral Diffie Hellman

strong MACs (SHA-2) or

GCM as Authenticated Encryption scheme

This results in the OpenSSL string:
EDH+aRSA+AES256:EECDH+aRSA+AES256:!SSLv3

Table 14. Configuration A ciphers

ID

OpenSSL Name

Version

KeyEx

Auth

Cipher

MAC

0x009F

DHE-RSA-AES256-GCM-SHA384

TLSv1.2

DH

RSA

AESGCM(256)

AEAD

0x006B

DHE-RSA-AES256-SHA256

TLSv1.2

DH

RSA

AES(256) (CBC)

SHA256

0xC030

ECDHE-RSA-AES256-GCM-SHA384

TLSv1.2

ECDH

RSA

AESGCM(256)

AEAD

0xC028

ECDHE-RSA-AES256-SHA384

TLSv1.2

ECDH

RSA

AES(256) (CBC)

SHA384

Compatibility

At the time of this writing only Win 7 and Win 8.1 crypto stack,
OpenSSL >= 1.0.1e, Safari 6 / iOS 6.0.1 and Safari 7 / OS X 10.9
are covered by that cipher string.

18.2. Configuration B: Weaker ciphers but better compatibility

In this section we propose a slightly weaker set of cipher suites. For
example, there are known weaknesses for the SHA-1 hash function that is
included in this set. The advantage of this set of cipher suites is not only
better compatibility with a broad range of clients, but also less computational
workload on the provisioning hardware.

Note that these cipher suites will not work with Windows XP’s crypto stack (e.g. IE, Outlook),

Explanation

For a detailed explanation of the cipher suites chosen, please see
[ChoosingYourOwnCipherSuites]. In short, finding a single perfect cipher
string is practically impossible and there must be a tradeoff between compatibility and security.
On the one hand there are mandatory and optional ciphers defined in a few RFCs,
on the other hand there are clients and servers only implementing subsets of the
specification.

Straightforwardly, the authors wanted strong ciphers, forward secrecy
[25]
and the best client compatibility possible while still ensuring a cipher string that can be
used on legacy installations (e.g. OpenSSL 0.9.8).

Our recommended cipher strings are meant to be used via copy and paste and need to work
"out of the box".

TLSv1.2 is preferred over TLSv1.0 (while still providing a useable cipher string for TLSv1.0 servers).

AES256 and CAMELLIA256 count as very strong ciphers at the moment.

AES128 and CAMELLIA128 count as strong ciphers at the moment

DHE or ECDHE for forward secrecy

RSA as this will fit most of today’s setups

AES256-SHA as a last resort: with this cipher at the end, even server systems with very old OpenSSL versions will work out of the box (version 0.9.8 for example does not provide support for ECC and TLSv1.1 or above). Note however that this cipher suite will not provide forward secrecy. It is meant to provide the same client coverage(eg. support Microsoft crypto libraries) on legacy setups.

18.3. Compatibility

TODO

Write this section. The idea here is to first document which server (and openssl) version we assumed. Once these parameters are fixed, we then list all clients which are supported for Variant A) and B). Therefore we can document compatibilities to some extent. The sysadmin can then choose roughly what he looses or gains by omitting certain cipher suites.

19. Random Number Generators

A good source of random numbers is essential for many crypto operations. The key
feature of a good random number generator is the non-predictability of the
generated numbers. This means that hardware support for generating entropy is
essential.

Hardware random number generators in operating systems or standalone components
collect entropy from various random events mostly by using the (low bits of the)
time an event occurs as an entropy source. The entropy is merged into an entropy
pool and in some implementations there is some bookkeeping about the number of
random bits available.

19.1. When Random Number Generators Fail

Random number generators can fail – returning predictable non-random numbers –
if not enough entropy is available when random numbers should be generated.

No persistent clock, so boot-time is not contributing to the initial RNG state.

No hard-disk: No entropy from hard-disk timing, no way to store entropy
between reboots.

Virtual machines emulate some hardware components so that the generated
entropy is over-estimated. The most critical component that has been shown to
return wrong results is an emulated environment is the timing source (Engblom, 2011).

Typically the most vulnerable time where low-entropy situations occur is
shortly after a reboot. Unfortunately many operating system installers create
cryptographic keys shortly after a reboot (Heninger, Durumeric, Wustrow, & Halderman, 2012).

Another problem is that OpenSSL seeds its internal random generator only
seldomly from the hardware random number generator of the operating system. This
can lead to situations where a daemon that is started at a time when entropy is
low keeps this low-entropy situation for hours leading to predictable session keys (Heninger, Durumeric, Wustrow, & Halderman, 2012).

For systems where – during the lifetime of the keys – it is expected that
low-entropy situations occur, RSA keys should be preferred over DSA keys: For
DSA, if there is ever insufficient entropy at the time keys are used for signing
this may lead to repeated ephemeral keys. An attacker who can guess an ephemeral
private key used in such a signature can compromise the DSA secret key. For RSA
this can lead to discovery of encrypted plaintext or forged signatures but not
to the compromise of the secret key (Heninger, Durumeric, Wustrow, & Halderman, 2012).

20. Keylengths

On the choice between AES256 and AES128: I would never consider
using AES256, just like I don't wear a helmet when I sit inside my car. It's
too much bother for the epsilon improvement in security.

Recommendations on keylengths need to be adapted regularly. Since this
document first of all is static and second of all, does not consider
itself to be authoritative on keylengths, we would rather refer to
existing publications and websites. Recommending a safe key length is a
hit-and-miss issue.

Furthermore, when choosing an encryption algorithm and key length, the
designer/sysadmin always needs to consider the value of the information
and how long it must be protected. In other words: consider the number
of years the data needs to stay confidential.

The ECRYPT II publication
gives a fascinating overview of strengths of
symmetric keys in chapter 5 and chapter 7. Summarizing ECRYPT II, we
recommend 128 bit of key strength for symmetric keys. In ECRYPT II, this
is considered safe for security level 7, long term protection.

In the same ECRYPT II publication you can find a practical comparison of
key size equivalence between symmetric key sizes and RSA, discrete log
(DLOG) and EC keylengths. ECRYPT II arrives at the interesting
conclusion that for an equivalence of 128 bit symmetric size, you will
need to use an 3248 bit RSA key (II & SYM, 2012).

There are a couple of other studies comparing keylengths and their
respective strengths. The website https://www.keylength.com/ compares
these papers and offers a good overview of approximations for key
lengths based on recommendations by different standardization bodies and
academic publications. Figure #fig:keylengths.com[1] shows a typical
comparison of keylengths on this web site.

20.1. Summary

For asymmetric public-key cryptography we consider any key length below
3248 bits to be deprecated at the time of this writing (for long term
protection).

For elliptic curve cryptography we consider key lengths below 256 bits
to be inadequate for long term protection.

For symmetric algorithms we consider anything below 128 bits to be
inadequate for long term protection.

20.2. Special remark on 3DES:

We want to note that 3DES theoretically has 168 bits of security,
however based on the NIST Special Publication 800-57
[26].

Due to several security
problems the effective key length should be considered 80 bits. The NIST
recommends
not to use 3DES any more and to migrate to AES as soon as possible.

21. A note on Elliptic Curve Cryptography

Everyone knows what a curve is, until he has studied enough
mathematics to become confused through the countless number
of possible exceptions.

Elliptic Curve Cryptography (simply called ECC from now on) is a
branch of cryptography that emerged in the mid-1980s. The security of
the RSA algorithm is based on the assumption that factoring large
numbers is infeasible. Likewise, the security of ECC, DH and DSA is
based on the discrete logarithm problem (i_wikipedia_Discrete logarithm_, 2013).
Finding the discrete
logarithm of an elliptic curve from its public base point is thought
to be infeasible. This is known as the Elliptic Curve Discrete
Logarithm Problem (ECDLP). ECC and the underlying mathematical
foundation are not easy to understand - luckily, there have been some
great introductions on the topic.
[27][28][29].

ECC provides for much stronger security with less computationally
expensive operations in comparison to traditional asymmetric
algorithms (See the Section Keylengths). The security of ECC
relies on the elliptic curves and curve points chosen as parameters
for the algorithm in question. Well before the NSA-leak scandal, there
has been a lot of discussion regarding these parameters and their
potential subversion. A part of the discussion involved recommended
sets of curves and curve points chosen by different standardization
bodies such as the National Institute of Standards and Technology
(NIST) [30] which were later widely
implemented in most common crypto libraries. Those parameters came
under question repeatedly from cryptographers (Bernstein & Lange, 2013).

At the time of writing, there is ongoing research as to the security
of various ECC parameters (SafeCurves: choosing safe curves for elliptic-curve cryptography, 2013). Most software configured to rely on ECC
(be it client or server) is not able to promote or black-list certain
curves. It is the hope of the authors that such functionality will be
deployed widely soon. The authors of this paper include configurations
and recommendations with and without ECC - the reader may choose to
adopt those settings as he finds best suited to his environment. The
authors will not make this decision for the reader.

Warning

One should get familiar with ECC, different curves and parameters if
one chooses to adopt ECC configurations. Since there is much
discussion on the security of ECC, flawed settings might very well
compromise the security of the entire system!

22. A note on SHA-1

In the last years several weaknesses have been shown for SHA-1. In
particular, collisions on SHA-1 can be found using 263 operations,
and recent results even indicate a lower complexity. Therefore,
ECRYPT II and NIST recommend against using SHA-1 for generating
digital signatures and for other applications that require collision
resistance. The use of SHA-1 in message authentication, e.g. HMAC, is
not immediately threatened.

We recommend using SHA-2 whenever available. Since SHA-2 is not
supported by older versions of TLS, SHA-1 can be used for message
authentication if a higher compatibility with a more diverse set of
clients is needed.

Our configurations A and B reflect this. While configuration A does not
include SHA-1, configuration B does and thus is more compatible with a
wider range of clients.

23. A note on Diffie Hellman Key Exchanges

A common question is which Diffie-Hellman (DH) parameters should be used
for Diffie Hellman key-exchanges [31]. We follow the recommendations in ECRYPT II (II & SYM, 2012).

Where configurable, we recommend using the Diffie Hellman groups defined
for IKE, specifically groups 14-18 (2048–8192 bit MODP) (Kivinen & Kojo, 2003). These groups
have been checked by many eyes and can be assumed to be secure.

For convenience, we provide these parameters as PEM files on our
webserver [32].

24. Public Key Infrastructures

Public-Key Infrastructures try to solve the problem of verifying whether
a public key belongs to a given entity, so as to prevent Man In The
Middle attacks.

There are two approaches to achieve that: Certificate Authorities and
the Web of Trust.

Certificate Authorities (CAs) sign end-entities’ certificates, thereby
associating some kind of identity (e.g. a domain name or an email
address) with a public key. CAs are used with TLS and S/MIME
certificates, and the CA system has a big list of possible and real
problems which are summarized in section Hardening PKI and
(Durumeric, Kasten, Bailey, & Halderman, 2013).

The Web of Trust is a decentralized system where people sign each
other’s keys, so that there is a high chance that there is a "trust
path" from one key to another. This is used with PGP keys, and while it
avoids most of the problems of the CA system, it is more cumbersome.

As alternatives to these public systems, there are two more choices:
running a private CA, and manually trusting keys (as it is used with SSH
keys or manually trusted keys in web browsers).

The first part of this section addresses how to obtain a certificate in
the CA system. The second part offers recommendations on how to improve
the security of your PKI.

24.1. Certificate Authorities

In order to get a certificate, you can find an external CA willing to
issue a certificate for you, run your own CA, or use self-signed
certificates. As always, there are advantages and disadvantages for
every one of these options; a balance of security versus usability needs
to be found.

24.1.1. Certificates From an External Certificate Authority

There is a fairly large number of commercial CAs that will issue
certificates for money. Some of the most ubiquitous commercial CAs are
Verisign, GoDaddy, and Teletrust. However, there are also CAs that offer
certificates for free. The most notable examples are StartSSL, which is
a company that offers some types of certificates for free, and CAcert,
which is a non-profit volunteer-based organization that does not charge
at all for issuing certificates. Finally, in the research and education
field, a number of CAs exist that are generally well-known and
well-accepted within the higher-education community.

A large number of CAs is pre-installed in client software’s or operating
system’s`‘trust stores’'; depending on your application, you have to
select your CA according to this, or have a mechanism to distribute the
chosen CA’s root certificate to the clients.

When requesting a certificate from a CA, it is vital that you generate
the key pair yourself. In particular, the private key should never be
known to the CA. If a CA offers to generate the key pair for you, you
should not trust that CA.

Generating a key pair and a certificate request can be done with a
number of tools. On Unix-like systems, it is likely that the OpenSSL
suite is available to you. In this case, you can generate a private key
and a corresponding certificate request as follows:

24.1.2. Setting Up Your Own Certificate Authority

In some situations it is advisable to run your own certificate
authority. Whether this is a good idea depends on the exact
circumstances. Generally speaking, the more centralized the control of
the systems in your environment, the fewer pains you will have to go
through to deploy your own CA. On the other hand, running your own CA
maximizes the trust level that you can achieve because it minimizes
external trust dependencies.

Again using OpenSSL as an example, you can set up your own CA with the
following commands on a Debian system:

$ cd /usr/lib/ssl/misc
$ sudo ./CA.pl -newca

Answer the questions according to your setup. Now that you have
configured your basic settings and issued a new root certificate, you
can issue new certificates as follows:

$ cd /usr/lib/ssl/misc
$ sudo ./CA.pl -newreq

Alternatively, software such as TinyCA that acts as a "wrapper"
around OpenSSL and tries to make life easier is available.

24.1.3. Creating a Self-Signed Certificate

If the desired trust level is very high and the number of systems
involved is limited, the easiest way to set up a secure environment may
be to use self-signed certificates. A self-signed certificate is not
issued by any CA at all, but is signed by the entity that it is issued
to. Thus, the organizational overhead of running a CA is eliminated at
the expense of having to establish all trust relationships between
entities manually.

With OpenSSL, you can self-sign a previously created certificate with
this command:

The resulting certificate will by default not be trusted by anyone at
all, so in order to be useful, the certificate will have to be made
known a priori to all parties that may encounter it.

24.2. Hardening PKI

In recent years several CAs were compromised by attackers in order to
get a hold of trusted certificates for malicious activities. In 2011 the
Dutch CA Diginotar was hacked and all certificates were revoked (Elinor Mills, 2011).
Recently Google found certificates issued to them, which were not used
by the company (Damon Poeter, 2011). The concept of PKIs heavily depends on the security of
CAs. If they get compromised the whole PKI system will fail. Some CAs
tend to incorrectly issue certificates that were designated to do a
different job than what they were intended to by the CA (Adam Langley, et. al., 2013).

24.3. Certification Authorization Records

RFC 6844 describes Certification Authorization Records, a mechanism for
domain name owners to signal which Certificate Authorities are
authorized to issue certificates for their domain.

When a CAA record is defined for a particular domain, it specifies that
the domain owner requests Certificate Authorities to validate any
request against the CAA record. If the certificate issuer is not listed
in the CAA record, it should not issue the certificate.

The RFC also permits Certificate Evaluators to test an issued
certificate against the CAA record, but should exercise caution, as the
CAA record may change during the lifetime of a certificate, without
affecting its validity.

CAA also supports an iodef property type which can be requested by a
Certificate Authority to report certificate issue requests which are
inconsistent with the issuer’s Certificate Policy.

"ca1.example" and "ca2.example" are unique identifiers for the CA
you plan on using. These strings can be obtained from your Certificate
Authority, and typically are its top level domain. An example is
"letsencrypt.org" for the Let’s Encrypt CA operated by the Internet
Security Research Group.

Knot-DNS supports CAA records as of version 2.2.0.

24.3.2. Validation of CAA records

Once a CAA record is deployed, it can be validated using the following
dig query:

25. TLS and its support mechanisms

25.1. HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) is a web security policy mechanism.
HSTS is realized through HTTP header by which a web server declares that
complying user agents (web browsers) should interact with it by using only
secure HTTPS connections.
[33]

HSTS header is bound to a DNS name or domain by which the server was accessed.
For example if server serves content for two domains and it is HTTPS enabled
only for one domain, the browser won’t enforce HSTS for the latter.

HSTS reduces the risk of active man-in-the-middle attacks such as SSL stripping,
and impersonation attacks with untrusted certificate.
HSTS also helps to avoid unintentional mistakes such as insecure links to a
secure web site (missing HTTPS links
[34]), and mistyped HTTPS URLs.

After the web browser receives a HSTS header in a correctly[35]
prepared SSL session it will automatically use secure HTTPS links for accessing
the server.

This prevents unencrypted HTTP access (SSL striping, mistyped HTTPS URLs, etc.)
when the server is accessed later by the client.

When a server (that previously emitted a HSTS header) starts using an
untrusted certificate, complying user agents must show an error
message and block the server connection. Thus impersonation MITM
attack with untrusted certificates cannot occur.

For the initial setup HSTS header needs a trusted secure connection over HTTPS.
This limitation can be addressed by compiling a list of STS enabled sites
directly into a browser.
[36]

25.1.1. HSTS Header Directives

HSTS header can be parametrized by two directives:

max-age=<number-of-seconds>

includeSubdomains

max-age is a required directive.
This directive indicates the number of seconds during which the user agent
should enforce the HSTS policy (after the reception of the STS header field from
a server).

includeSubdomains is an optional directive.
This directive indicates that the HSTS policy applies to this HSTS host as well
as any subdomains of the host’s domain name.

25.1.3. HSTS Considerations

Before enabling HSTS it is recommended to consider following:

Is it required to serve content or services over HTTP?

Enabling includeSubdomains and SSL certificate management.

Proper value of max-age.

It is recommended to serve all content using HTTPS, but there are exceptions to
this rule as well.
Consider running a private PKI
[38].
CRLs and OCSP responses are published typically by HTTP protocol.
If HSTS is enabled on the site where OCSP and CRLs are published the browser
might fail fetching CRL or validating OCSP response.

Similar reasoning goes for includeSubdomains.
One needs to be sure that HTTPS can be enforced for all subdomains.
Moreover the administrators are advised to watch for expiration of the SSL
certificate and handle the renewal process with caution.
If a SSL certificate is renewed after expiration or misses a (HSTS enabled)
domain name, the connection to site will break (without providing override
mechanism to the end user).

Finally HSTS should be tested with lower max-age values and deployed with
higher max-age values.

25.1.4. Testing HSTS

HSTS can be tested either using locally or through the Internet.

For local testing it is possible to utilize Chrome Web browser UI by typing
chrome://net-internals/#hsts
[39]
in the address bar.

Testing over the Internet can be conducted by Qualys SSL Labs test
https://www.ssllabs.com/ssltest/.
Strict Transport Security (HSTS) information is located in the
Protocol Details section.

25.2. HTTP Public Key Pinning (HPKP)

Much like HTTP Strict Transport Security (HSTS), HTTP Public Key Pinning (HPKP)
is a Trust-On-First-Use (TOFU) mechanism.
It protects HTTPS websites from impersonation using certificates issued by
compromised certificate authorities.
The data for Pinning is supplied by an HTTP-Header sent by the WebServer.

pin-sha256 is a required directive.
It can and should be used several (at least two) times for specifying the public
keys of your domain-certificates or CA-certificates.
Operators can pin any one or more of the public keys in the certificate-chain,
and indeed must pin to issuers not in the chain (as, for example, a backup-pin).
Pinning to an intermediate issuer, or even to a trust anchor or root, still
significantly reduces the number of issuers who can issue end-entity
certificates for the Known Pinned Host, while still giving that host flexibility
to change keys without a disruption of service.
OpenSSL can be used to convert the public-key of an X509-certificate as follows:

This piped usage of OpenSSL first gets the Public-Key of <certificate.cer>,
converts it do DER (binary) format, calculates an SHA256 Hash and finally
encodes it Base64.
The output (including the ending Equal-Sign) is exactly whats needed for the
pin-sha256="<YOUR_PUBLICKEY_HASH⇒" parameter.

To generate the hash for a prepared backup-key just create a
certificate-signing-request and replace openssl x509 by
openssl req -in <backup-cert.csr> -pubkey -noout as first OpenSSL
command.

max-age is a required directive (when using the Public-Key-Pins header).
This directive specifies the number of seconds during which the user agent
should regard the host (from whom the message was received) as a "Known Pinned
Host".

includeSubdomains is an optional directive.
This directive indicates that the same pinning applies to this host as well as
any subdomains of the host’s domain name.
Be careful - you need to use a multi-domain/wildcard-certificate or use the same
pub/private-keypair in all subdomain-certificates or need to pin to
CA-certificates signing all your subdomain-certificates.

report-uri is an optional directive.
The presence of a report-uri directive indicates to the web-browser that in the
event of pin-validation failure, it should post a report to the report-uri
(HTTP-Post is done using JSON, Syntax see {RFC-7469 Section 3}
[40]).
There are WebServices like https://report-uri.io/ out there which can be used to
easily collect and visualize these reports.

25.2.2. HPKP Client Support

Currently (20. Dec 2018) there is no HPKP support in: Apple Safari,
Microsoft Internet Explorer and Edge. HPKP Support has been removed
from Google Chrome and Chromium from version 72 onwards.

25.2.3. HPKP Considerations

Before enabling HPKP it is recommended to consider following:

Which Public-Keys to use for Pinning (Certificate + Backup-Certificate, CAs,
Intermediate-CAs)

Proper value of max-age. Start testing with a short Period, increase Period after deployment.

Be careful when using includeSubdomains, are all your subdomains covered by
the defined Public-Key-Hashes?

The administrators are advised to watch for expiration of the SSL certificate
and handle the renewal process with caution.

If a SSL certificate is renewed without keeping the public-key (reusing the CSR)
for an HPKP enabled domain name, the connection to site will break (without
providing override mechanism to the end user).

25.2.4. Testing HPKP

HPKP can be tested either using locally or through the Internet.

There is a handy bash-script which uses OpenSSL for doing several SSL/TLS-Tests
available at https://testssl.sh/

IV: Appendix

26. Tools

This section lists tools for checking the security settings.

26.1. SSL & TLS

Server checks via the web

ssllabs.com offers a great way to check your webserver for
misconfigurations. See https://www.ssllabs.com/ssltest/. Furthermore,
ssllabs.com has a good best practices tutorial, which focuses on avoiding the
most common mistakes in SSL.

The list of OpenSSL Ciphers was generated with OpenSSL 1.0.1e 11 Feb 2013.

30. Further Research

The following is a list of services, software packages, hardware devices or
protocols that we considered documenting but either did not manage to document
yet or might be able to document later. We encourage input from the community.