Merge branch 'master' of https://git.bettercrypto.org/ach-master into theory-rewrite
authorAaron Kaplan <aaron@lo-res.org>
Mon, 23 Dec 2013 20:28:29 +0000 (21:28 +0100)
committerAaron Kaplan <aaron@lo-res.org>
Mon, 23 Dec 2013 20:28:29 +0000 (21:28 +0100)
Conflicts:
src/RNGs.tex

49 files changed:
src/DH.tex [deleted file]
src/ECC.tex [deleted file]
src/Makefile
src/PKIs.tex [deleted file]
src/SHA.tex [deleted file]
src/abstract.tex
src/applied-crypto-hardening.synctex.gz [deleted file]
src/applied-crypto-hardening.tex
src/checkpoint_1.png [deleted file]
src/checkpoint_2.png [deleted file]
src/checkpoint_3.png [deleted file]
src/checkpoint_4.png [deleted file]
src/cipher_suites.tex [deleted file]
src/cipher_suites/architecture.tex [deleted file]
src/cipher_suites/choosing.tex [deleted file]
src/cipher_suites/compatibility.tex [deleted file]
src/cipher_suites/forward.tex [deleted file]
src/cipher_suites/insecure.tex [deleted file]
src/cipher_suites/recommended.tex [deleted file]
src/disclaimer.tex
src/howtoread.tex
src/img/checkpoint_1.png [new file with mode: 0644]
src/img/checkpoint_2.png [new file with mode: 0644]
src/img/checkpoint_3.png [new file with mode: 0644]
src/img/checkpoint_4.png [new file with mode: 0644]
src/img/keylengths_com.png [new file with mode: 0644]
src/keylengths.tex [deleted file]
src/keylengths_com.png [deleted file]
src/methods.tex
src/practical_settings/mailserver.tex
src/practical_settings/ssh.tex
src/practical_settings/vpn.tex
src/practical_settings/webserver.tex
src/related_publications.tex [new file with mode: 0644]
src/security.bib
src/theory.tex [new file with mode: 0644]
src/theory/DH.tex [new file with mode: 0644]
src/theory/ECC.tex [new file with mode: 0644]
src/theory/SHA.tex [new file with mode: 0644]
src/theory/cipher_suites.tex [new file with mode: 0644]
src/theory/cipher_suites/architecture.tex [new file with mode: 0644]
src/theory/cipher_suites/choosing.tex [new file with mode: 0644]
src/theory/cipher_suites/compatibility.tex [new file with mode: 0644]
src/theory/cipher_suites/forward.tex [new file with mode: 0644]
src/theory/cipher_suites/insecure.tex [new file with mode: 0644]
src/theory/cipher_suites/recommended.tex [new file with mode: 0644]
src/theory/keylengths.tex [new file with mode: 0644]
src/theory/overview.tex [new file with mode: 0644]
src/whoshouldread.tex [new file with mode: 0644]

diff --git a/src/DH.tex b/src/DH.tex
deleted file mode 100644 (file)
index 4a869a5..0000000
+++ /dev/null
@@ -1,12 +0,0 @@
-\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}
-
-Where configurable, we recommend using the Diffie Hellman groups
-defined for IKE, specifically groups 14-18 (for MODP, \cite{rfc3526})
-and 19-21 (for elliptic curve DH, \cite{rfc5903}). 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
-  them on the server and insert URL here}.
diff --git a/src/ECC.tex b/src/ECC.tex
deleted file mode 100644 (file)
index e3b5aa0..0000000
+++ /dev/null
@@ -1,47 +0,0 @@
-\section{A note on Elliptic Curve Cryptography}
-\label{section:EllipticCurveCryptography}
-
-Elliptic Curve Cryptogaphy (simply called ECC from now on) is a branch of 
-cryptography that emerged in the mid-1980ties.
-The security of the RSA algorithm is based on the assumption that factoring 
-large primes is infeasible. Likewise the security of ECC, DH and DSA is 
-based on the discrete logrithm 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 have been some great introductions on the topic lately
-\footnote{\url{http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography}}
-\footnote{\url{https://www.imperialviolet.org/2010/12/04/ecc.html}}
-\footnote{\url{http://www.isg.rhul.ac.uk/~sdg/ecc.html}}.
-
-ECC provides for much stronger security with less computonally expensive
-operations in comparison to traditional PKI algorithms (See the Section \ref{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) 
-\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}.
-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.
-
-
-\textbf{A word of 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!
-
-%% mention different attacks on ECC besides flawed parameters!
-
index 79584c9..ecbcd2e 100644 (file)
@@ -41,7 +41,8 @@ clean:
        rm -f applied-crypto-hardening.aux applied-crypto-hardening.bbl \
             applied-crypto-hardening.blg applied-crypto-hardening.dvi   \
             applied-crypto-hardening.log applied-crypto-hardening.pdf   \
-            applied-crypto-hardening.toc applied-crypto-hardening.markdown
+            applied-crypto-hardening.toc applied-crypto-hardening.markdown \
+                       applied-crypto-hardening.out
        find . -name "*_generated.tex" -exec rm \{\} \;
        rm -rf applied-crypto-hardening/
        rm -rf gitHeadInfo.gin
diff --git a/src/PKIs.tex b/src/PKIs.tex
deleted file mode 100644 (file)
index a5b87ac..0000000
+++ /dev/null
@@ -1,155 +0,0 @@
-\section{Public Key Infrastructures}
-\label{section:PKIs}
-
-Public-Key Infrastructures aim to provide a way to simplify the verification of
-a certificate's trustworthiness.  For this, certificate authorities (CAs) are
-used to create a signature chain from the root CA down to the server (or client).
-Accepting a CA as a generally-trusted mediator solves the trust-scaling problem
-at the cost of introducing an actor that magically is more trustworthy.
-
-The first part of this section addresses how to obtain a certificate.  The
-second part offers recommendations on how to improve the security of your
-PKI.
-
-\subsection{Certificate Authorities}
-\label{sec:cas}
-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.
-
-\subsubsection{Certificates From an External Certificate Authority}
-\label{sec:signcertfromca}
-
-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 organisation 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.
-
-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 Unixoid 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:
-
-\begin{lstlisting}[breaklines]
-% openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize>
-Country Name (2 letter code) [AU]:DE
-State or Province Name (full name) [Some-State]:Bavaria
-Locality Name (eg, city) []:Munich
-Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example
-Organizational Unit Name (eg, section) []:Example Section
-Common Name (e.g. server FQDN or YOUR name) []:example.com
-Email Address []:admin@example.com
-
-Please enter the following 'extra' attributes
-to be sent with your certificate request
-A challenge password []:
-An optional company name []:
-\end{lstlisting}
-
-\subsubsection{Setting Up Your Own Certificate Authority}
-\label{sec:setupownca}
-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:
-
-\begin{lstlisting}
-% cd /usr/lib/ssl/misc
-% sudo ./CA.pl -newca
-\end{lstlisting}
-
-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:
-
-\begin{lstlisting}
-% cd /usr/lib/ssl/misc
-% sudo ./CA.pl -newreq
-\end{lstlisting}
-
-\subsubsection{Creating a Self-Signed Certificate}
-\label{sec:pki:selfsignedcert}
-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, a self-signed certificate may be created with this command:
-
-\begin{lstlisting}
-% openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
-\end{lstlisting}
-
-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.
-
-
-\subsection{Hardening PKI}
-\label{sec:hardeningpki}
-In recent years several CAs were compromised by attackers in order to
-get ahold of trusted certificates for malicious activities. In 2011 
-the Dutch CA Diginotar was hacked and all certificates were
-revoked~\cite{diginotar-hack}. Recently Google found certificates
-issued to them, which were not used by the
-company~\cite{googlecahack}. 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~\cite{gocode}.
-
-Therefore several security enhancements were introduced by different
-organisations and vendors~\cite{tschofenig-webpki}. Currently two
-methods are used, DANE~\cite{rfc6698} and Certificate
-Pinning~\cite{draft-ietf-websec-key-pinning}. Google recently proposed
-a new system to detect malicous CAs and certificates  called Certificate 
-Transparency~\cite{certtransparency}.
-
-% \subsubsection{DANE}
-% \label{sec:dane}
-
-% \subsubsection{Certificate Pinning}
-% \label{sec:certpinning}
-
-
-
-% This section deals with settings related to trusting CAs. However,
-% our main recommendations for PKIs is: if you are able to run your
-% own PKI and disable any other CA, do so. This makes sense most in
-% environments where any machine-to-machine communication system
-% compatibility with external entities is not an issue.
-%% azet: this needs discussion! self-signed certificates simply do not
-%% work in practices for real-world scenarios - i.e. websites that
-%% actually serve a lot of people
-
-% A good background on PKIs can be found in
-% \footnote{\url{https://developer.mozilla.org/en/docs/Introduction_to_Public-Key_Cryptography}}
-% \footnote{\url{http://cacr.uwaterloo.ca/hac/about/chap8.pdf}}
-% \footnote{\url{http://www.verisign.com.au/repository/tutorial/cryptography/intro1.shtml}}
-% .
-
-% \todo{ts: Background and Configuration (EMET) of Certificate Pinning,
-%   TLSA integration, When to use self-signed certificates, how to get
-%   certificates from public CA authorities (CACert, StartSSL),
-%   Best-practices how to create a CA and how to generate private
-%   keys/CSRs, Discussion about OCSP and CRLs. TD: Useful Firefox
-%   plugins: CipherFox, Conspiracy, Perspectives.}
-
-
-% ``Certificate Policy''\cite{Wikipedia:Certificate_Policy} (CA)
diff --git a/src/SHA.tex b/src/SHA.tex
deleted file mode 100644 (file)
index fb88353..0000000
+++ /dev/null
@@ -1,21 +0,0 @@
-\section{A note on SHA-1}
-\label{section:SHA}
-
-
-In the last years several weaknesses have been shown for SHA-1. In
-particular, collisions on SHA-1 can be found using $2^{63}$ 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.
index f1160a4..f9c3e61 100644 (file)
@@ -14,7 +14,7 @@
 
 \vskip 2em
 
-\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}}
 
 \vskip 2em
 
diff --git a/src/applied-crypto-hardening.synctex.gz b/src/applied-crypto-hardening.synctex.gz
deleted file mode 100644 (file)
index 6364daf..0000000
Binary files a/src/applied-crypto-hardening.synctex.gz and /dev/null differ
index 18f7215..1b5857d 100644 (file)
@@ -49,7 +49,6 @@
 
 
 
-
 \usepackage{gitinfo}
 
 % custom changes:
 \definecolor{CadetBlue}{cmyk}{0.62,0.57,0.23,0}
 \definecolor{lightlightgray}{gray}{0.9}
 
+\usepackage{titlesec}
+%\allsectionsfont{\color{darkblue}\itshape\underline}
+%\sectionfont{\color{darkblue}\itshape\selectfont}
+%\subsectionfont{\color{darkblue}\itshape\selectfont}
+\renewcommand*\sectfont{\sffamily\color{darkblue}\mdseries}
+%\renewcommand*\sectfont{\rmfamily\mdseries\itshape}
+
+
 % makes default font sans-serif
  \renewcommand{\familydefault}{\sfdefault}
 
@@ -219,7 +226,7 @@ morekeywords={__global__, __device__},  %
 \date{\today}
 
 % hyperref needs to be the last package you load.
-\usepackage[pdftex,breaklinks,colorlinks,citecolor=blue,urlcolor=blue]{hyperref}
+\usepackage[pdftex,breaklinks,colorlinks,linkcolor=darkblue,citecolor=blue,urlcolor=blue]{hyperref}
 
 
 %%% Begin document
@@ -234,6 +241,8 @@ morekeywords={__global__, __device__},  %
 \tableofcontents
 \chapter{Introduction}
 \label{chapter:Intro}
+\input{whoshouldread}
+\input{related_publications}
 \input{howtoread}
 \input{disclaimer}
 \input{motivation}
@@ -244,16 +253,9 @@ morekeywords={__global__, __device__},  %
 \input{practical_settings}
 %%
 \chapter{Theory}
-\epigraph{``Number theorists are like lotus-eaters - having tasted this food they can never give it up.''}{-- Leopold Kronecker}
+%\epigraph{``Number theorists are like lotus-eaters - having tasted this food they can never give it up.''}{-- Leopold Kronecker}
 \label{chapter:Theory}
-\input{PKIs}
-\input{ECC}
-\input{SHA}
-\input{DH}
-\input{keylengths}
-\input{RNGs}
-\input{cipher_suites}
-\input{ssllibs}
+\input{theory}
 \chapter{Appendix}
 \input{tools}
 \input{links}
diff --git a/src/checkpoint_1.png b/src/checkpoint_1.png
deleted file mode 100644 (file)
index 88f5266..0000000
Binary files a/src/checkpoint_1.png and /dev/null differ
diff --git a/src/checkpoint_2.png b/src/checkpoint_2.png
deleted file mode 100644 (file)
index 0323e29..0000000
Binary files a/src/checkpoint_2.png and /dev/null differ
diff --git a/src/checkpoint_3.png b/src/checkpoint_3.png
deleted file mode 100644 (file)
index e6bbe0a..0000000
Binary files a/src/checkpoint_3.png and /dev/null differ
diff --git a/src/checkpoint_4.png b/src/checkpoint_4.png
deleted file mode 100644 (file)
index b5d2a24..0000000
Binary files a/src/checkpoint_4.png and /dev/null differ
diff --git a/src/cipher_suites.tex b/src/cipher_suites.tex
deleted file mode 100644 (file)
index a03e33f..0000000
+++ /dev/null
@@ -1,34 +0,0 @@
-
-\section{Cipher suites}
-\label{section:CipherSuites}
-\todo{team: section \ref{section:CipherSuites} is currently a bit messy. Re-do it}
-
-
-\subsection{Architectural overview }
-\label{subsection:architecture}
-\input{"./cipher_suites/architecture.tex"}
-
-
-\subsection{Forward Secrecy}
-\label{subsection:PFS}
-\input{"./cipher_suites/forward.tex"}
-
-
-\subsection{Recommended cipher suites}
-\label{section:recommendedciphers}
-\input{"./cipher_suites/recommended.tex"}
-
-
-%\subsection{Known insecure and weak cipher suites}
-%\input{"./cipher_suites/insecure.tex"}
-
-
-\subsection{Compatibility}
-\label{subsection:compatibility}
-\input{"./cipher_suites/compatibility.tex"}
-
-
-\subsection{Choosing your own cipher suites}
-\label{section:ChoosingYourOwnCipherSuites}
-\input{"./cipher_suites/choosing.tex"}
-
diff --git a/src/cipher_suites/architecture.tex b/src/cipher_suites/architecture.tex
deleted file mode 100644 (file)
index e4e8bca..0000000
+++ /dev/null
@@ -1,54 +0,0 @@
-%%\subsection{Architectural overview }
-
-This section defines some terms which will be used throughout this guide.
-
-
-A cipher suite is a standardised collection of key exchange algorithms, encryption 
-algorithms (ciphers) and Message authentication codes (MAC) algortihm that provides
-authenticated encryption schemes. It consists of the following components:
-
-\begin{description}
-
-\item{\it 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.'' \cite{katz2008introduction}
-
-Example: \texttt{DHE}
-
-\item{\it Authentication:}
-The client authenticates the server by its certificate. Optionally the server 
-may authenticate the client certificate.
-
-Example: \texttt{RSA}
-
-\item{\it Cipher:}
-The cipher is used to encrypt the message stream. It also contains the key size
-and mode used by the suite.
-
-Example: \texttt{AES256}
-
-\item{\it Message authentication code (MAC):}
-A MAC ensures that the message has not been tampered with (integrity).
-
-Examples: \texttt{SHA256}
-
-\item{\it 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: \texttt{AES256-GCM}
-
-
-
-\begin{figure}[h]
-\makebox[\textwidth]{
-\framebox[1.1\width]{ \texttt{DHE} }--\framebox[1.1\width]{ \texttt{RSA} }--\framebox[1.1\width]{ \texttt{AES256} }--\framebox[1.1\width]{ \texttt{SHA256} } }
-\caption{Composition of a typical cipher string}
-\end{figure}
-
-\item {\textbf{A note on nomenclature:}} there are two common naming schemes for cipher strings -- IANA names (see section \ref{section:Links}) and the more well known OpenSSL names. In this document we will always use OpenSSL names unless a specific service uses IANA names.
-
-\end{description}
diff --git a/src/cipher_suites/choosing.tex b/src/cipher_suites/choosing.tex
deleted file mode 100644 (file)
index b31a23b..0000000
+++ /dev/null
@@ -1,248 +0,0 @@
-%%\subsection{Choosing your own cipher suites}
-%%\label{section:ChoosingYourOwnCipherSuites}
-
-\todo{ Adi...  you want to describe how to make your own selection of cipher suites here.}
-
-%%SSL/TLS cipher suites consist of a key exchange algorithm, an authentication, a
-%%stream cipher (or a block cipher with a chaining mode) and a message authentication
-%%mechanism.
-%% ^^ commented out due to duplication (see previous section on architecture) - azet
-
-Many of the parts in a ciphersuite are interchangeable. Like the key exchange
-algorithm in this example: \texttt{ECDHE-RSA-AES256-GCM-SHA384} and
-\texttt{DHE-RSA-AES256-GCM-SHA384}.  To provide a decent level of security, all
-algorithms need to be safe (subject to the disclaimer in section
-\ref{section:disclaimer}).
-
-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
-support of these low-security algorithms is disabled by setting
-\texttt{!EXP:!LOW:!NULL} as part of the cipher string.
-
-\todo{Team: do we need references for all cipher suites considered weak?}
-
-\subsubsection{Key Exchange}
-
-Many algorithms allow secure key exchange.  Those are RSA, DH, EDH, ECDSA,
-ECDH, EECDH amongst others. During the key exchange, keys used for authentication
-and symmetric encryption are exchanged. For RSA, DSA and ECDSA those keys are derived
-from the server's public key.
-
-\todo{explain this section}
-
-\begin{center}
-\begin{tabular}{llll}
-    \toprule
-          & \textbf{Key}  & \textbf{EC}  & \textbf{ephemeral} \\ \cmidrule(lr){1-4}
-   RSA    & RSA           & no           & no                 \\
-   DH     & RSA           & no           & no                 \\
-   EDH    & RSA           & no           & yes                \\
-   ECDH   & both          & yes          & no                 \\
-   EECDH  & both          & yes          & yes                \\
-   DSA    & DSA           & no           & no                 \\
-   ECDSA  & DSA           & yes          & no                 \\
-\bottomrule
-\end{tabular}
-%\\
-%\\
-%disabled: \texttt{!PSK:!SRP}
-\end{center}
-
-\textbf{Ephemeral Key Exchange} uses different keys for authentication (the server's RSA
-key) and encryption (a randomly created key). This advantage is called ``Forward
-Secrecy'' and means that even recorded traffic cannot be decrypted later when someone
-obtains the server key. \\
-All ephemeral key exchange schemes are based on the Diffie-Hellman algorithm and require
-pre-generated Diffie-Hellman parameter (which allow fast ephemeral key generation). It
-is important to note that the Diffie-Hellman parameter settings need to reflect at least 
-the security (speaking in number of bits) as the RSA host key. \todo{TODO: reference!}
-
-
-\textbf{Elliptic Curves} (see section \ref{section:EllipticCurveCryptography})
-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 weren't properly explained by the
-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
-(\texttt{secp384r1}).
-
-
-Other key exchange mechanisms like Pre-Shared Key (PSK) are irrelevant for
-regular SSL/TLS use.
-
-\subsubsection{Authentication}
-
-RSA, DSA, DSS, ECDSA, ECDH
-
-During Key Exchange the server proved that he is in control of the private key
-associated with a certain public key (the server's certificate). The client
-verifies the server's identity by comparing the signature on the certificate
-and matching it with its trust database. For details about the trust model of
-SSL/TLS please see \ref{section:PKIs}.
-
-In addition to the server providing its identity, a client might do so as well.
-That way mutual trust can be established. Another mechanism providing client
-authentication is Secure Remote Password (SRP)\todo{reference}. All those
-mechanisms require special configuration.
-
-Other authentication mechanisms like Pre Shared Keys aren't used in SSL/TLS.
-Anonymous sessions will not be discussed in this paper.
-
-\texttt{!PSK:!aNULL}
-
-\subsubsection{Encryption}
-
-AES, CAMELLIA, SEED, ARIA(?), FORTEZZA(?)...
-
-Other ciphers like IDEA, RC2, RC4, 3DES or DES are weak and therefor not recommended:
-\texttt{!DES:!3DES:!RC2:!RC4:!eNULL}
-
-\subsubsection{Message authentication}
-
-SHA-1 (SHA), SHA-2 (SHA256, SHA384), AEAD
-
-Note that SHA-1 is considered broken and should not be used. SHA-1 is however the
-only still available message authentication mechanism supporting TLS1.0/SSLv3. Without
-SHA-1 most clients will be locked out.
-
-Other hash functions like MD2, MD4 or MD5 are unsafe and broken: \texttt{!MD2:!MD4:!MD5}
-
-\subsubsection{Combining cipher strings}
-%% reference 'man ciphers' and 'openssl ciphers' and show some simple examples
-%% VERY IMPORTANT: hint at the IANA-list and the differences in implementations
-
-\todo{ Adi...  The text below was simply the old text, still left here for reference.}
-
-%%% NOTE: we do not need to list this all here, can move to an appendix
-%At the time of this writing, SSL is defined in RFCs:  
-%
-%\begin{itemize}
-%\item RFC2246 - TLS1.0                
-%\item RFC3268 - AES           
-%\item RFC4132 - Camelia               
-%\item RFC4162 - SEED          
-%\item RFC4279 - PSK           
-%\item RFC4346 - TLS 1.1               
-%\item RFC4492 - ECC           
-%\item RFC4785 - PSK\_NULL             
-%\item RFC5246 - TLS 1.2               
-%\item RFC5288 - AES\_GCM              
-%\item RFC5289 - AES\_GCM\_SHA2\_ECC           
-%\item RFC5430 - Suite B               
-%\item RFC5487 - GCM\_PSK              
-%\item RFC5489 - ECDHE\_PSK            
-%\item RFC5932 - Camelia               
-%\item RFC6101 - SSL 3.0               
-%\item RFC6209 - ARIA          
-%\item RFC6367 - Camelia               
-%\item RFC6655 - AES\_CCM              
-%\item RFC7027 - Brainpool Curves              
-%\end{itemize}
-
-%\subsubsection{Overview of SSL Server settings}
-%
-%
-%Most Server software (Webservers, Mail servers, etc.) can be configured to prefer certain cipher suites over others. 
-%We followed the recommendations by Ivan Ristic's SSL/TLS Deployment Best Practices\footnote{\url{https://www.ssllabs.com/projects/best-practices/index.html}} document (see section 2.2 "Use Secure Protocols") and arrived at a list of recommended cipher suites for SSL enabled servers.
-%
-%Following Ivan Ristic's adivce we arrived at a categorisation of cipher suites.
-%
-%\begin{center}
-%\begin{tabular}{lllll}
-%\cmidrule[\heavyrulewidth]{2-5}
-%& \textbf{Version}   & \textbf{KeyEx} & \textbf{Cipher}    & \textbf{MAC}       \\\cmidrule(lr){2-5}
-%\cellcolor{green}prefer  & TLS 1.2   & DHE\_DSS   & AES\_256\_GCM   & SHA384        \\
-%    &   & DHE\_RSA   & AES\_256\_CCM   & SHA256        \\
-%    &   & ECDHE\_ECDSA   & AES\_256\_CBC   &       \\
-%    &   & ECDHE\_RSA &   &       \\ 
-%    &   &   &   &       \\
-%\cellcolor{orange}consider    & TLS 1.1   & DH\_DSS    & AES\_128\_GCM   & SHA       \\
-%    & TLS 1.0   & DH\_RSA    & AES\_128\_CCM   &       \\
-%    &   & ECDH\_ECDSA    & AES\_128\_CBC   &       \\ 
-%    &   & ECDH\_RSA  & CAMELLIA\_256\_CBC  &       \\
-%    &   & RSA   & CAMELLIA\_128\_CBC  &       \\
-%    &   &   &   &       \\
-%\cellcolor{red}avoid   
-%& SSL 3.0   & NULL  & NULL  & NULL      \\
-%    &   & DH\_anon   & RC4\_128   & MD5       \\
-%    &   & ECDH\_anon & 3DES\_EDE\_CBC  &       \\
-%    &   &   & DES\_CBC   &       \\
-%    &   &   &   &       \\
-%\cellcolor{blue}{\color{white}special }
-%&   & PSK   & CAMELLIA\_256\_GCM  &       \\
-%    &   & DHE\_PSK   & CAMELLIA\_128\_GCM  &       \\
-%    &   & RSA\_PSK   & ARIA\_256\_GCM  &       \\
-%    &   & ECDHE\_PSK & ARIA\_256\_CBC  &       \\
-%    &   &   & ARIA\_128\_GCM  &       \\
-%    &   &   & ARIA\_128\_CBC  &       \\
-%    &   &   & SEED  &       \\
-%\cmidrule[\heavyrulewidth]{2-5}
-%\end{tabular}
-%\end{center}
-%
-%A remark on the ``consider'' section: the BSI (Federal office for information security, Germany) recommends in its technical report TR-02102-2\footnote{\url{https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html}} to \textbf{avoid} non-ephemeral\footnote{Ephemeral keys are session keys which are destroyed upon termination of the encrypted session. In TLS/SSL, they are realized by the DHE cipher suites. } keys for any communication which might contain personal or sensitive data. In this document, we follow BSI's advice and therefore only keep cipher suites containing (EC)DH\textbf{E} (ephemeral) variants. System administrators, who can not use forward secrecy can still use the cipher suites in the ``consider'' section. We however, do not recommend them in this document.
-%
-%%% NOTE: s/forward secrecy/perfect forward secrecy???
-%
-%Note that the entries marked as ``special'' are cipher suites which are not common to all clients (webbrowsers etc).
-%
-%
-%\subsubsection{Tested clients}
-% 
-%Next we tested the cipher suites above on the following clients:
-%
-%%% NOTE: we need to test with more systems!!
-%\begin{itemize}
-%\item Chrome 30.0.1599.101 Mac OS X 10.9
-%\item Safari 7.0 Mac OS X 10.9
-%\item Firefox 25.0 Mac OS X 10.9
-%\item Internet Explorer 10 Windows 7
-%\item Apple iOS 7.0.3
-%\end{itemize}
-%
-%
-%The result of testing the cipher suites with these clients gives us a preference order as shown in table \ref{table:prefOrderCipherSuites}. 
-%Should a client not be able to use a specific cipher suite, it will fall back to the next possible entry as given by the ordering.
-%
-%\begin{table}[h]
-%\centering\small
-%    \begin{tabular}{cllcccc}
-%    \toprule
-%    \textbf{Pref}   & \textbf{Cipher Suite}                            & \textbf{ID}   & \multicolumn{4}{l}{\textbf{Supported by}}\\ 
-%    \cmidrule(lr){4-7}
-%                    & \textbf{OpenSSL Name}                            &               & Chrome & FF   & IE   & Safari \\
-%    \cmidrule(lr){1-7}
-%    \phantom{0}1    & \verb|TLS_DHE_RSA_WITH_AES_256_GCM_SHA384|     & \verb|0x009f| & \no    & \no  & \no  & \no    \\
-%                    & \verb|DHE-RSA-AES256-GCM-SHA384|                      &               & &&&\\\rowcolor{lightlightgray}
-%    \phantom{0}2    & \verb|TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384| & \verb|0xC024| & \no    & \no  & \no  & \yes   \\\rowcolor{lightlightgray}
-%                    & \verb|ECDHE-ECDSA-AES256-SHA384|                      &               & &&&\\
-%    \phantom{0}3    & \verb|TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384|   & \verb|0xC028| & \no    & \no  & \no  & \yes   \\
-%                    & \verb|ECDHE-RSA-AES256-SHA384|                        &               & &&&\\\rowcolor{lightlightgray}
-%    \phantom{0}4    & \verb|TLS_DHE_RSA_WITH_AES_256_CBC_SHA256|     & \verb|0x006B| & \yes   & \no  & \no  & \yes   \\\rowcolor{lightlightgray}
-%                    & \verb|DHE-RSA-AES256-SHA256|                          &               & &&&\\
-%    \phantom{0}5    & \verb|TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA|    & \verb|0xC00A| & \yes   & \yes & \yes & \yes   \\
-%                    & \verb|ECDHE-ECDSA-AES256-SHA|                         &               & &&&\\\rowcolor{lightlightgray}
-%    \phantom{0}6    & \verb|TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA|      & \verb|0xC014| & \yes   & \yes & \yes & \yes   \\\rowcolor{lightlightgray}
-%                    & \verb|ECDHE-RSA-AES256-SHA|                           &               & &&&\\
-%    \phantom{0}7    & \verb|TLS_DHE_RSA_WITH_AES_256_CBC_SHA|        & \verb|0x0039| & \yes   & \yes & \no  & \yes   \\
-%                    & \verb|DHE-RSA-AES256-SHA|                             &               & &&&\\\rowcolor{lightlightgray}
-%    \phantom{0}8    & \verb|TLS_DHE_DSS_WITH_AES_256_CBC_SHA|        & \verb|0x0038| & \no    & \yes & \yes & \no    \\\rowcolor{lightlightgray}
-%                    & \verb|DHE-DSS-AES256-SHA|                             &               & &&&\\
-%    \phantom{0}9    & \verb|TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA|   & \verb|0x0088| & \no    & \yes & \no  & \no    \\
-%                    & \verb|DHE-RSA-CAMELLIA256-SHA|                        &               & &&&\\\rowcolor{lightlightgray}
-%    \phantom{}10    & \verb|TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA|   & \verb|0x0087| & \no    & \yes & \no  & \no    \\\rowcolor{lightlightgray}
-%                    & \verb|DHE-DSS-CAMELLIA256-SHA|                        &               & &&&\\
-%   \bottomrule
-%    \end{tabular}
-%\caption{Preference order of cipher suites.  All suites are supported by OpenSSL.}
-%\label{table:prefOrderCipherSuites}
-%\end{table}
-%
-%Note: the above table \ref{table:prefOrderCipherSuites} contains Elliptic curve key exchanges. There are currently strong doubts\footnote{\url{http://safecurves.cr.yp.to/rigid.html}} concerning ECC.
-%If unsure, remove the cipher suites starting with ECDHE in the table above.
-%
-%
-%Based on this ordering, we can now define the corresponding settings for servers. We will start with the most common web servers.
diff --git a/src/cipher_suites/compatibility.tex b/src/cipher_suites/compatibility.tex
deleted file mode 100644 (file)
index d8621fd..0000000
+++ /dev/null
@@ -1,2 +0,0 @@
-%%\subsection{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.}
\ No newline at end of file
diff --git a/src/cipher_suites/forward.tex b/src/cipher_suites/forward.tex
deleted file mode 100644 (file)
index e7a9ab6..0000000
+++ /dev/null
@@ -1,8 +0,0 @@
-%%\subsection{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
-\footnote{\url{http://en.wikipedia.org/wiki/Forward\_secrecy}}
-\footnote{\url{https://www.eff.org/deeplinks/2013/08/pushing-perfect-forward-secrecy-important-web-privacy-protection}}
-\footnote{\url{http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html}}.
diff --git a/src/cipher_suites/insecure.tex b/src/cipher_suites/insecure.tex
deleted file mode 100644 (file)
index 585af09..0000000
+++ /dev/null
@@ -1,17 +0,0 @@
-%%\subsection{Known insecure and weak cipher suites}
-%\todo{PG: please write this section. List all known broken, obsolete, weak and insecure cipher suites . Or even better: find the best site which keeps track of outdated cipher suites and simply reference it. We do not want to maintain such a list ourselves!}
-
-%%Ciphers with 112bit or less are considered weak and aren't recommended. Note that \texttt{3DES} provides only 112bit of security \footnote{\url{http://csrc.nist.gov/publications/PubsSPs.html\#800-57-part1}}.
-
-%% comment Florian:
-%% Please do not consider ciphers with a 112 bit key as weak. I think it is
-%% fine to do not recommend 3DES, but we should not claim that it is weak.
-%% In particular, 3DES with an effective keysize of 112 bits is still
-%% recommended by NIST and by ECRYPT2 for medium-term protection until 2030.
-
-
-%One special remark is necessary for 3DES: here we want to note
-%that it theoretically has 168 bit security, however based on the NIST Special
-%Publication 800-57
-%\footnote{\url{http://csrc.nist.gov/publications/PubsSPs.html\#800-57-part1},
-%pages 63 and 64}, it is clear that 3DES is only considered 80 bits / 112 bits.
diff --git a/src/cipher_suites/recommended.tex b/src/cipher_suites/recommended.tex
deleted file mode 100644 (file)
index dd84b85..0000000
+++ /dev/null
@@ -1,166 +0,0 @@
-%%\subsection{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 website \url{https://www.ssllabs.com/} 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.\\
-
-\textbf{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
-\ref{section:ChoosingYourOwnCipherSuites}}.
-
-
-\subsubsection{Configuration A: Strong ciphers, fewer clients}
-
-At the time of writing we recommend 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 freely.
-
-
-We arrived at this set of cipher suites by selecting:
-
-\begin{itemize}
-\item TLS 1.2
-\item Perfect forward secrecy / ephemeral Diffie Hellman
-\item strong MACs (SHA-2) or
-\item GCM as Authenticated Encryption scheme
-\end{itemize}
-
-This results in the OpenSSL string:
-
-\begin{lstlisting}[breaklines]
-'EDH+aRSA+AES256:EECDH+aRSA+AES256:!SSLv3'
-\end{lstlisting}
-
-%$\implies$ resolves to 
-%
-%\begin{verbatim}
-%openssl ciphers -V $string
-%\end{verbatim}
-
-
-
-%\todo{make a column for cipher chaining mode} --> not really important, is it?
-\begin{center}
-
-\begin{tabular}{lllllll}
-\toprule
-\textbf{ID}   & \textbf{OpenSSL Name}       & \textbf{Version} & \textbf{KeyEx} & \textbf{Auth} & \textbf{Cipher} & \textbf{MAC}\\\cmidrule(lr){1-7}
-\verb|0x009F| & DHE-RSA-AES256-GCM-SHA384   & TLSv1.2          & DH             &  RSA          & AESGCM(256)     & AEAD         \\
-\verb|0x006B| & DHE-RSA-AES256-SHA256       & TLSv1.2          & DH             &  RSA          & AES(256) (CBC)  & SHA256       \\
-\verb|0xC030| & ECDHE-RSA-AES256-GCM-SHA384 & TLSv1.2          & ECDH           &  RSA          & AESGCM(256)     & AEAD         \\
-\verb|0xC028| & ECDHE-RSA-AES256-SHA384     & TLSv1.2          & ECDH           &  RSA          & AES(256) (CBC)  & SHA384       \\
-\bottomrule
-\end{tabular}
-\end{center}
-
-
-\textbf{Compatibility}
-
-Only clients which support TLS 1.2 are covered by these cipher suites (Chrome 30,
-Win 7 and Win 8.1 crypto stack, Opera 17, OpenSSL $\ge$ 1.0.1e, Safari 6 / iOS
-6.0.1, Safari 7 / OS X 10.9).
-
-
-
-\subsubsection{Configuration B: Weaker ciphers, more compatability}
-
-In this section we propose a slightly weaker set of cipher suites.  For
-example, there are some 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
-the compatibility with a broad range of clients, but also less computational
-workload on the provisioning hardware.
-\\
-
-\textbf{All further examples in this publication use Configuration B}.\\
-
-We arrived at this set of cipher suites by selecting:
-
-\begin{itemize}
-\item TLS 1.2, TLS 1.1, TLS 1.0
-\item allow SHA-1
-
-\todo{AK: Note that SHA1 is considered broken but if we are in DHE, we might get around it as long as you can not calculate a SHA1 collision ``live'' on the wire}
-
-\end{itemize}
-
-This results in the OpenSSL string:
-
-\begin{lstlisting}[breaklines]
-'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:!SRP:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'
-\end{lstlisting}
-
-\todo{make a column for cipher chaining mode}
-\begin{center}
-\begin{tabular}{lllllll}
-\toprule
-\textbf{ID}   & \textbf{OpenSSL Name}       & \textbf{Version} & \textbf{KeyEx} & \textbf{Auth} & \textbf{Cipher} & \textbf{MAC}\\\cmidrule(lr){1-7}
-\verb|0x009F| & DHE-RSA-AES256-GCM-SHA384   & TLSv1.2          & DH             & RSA           & AESGCM(256)     & AEAD         \\
-\verb|0x006B| & DHE-RSA-AES256-SHA256       & TLSv1.2          & DH             & RSA           & AES(256)        & SHA256       \\
-\verb|0xC030| & ECDHE-RSA-AES256-GCM-SHA384 & TLSv1.2          & ECDH           & RSA           & AESGCM(256)     & AEAD         \\
-\verb|0xC028| & ECDHE-RSA-AES256-SHA384     & TLSv1.2          & ECDH           & RSA           & AES(256)        & SHA384       \\
-\verb|0x009E| & DHE-RSA-AES128-GCM-SHA256   & TLSv1.2          & DH             & RSA           & AESGCM(128)     & AEAD         \\
-\verb|0x0067| & DHE-RSA-AES128-SHA256       & TLSv1.2          & DH             & RSA           & AES(128)        & SHA256       \\
-\verb|0xC02F| & ECDHE-RSA-AES128-GCM-SHA256 & TLSv1.2          & ECDH           & RSA           & AESGCM(128)     & AEAD         \\
-\verb|0xC027| & ECDHE-RSA-AES128-SHA256     & TLSv1.2          & ECDH           & RSA           & AES(128)        & SHA256       \\
-\verb|0x0088| & DHE-RSA-CAMELLIA256-SHA     & SSLv3            & DH             & RSA           & Camellia(256)   & SHA1         \\
-\verb|0x0039| & DHE-RSA-AES256-SHA          & SSLv3            & DH             & RSA           & AES(256)        & SHA1         \\
-\verb|0xC014| & ECDHE-RSA-AES256-SHA        & SSLv3            & ECDH           & RSA           & AES(256)        & SHA1         \\
-\verb|0x0045| & DHE-RSA-CAMELLIA128-SHA     & SSLv3            & DH             & RSA           & Camellia(128)   & SHA1         \\
-\verb|0x0033| & DHE-RSA-AES128-SHA          & SSLv3            & DH             & RSA           & AES(128)        & SHA1         \\
-\verb|0xC013| & ECDHE-RSA-AES128-SHA        & SSLv3            & ECDH           & RSA           & AES(128)        & SHA1         \\
-\verb|0x0084| & CAMELLIA256-SHA             & SSLv3            & RSA            & RSA           & Camellia(256)   & SHA1         \\
-\verb|0x0035| & AES256-SHA                  & SSLv3            & RSA            & RSA           & AES(256)        & SHA1         \\
-\verb|0x0041| & CAMELLIA128-SHA             & SSLv3            & RSA            & RSA           & Camellia(128)   & SHA1         \\
-\verb|0x002F| & AES128-SHA                  & SSLv3            & RSA            & RSA           & AES(128)        & SHA1         \\
-\bottomrule
-\end{tabular}
-\end{center}
-
-\textbf{Compatibility}
-
-Note that these cipher suites will not work with Windows XP's crypto stack (e.g. IE, Outlook), 
-%%Java 6, Java 7 and Android 2.3. Java 7 could be made compatible by installing the "Java 
-%%Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files"
-%%(JCE) \footnote{\url{http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html}}.
-We could not verify yet if installing JCE also fixes the Java 7
-DH-parameter length limitation (1024 bit). 
-\todo{do that!}
-
-\textbf{Explanation}
-
-For a detailed explanation of the cipher suites chosen, please see
-\ref{section:ChoosingYourOwnCipherSuites}. In short, finding the perfect cipher
-string is impossible and 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.
-
-Straight forward, the authors wanted strong ciphers, forward secrecy
-\footnote{\url{http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html}}
-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".
-
-\begin{itemize}
-\item TLSv1.2 is preferred over TLSv1.0/SSLv3 (while still providing a useable cipher
-      string for SSLv3).
-\item AES256 and CAMELLIA256 count as very strong ciphers at the moment.
-\item AES128 and CAMELLIA128 count as strong ciphers at the moment
-\item DHE or ECDHE for forward secrecy
-\item RSA as this will fit most of todays setups
-\item AES256-SHA as a last resort (with this cipher at the end, even systems with
-      legacy distributions of OpenSSL will work out of the box. Forward secrecy
-      will not be available. On systems that do not support elliptic curves, that cipher
-      offers support for the Microsoft crypto libraries that only support ECDHE. \todo{what does that mean?! inconclusive!}
-\end{itemize}
-
-\todo{Adi: review "justification" when next section is written}
index 138a63a..db0ea23 100644 (file)
@@ -1,7 +1,14 @@
+\newpage
 \section{Disclaimer and scope}
 \label{section:disclaimer}
 
-\epigraph{``A chain is no stronger than its weakest link, and life is after all a chain``}{-- William James}
+\epigraph{``A chain is no stronger than its weakest link, and life is after all a chain''}{-- William James}
+
+\epigraph{``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.''}{-— Edward
+Snowden, answering questions live on the Guardian's
+website\cite{snowdenGuardianGreenwald}}
 
 
 This guide specifically does not address physical security, protecting software
@@ -21,6 +28,7 @@ with.\footnote{An easy to read yet very insightful recent example is the
 "FLUSH+RELOAD" technique \cite{yarom2013flush+} for leaking cryptographic keys
 from one virtual machine to another via L3 cache timing attacks.}
 
+\vskip 0.5em
 This guide does not talk much about the well-known insecurities of trusting a
 public-key infrastructure (PKI)\footnote{Interested readers are referred to
 \url{https://bugzilla.mozilla.org/show_bug.cgi?id=647959} or
@@ -28,6 +36,8 @@ public-key infrastructure (PKI)\footnote{Interested readers are referred to
 (german) which brings the problem of trusting PKIs right to the point}. Nor
 does this text fully explain how to run your own Certificate Authority (CA). 
 
+
+\vskip 0.5em
 Most of this zoo of information security issues are addressed in the very
 comprehensive book ``Security Engineering'' by Ross Anderson
 \cite{anderson2008security}. 
@@ -37,9 +47,10 @@ 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. 
 
+\vskip 0.5em
 
 
-\epigraph{``Security is a process, not a product.``}{-- Bruce Schneier}
+\epigraph{``Security is a process, not a product.''}{-- Bruce Schneier}
 
 This guide can only describe what the authors currently
 \emph{believe} to be the best settings based on their personal experience and
@@ -51,6 +62,7 @@ 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.
 
+\vskip 0.5em
 
 We therefore recommend that system administrators keep up to date with recent
 topics in IT security and cryptography. 
index 46b2395..20d2a97 100644 (file)
@@ -1,9 +1,21 @@
 \section{How to read this guide}
 
-%This guide starts with some general remarks in sections \ref{section:DH},\ref{section:EllipticCurveCryptography},\ref{section:keylengths} on 
+This guide tries to accomodate 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.
+\vskip 0.5em
 
+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 homagepage, a mail server, $ \ldots $)
 
-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.
+
+\vskip 0.5em
+
+While chapter \ref{section:PracticalSettings} is intended to server 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 chosing \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.
 
 \vskip 1.5em
 
diff --git a/src/img/checkpoint_1.png b/src/img/checkpoint_1.png
new file mode 100644 (file)
index 0000000..88f5266
Binary files /dev/null and b/src/img/checkpoint_1.png differ
diff --git a/src/img/checkpoint_2.png b/src/img/checkpoint_2.png
new file mode 100644 (file)
index 0000000..0323e29
Binary files /dev/null and b/src/img/checkpoint_2.png differ
diff --git a/src/img/checkpoint_3.png b/src/img/checkpoint_3.png
new file mode 100644 (file)
index 0000000..e6bbe0a
Binary files /dev/null and b/src/img/checkpoint_3.png differ
diff --git a/src/img/checkpoint_4.png b/src/img/checkpoint_4.png
new file mode 100644 (file)
index 0000000..b5d2a24
Binary files /dev/null and b/src/img/checkpoint_4.png differ
diff --git a/src/img/keylengths_com.png b/src/img/keylengths_com.png
new file mode 100644 (file)
index 0000000..202e5db
Binary files /dev/null and b/src/img/keylengths_com.png differ
diff --git a/src/keylengths.tex b/src/keylengths.tex
deleted file mode 100644 (file)
index 23b7607..0000000
+++ /dev/null
@@ -1,73 +0,0 @@
-\section{Keylengths}
-\label{section:keylengths}
-
-
-\epigraph{``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.''}{-- Vincent Rijmen
-in a personal mail exchange Dec 2013}
-
-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 chosing an encryption algorithm and keylength, 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 (\cite{ii2011ecrypt}) gives a fascinating overview of
-strenghts of symmetric keys in chapter 5 and chapter 7. Summarizing ECRYPT II, we
-recommend 128 bit of key strenght 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. See chapter 7 of \cite{ii2011ecrypt}, page 30.
-
-
-There are a couple of other studies comparing keylengths and their respective
-strengths.  The website \url{http://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 \ref{fig:keylengths.com} shows a typical comparison of keylengths on
-this web site.
-
-\begin{figure}[h]
-  \centering
-  \includegraphics[width=0.65\textwidth]{keylengths_com.png}
-  \caption{Screenshot of \url{http://www.keylength.com} for 128 bit symmetric key size equivalents}
-  \label{fig:keylengths.com}
-\end{figure}
-
-
-\paragraph{Summary}
-\begin{itemize}
-
-\item For traditional asymmetric public-key cryptography we consider any key
-length below 2048 bits to be deprecated at the time of this writing (for long
-term protection).  
-
-\item For elliptic curve cryptography we consider key lengths below 256 bits to
-be inadequate for long term protection.  
-
-\item For symmetric algorithms we consider anything below 128 bits to be
-inadequate for long term protection.
-
-\end{itemize}
-
-\paragraph{Special remark on 3DES} \mbox{} \\
-We want to note that 3DES theoretically has 168 bits of security, however based
-on the NIST Special Publication 800-57
-\footnote{\url{http://csrc.nist.gov/publications/PubsSPs.html\#800-57-part1},
-pages 63 and 64}, it is clear that 3DES can only be considered to provide for
-80 bits / 112 bits security.
-
-
-
-
-
diff --git a/src/keylengths_com.png b/src/keylengths_com.png
deleted file mode 100644 (file)
index 202e5db..0000000
Binary files a/src/keylengths_com.png and /dev/null differ
index e608eb6..89dfb6f 100644 (file)
@@ -18,7 +18,13 @@ requests'' on the github
 mirror\footnote{\url{https://github.com/BetterCrypto/Applied-Crypto-Hardening}}
 for this paper.
 
+
+\vskip 0.5em
+
 Public peer-review and ``multiple eyes'' checking of our publication is the
 best strategy we can imagine at the present moment
 \footnote{\url{http://www.wired.com/opinion/2013/10/how-to-design-and-defend-against-the-perfect-backdoor/}}.
 
+\vskip 0.5em
+We invite the gentle reader to participate in this public review process.
+
index 693d11e..f03fe86 100644 (file)
@@ -2,13 +2,12 @@
 
 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. 
 
-\subsubsection{Dovecot}
+\subsection{Dovecot}
 
 
-\begin{description}
-\item[Tested with Version:] Dovecot 2.2:
+\subsubsection{Tested with Version} Dovecot 2.2
 
-\item[Settings:] \mbox{}
+\subsubsection{Settings}
 % Example: http://dovecot.org/list/dovecot/2013-October/092999.html
 
 \begin{lstlisting}[breaklines]
@@ -16,12 +15,12 @@ This section documents the most common mail (SMTP) and IMAPs/POPs servers. Anoth
   ssl_prefer_server_ciphers = yes
 \end{lstlisting}
 
-\item[Additional info:] \mbox{}
+\subsubsection{Additional info}
 
 Dovecot 2.1: Almost as good as dovecot 2.2. Does not support
 ssl\_prefer\_server\_ciphers
 
-\item[Limitations:] \mbox{}
+\subsubsection{Limitations}
 
 Dovecot currently does not support disabling TLS compression. Furthermore, DH
 parameters greater than 1024bit are not supported. The most recent version
@@ -32,21 +31,23 @@ parameters greater than 1024bit are not supported. The most recent version
 
 % in case you have the need for further justifications why you chose this and that setting or if the settings do not fit into the standard Variant A or Variant B schema, please document this here
 
-\item[References:] \url{http://wiki2.dovecot.org/SSL}
+\subsubsection{References} \url{http://wiki2.dovecot.org/SSL}
 
 % add any further references or best practice documents here
 
-\item[How to test:]
+\subsubsection{How to test}
 % describe here or point the admin to tools (can be a simple footnote or \ref{} to  the tools section) which help the admin to test his settings.
 
 \todo{FIXME}
 
-\end{description}
 
 %% ---------------------------------------------------------------------- 
 
-\subsubsection{cyrus-imapd (based on 2.4.17)}
+\subsection{cyrus-imapd (based on 2.4.17)}
 
+\subsubsection{Tested with Version} \todo{FIXME: add}
+
+\subsubsection{Settings}
 \paragraph*{imapd.conf}\mbox{}\\
 
 To activate SSL/TLS configure your certificate with
@@ -88,7 +89,7 @@ To support POP3S/IMAPS on ports 995/993 add
 \end{lstlisting}
 
 
-\paragraph*{Limitations}\mbox{}\\
+\subsubsection{Limitations}
 
 cyrus-imapd currently (2.4.17, trunk) does not support elliptic curve cryptography. Hence, ECDHE will not work even if defined in your cipher list.\\
 
@@ -97,6 +98,11 @@ Currently there is no way to prefer server ciphers or to disable compression.\\
 There is a working patch for all three features:
 \url{https://bugzilla.cyrusimap.org/show_bug.cgi?id=3823}\\
 
+\subsubsection{References}
+\todo{FIXME}
+
+\subsubsection{How to test}
+\todo{FIXME}
 
 
 
@@ -109,7 +115,7 @@ There is a working patch for all three features:
 
 %% ---------------------------------------------------------------------- 
 
-\subsubsection{SMTP in general}
+\subsection{SMTP in general}
 \label{subsection:smtp_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.\\
@@ -153,16 +159,10 @@ mode, because the alternative is plain text transmission.
 
 %% ---------------------------------------------------------------------- 
 
-\subsubsection{Postfix}
-
-\begin{description}
-\item[Tested with Version:] \mbox{}
+\subsection{Postfix}
 
-\begin{itemize}
-\item Postfix 2.9.6 (Debian Wheezy)
-\end{itemize}
-
-\item[Settings:] \mbox{}
+\subsubsection{Tested with Version} Postfix 2.9.6 (Debian Wheezy)
+\subsubsection{Settings}
 
 %% I (cm) consider the generation of own DH parameters to be voodoo until
 %% someone can explain the contrary. They are, after all, public, and
@@ -238,7 +238,7 @@ For those users who want to use ECC key exchange, it is possible to specify this
   smtpd_tls_eecdh_grade = ultra
 \end{lstlisting}
 
-\item[Limitations:] \mbox{}
+\subsubsection{Limitations}
 
 tls\_ssl\_options is supported from Postfix 2.11 onwards. You can
 leave the statement in the configuration for older versions, it will
@@ -247,12 +247,12 @@ be ignored.
 tls\_preempt\_cipherlist is supported from Postfix 2.8 onwards. Again,
 you can leave the statement in for older versions.
 
-\item[References:]
+\subsubsection{References}
 
 Refer to \url{http://www.postfix.org/TLS_README.html} for an in-depth
 discussion.
 
-\item[Additional settings:]
+\subsubsection{Additional settings}
 
 Postfix has two sets of built-in DH parameters that can be overridden
 with the \verb|smtpd_tls_dh512_param_file|
@@ -268,7 +268,8 @@ interoperability risk, but we have not tested this yet.
 % \item[Justification for special settings (if needed):]
 % no special settings
 
-\item[How to test:]
+
+\subsubsection{How to test}
 
 You can check the effect of the settings with the following command:
 \begin{lstlisting}[breaklines]
@@ -280,17 +281,14 @@ $ zegrep "TLS connection established from.*with cipher" | /var/log/mail.log | aw
     335 TLSv1 with cipher DHE-RSA-AES256-SHA
 \end{lstlisting}
 
-\end{description}
-
+\subsubsection{References} \todo{FIXME}
 
 %% ---------------------------------------------------------------------- 
 
-\subsubsection{Exim (based on 4.82)}
+\subsection{Exim (based on 4.82)}
 
 It is highly recommended to read
-
 \url{http://exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html}
-
 first.
 
 \paragraph*{MSA mode (submission)}\mbox{}\\
@@ -445,37 +443,9 @@ There already is a working patch to provide support:\\
 %\subsubsection{starttls?}
 
 %% ----------------------------------------------------------------------
-\subsubsection{Exchange}
+\subsection{Exchange}
 
 \todo{FIXME: write this section}
 
-\begin{description}
-\item[Tested with Version:] \todo{version?}
-
-\item[Settings:] \mbox{}
-
-\begin{lstlisting}[breaklines]
-    %Here goes your setting string
-\end{lstlisting}
-
-\item[Additional settings:] \mbox{}
-
-%Here you can add additional settings
-
-\begin{lstlisting}[breaklines]
-    %copy \& paste additional settings
-\end{lstlisting}
-
-\item[Justification for special settings (if needed):] \mbox{}
-
-% in case you have the need for further justifications why you chose this and that setting or if the settings do not fit into the standard Variant A or Variant B schema, please document this here
-
-\item[References:] \todo{add references}
-
-% add any further references or best practice documents here
-
-\item[How to test:]
-% describe here or point the admin to tools (can be a simple footnote or \ref{} to  the tools section) which help the admin to test his settings.
 
-\end{description}
 
index 960c14e..25bc3d0 100644 (file)
@@ -1,12 +1,7 @@
+%%---------------------------------------------------------------------- 
 \subsection{OpenSSH}
-
-
-\begin{description}
-\item[Tested with Version:] OpenSSH 6.1
-
-\item[Settings:] \mbox{}
-
-
+\subsubsection{Tested with Version} OpenSSH 6.1
+\subsubsection{Settings}
 \paragraph*{sshd_config}
 \begin{lstlisting}[breaklines]
        # ...
@@ -23,7 +18,6 @@
 \end{lstlisting}
 
 % XXX: curve25519-sha256@libssh.org only available upstream(!)
-
 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.1). DSA host keys have been removed on purpose, the DSS standard does not
@@ -32,29 +26,22 @@ support for DSA keys stronger than 1024bit
 below current standards (see section \ref{section:keylengths}). Legacy systems
 can use this configuration and simply omit unsupported ciphers, key exchange
 algorithms and MACs.  
-
-\item[Additional settings:] \mbox{}
-
+\subsubsection{Additional settings}
 Note that the setting \texttt{ServerKeyBits 4096}  has no effect until you re-generate new ssh host keys. There might be issues if you have users which rely on the fingerprint of the old ssh host key being stored in their clients' \texttt{.ssh/known\_hosts} file.
-
-\item[References:]
+%\subsubsection{Justification for special settings (if needed)}
+\subsubsection{References}
 The openssh sshd\_config  man page is the best reference: \url{http://www.openssh.org/cgi-bin/man.cgi?query=sshd_config}
-
-
-\item[How to test:]
+\subsubsection{How to test}
 Connect a client with verbose logging enabled to the SSH server \\
 \begin{lstlisting}[breaklines]
 $ ssh -vvv myserver.com
 \end{lstlisting}and observe the key exchange in the output.
-\end{description}
 
-\subsection{Cisco ASA}
 
-
-\begin{description}
-\item[Tested with Version:]9.1(3) 
-
-\item[Settings:] \mbox{}
+%%---------------------------------------------------------------------- 
+\subsection{Cisco ASA}
+\subsubsection{Tested with Version} 9.1(3)
+\subsubsection{Settings}
 \begin{lstlisting}[breaklines]
 crypto key generate rsa modulus 2048
 ssh version 2
@@ -63,25 +50,19 @@ line vty 0 4
  transport input ssh
 \end{lstlisting}
 Note: 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-exchnage 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.
-\item[References:]
-http://www.cisco.com/en/US/docs/security/asa/asa91/configuration/general/admin\_management.html 
-
-
-\item[How to test:]
+\subsubsection{References}
+\url{http://www.cisco.com/en/US/docs/security/asa/asa91/configuration/general/admin\_management.html }
+\subsubsection{How to test}
 Connect a client with verbose logging enabled to the SSH server \\
 \begin{lstlisting}[breaklines]
 $ ssh -vvv myserver.com
 \end{lstlisting}and observe the key exchange in the output.
-\end{description}
 
 
+%---------------------------------------------------------------------- 
 \subsection{Cisco IOS}
-
-
-\begin{description}
-\item[Tested with Version:] 15.0, 15.1, 15.2
-
-\item[Settings:] \mbox{}
+\subsubsection{Tested with Version} 15.0, 15.1, 15.2
+\subsubsection{Settings}
 \begin{lstlisting}[breaklines]
 crypto key generate rsa modulus 2048 label SSH-KEYS
 ip ssh rsa keypair-name SSH-KEYS
@@ -90,15 +71,11 @@ ip ssh dh min size 2048
 \end{lstlisting}
 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.
-
-\item[References:]
-http://www.cisco.com/en/US/docs/ios/sec\_user\_services/configuration/guide/sec\_secure\_shell\_v2.html 
-
+\subsubsection{References}
+\url{http://www.cisco.com/en/US/docs/ios/sec\_user\_services/configuration/guide/sec\_secure\_shell\_v2.html }
 % add any further references or best practice documents here
-
-\item[How to test:]
+\subsubsection{How to test}
 Connect a client with verbose logging enabled to the SSH server \\
 \begin{lstlisting}[breaklines]
 $ ssh -vvv myserver.com
 \end{lstlisting}and observe the key exchange in the output.
-\end{description}
index a572ada..1142852 100644 (file)
@@ -167,7 +167,7 @@ Communities can be found in the ``IPSEC VPN'' tab of SmartDashboard.
 
 \begin{figure}[p]
   \centering
-  \includegraphics[width=0.592\textwidth]{checkpoint_1.png}
+  \includegraphics[width=0.592\textwidth]{img/checkpoint_1.png}
   \caption{VPN Community encryption properties}
   \label{fig:checkpoint_1}
 \end{figure}
@@ -179,7 +179,7 @@ Phase 1 and 2 (figure \ref{fig:checkpoint_2}).
 
 \begin{figure}[p]
   \centering
-  \includegraphics[width=0.411\textwidth]{checkpoint_2.png}
+  \includegraphics[width=0.411\textwidth]{img/checkpoint_2.png}
   \caption{Custom Encryption Suite Properties}
   \label{fig:checkpoint_2}
 \end{figure}
@@ -190,7 +190,7 @@ found under ``Advanced Settings'' / ``Advanced VPN Properties''
 
 \begin{figure}[p]
   \centering
-  \includegraphics[width=0.589\textwidth]{checkpoint_3.png}
+  \includegraphics[width=0.589\textwidth]{img/checkpoint_3.png}
   \caption{Advanced VPN Properties}
   \label{fig:checkpoint_3}
 \end{figure}
@@ -205,7 +205,7 @@ button, you can configure sets of algorithms that all gateways support
 
 \begin{figure}[p]
   \centering
-  \includegraphics[width=0.474\textwidth]{checkpoint_4.png}
+  \includegraphics[width=0.474\textwidth]{img/checkpoint_4.png}
   \caption{Remote Access Encryption Properties}
   \label{fig:checkpoint_4}
 \end{figure}
@@ -268,7 +268,7 @@ client and server.
 % this is only a DoS-protection, out of scope:
 % # TLS Authentication
 % tls-auth ta.key
-
+\todo{FIXME: we should use the CIPHERSTRINGB  macro here}
 % previous:
 % tls-cipher
 % ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-CAMELLIA256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:AES256-SHA
@@ -285,6 +285,7 @@ auth SHA384
 Client and server have to use compatible configurations, otherwise they can't communicate.
 The \verb|cipher| and \verb|auth| directives have to be identical.
 
+\todo{FIXME: we should use the CIPHERSTRINGB  macro here}
 \begin{lstlisting}[breaklines]
 tls-cipher DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-CAMELLIA256-SHA:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-AES128-SHA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
 cipher AES-256-CBC
index 4eb1eba..2efa748 100644 (file)
@@ -3,7 +3,7 @@
 %%---------------------------------------------------------------------- 
 \subsection{Apache}
 
-\subsubsection{Tested with Version}
+\subsubsection{Tested with Version} \todo{FIXME: add}
 
 \subsubsection{Settings} 
 
 Note again, that any cipher suite starting with ECDHE can be omitted, if in doubt.
 
 
+\vskip 1.0em
 \subsubsection{Additional settings}
 
-You should redirect everything to httpS:// if possible. In Apache you can do this with the following setting inside of a VirtualHost environment:
+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:
 
 \begin{lstlisting}[breaklines]
   <VirtualHost *:80>
@@ -81,7 +82,7 @@ See section \ref{section:Tools}
 
 \subsubsection{Additional settings}
 
-As for any other webserver, you should automatically redirect http traffic toward httpS://
+As for any other webserver, you might want to automatically redirect http traffic toward httpS://
 
 \begin{lstlisting}[breaklines]
   $HTTP["scheme"] == "http" {
@@ -145,7 +146,7 @@ If you decide to trust NIST's ECC curve recommendation, you can add the followin
   ssl_ecdh_curve          secp384r1;
 \end{lstlisting}
 
-You should redirect everything to httpS:// if possible. In Nginx you can do this with the following setting:
+You might want to redirect everything to httpS:// if possible. In Nginx you can do this with the following setting:
 
 \begin{lstlisting}[breaklines]
   rewrite     ^(.*)   https://$host$1 permanent;
diff --git a/src/related_publications.tex b/src/related_publications.tex
new file mode 100644 (file)
index 0000000..73934c5
--- /dev/null
@@ -0,0 +1,14 @@
+\section{Related publications}
+\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. 
+
+
+
+
index 9dbd614..fa8ea0b 100644 (file)
   url        = {https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102_pdf}
 }
 
+@techreport{ENISA2013,
+  title      = {ENISA - Algorithms, Key Sizes and Parameters Report},
+  author     = {{ENISA and Vincent Rijmen, Nigel P. Smart, Bogdan warinschi, Gaven Watson}},
+  year       = {2013},
+  month      = {Oct},
+  url        = {http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report},
+}
   
 @book{anderson2008security,
   title      = {Security engineering},
   year = 2013,
   month = 07,
 }
+
+@misc{snowdenGuardianGreenwald,
+  author = {{Glenn Greenwald}},
+  title = {{Edward Snowden: NSA whistleblower answers reader questions}},
+  howpublished = "\url{http://www.theguardian.com/world/2013/jun/17/edward-snowden-nsa-files-whistleblower},
+               \url{http://www.theguardian.com/world/2013/jun/17/edward-snowden-nsa-files-whistleblower}",
+  year = 2013,
+  month = 07,
+  day = 17,
+}
diff --git a/src/theory.tex b/src/theory.tex
new file mode 100644 (file)
index 0000000..2a7e9bc
--- /dev/null
@@ -0,0 +1,8 @@
+\input{theory/overview}
+\input{theory/cipher_suites}
+\input{theory/ECC}
+\input{theory/SHA}
+\input{theory/DH}
+\input{theory/keylengths}
+\input{theory/RNGs}
+\input{theory/PKIs}
diff --git a/src/theory/DH.tex b/src/theory/DH.tex
new file mode 100644 (file)
index 0000000..4a869a5
--- /dev/null
@@ -0,0 +1,12 @@
+\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}
+
+Where configurable, we recommend using the Diffie Hellman groups
+defined for IKE, specifically groups 14-18 (for MODP, \cite{rfc3526})
+and 19-21 (for elliptic curve DH, \cite{rfc5903}). 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
+  them on the server and insert URL here}.
diff --git a/src/theory/ECC.tex b/src/theory/ECC.tex
new file mode 100644 (file)
index 0000000..9d245c3
--- /dev/null
@@ -0,0 +1,51 @@
+\section{A note on Elliptic Curve Cryptography}
+\label{section:EllipticCurveCryptography}
+
+%\epigraph{``Mathematics is the queen of the sciences and number theory is the queen of mathematics.''}{-- Carl Friedrich Gauss}
+
+\epigraph{``Everyone knows what a curve is, until he has studied enough mathematics to become confused through the countless number of possible exceptions.''}{-- Felix Klein }
+
+Elliptic Curve Cryptogaphy (simply called ECC from now on) is a branch of 
+cryptography that emerged in the mid-1980ties.
+The security of the RSA algorithm is based on the assumption that factoring 
+large primes is infeasible. Likewise the security of ECC, DH and DSA is 
+based on the discrete logrithm 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 have been some great introductions on the topic lately
+\footnote{\url{http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography}}
+\footnote{\url{https://www.imperialviolet.org/2010/12/04/ecc.html}}
+\footnote{\url{http://www.isg.rhul.ac.uk/~sdg/ecc.html}}.
+
+ECC provides for much stronger security with less computonally expensive
+operations in comparison to traditional PKI algorithms (See the Section \ref{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) 
+\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}.
+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.
+
+
+\textbf{A word of 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!
+
+%% mention different attacks on ECC besides flawed parameters!
+
diff --git a/src/theory/SHA.tex b/src/theory/SHA.tex
new file mode 100644 (file)
index 0000000..fb88353
--- /dev/null
@@ -0,0 +1,21 @@
+\section{A note on SHA-1}
+\label{section:SHA}
+
+
+In the last years several weaknesses have been shown for SHA-1. In
+particular, collisions on SHA-1 can be found using $2^{63}$ 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.
diff --git a/src/theory/cipher_suites.tex b/src/theory/cipher_suites.tex
new file mode 100644 (file)
index 0000000..b1096f5
--- /dev/null
@@ -0,0 +1,34 @@
+
+\section{Cipher suites}
+\label{section:CipherSuites}
+\todo{team: section \ref{section:CipherSuites} is currently a bit messy. Re-do it}
+
+
+\subsection{Architectural overview }
+\label{subsection:architecture}
+\input{"./theory/cipher_suites/architecture.tex"}
+
+
+\subsection{Forward Secrecy}
+\label{subsection:PFS}
+\input{"./theory/cipher_suites/forward.tex"}
+
+
+\subsection{Recommended cipher suites}
+\label{section:recommendedciphers}
+\input{"./theory/cipher_suites/recommended_generated.tex"}
+
+
+%\subsection{Known insecure and weak cipher suites}
+%\input{"./theory/cipher_suites/insecure.tex"}
+
+
+\subsection{Compatibility}
+\label{subsection:compatibility}
+\input{"./theory/cipher_suites/compatibility.tex"}
+
+
+\subsection{Choosing your own cipher suites}
+\label{section:ChoosingYourOwnCipherSuites}
+\input{"./theory/cipher_suites/choosing.tex"}
+
diff --git a/src/theory/cipher_suites/architecture.tex b/src/theory/cipher_suites/architecture.tex
new file mode 100644 (file)
index 0000000..e4e8bca
--- /dev/null
@@ -0,0 +1,54 @@
+%%\subsection{Architectural overview }
+
+This section defines some terms which will be used throughout this guide.
+
+
+A cipher suite is a standardised collection of key exchange algorithms, encryption 
+algorithms (ciphers) and Message authentication codes (MAC) algortihm that provides
+authenticated encryption schemes. It consists of the following components:
+
+\begin{description}
+
+\item{\it 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.'' \cite{katz2008introduction}
+
+Example: \texttt{DHE}
+
+\item{\it Authentication:}
+The client authenticates the server by its certificate. Optionally the server 
+may authenticate the client certificate.
+
+Example: \texttt{RSA}
+
+\item{\it Cipher:}
+The cipher is used to encrypt the message stream. It also contains the key size
+and mode used by the suite.
+
+Example: \texttt{AES256}
+
+\item{\it Message authentication code (MAC):}
+A MAC ensures that the message has not been tampered with (integrity).
+
+Examples: \texttt{SHA256}
+
+\item{\it 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: \texttt{AES256-GCM}
+
+
+
+\begin{figure}[h]
+\makebox[\textwidth]{
+\framebox[1.1\width]{ \texttt{DHE} }--\framebox[1.1\width]{ \texttt{RSA} }--\framebox[1.1\width]{ \texttt{AES256} }--\framebox[1.1\width]{ \texttt{SHA256} } }
+\caption{Composition of a typical cipher string}
+\end{figure}
+
+\item {\textbf{A note on nomenclature:}} there are two common naming schemes for cipher strings -- IANA names (see section \ref{section:Links}) and the more well known OpenSSL names. In this document we will always use OpenSSL names unless a specific service uses IANA names.
+
+\end{description}
diff --git a/src/theory/cipher_suites/choosing.tex b/src/theory/cipher_suites/choosing.tex
new file mode 100644 (file)
index 0000000..b31a23b
--- /dev/null
@@ -0,0 +1,248 @@
+%%\subsection{Choosing your own cipher suites}
+%%\label{section:ChoosingYourOwnCipherSuites}
+
+\todo{ Adi...  you want to describe how to make your own selection of cipher suites here.}
+
+%%SSL/TLS cipher suites consist of a key exchange algorithm, an authentication, a
+%%stream cipher (or a block cipher with a chaining mode) and a message authentication
+%%mechanism.
+%% ^^ commented out due to duplication (see previous section on architecture) - azet
+
+Many of the parts in a ciphersuite are interchangeable. Like the key exchange
+algorithm in this example: \texttt{ECDHE-RSA-AES256-GCM-SHA384} and
+\texttt{DHE-RSA-AES256-GCM-SHA384}.  To provide a decent level of security, all
+algorithms need to be safe (subject to the disclaimer in section
+\ref{section:disclaimer}).
+
+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
+support of these low-security algorithms is disabled by setting
+\texttt{!EXP:!LOW:!NULL} as part of the cipher string.
+
+\todo{Team: do we need references for all cipher suites considered weak?}
+
+\subsubsection{Key Exchange}
+
+Many algorithms allow secure key exchange.  Those are RSA, DH, EDH, ECDSA,
+ECDH, EECDH amongst others. During the key exchange, keys used for authentication
+and symmetric encryption are exchanged. For RSA, DSA and ECDSA those keys are derived
+from the server's public key.
+
+\todo{explain this section}
+
+\begin{center}
+\begin{tabular}{llll}
+    \toprule
+          & \textbf{Key}  & \textbf{EC}  & \textbf{ephemeral} \\ \cmidrule(lr){1-4}
+   RSA    & RSA           & no           & no                 \\
+   DH     & RSA           & no           & no                 \\
+   EDH    & RSA           & no           & yes                \\
+   ECDH   & both          & yes          & no                 \\
+   EECDH  & both          & yes          & yes                \\
+   DSA    & DSA           & no           & no                 \\
+   ECDSA  & DSA           & yes          & no                 \\
+\bottomrule
+\end{tabular}
+%\\
+%\\
+%disabled: \texttt{!PSK:!SRP}
+\end{center}
+
+\textbf{Ephemeral Key Exchange} uses different keys for authentication (the server's RSA
+key) and encryption (a randomly created key). This advantage is called ``Forward
+Secrecy'' and means that even recorded traffic cannot be decrypted later when someone
+obtains the server key. \\
+All ephemeral key exchange schemes are based on the Diffie-Hellman algorithm and require
+pre-generated Diffie-Hellman parameter (which allow fast ephemeral key generation). It
+is important to note that the Diffie-Hellman parameter settings need to reflect at least 
+the security (speaking in number of bits) as the RSA host key. \todo{TODO: reference!}
+
+
+\textbf{Elliptic Curves} (see section \ref{section:EllipticCurveCryptography})
+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 weren't properly explained by the
+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
+(\texttt{secp384r1}).
+
+
+Other key exchange mechanisms like Pre-Shared Key (PSK) are irrelevant for
+regular SSL/TLS use.
+
+\subsubsection{Authentication}
+
+RSA, DSA, DSS, ECDSA, ECDH
+
+During Key Exchange the server proved that he is in control of the private key
+associated with a certain public key (the server's certificate). The client
+verifies the server's identity by comparing the signature on the certificate
+and matching it with its trust database. For details about the trust model of
+SSL/TLS please see \ref{section:PKIs}.
+
+In addition to the server providing its identity, a client might do so as well.
+That way mutual trust can be established. Another mechanism providing client
+authentication is Secure Remote Password (SRP)\todo{reference}. All those
+mechanisms require special configuration.
+
+Other authentication mechanisms like Pre Shared Keys aren't used in SSL/TLS.
+Anonymous sessions will not be discussed in this paper.
+
+\texttt{!PSK:!aNULL}
+
+\subsubsection{Encryption}
+
+AES, CAMELLIA, SEED, ARIA(?), FORTEZZA(?)...
+
+Other ciphers like IDEA, RC2, RC4, 3DES or DES are weak and therefor not recommended:
+\texttt{!DES:!3DES:!RC2:!RC4:!eNULL}
+
+\subsubsection{Message authentication}
+
+SHA-1 (SHA), SHA-2 (SHA256, SHA384), AEAD
+
+Note that SHA-1 is considered broken and should not be used. SHA-1 is however the
+only still available message authentication mechanism supporting TLS1.0/SSLv3. Without
+SHA-1 most clients will be locked out.
+
+Other hash functions like MD2, MD4 or MD5 are unsafe and broken: \texttt{!MD2:!MD4:!MD5}
+
+\subsubsection{Combining cipher strings}
+%% reference 'man ciphers' and 'openssl ciphers' and show some simple examples
+%% VERY IMPORTANT: hint at the IANA-list and the differences in implementations
+
+\todo{ Adi...  The text below was simply the old text, still left here for reference.}
+
+%%% NOTE: we do not need to list this all here, can move to an appendix
+%At the time of this writing, SSL is defined in RFCs:  
+%
+%\begin{itemize}
+%\item RFC2246 - TLS1.0                
+%\item RFC3268 - AES           
+%\item RFC4132 - Camelia               
+%\item RFC4162 - SEED          
+%\item RFC4279 - PSK           
+%\item RFC4346 - TLS 1.1               
+%\item RFC4492 - ECC           
+%\item RFC4785 - PSK\_NULL             
+%\item RFC5246 - TLS 1.2               
+%\item RFC5288 - AES\_GCM              
+%\item RFC5289 - AES\_GCM\_SHA2\_ECC           
+%\item RFC5430 - Suite B               
+%\item RFC5487 - GCM\_PSK              
+%\item RFC5489 - ECDHE\_PSK            
+%\item RFC5932 - Camelia               
+%\item RFC6101 - SSL 3.0               
+%\item RFC6209 - ARIA          
+%\item RFC6367 - Camelia               
+%\item RFC6655 - AES\_CCM              
+%\item RFC7027 - Brainpool Curves              
+%\end{itemize}
+
+%\subsubsection{Overview of SSL Server settings}
+%
+%
+%Most Server software (Webservers, Mail servers, etc.) can be configured to prefer certain cipher suites over others. 
+%We followed the recommendations by Ivan Ristic's SSL/TLS Deployment Best Practices\footnote{\url{https://www.ssllabs.com/projects/best-practices/index.html}} document (see section 2.2 "Use Secure Protocols") and arrived at a list of recommended cipher suites for SSL enabled servers.
+%
+%Following Ivan Ristic's adivce we arrived at a categorisation of cipher suites.
+%
+%\begin{center}
+%\begin{tabular}{lllll}
+%\cmidrule[\heavyrulewidth]{2-5}
+%& \textbf{Version}   & \textbf{KeyEx} & \textbf{Cipher}    & \textbf{MAC}       \\\cmidrule(lr){2-5}
+%\cellcolor{green}prefer  & TLS 1.2   & DHE\_DSS   & AES\_256\_GCM   & SHA384        \\
+%    &   & DHE\_RSA   & AES\_256\_CCM   & SHA256        \\
+%    &   & ECDHE\_ECDSA   & AES\_256\_CBC   &       \\
+%    &   & ECDHE\_RSA &   &       \\ 
+%    &   &   &   &       \\
+%\cellcolor{orange}consider    & TLS 1.1   & DH\_DSS    & AES\_128\_GCM   & SHA       \\
+%    & TLS 1.0   & DH\_RSA    & AES\_128\_CCM   &       \\
+%    &   & ECDH\_ECDSA    & AES\_128\_CBC   &       \\ 
+%    &   & ECDH\_RSA  & CAMELLIA\_256\_CBC  &       \\
+%    &   & RSA   & CAMELLIA\_128\_CBC  &       \\
+%    &   &   &   &       \\
+%\cellcolor{red}avoid   
+%& SSL 3.0   & NULL  & NULL  & NULL      \\
+%    &   & DH\_anon   & RC4\_128   & MD5       \\
+%    &   & ECDH\_anon & 3DES\_EDE\_CBC  &       \\
+%    &   &   & DES\_CBC   &       \\
+%    &   &   &   &       \\
+%\cellcolor{blue}{\color{white}special }
+%&   & PSK   & CAMELLIA\_256\_GCM  &       \\
+%    &   & DHE\_PSK   & CAMELLIA\_128\_GCM  &       \\
+%    &   & RSA\_PSK   & ARIA\_256\_GCM  &       \\
+%    &   & ECDHE\_PSK & ARIA\_256\_CBC  &       \\
+%    &   &   & ARIA\_128\_GCM  &       \\
+%    &   &   & ARIA\_128\_CBC  &       \\
+%    &   &   & SEED  &       \\
+%\cmidrule[\heavyrulewidth]{2-5}
+%\end{tabular}
+%\end{center}
+%
+%A remark on the ``consider'' section: the BSI (Federal office for information security, Germany) recommends in its technical report TR-02102-2\footnote{\url{https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html}} to \textbf{avoid} non-ephemeral\footnote{Ephemeral keys are session keys which are destroyed upon termination of the encrypted session. In TLS/SSL, they are realized by the DHE cipher suites. } keys for any communication which might contain personal or sensitive data. In this document, we follow BSI's advice and therefore only keep cipher suites containing (EC)DH\textbf{E} (ephemeral) variants. System administrators, who can not use forward secrecy can still use the cipher suites in the ``consider'' section. We however, do not recommend them in this document.
+%
+%%% NOTE: s/forward secrecy/perfect forward secrecy???
+%
+%Note that the entries marked as ``special'' are cipher suites which are not common to all clients (webbrowsers etc).
+%
+%
+%\subsubsection{Tested clients}
+% 
+%Next we tested the cipher suites above on the following clients:
+%
+%%% NOTE: we need to test with more systems!!
+%\begin{itemize}
+%\item Chrome 30.0.1599.101 Mac OS X 10.9
+%\item Safari 7.0 Mac OS X 10.9
+%\item Firefox 25.0 Mac OS X 10.9
+%\item Internet Explorer 10 Windows 7
+%\item Apple iOS 7.0.3
+%\end{itemize}
+%
+%
+%The result of testing the cipher suites with these clients gives us a preference order as shown in table \ref{table:prefOrderCipherSuites}. 
+%Should a client not be able to use a specific cipher suite, it will fall back to the next possible entry as given by the ordering.
+%
+%\begin{table}[h]
+%\centering\small
+%    \begin{tabular}{cllcccc}
+%    \toprule
+%    \textbf{Pref}   & \textbf{Cipher Suite}                            & \textbf{ID}   & \multicolumn{4}{l}{\textbf{Supported by}}\\ 
+%    \cmidrule(lr){4-7}
+%                    & \textbf{OpenSSL Name}                            &               & Chrome & FF   & IE   & Safari \\
+%    \cmidrule(lr){1-7}
+%    \phantom{0}1    & \verb|TLS_DHE_RSA_WITH_AES_256_GCM_SHA384|     & \verb|0x009f| & \no    & \no  & \no  & \no    \\
+%                    & \verb|DHE-RSA-AES256-GCM-SHA384|                      &               & &&&\\\rowcolor{lightlightgray}
+%    \phantom{0}2    & \verb|TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384| & \verb|0xC024| & \no    & \no  & \no  & \yes   \\\rowcolor{lightlightgray}
+%                    & \verb|ECDHE-ECDSA-AES256-SHA384|                      &               & &&&\\
+%    \phantom{0}3    & \verb|TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384|   & \verb|0xC028| & \no    & \no  & \no  & \yes   \\
+%                    & \verb|ECDHE-RSA-AES256-SHA384|                        &               & &&&\\\rowcolor{lightlightgray}
+%    \phantom{0}4    & \verb|TLS_DHE_RSA_WITH_AES_256_CBC_SHA256|     & \verb|0x006B| & \yes   & \no  & \no  & \yes   \\\rowcolor{lightlightgray}
+%                    & \verb|DHE-RSA-AES256-SHA256|                          &               & &&&\\
+%    \phantom{0}5    & \verb|TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA|    & \verb|0xC00A| & \yes   & \yes & \yes & \yes   \\
+%                    & \verb|ECDHE-ECDSA-AES256-SHA|                         &               & &&&\\\rowcolor{lightlightgray}
+%    \phantom{0}6    & \verb|TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA|      & \verb|0xC014| & \yes   & \yes & \yes & \yes   \\\rowcolor{lightlightgray}
+%                    & \verb|ECDHE-RSA-AES256-SHA|                           &               & &&&\\
+%    \phantom{0}7    & \verb|TLS_DHE_RSA_WITH_AES_256_CBC_SHA|        & \verb|0x0039| & \yes   & \yes & \no  & \yes   \\
+%                    & \verb|DHE-RSA-AES256-SHA|                             &               & &&&\\\rowcolor{lightlightgray}
+%    \phantom{0}8    & \verb|TLS_DHE_DSS_WITH_AES_256_CBC_SHA|        & \verb|0x0038| & \no    & \yes & \yes & \no    \\\rowcolor{lightlightgray}
+%                    & \verb|DHE-DSS-AES256-SHA|                             &               & &&&\\
+%    \phantom{0}9    & \verb|TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA|   & \verb|0x0088| & \no    & \yes & \no  & \no    \\
+%                    & \verb|DHE-RSA-CAMELLIA256-SHA|                        &               & &&&\\\rowcolor{lightlightgray}
+%    \phantom{}10    & \verb|TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA|   & \verb|0x0087| & \no    & \yes & \no  & \no    \\\rowcolor{lightlightgray}
+%                    & \verb|DHE-DSS-CAMELLIA256-SHA|                        &               & &&&\\
+%   \bottomrule
+%    \end{tabular}
+%\caption{Preference order of cipher suites.  All suites are supported by OpenSSL.}
+%\label{table:prefOrderCipherSuites}
+%\end{table}
+%
+%Note: the above table \ref{table:prefOrderCipherSuites} contains Elliptic curve key exchanges. There are currently strong doubts\footnote{\url{http://safecurves.cr.yp.to/rigid.html}} concerning ECC.
+%If unsure, remove the cipher suites starting with ECDHE in the table above.
+%
+%
+%Based on this ordering, we can now define the corresponding settings for servers. We will start with the most common web servers.
diff --git a/src/theory/cipher_suites/compatibility.tex b/src/theory/cipher_suites/compatibility.tex
new file mode 100644 (file)
index 0000000..3874aba
--- /dev/null
@@ -0,0 +1,3 @@
+\subsection{Compatibility}
+\label{section: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.}
diff --git a/src/theory/cipher_suites/forward.tex b/src/theory/cipher_suites/forward.tex
new file mode 100644 (file)
index 0000000..e7a9ab6
--- /dev/null
@@ -0,0 +1,8 @@
+%%\subsection{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
+\footnote{\url{http://en.wikipedia.org/wiki/Forward\_secrecy}}
+\footnote{\url{https://www.eff.org/deeplinks/2013/08/pushing-perfect-forward-secrecy-important-web-privacy-protection}}
+\footnote{\url{http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html}}.
diff --git a/src/theory/cipher_suites/insecure.tex b/src/theory/cipher_suites/insecure.tex
new file mode 100644 (file)
index 0000000..585af09
--- /dev/null
@@ -0,0 +1,17 @@
+%%\subsection{Known insecure and weak cipher suites}
+%\todo{PG: please write this section. List all known broken, obsolete, weak and insecure cipher suites . Or even better: find the best site which keeps track of outdated cipher suites and simply reference it. We do not want to maintain such a list ourselves!}
+
+%%Ciphers with 112bit or less are considered weak and aren't recommended. Note that \texttt{3DES} provides only 112bit of security \footnote{\url{http://csrc.nist.gov/publications/PubsSPs.html\#800-57-part1}}.
+
+%% comment Florian:
+%% Please do not consider ciphers with a 112 bit key as weak. I think it is
+%% fine to do not recommend 3DES, but we should not claim that it is weak.
+%% In particular, 3DES with an effective keysize of 112 bits is still
+%% recommended by NIST and by ECRYPT2 for medium-term protection until 2030.
+
+
+%One special remark is necessary for 3DES: here we want to note
+%that it theoretically has 168 bit security, however based on the NIST Special
+%Publication 800-57
+%\footnote{\url{http://csrc.nist.gov/publications/PubsSPs.html\#800-57-part1},
+%pages 63 and 64}, it is clear that 3DES is only considered 80 bits / 112 bits.
diff --git a/src/theory/cipher_suites/recommended.tex b/src/theory/cipher_suites/recommended.tex
new file mode 100644 (file)
index 0000000..e51968b
--- /dev/null
@@ -0,0 +1,168 @@
+%%\subsection{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 website \url{https://www.ssllabs.com/} 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.\\
+
+\textbf{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
+\ref{section:ChoosingYourOwnCipherSuites}}.
+
+
+\subsubsection{Configuration A: Strong ciphers, fewer clients}
+
+At the time of writing we recommend 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 freely.
+
+
+We arrived at this set of cipher suites by selecting:
+
+\begin{itemize}
+\item TLS 1.2
+\item Perfect forward secrecy / ephemeral Diffie Hellman
+\item strong MACs (SHA-2) or
+\item GCM as Authenticated Encryption scheme
+\end{itemize}
+
+This results in the OpenSSL string:
+
+\begin{lstlisting}[breaklines]
+'EDH+aRSA+AES256:EECDH+aRSA+AES256:!SSLv3'
+\end{lstlisting}
+
+%$\implies$ resolves to 
+%
+%\begin{verbatim}
+%openssl ciphers -V $string
+%\end{verbatim}
+
+
+
+%\todo{make a column for cipher chaining mode} --> not really important, is it?
+\begin{center}
+
+\begin{tabular}{lllllll}
+\toprule
+\textbf{ID}   & \textbf{OpenSSL Name}       & \textbf{Version} & \textbf{KeyEx} & \textbf{Auth} & \textbf{Cipher} & \textbf{MAC}\\\cmidrule(lr){1-7}
+\verb|0x009F| & DHE-RSA-AES256-GCM-SHA384   & TLSv1.2          & DH             &  RSA          & AESGCM(256)     & AEAD         \\
+\verb|0x006B| & DHE-RSA-AES256-SHA256       & TLSv1.2          & DH             &  RSA          & AES(256) (CBC)  & SHA256       \\
+\verb|0xC030| & ECDHE-RSA-AES256-GCM-SHA384 & TLSv1.2          & ECDH           &  RSA          & AESGCM(256)     & AEAD         \\
+\verb|0xC028| & ECDHE-RSA-AES256-SHA384     & TLSv1.2          & ECDH           &  RSA          & AES(256) (CBC)  & SHA384       \\
+\bottomrule
+\end{tabular}
+\end{center}
+
+
+\textbf{Compatibility}
+
+Only clients which support TLS 1.2 are covered by these cipher suites (Chrome 30,
+Win 7 and Win 8.1 crypto stack, Opera 17, OpenSSL $\ge$ 1.0.1e, Safari 6 / iOS
+6.0.1, Safari 7 / OS X 10.9).
+
+
+
+\subsubsection{Configuration B: Weaker ciphers, more compatability}
+
+In this section we propose a slightly weaker set of cipher suites.  For
+example, there are some 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
+the compatibility with a broad range of clients, but also less computational
+workload on the provisioning hardware.
+\\
+
+\textbf{All further examples in this publication use Configuration B}.\\
+
+We arrived at this set of cipher suites by selecting:
+
+\begin{itemize}
+\item TLS 1.2, TLS 1.1, TLS 1.0
+\item allowing SHA-1 (see the comments on SHA-1 in section \ref{section:SHA})
+
+% \todo{AK: Note that SHA1 is considered broken but if we are in DHE, we might get around it as long as you can not calculate a SHA1 collision ``live'' on the wire}
+% FIXED: see section "SHA-1"
+
+\end{itemize}
+
+This results in the OpenSSL string:
+
+%'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:!SRP:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'
+\begin{lstlisting}[breaklines]
+@@@CIPHERSTRINGB@@@
+\end{lstlisting}
+
+\todo{make a column for cipher chaining mode}
+\begin{center}
+\begin{tabular}{lllllll}
+\toprule
+\textbf{ID}   & \textbf{OpenSSL Name}       & \textbf{Version} & \textbf{KeyEx} & \textbf{Auth} & \textbf{Cipher} & \textbf{MAC}\\\cmidrule(lr){1-7}
+\verb|0x009F| & DHE-RSA-AES256-GCM-SHA384   & TLSv1.2          & DH             & RSA           & AESGCM(256)     & AEAD         \\
+\verb|0x006B| & DHE-RSA-AES256-SHA256       & TLSv1.2          & DH             & RSA           & AES(256)        & SHA256       \\
+\verb|0xC030| & ECDHE-RSA-AES256-GCM-SHA384 & TLSv1.2          & ECDH           & RSA           & AESGCM(256)     & AEAD         \\
+\verb|0xC028| & ECDHE-RSA-AES256-SHA384     & TLSv1.2          & ECDH           & RSA           & AES(256)        & SHA384       \\
+\verb|0x009E| & DHE-RSA-AES128-GCM-SHA256   & TLSv1.2          & DH             & RSA           & AESGCM(128)     & AEAD         \\
+\verb|0x0067| & DHE-RSA-AES128-SHA256       & TLSv1.2          & DH             & RSA           & AES(128)        & SHA256       \\
+\verb|0xC02F| & ECDHE-RSA-AES128-GCM-SHA256 & TLSv1.2          & ECDH           & RSA           & AESGCM(128)     & AEAD         \\
+\verb|0xC027| & ECDHE-RSA-AES128-SHA256     & TLSv1.2          & ECDH           & RSA           & AES(128)        & SHA256       \\
+\verb|0x0088| & DHE-RSA-CAMELLIA256-SHA     & SSLv3            & DH             & RSA           & Camellia(256)   & SHA1         \\
+\verb|0x0039| & DHE-RSA-AES256-SHA          & SSLv3            & DH             & RSA           & AES(256)        & SHA1         \\
+\verb|0xC014| & ECDHE-RSA-AES256-SHA        & SSLv3            & ECDH           & RSA           & AES(256)        & SHA1         \\
+\verb|0x0045| & DHE-RSA-CAMELLIA128-SHA     & SSLv3            & DH             & RSA           & Camellia(128)   & SHA1         \\
+\verb|0x0033| & DHE-RSA-AES128-SHA          & SSLv3            & DH             & RSA           & AES(128)        & SHA1         \\
+\verb|0xC013| & ECDHE-RSA-AES128-SHA        & SSLv3            & ECDH           & RSA           & AES(128)        & SHA1         \\
+\verb|0x0084| & CAMELLIA256-SHA             & SSLv3            & RSA            & RSA           & Camellia(256)   & SHA1         \\
+\verb|0x0035| & AES256-SHA                  & SSLv3            & RSA            & RSA           & AES(256)        & SHA1         \\
+\verb|0x0041| & CAMELLIA128-SHA             & SSLv3            & RSA            & RSA           & Camellia(128)   & SHA1         \\
+\verb|0x002F| & AES128-SHA                  & SSLv3            & RSA            & RSA           & AES(128)        & SHA1         \\
+\bottomrule
+\end{tabular}
+\end{center}
+
+\textbf{Compatibility}
+
+Note that these cipher suites will not work with Windows XP's crypto stack (e.g. IE, Outlook), 
+%%Java 6, Java 7 and Android 2.3. Java 7 could be made compatible by installing the "Java 
+%%Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files"
+%%(JCE) \footnote{\url{http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html}}.
+We could not verify yet if installing JCE also fixes the Java 7
+DH-parameter length limitation (1024 bit). 
+\todo{do that!}
+
+\textbf{Explanation}
+
+For a detailed explanation of the cipher suites chosen, please see
+\ref{section:ChoosingYourOwnCipherSuites}. In short, finding the perfect cipher
+string is impossible and 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.
+
+Straight forward, the authors wanted strong ciphers, forward secrecy
+\footnote{\url{http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html}}
+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".
+
+\begin{itemize}
+\item TLSv1.2 is preferred over TLSv1.0/SSLv3 (while still providing a useable cipher
+      string for SSLv3).
+\item AES256 and CAMELLIA256 count as very strong ciphers at the moment.
+\item AES128 and CAMELLIA128 count as strong ciphers at the moment
+\item DHE or ECDHE for forward secrecy
+\item RSA as this will fit most of todays setups
+\item AES256-SHA as a last resort (with this cipher at the end, even systems with
+      legacy distributions of OpenSSL will work out of the box. Forward secrecy
+      will not be available. On systems that do not support elliptic curves, that cipher
+      offers support for the Microsoft crypto libraries that only support ECDHE. \todo{what does that mean?! inconclusive!}
+\end{itemize}
+
+\todo{Adi: review "justification" when next section is written}
diff --git a/src/theory/keylengths.tex b/src/theory/keylengths.tex
new file mode 100644 (file)
index 0000000..7e844c8
--- /dev/null
@@ -0,0 +1,73 @@
+\section{Keylengths}
+\label{section:keylengths}
+
+
+\epigraph{``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.''}{-- Vincent Rijmen
+in a personal mail exchange Dec 2013}
+
+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 chosing an encryption algorithm and keylength, 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 (\cite{ii2011ecrypt}) gives a fascinating overview of
+strenghts of symmetric keys in chapter 5 and chapter 7. Summarizing ECRYPT II, we
+recommend 128 bit of key strenght 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. See chapter 7 of \cite{ii2011ecrypt}, page 30.
+
+
+There are a couple of other studies comparing keylengths and their respective
+strengths.  The website \url{http://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 \ref{fig:keylengths.com} shows a typical comparison of keylengths on
+this web site.
+
+\begin{figure}[h]
+  \centering
+  \includegraphics[width=0.65\textwidth]{img/keylengths_com.png}
+  \caption{Screenshot of \url{http://www.keylength.com} for 128 bit symmetric key size equivalents}
+  \label{fig:keylengths.com}
+\end{figure}
+
+
+\paragraph{Summary}
+\begin{itemize}
+
+\item For traditional asymmetric public-key cryptography we consider any key
+length below 2048 bits to be deprecated at the time of this writing (for long
+term protection).  
+
+\item For elliptic curve cryptography we consider key lengths below 256 bits to
+be inadequate for long term protection.  
+
+\item For symmetric algorithms we consider anything below 128 bits to be
+inadequate for long term protection.
+
+\end{itemize}
+
+\paragraph{Special remark on 3DES} \mbox{} \\
+We want to note that 3DES theoretically has 168 bits of security, however based
+on the NIST Special Publication 800-57
+\footnote{\url{http://csrc.nist.gov/publications/PubsSPs.html\#800-57-part1},
+pages 63 and 64}, it is clear that 3DES can only be considered to provide for
+80 bits / 112 bits security.
+
+
+
+
+
diff --git a/src/theory/overview.tex b/src/theory/overview.tex
new file mode 100644 (file)
index 0000000..5cd7e83
--- /dev/null
@@ -0,0 +1,19 @@
+\section{Overview}
+\label{sec:TheoryOverview}
+
+
+\epigraph{``The balance between freedom and security is a delicate one.''}{-- Mark Udall, american politician}
+
+This chapter provides the necessary background information on why chapter \ref{chapter:PracticalSettings} recommended \textit{cipher string B}.
+
+\vskip 0.5em
+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.
+
+\vskip 0.5em
+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{section:compatibility}. 
+All these sections will allow a system administrator to balance his or her needs for strong encryption with useability and compatibility.
+
+\vskip 0.5em
+
+Last but not least, we finish this chapter by talking about issues in PKIs (section \ref{section:PKI}), 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.
+
diff --git a/src/whoshouldread.tex b/src/whoshouldread.tex
new file mode 100644 (file)
index 0000000..3d4d005
--- /dev/null
@@ -0,0 +1,9 @@
+\section{Audience}
+
+
+Sysadmins. Sysadmins. Sysadmins.
+
+
+
+
+