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 in an emulated environment is the
-timing source\cite{Eng11,POL11}.
+timing source~\cite{Eng11,POL11}.
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\cite{HDWH12}.
+create cryptographic keys shortly after a reboot~\cite{HDWH12}.
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\cite{HDWH12}.
+leading to predictable session keys~\cite{HDWH12}.
\subsection{Linux}
Unfortunately most crypto implementations are using \verb+/dev/urandom+
and can produce predictable random numbers if not enough entropy has
-been collected\cite{HDWH12}.
+been collected~\cite{HDWH12}.
Linux supports the injection of additional entropy into the entropy pool
via the device \verb+/dev/random+. On the one hand this is used for
(e.g. by writing to \verb+/dev/random+ on Linux) is recommended. Note
that only a process run as root can update the entropy counters in the
kernel, each non-root user-process can feed entropy to the pool but
-cannot update the counters\cite{Wikipedia:/dev/random}.
+cannot update the counters~\cite{Wikipedia:/dev/random}.
For Linux the \verb+haveged+
-implementation\cite{HAV13a} based on the HAVEGE\cite{SS03}
+implementation~\cite{HAV13a} based on the HAVEGE~\cite{SS03}
strong random number generator currently looks like the best choice. It
can feed its generated entropy into the kernel entropy pool and recently
has grown a mechanism to monitor the quality of generated random
-numbers\cite{HAV13b}. The memory footprint may be too high for small
+numbers~\cite{HAV13b}. The memory footprint may be too high for small
embedded devices, though.
For systems where -- during the lifetime of the keys -- it is expected
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\cite{HDWH12}.
+signatures but not to the compromise of the secret key~\cite{HDWH12}.
\begin{abstract}
\section*{Abstract}
-\epigraph{``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 \cite{anderson2008security}}
+\epigraph{``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~\cite{anderson2008security}}
This guide arose out of the need for system administrators to have an
updated, solid, well researched and thought-through guide for configuring SSL,
configuring complex cipher suites} and related parameters in a \emph{copy \&
paste-able manner}. The guide tries to stay as concise as is possible for such
a complex topic as cryptography. Naturaly, it can not be complete. Instead,
-there are many excellent guides (\cite{ii2011ecrypt},\cite{TR02102}) and best
+there are many excellent guides~\cite{ii2011ecrypt,TR02102} 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.
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.''}{Edward
Snowden, answering questions live on the Guardian's
-website\cite{snowdenGuardianGreenwald}}
+website~\cite{snowdenGuardianGreenwald}}
This guide specifically does not address physical security, protecting software
assurance techniques, traffic analysis attacks, issues with key-roll over and
key management, securing client PCs and mobile devices (theft, loss), proper
OPSec\footnote{\url{http://en.wikipedia.org/wiki/Operations_security}}, social
-engineering attacks, anti-tempest\cite{Wikipedia:Tempest} attack techniques,
+engineering attacks, anti-tempest~\cite{Wikipedia:Tempest} attack techniques,
protecting against 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
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.\footnote{An easy to read yet very insightful recent example is the
-"FLUSH+RELOAD" technique \cite{yarom2013flush+} for leaking cryptographic keys
+"FLUSH+RELOAD" technique~\cite{yarom2013flush+} for leaking cryptographic keys
from one virtual machine to another via L3 cache timing attacks.}
This guide does not talk much about the well-known insecurities of trusting a
Most of this zoo of information security issues are addressed in the very
-comprehensive book ``Security Engineering'' by Ross Anderson
-\cite{anderson2008security}.
+comprehensive book ``Security Engineering'' by Ross Anderson~\cite{anderson2008security}.
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
This guide tries to accommodate two needs: first of all, having a handy reference on how to configure the most common services's crypto settings and second of all, explaining a bit, how to chose your own cipher 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 \ref{section:PracticalSettings} (``Practical recommendations''). However, for the quick copy \& paste approach it is important to know that this guide assumes users are happy with \textit{cipher String B} which is the baseline and most compatible recommendation that the authors came up with. \textit{Cipher string B} is described in \ref{section:recommendedciphers}.
-\textit{Cipher String B} covers the most common use-cases (such as running an e-commerce shop, a private homepage, a mail server, $ \ldots $)
+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 \ref{chapter:PracticalSettings} (``Practical recommendations''). However, for the quick copy \& paste approach it is important to know that this guide assumes users are happy with \textit{cipher String B} which is the baseline and most compatible recommendation that the authors came up with. \textit{Cipher string B} is described in \ref{section:recommendedciphers}. \textit{Cipher String B} covers the most common use-cases (such as running an e-commerce shop, a private homepage, a mail server, $ \ldots $)
-While chapter \ref{section:PracticalSettings} is intended to serve as a copy \& paste reference, chapter \ref{chapter:Theory} (``Theory'') explains the reasoning behind \textit{cipher string B}. In particular, section \ref{section:CipherSuites} explains how to choose individual cipher strings. We advise the reader to actually read this section and challenge our reasoning in choosing \textit{cipher string B} and to come up with a better or localized solution.
+While chapter \ref{chapter:PracticalSettings} is intended to serve as a copy \& paste reference, chapter \ref{chapter:Theory} (``Theory'') explains the reasoning behind \textit{cipher string B}. In particular, section \ref{section:CipherSuites} explains how to choose individual cipher strings. We advise the reader to actually read this section and challenge our reasoning in choosing \textit{cipher string B} and to come up with a better or localized solution.
%We start with some general remarks in sections \ref{section:DH},\ref{section:EllipticCurveCryptography},\ref{section:keylengths} on
%If you are a system administrator and want to quickly update your services, jump right to section \ref{section:PracticalSettings}. However, we recommend that you take some time and first read through the theory part (chapter \ref{chapter:Theory}), especially section \ref{section:CipherSuites} on how to choose your own cipher string and then adapt the settings in section \ref{section:PracticalSettings} to your own needs.
\item SSL and the Future of Authenticity, Moxie Marlinspike - Black Hat USA 2011: \url{http://www.youtube.com/watch?v=Z7Wl2FW2TcA}
\item ENISA - Algorithms, Key Sizes and Parameters Report (Oct.'13) \url{http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report}
\item Diffie-Hellman Groups \url{http://ibm.co/18lslZf}
-\item Diffie-Hellman Groups standardized in RFC3526\cite{rfc3526} \url{http://datatracker.ietf.org/doc/rfc3526/}
-\item ECC-enabled GnuPG per RFC6637\cite{rfc6637} \url{https://code.google.com/p/gnupg-ecc}
+\item Diffie-Hellman Groups standardized in RFC3526~\cite{rfc3526} \url{http://datatracker.ietf.org/doc/rfc3526/}
+\item ECC-enabled GnuPG per RFC6637~\cite{rfc6637} \url{https://code.google.com/p/gnupg-ecc}
\item TLS Security (Survey + Lucky13 + RC4 Attack) by Kenny Paterson \url{https://www.cosic.esat.kuleuven.be/ecc2013/files/kenny.pdf}
\item Ensuring High-Quality Randomness in Cryptographic Key Generation \url{http://arxiv.org/abs/1309.7366v1}
\item Wikipedia: Ciphertext Stealing \url{http://en.wikipedia.org/wiki/Ciphertext_stealing}
\begin{figure}[H]
% move this epigraph to a fitting place. I don't see why it fits here inside of the begin figure env. ~~ AK
%\epigraph{``[...] be conservative in what you do, be liberal in what
-%you accept from others.''}{The robustness priciple or "Postel's Law"\cite{rfc761}}
+%you accept from others.''}{The robustness priciple or ``Postel's Law''~\cite{rfc761}}
\centering
\includegraphics[width=0.9\textwidth]{neboltai.png}
\caption*{Do not talk unencrypted}
to the main configuration.\\
Note: +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\cite{rfc5114} (ike23).
+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~\cite{rfc5114} (ike23).
If you want to set your own DH parameters please read the TLS documentation of exim.\\
The size of the PSK should not be shorter than the output size of
the hash algorithm used in IKE \footnote{It is used in a HMAC, see
-RFC2104\cite{rfc2104} and the discussion starting
+RFC2104~\cite{rfc2104} and the discussion starting
in \url{http://www.vpnc.org/ietf-ipsec/02.ipsec/msg00268.html}.}.
For a key composed of upper- and lowercase letters, numbers, and two
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.
-\footnote{RFC6379\cite{rfc6379}, RFC4308\cite{rfc4308}}
+\footnote{RFC6379~\cite{rfc6379}, RFC4308~\cite{rfc4308}}
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
\label{section:relatedPublications}
-Ecrypt II (\cite{ii2011ecrypt}), ENISA's report on Algorithms, key sizes and
-parameters (\cite{ENISA2013}) and BSI's Technische Richtlinie TR-02102 (\cite{TR02102}) are
-great publications which are more in depth than this guide. However, this guide
-has a different approach: it focuses on \emph{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.
+Ecrypt II~\cite{ii2011ecrypt}, ENISA's report on Algorithms, key sizes and
+parameters~\cite{ENISA2013} and BSI's Technische Richtlinie
+TR-02102~\cite{TR02102} are great publications which are more in depth than
+this guide. However, this guide has a different approach: it focuses on
+\emph{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.
\texttt{TLS\_RSA\_CAMELLIA\_256\_CBC\_SHA1} in GnuTLS is equivalent to
\texttt{CAMELLIA256-SHA} in OpenSSL and \texttt{TLS\_RSA\_WITH\_CAMELLIA\_256\_CBC\_SHA}
in the IANA standard with the hex code \texttt{0x00,0x84} as specified
-in RFC5932\cite{rfc5932}. Section \ref{section:cipher_suite_names}
+in RFC5932~\cite{rfc5932}. Section \ref{section:cipher_suite_names}
lists all currently defined cipher suites with their codes and both names.
Regardless of this clash of nomenclature, as a sysadmin you are required to check what the SSL libraries on
\section{A note on Diffie Hellman Key Exchanges}
\label{section:DH}
-A common question is which Diffie Hellman (DH) Parameters should be used for Diffie Hellman key exchanges\footnote{\url{http://crypto.stackexchange.com/questions/1963/how-large-should-a-diffie-hellman-p-be}}. We follow the recommendations in ECRYPT II, chapter 16.\cite{ii2011ecrypt}
+A common question is which Diffie Hellman (DH) Parameters should be used for
+Diffie Hellman key
+exchanges\footnote{\url{http://crypto.stackexchange.com/questions/1963/how-large-should-a-diffie-hellman-p-be}}.
+We follow the recommendations in ECRYPT II~\cite[chapter 16]{ii2011ecrypt}
Where configurable, we recommend using the Diffie Hellman groups
-defined for IKE, specifically groups 14-18 (2048--8192 bit MODP \cite{rfc3526}).
+defined for IKE, specifically groups 14-18 (2048--8192 bit MODP~\cite{rfc3526}).
These groups have been checked by many eyes and can be assumed to be secure.
For convenience, we provide these parameters as PEM files. \todo{put
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\cite{Wikipedia:Discrete,McC90,WR13}. Finding the discrete logarithm of
+problem~\cite{Wikipedia:Discrete,McC90,WR13}. 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
National Institute of Standards and Technology (NIST)
\footnote{\url{http://www.nist.gov}} which were later widely implemented in
most common crypto libraries. Those parameters came under question repeatedly
-from cryptographers\cite{BL13,Sch13b,W13}. At the time of writing, there is
-ongoing research as to the security of various ECC parameters\cite{DJBSC}.
+from cryptographers~\cite{BL13,Sch13b,W13}. At the time of writing, there is
+ongoing research as to the security of various ECC parameters~\cite{DJBSC}.
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
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 \ref{sec:hardeningpki} and
-\cite{https13}.
+problems which are summarized in section \ref{sec:hardeningpki} and~\cite{https13}.
The Web of Trust is a decentralized system where people sign each
others keys, so that there is a high chance that there is a ``trust
% sudo ./CA.pl -newreq
\end{lstlisting}
-Alternatively, software such as TinyCA\cite{Wikipedia:TinyCA} that
+Alternatively, software such as TinyCA~\cite{Wikipedia:TinyCA} that
acts as a ``wrapper'' around OpenSSL and tries to make life easier is
available.
% plugins: CipherFox, Conspiracy, Perspectives.}
-% ``Certificate Policy''\cite{Wikipedia:Certificate_Policy} (CA)
+% ``Certificate Policy''~\cite{Wikipedia:Certificate_Policy} (CA)
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 in an emulated environment is the
-timing source\cite{Eng11,POL11}.
+timing source~\cite{Eng11,POL11}.
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\cite{HDWH12}.
+create cryptographic keys shortly after a reboot~\cite{HDWH12}.
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\cite{HDWH12}.
+leading to predictable session keys~\cite{HDWH12}.
\subsection{Linux}
Unfortunately most crypto implementations are using \verb+/dev/urandom+
and can produce predictable random numbers if not enough entropy has
-been collected\cite{HDWH12}.
+been collected~\cite{HDWH12}.
Linux supports the injection of additional entropy into the entropy pool
via the device \verb+/dev/random+. On the one hand this is used for
(e.g. by writing to \verb+/dev/random+ on Linux) is recommended. Note
that only a process with root rights can update the entropy counters in the
kernel; non-root or user processes can still feed entropy to the pool but
-cannot update the counters\cite{Wikipedia:/dev/random}.
+cannot update the counters~\cite{Wikipedia:/dev/random}.
For Linux the \verb+haveged+
-implementation\cite{HAV13a} based on the HAVEGE\cite{SS03}
+implementation~\cite{HAV13a} based on the HAVEGE~\cite{SS03}
strong random number generator currently looks like the best choice. It
can feed its generated entropy into the kernel entropy pool and recently
has grown a mechanism to monitor the quality of generated random
-numbers\cite{HAV13b}. The memory footprint may be too high for small
+numbers~\cite{HAV13b}. The memory footprint may be too high for small
embedded devices, though.
For systems where -- during the lifetime of the keys -- it is expected
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\cite{HDWH12}.
+signatures but not to the compromise of the secret key~\cite{HDWH12}.
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.'' \cite{katz2008introduction}
+line does not learn anything about the resulting secret key.''~\cite{katz2008introduction}
Example: \texttt{DHE}
Note: There are some very weak cipher suites in every crypto library, most of
them for historic reasons or due to legacy standards. The crypto export embargo
-is a good example\cite{Wikipedia:ExportCipher}. For the following chapter
+is a good example~\cite{Wikipedia:ExportCipher}. For the following chapter
support of these low-security algorithms is disabled by setting
\texttt{!EXP:!LOW:!NULL} as part of the cipher string.
required by current TLS standards only consist of the so-called NIST-curves
(\texttt{secp256r1} and \texttt{secp384r1}) which may be weak because the
parameters that led to their generation were not properly explained by the
-authors\cite{DJBSC}. \\ Disabling support for Elliptic Curves leads to no
+authors~\cite{DJBSC}. Disabling support for Elliptic Curves leads to no
ephemeral key exchange being available for the Windows platform. When you
decide to use Elliptic Curves despite the uncertainty, make sure to at least
use the stronger curve of the two supported by all clients
data needs to stay confidential.
-The ECRYPT II publication (\cite{ii2011ecrypt}) gives a fascinating overview of
+The ECRYPT II publication~\cite{ii2011ecrypt} 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.
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. See chapter 7 of \cite{ii2011ecrypt}, page 30.
+key~\cite[chapter 7, page 30]{ii2011ecrypt}.
There are a couple of other studies comparing keylengths and their respective
This chapter provides the necessary background information on why chapter \ref{chapter:PracticalSettings} recommended \textit{cipher string B}.
-We start off by explaining the structure of cipher strings in section \ref{subsection:architecture} (architecture) and define Perfect Forward Secrecy (PFS) in \ref{subsection:PFS}. Next we present \textit{Cipher String A} and \textit{Cipher String B} in section \ref{section:recommendedciphers}. This concludes the section on cipher strings. In theory, the reader should now be able to construct his or her own cipher string. However, the question why certain settings were chosen still remains. To answer this part, we need to look at recommended keylengths, problems in specific algorithms and hash functions and other cryptographic parameters. As mentioned initially in section \ref{section:relatedPublications}, the ENISA (\cite{ENISA2013}), ECRYPT 2 (\cite{ii2011ecrypt}) and BSI (\cite{TR02102}) reports go much more into these topics and should be consulted in addition.
+We start off by explaining the structure of cipher strings in section \ref{subsection:architecture} (architecture) and define Perfect Forward Secrecy (PFS) in \ref{subsection:PFS}. Next we present \textit{Cipher String A} and \textit{Cipher String B} in section \ref{section:recommendedciphers}. This concludes the section on cipher strings. In theory, the reader should now be able to construct his or her own cipher string. However, the question why certain settings were chosen still remains. To answer this part, we need to look at recommended keylengths, problems in specific algorithms and hash functions and other cryptographic parameters. As mentioned initially in section \ref{section:relatedPublications}, the ENISA~\cite{ENISA2013}, ECRYPT 2~\cite{ii2011ecrypt} and BSI~\cite{TR02102} reports go much more into these topics and should be consulted in addition.
-We try to answer the questions by explaining issues with random number generators (section \ref{section:RNGs}), keylengths (section \ref{section:keylengths}), current issues in ECC (section \ref{section:EllipticCurveCryptography}), a note of warning on SHA-1 (section \ref{section:SHA}) and some comments on Diffie Hellman key exchanges (section \ref{section:DH}). All of this is important in understanding why certain choices were made for \textit{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 \ref{subsection:compatibility}.
-All these sections will allow a system administrator to balance his or her needs for strong encryption with usability and compatibility.
+We try to answer the questions by explaining issues with random number generators (section \ref{section:RNGs}), keylengths (section \ref{section:keylengths}), current issues in ECC (section \ref{section:EllipticCurveCryptography}), a note of warning on SHA-1 (section \ref{section:SHA}) and some comments on Diffie Hellman key exchanges (section \ref{section:DH}). All of this is important in understanding why certain choices were made for \textit{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 \ref{subsection:compatibility}. 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 \ref{section:PKIs}), 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.
+Last but not least, we finish this chapter by talking about issues in PKIs (section \ref{section:PKIs}), 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.
%%% Local Variables:
%%% mode: latex
git.bettercrypto.org / ach-master.git / commitdiff