0% found this document useful (0 votes)

62 views94 pages

Applied Crypto Hardening

This document is a draft revision of a guide on applied cryptography hardening. It was last revised on February 18, 2015 by Aaron Zauner. The guide provides recommendations for system administrators on configuring encryption for web servers, SSH, and mail servers to best secure communications and protect against surveillance. It acknowledges that while crypto tools can help, other attacks still require different protections that are outside the scope of this guide.

Uploaded by

Surf Men

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

62 views94 pages

Applied Crypto Hardening

Uploaded by

Surf Men

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

Applied Crypto Hardening

Wolfgang Breyha, David Durvaux, Tobias Dussa, L. Aaron Kaplan, Florian Mendel,
Christian Mock, Manuel Koschuch, Adi Kriegisch, Ulrich Pöschl, Ramin Sabet, Berg
San, Ralf Schlatterbeck, Thomas Schreck, Alexander Würstlein, Aaron Zauner, Pepi
Zawodsky

(University of Vienna, CERT.be, KIT-CERT, CERT.at, A-SIT/IAIK, coretec.at, FH Campus Wien, VRVis,
MilCERT Austria, A-Trust, Runtux.com, Friedrich-Alexander University Erlangen-Nuremberg,
azet.org, maclemon.at)

March 1, 2015

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

Do not talk unencrypted

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 2 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

Acknowledgements

We would like to express our thanks to the following reviewers and people who have generously
offered their time and interest (in alphabetical order):

Brown, Scott O’Brien, Hugh

Brulebois, Cyril Pacher, Christoph
Dirksen-Thedens, Mathis Palfrader, Peter
Dulaunoy, Alexandre Pape, Tobias (layout)
Gühring Philipp Petukhova, Anna (Logo)
Grigg, Ian Pichler, Patrick
Horenbeck, Maarten Riebesel, Nicolas
Huebl, Axel Roeckx, Kurt
Kovacic, Daniel Rublik, Martin
Lenzhofer, Stefan Schwarz, René («DigNative»)
Lorünser, Thomas Seidl, Eva (PDF layout)
Mehlmauer, Christian Wagner, Sebastian («sebix»)
Millauer, Tobias Zangerl, Alexander
Mirbach, Andreas

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.

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 3 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

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.”
— Ross Anderson in [And08]

This guide arose out of the need for system administrators to have an updated, solid, well re-
searched 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 admin-
istrators 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 [Sch13a], 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 conﬁgurations 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 B and C at the end of this document.

The focus of this guide is merely to give current best practices for conﬁguring complex cipher suites
and related parameters in a copy & paste-able manner. The guide tries to stay as concise as is pos-
sible for such a complex topic as cryptography. Naturally, it can not be complete. There are many
excellent guides [IS12, fSidIB13, ENI13] and best practice documents available when it comes to
cryptography. However none of them focuses speciﬁcally on what an average system administrator
needs for hardening his or her systems’ crypto settings.

This guide tries to ﬁll this gap.

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

Contents

1. Introduction 7
1.1. Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. How to read this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Disclaimer and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2. Practical recommendations 11
2.1. Webservers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1. Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2. lighttpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3. nginx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.4. Cherokee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.5. MS IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1. OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2. Cisco ASA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.3. Cisco IOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3. Mail Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.1. SMTP in general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.2. Dovecot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.3. cyrus-imapd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.4. Postﬁx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.5. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4. VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.2. Check Point FireWall-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.3. PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.4. Cisco ASA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.5. Openswan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.6. tinc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5. PGP/GPG - Pretty Good Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.6. IPMI, ILO and other lights out management solutions . . . . . . . . . . . . . . . . . . . 43
2.7. Instant Messaging Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.7.1. General server conﬁguration recommendations . . . . . . . . . . . . . . . . . . 43
2.7.2. ejabberd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.7.3. Chat privacy - Off-the-Record Messaging (OTR) . . . . . . . . . . . . . . . . . . 45
2.7.4. Charybdis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.7.5. SILC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.8. Database Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.8.1. Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.8.2. MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.8.3. DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.8.4. PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 5 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

Contents Contents

2.9. Intercepting proxy solutions and reverse proxies . . . . . . . . . . . . . . . . . . . . . 49

2.9.1. Bluecoat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.9.2. Pound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.9.3. stunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.10.Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.10.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.10.2. Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3. Theory 58
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2. Cipher suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.1. Architectural overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.2. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.2.3. Recommended cipher suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.2.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3. Random Number Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.3.1. When random number generators fail . . . . . . . . . . . . . . . . . . . . . . . 63
3.3.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.3.3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4. Keylengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.5. A note on Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.6. A note on SHA-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.7. A note on Diﬃe Hellman Key Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.8. Public Key Infrastructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.8.1. Certiﬁcate Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.8.2. Hardening PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.9. TLS and its support mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.9.1. HTTP Strict Transport Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

A. Tools 76
A.1. SSL & TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A.2. Key length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.3. RNGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.4. Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

B. Links 78

C. Suggested Reading 79

D. Cipher Suite Name Cross-Reference 80

E. Further research 89

Index 94

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 6 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

1. Introduction

1.1. Audience

Sysadmins. Sysadmins. Sysadmins. They are a force-multiplier.

1.2. Related publications

Ecrypt II [IS12], ENISA’s report on Algorithms, key sizes and parameters [ENI13] and BSI’s Technische
Richtlinie TR-02102 [fSidIB13] are great publications which are more in depth than this guide.
However, this guide has a different approach: it focuses on copy & paste-able settings for system
administrators, effectively breaking down the complexity in the above mentioned reports to an
easy to use format for the intended target audience.

1.3. How to read this guide

This guide tries to accommodate two needs: ﬁrst of all, having a handy reference on how to
conﬁgure 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 chose 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 chapter 2 (“Practical recommendations”).

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 the latter is a weaker one
but provides wider compatibility. Cipher strings A and B are described in 3.2.3.

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

While chapter 2 is intended to serve as a copy & paste reference, chapter 3 (“Theory”) explains the
reasoning behind cipher string B. In particular, section 3.2 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.

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 7 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

1.4. Disclaimer and scope 1.4. Disclaimer and scope

Start Introduction

No time, I just want yes

to copy & paste read Practical recommendations

To understand why we chose

certain settings, read Theory ﬁrst re-read Practical recommendations

Appendix: references, links

1.4. Disclaimer and scope

“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 terriﬁcally weak that
NSA can frequently ﬁnd ways around it.”
— Edward Snowden, answering questions live on the
Guardian’s website [Gle13]

This guide speciﬁcally does not address physical security, protecting software and hardware against
exploits, basic IT security housekeeping, information assurance techniques, traﬃc analysis attacks,
issues with key-roll over and key management, securing client PCs and mobile devices (theft,
loss), proper Operations Security1 , social engineering attacks, protection against tempest [Wik13c]
attack techniques, thwarting different side-channel attacks (timing–, cache timing–, differential fault
analysis, differential power analysis or power monitoring attacks), downgrade attacks, jamming
the encrypted channel or other similar attacks which are typically employed to circumvent strong
encryption. The authors can not overstate the importance of these other techniques. Interested

1 https://en.wikipedia.org/wiki/Operations_security

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 8 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

1.4. Disclaimer and scope 1.4. Disclaimer and scope

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.2

This guide does not talk much about the well-known insecurities of trusting a public-key infrastruc-
ture (PKI)3 . Nor does this text fully explain how to run your own Certiﬁcate Authority (CA).

Most of this zoo of information security issues are addressed in the very comprehensive book
“Security Engineering” by Ross Anderson [And08].

For some experts in cryptography this text might seem too informal. However, we strive to keep the
language as non-technical as possible and ﬁtting 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. Security is a process.

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.

Scope

In this guide, we restricted ourselves to:

• Internet-facing services
• Commonly used services
• Devices which are used in business environments (this speciﬁcally excludes XBoxes, Playsta-
tions and similar consumer devices)
• OpenSSL

We explicitly excluded:

• Specialized systems (such as medical devices, most embedded systems, industrial control
systems, etc.)

2 An easy to read yet very insightful recent example is the "FLUSH+RELOAD" technique [YF13] for leaking cryptographic
keys from one virtual machine to another via L3 cache timing attacks.
3 Interested readers are referred to https://bugzilla.mozilla.org/show_bug.cgi?id=647959 or http://www.h-online.com/

security/news/item/Honest-Achmed-asks-for-trust-1231314.html which brings the problem of trusting PKIs right to the

point

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 9 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

1.5. Methods 1.5. Methods

• Wireless Access Points

• Smart-cards/chip cards

1.5. Methods

“C.O.S.H.E.R - completely open source, headers, engineering

and research
— A. Kaplan’s mail signature for many years

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 the section
“Acknowledgements”. Every write operation to the document is logged via the “git” version control
system and can thus be traced back to a speciﬁc author. We accept “git pull requests” on the github
mirror4 for this paper.

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

We invite the gentle reader to participate in this public review process.

4 https://github.com/BetterCrypto/Applied-Crypto-Hardening
5 http://www.wired.com/opinion/2013/10/how-to-design-and-defend-against-the-perfect-backdoor/

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 10 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2. Practical recommendations

2.1. Webservers

2.1.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 1 )

Tested with Versions

• Apache 2.2.22 linked against OpenSSL 1.0.1e, Debian Wheezy

• Apache 2.4.6 linked against OpenSSL 1.0.1e, Debian Jessie

Settings

Enabled modules SSL and Headers are required.

SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
#SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCompression off
# Add six earth month HSTS header for all users...
Header always set Strict-Transport-Security "max-age=15768000"
# If you want to protect all subdomains, use the following header
# ALL subdomains HAVE TO support HTTPS if you use this!
# Strict-Transport-Security: "max-age=15768000 ; includeSubDomains"
SSLCipherSuite 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+\
\aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!\
\eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256\
\-SHA:CAMELLIA128-SHA:AES128-SHA'

Listing 2.1: SSL conﬁguration for an Apache vhost

[configuration/Webservers/Apache/default-ssl]

1 https://www.mail-archive.com/[email protected]/msg33405.html

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 11 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.1. Webservers 2.1.2. lighttpd

Additional settings

You might want to redirect everything to https:// if possible. In Apache you can do this with the
following setting inside of a VirtualHost environment:
<VirtualHost *:80>
Redirect permanent / https://SERVER_NAME/
</VirtualHost>

Listing 2.2: https auto-redirect vhost

[configuration/Webservers/Apache/hsts-vhost]

References

• Apache2 Docs on SSL and TLS: https://httpd.apache.org/docs/2.4/ssl/

How to test

See appendix A

2.1.2. lighttpd

Tested with Versions

• lighttpd/1.4.31-4 with OpenSSL 1.0.1e on Debian Wheezy

• 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)

Settings

$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+SHA384:\
\EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!\
\aNULL!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:\
\AES256-SHA:CAMELLIA128-SHA:AES128-SHA"
ssl.honor-cipher-order = "enable"

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 12 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.1. Webservers 2.1.2. lighttpd

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")
}

Listing 2.3: SSL conﬁguration for lighttpd

[configuration/Webservers/lighttpd/10-ssl.conf]

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.

# use group16 dh parameters

ssl.dh-file = "/etc/lighttpd/ssl/dh4096.pem"
ssl.ec-curve = "secp384r1"

Listing 2.4: SSL EC/DH conﬁguration for lighttpd

[configuration/Webservers/lighttpd/10-ssl-dh.conf]

Please read section 3.7 for more information on Diﬃe Hellman key exchange and elliptic curves.

Additional settings

As for any other webserver, you might want to automatically redirect http:// traﬃc 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.
$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 properly
setenv.add-environment = (
"HTTPS" => "on"
)
}

Listing 2.5: https auto-redirect conﬁguration

[configuration/Webservers/lighttpd/11-hsts.conf]

Additional information

The conﬁg 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,

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 13 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.1. Webservers 2.1.3. nginx

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.

References

• HTTPS redirection: http://redmine.lighttpd.net/projects/1/wiki/HowToRedirectHttpToHttps

• Lighttpd Docs SSL: http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL
• Release 1.4.30 (How to mitigate BEAST attack) http://redmine.lighttpd.net/projects/lighttpd/
wiki/Release-1_4_30
• SSL Compression disabled by default: http://redmine.lighttpd.net/issues/2445

How to test

See appendix A

2.1.3. nginx

Tested with Version

• 1.4.4 with OpenSSL 1.0.1e on OS X Server 10.8.5

• 1.2.1-2.2+wheezy2 with OpenSSL 1.0.1e on Debian Wheezy
• 1.4.4 with OpenSSL 1.0.1e on Debian Wheezy
• 1.2.1-2.2 bpo60+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)

Settings

ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # not possible to do exclusive
ssl_ciphers 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+\
\aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!\
\eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256\
\-SHA:CAMELLIA128-SHA:AES128-SHA';
add_header Strict-Transport-Security max-age=15768000; # six months
# use this only if all subdomains support HTTPS!
# add_header Strict-Transport-Security "max-age=15768000; includeSubDomains";

Listing 2.6: SSL settings for nginx

[configuration/Webservers/nginx/default]

If you absolutely want to specify your own DH parameters, you can specify them via

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 14 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.1. Webservers 2.1.4. Cherokee

ssl_dhparam file;

However, we advise you to read section 3.7 and stay with the standard IKE/IETF parameters (as
long as they are >1024 bits).

Additional settings

If you decide to trust NIST’s ECC curve recommendation, you can add the following line to nginx’s
conﬁguration ﬁle to select special curves:
ssl_ecdh_curve secp384r1;
Listing 2.7: SSL EC/DH settings for nginx
[configuration/Webservers/nginx/default-ec]

You might want to redirect everything to https:// if possible. In Nginx you can do this with the
following setting:
return 301 https://$host$request_uri;
Listing 2.8: https auto-redirect in nginx
[configuration/Webservers/nginx/default-hsts]

References

• http://nginx.org/en/docs/http/ngx_http_ssl_module.html
• http://wiki.nginx.org/HttpSslModule

How to test

See appendix A

2.1.4. Cherokee

Tested with Version

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

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.

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 15 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.1. Webservers 2.1.4. Cherokee

• 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 Certiﬁcate and Certiﬁcate key
– Advanced Options
* Ciphers: EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:
EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:
+SSLv3:!aNULL!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:
!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
* Server Preference: Prefer
* Compression: Disabled
• Advanced: TLS
– SSL version 2 and SSL version 3: No
– TLS version 1, TLS version 1.1 and TLS version 1.2: Yes

Additional settings

For each vServer on the Security tab it is possilbe to set the Diﬃe Hellman length to up to 4096
bits. We recommend to use >1024 bits. More information about Diﬃe-Hellman and which curves
are recommended can be found in section 3.7.

In Advanced: TLS it is possible to set the path to a Diﬃe Hellman parameters ﬁle for 512, 1024,
2048 and 4096 bits.

HSTS can be conﬁgured on host-basis in section vServers / Security / HTTP Strict Transport Security
(HSTS):

• Enable HSTS: Accept

• HSTS Max-Age: 15768000
• Include Subdomains: depends on your setup

To redirect HTTP to HTTPS, conﬁgure a new rule per Virtual Server in the Behavior tab. The rule is
SSL/TLS combined with a NOT operator. As Handler deﬁne Redirection and use /(.*)$ as Regular
Expression and https://${host}/$1 as Substitution.
server!bind!2!port = 443
server!bind!2!tls = 1
server!tls = libssl
vserver!1!hsts = 1
vserver!1!hsts!max_age = 15768000
vserver!1!hsts!subdomains = 1
vserver!1!rule!5!handler = redir
vserver!1!rule!5!handler!rewrite!10!regex = /(.*)$
vserver!1!rule!5!handler!rewrite!10!show = 1
vserver!1!rule!5!handler!rewrite!10!substring = https://${host}/$1
vserver!1!rule!5!handler!type = just_about

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 16 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.1. Webservers 2.1.5. MS IIS

vserver!1!rule!5!match = not
vserver!1!rule!5!match!right = tls
vserver!1!ssl_certificate_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
vserver!1!ssl_certificate_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
vserver!1!ssl_cipher_server_preference = 1
vserver!1!ssl_ciphers = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384\
\:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!\
\aNULL!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:\
\AES256-SHA:CAMELLIA128-SHA:AES128-SHA
vserver!1!ssl_compression = 0
vserver!1!ssl_dh_length = 2048

Listing 2.9: SSL conﬁguration for cherokee

[configuration/Webservers/Cherokee/cherokee.conf]

References

• Cookbook: SSL, TLS and certiﬁcates: http://cherokee-project.com/doc/cookbook_ssl.html

• Cookbook: Redirecting all traﬃc from HTTP to HTTPS: http://cherokee-project.com/doc/
cookbook_http_to_https.html

How to test

See appendix A

2.1.5. MS IIS

To conﬁgure SSL/TLS on Windows Server IIS Crypto can be used. 2 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 conﬁguration 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. 3
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\\
\Ciphers]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\\
\CipherSuites]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\\
\Hashes]

2 https://www.nartac.com/Products/IISCrypto/
3 http://support.microsoft.com/kb/245030/en-us

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 17 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.1. Webservers 2.1.5. MS IIS

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\\
\KeyExchangeAlgorithms]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\\
\Protocols]

Tested with Version

• Windows Server 2008

• Windows Server 2008 R2
• Windows Server 2012
• Windows Server 2012 R2

• Windows Vista and Internet Explorer 7 and upwards

• Windows 7 and Internet Explorer 8 and upwards
• Windows 8 and Internet Explorer 10 and upwards
• Windows 8.1 and Internet Explorer 11

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 doubts4 ).

Since one is stuck with ECDSA, an elliptic curve certiﬁcate needs to be used.

The conﬁguration of cipher suites MS IIS will use, can be conﬁgured in one of the following ways:

1. Group Policy 5

2. Registry 6

3. IIS Crypto 7

4. Powershell

Table 2.1 shows the process of turning on one algorithm after another and the effect on the
supported clients tested using https://www.ssllabs.com.

SSL 3.0, SSL 2.0 and MD5 are turned off. TLS 1.0 and TLS 1.2 are turned on.

Table 2.1 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 ﬁrst two lines) would eliminate all versions

4 http://safecurves.cr.yp.to/rigid.html
5 http://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx
6 http://support.microsoft.com/kb/245030
7 https://www.nartac.com/Products/IISCrypto/

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 18 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.1. Webservers 2.1.5. MS IIS

Table 2.1.: Client support

Cipher Suite Client

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 only IE 10,11, OpenSSL 1.0.1e

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 Chrome 30, Opera 17, Safari 6+
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA FF 10-24, IE 8+, Safari 5, Java 7

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.

Clients not supported:

1. Java 6

2. WinXP

3. Bing

Additional settings

It’s recommended to use Strict-Transport-Security: max-age=15768000 for detailed information

visit the 8 Microsoft knowledgebase.

You might want to redirect everything to https:// if possible. In IIS you can do this with the following
setting by Powershell:
Set-WebConfiguration -Location "$WebSiteName/$WebApplicationName"
-Filter 'system.webserver/security/access'
-Value "SslRequireCert"

Justiﬁcation for special settings (if needed)

References

• http://support.microsoft.com/kb/245030/en-us
• http://support.microsoft.com/kb/187498/en-us

8 http://www.iis.net/conﬁgreference/system.webserver/httpprotocol/customheaders

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 19 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.2. SSH 2.2. SSH

How to test

See appendix A

2.2. SSH

Please be advised that any change in the SSH-Settings of your server might cause problems
connecting to the server or starting/reloading the SSH-Daemon itself. So every time you conﬁg-
ure your SSH-Settings on a remote server via SSH itself, ensure that you have a second open
connection to the server, which you can use to reset or adapt your changes!

2.2.1. OpenSSH

Tested with Version

OpenSSH 6.6p1 (Gentoo)

Settings

Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
PermitRootLogin no # or 'without-password' to allow SSH key based login
StrictModes yes
PermitEmptyPasswords no
Ciphers [email protected],[email protected],aes128-gcm@openssh.\
\com,aes256-ctr,aes128-ctr
MACs [email protected],[email protected],umac-128-\
\[email protected],hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256,\
\diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1

Listing 2.10: Important OpenSSH 6.6 security settings

[configuration/SSH/OpenSSH/6.6/sshd_config]

Note: OpenSSH 6.6p1 now supports Curve25519

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 20 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.2. SSH 2.2.1. OpenSSH

Tested with Version

OpenSSH 6.5 (Debian Jessie)

Settings

Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
PermitRootLogin no # or 'without-password' to allow SSH key based login
StrictModes yes
PermitEmptyPasswords no
Ciphers [email protected],[email protected],aes256-ctr,aes128-ctr
MACs [email protected],[email protected],umac-128-\
\[email protected],hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,\
\diffie-hellman-group-exchange-sha1

Listing 2.11: Important OpenSSH 6.4 security settings

[configuration/SSH/OpenSSH/6.5/sshd_config]

Tested with Version

OpenSSH 6.0p1 (Debian wheezy)

Settings

Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
PermitRootLogin no # or 'without-password' to allow SSH key based login
StrictModes yes
PermitEmptyPasswords no
Ciphers aes256-ctr,aes128-ctr
MACs hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,\
\diffie-hellman-group-exchange-sha1

Listing 2.12: Important OpenSSH 6.0 security settings

[configuration/SSH/OpenSSH/6.0/sshd_config]

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 21 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.2. SSH 2.2.2. Cisco ASA

Note: 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 9 which is far below current standards (see section 3.4). Legacy systems can use this
conﬁguration and simply omit unsupported ciphers, key exchange algorithms and MACs.

References

The OpenSSH sshd_conﬁg man page is the best reference: http://www.openssh.org/cgi-bin/man.

cgi?query=sshd_conﬁg

How to test

Connect a client with verbose logging enabled to the SSH server

$ ssh -vvv myserver.com

and observe the key exchange in the output.

2.2.2. Cisco ASA

Tested with Versions

• 9.1(3)

Settings

crypto key generate rsa modulus 2048

ssh version 2
ssh key-exchange group dh-group14-sha1

Note: When the ASA is conﬁgured 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 reconﬁgure the lines to only
allow SSH-logins.

9 https://bugzilla.mindrot.org/show_bug.cgi?id=1647

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 22 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.2. SSH 2.2.3. Cisco IOS

References

• http://www.cisco.com/en/US/docs/security/asa/asa91/conﬁguration/general/admin_management.
html

How to test

Connect a client with verbose logging enabled to the SSH server

$ ssh -vvv myserver.com

and observe the key exchange in the output.

2.2.3. Cisco IOS

Tested with Versions

• 15.0, 15.1, 15.2

Settings

crypto key generate rsa modulus 4096 label SSH-KEYS

ip ssh rsa keypair-name SSH-KEYS
ip ssh version 2
ip ssh dh min size 2048

line vty 0 15
transport input ssh

Note: 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.

References

• http://www.cisco.com/en/US/docs/ios/sec_user_services/conﬁguration/guide/sec_cfg_secure_
shell.html

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 23 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.3. Mail Servers 2.3. Mail Servers

How to test

Connect a client with verbose logging enabled to the SSH server

$ ssh -vvv myserver.com

and observe the key exchange in the output.

2.3. Mail Servers

This section documents the most common mail (SMTP) and IMAPs/POPs servers. Another option
to secure IMAPs/POPs servers is to place them behind an stunnel server.

2.3.1. SMTP in general

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

Furthermore a mailserver can operate in three modes:

• As MSA (Mail Submission Agent) your mailserver receives mail from your clients MUAs (Mail
User Agent).
• As receiving MTA (Mail Transmission Agent, MX)
• As sending MTA (SMTP client)

We recommend the following basic setup for all modes:

• correctly setup MX, A and PTR RRs without using CNAMEs at all.
• enable encryption (opportunistic TLS)
• do not use self signed certiﬁcates

For SMTP client mode we additionally recommend:

• the hostname used as HELO must match the PTR RR

• setup a client certificate (most server certificates are client certificates as well)
• either the common name or at least an alternate subject name of your certificate must
match the PTR RR
• do not modify the cipher suite for client mode

For MSA operation we recommend:

• listen on submission port 587

• enforce SMTP AUTH even for local networks
• do not allow SMTP AUTH on unencrypted connections

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 24 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.3. Mail Servers 2.3.2. Dovecot

• optionally use the recommended cipher suites if (and only if) all your connecting MUAs
support them

We strongly recommend to allow all cipher suites for anything but MSA mode, because the alter-
native is plain text transmission.

2.3.2. Dovecot

Tested with Version

• Dovecot 2.1.7, Debian Wheezy (without “ssl_prefer_server_ciphers” setting)

• Dovecot 2.2.9, Debian Jessie
• 2.0.19apple1 on OS X Server 10.8.5 (without “ssl_prefer_server_ciphers” setting)
• Dovecot 2.2.9 on Ubuntu 14.04 trusty

Settings

# SSL protocols to use

ssl_protocols = !SSLv3 !SSLv2

# SSL ciphers to use

ssl_cipher_list = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH\
\+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!\
\eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-\
\SHA:CAMELLIA128-SHA:AES128-SHA

# Prefer the server's order of ciphers over client's.

ssl_prefer_server_ciphers = yes

Listing 2.13: Dovecot SSL conﬁguration

[configuration/MailServers/Dovecot/10-ssl.conf]

Additional info

Dovecot 2.0, 2.1: Almost as good as dovecot 2.2. Dovecot does not ignore unknown conﬁguration
parameters. Does not support ssl_prefer_server_ciphers

Limitations

Dovecot currently does not support disabling TLS compression. Furthermore, DH parameters
greater than 1024bit are not supported. The most recent version 2.2.7 of Dovecot implements
conﬁgurable DH parameter length 10 .

10 http://hg.dovecot.org/dovecot-2.2/rev/43ab5abeb8f0

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 25 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.3. Mail Servers 2.3.3. cyrus-imapd

References

• http://wiki2.dovecot.org/SSL

How to test

openssl s_client -crlf -connect SERVER.TLD:993

2.3.3. cyrus-imapd

Tested with Versions

• 2.4.17

Settings

To activate SSL/TLS conﬁgure your certiﬁcate with

tls_cert_file: /etc/ssl/certs/ssl-cert-snakeoil.pem
tls_key_file: /etc/ssl/private/ssl-cert-snakeoil.key

Listing 2.14: Activating TLS in cyrus

[configuration/MailServers/cyrus-imapd/imapd.conf]

Do not forget to add necessary intermediate certiﬁcates to the .pem ﬁle.

Limiting the ciphers provided may force (especially older) clients to connect without encryption at
all! Sticking to the defaults is recommended.

If you still want to force strong encryption use

tls_cipher_list: EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+\
\aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!\
\eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-\
\SHA:CAMELLIA128-SHA:AES128-SHA

Listing 2.15: TLS cipher selection in cyrus

[configuration/MailServers/cyrus-imapd/imapd.conf]

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

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 26 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.3. Mail Servers 2.3.4. Postﬁx

allowplaintext: no

Listing 2.16: Force encrypted connections in cyrus

[configuration/MailServers/cyrus-imapd/imapd.conf]

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
SERVICES {
imap cmd="imapd -U 30" listen="imap" prefork=0 maxchild=100
imaps cmd="imapd -s -U 30" listen="imaps" prefork=0 maxchild=100
pop3 cmd="pop3d -U 30" listen="pop3" prefork=0 maxchild=50
pop3s cmd="pop3d -s -U 30" listen="pop3s" prefork=0 maxchild=50
}

Listing 2.17: STARTTLS for POP3/IMAP and POP3S/IMAPS in cyrus

[configuration/MailServers/cyrus-imapd/cyrus.conf]

Limitations

cyrus-imapd currently (2.4.17, trunk) does not support elliptic curve cryptography. Hence, ECDHE
will not work even if deﬁned in your cipher list.

Currently there is no way to prefer server ciphers or to disable compression.

There is a working patch for all three features: https://bugzilla.cyrusimap.org/show_bug.cgi?id=

3823

How to test

openssl s_client -crlf -connect SERVER.TLD:993

2.3.4. Postﬁx

Tested with Versions

• Postﬁx 2.9.6, Debian Wheezy

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 27 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.3. Mail Servers 2.3.4. Postﬁx

Settings

MX and SMTP client conﬁguration: As discussed in section 2.3.1, because of opportunistic encryp-
tion we do not restrict the list of ciphers. There are still some steps needed to enable TLS, all in
main.cf:
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
# use 0 for Postfix >= 2.9, and 1 for earlier versions
smtpd_tls_loglevel = 0
# enable opportunistic TLS support in the SMTP server and client
smtpd_tls_security_level = may
smtp_tls_security_level = may
smtp_tls_loglevel = 1
# if you have authentication enabled, only offer it after STARTTLS
smtpd_tls_auth_only = yes
tls_ssl_options = NO_COMPRESSION

Listing 2.18: Opportunistic TLS in Postﬁx

[configuration/MailServers/Postfix/main.cf]

MSA: For the MSA smtpd process, we ﬁrst deﬁne the ciphers that are acceptable for the “manda-
tory” security level, again in main.cf:
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers=high
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:\
\EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL\
\:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256\
\-SHA:CAMELLIA128-SHA:AES128-SHA

Listing 2.19: MSA TLS conﬁguration in Postﬁx

[configuration/MailServers/Postfix/main.cf]

Then, we conﬁgure the MSA smtpd in master.cf with two additional options that are only used for
this instance of smtpd:
submission inet n - - - - smtpd
-o smtpd_tls_security_level=encrypt
-o tls_preempt_cipherlist=yes

Listing 2.20: MSA smtpd service conﬁguration in Postﬁx

[configuration/MailServers/Postfix/master.cf]

For those users who want to use EECDH key exchange, it is possible to customize this via:
smtpd_tls_eecdh_grade=ultra

Listing 2.21: EECDH customization in Postﬁx

[configuration/MailServers/Postfix/main.cf]

The default value since Postﬁx 2.8 is “strong”.

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 28 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.3. Mail Servers 2.3.5. Exim

Limitations

tls_ssl_options is supported from Postﬁx 2.11 onwards. You can leave the statement in the conﬁg-
uration for older versions, it will be ignored.

tls_preempt_cipherlist is supported from Postﬁx 2.8 onwards. Again, you can leave the statement
in for older versions.

References

Refer to http://www.postﬁx.org/TLS_README.html for an in-depth discussion.

Additional settings

Postﬁx 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 3.7) without much
interoperability risk, but we have not tested this yet.

How to test

You can check the effect of the settings with the following command:
$ zegrep "TLS connection established from.*with cipher" /var/log/mail.log | awk \
\'{printf("%s %s %s %s\n", $12, $13, $14, $15)}' | sort | uniq -c | sort -n
1 SSLv3 with cipher DHE-RSA-AES256-SHA
23 TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384
60 TLSv1 with cipher ECDHE-RSA-AES256-SHA
270 TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
335 TLSv1 with cipher DHE-RSA-AES256-SHA

openssl s_client -starttls smtp -crlf -connect SERVER.TLD:25

2.3.5. Exim

Tested with Versions

• Exim 4.82, Debian Jessie

Applied Crypto Hardening • Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner page 29 of 94

Draft revision: 7b6fd17 (2015-02-18 19:45:16 +0100) Aaron Zauner

2.3. Mail Servers 2.3.5. Exim

It is highly recommended to read http://exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_

smtp_connections_using_tlsssl.html ﬁrst.