\vskip 0.5em
-As Schneier noted in \cite{Sch13},
-it seems that intelligence agencies and adversaries on the Internet are not
-breaking so much the mathematics of encryption per se, but rather use software
-and hardware weaknesses, subvert standardization processes, plant backdoors,
-rig random number generators and most of all exploit careless settings in
-server configurations and encryption systems to listen in on private
-communications.
+As Schneier noted in \cite{Sch13}, it seems that intelligence agencies and
+adversaries on the Internet are not breaking so much the mathematics of
+encryption per se, but rather use software and hardware weaknesses, subvert
+standardization processes, plant backdoors, rig random number generators and
+most of all exploit careless settings in server configurations and encryption
+systems to listen in on private communications. Worst of all, most
+communication on the internet is not encrypted at all by default
+(for SMTP, opportunistic TLS would be a solution).
\vskip 0.5em
getting the crypto settings right to the best of the authors' current
knowledge. Other attacks, as the above mentioned, require different protection
schemes which are not covered in this guide. This guide is not an introduction
-to cryptography on how to use PGP nor SSL. For background information on
-cryptography, cryptoanalysis, PGP and SSL we would like to refer the reader to
-the the references (see chapter \ref{section:Links} and
-\ref{section:Suggested_Reading}) at the end of this document.
+to cryptography. For background information on cryptography and cryptoanalysis
+we would like to refer the reader to the the references in chapter
+\ref{section:Links} and \ref{section:Suggested_Reading} at the end of this
+document.
\vskip 0.5em
-The focus of this guide is merely to give current best practices for
-configuring complex cipher suites and related parameters in a \textbf{copy \&
+The focus of this guide is merely to give current \emph{best practices for
+configuring complex cipher suites} and related parameters in a \emph{copy \&
paste-able manner}. The guide tries to stay as concise as is possible for such
-a complex topic as cryptography. There are many excellent guides
-(\cite{ii2011ecrypt},\cite{TR02102}) and best practice documents available when
-it comes to cryptography. However none of them focuses specifically on what an
-average system administrator needs for hardening his or her systems' crypto
-settings.
+a complex topic as cryptography. Naturaly, it can not be complete. Instead,
+there are many excellent guides (\cite{ii2011ecrypt},\cite{TR02102}) and best
+practice documents available when it comes to cryptography. However none of
+them focuses specifically on what an average system administrator needs for
+hardening his or her systems' crypto settings.
+\vskip 0.5em
This guide tries to fill this gap.
+%\vskip 3.5em
+%\tiny
+%The guide was produced in an open source manner: every step of editing can be
+%traced back to a specific author via our version control system.
+
\end{abstract}
This guide specifically does not address physical security, protecting software
and hardware against exploits, basic IT security housekeeping, complete
-information assurance, issues with key-roll over and key management, securing client PCs and mobile devices,
-anti-tempest\cite{Wikipedia:Tempest} attack techniques,
+information assurance, issues with key-roll over and key management, securing
+client PCs and mobile devices (theft, loss), proper
+OPSec\footnote{\url{http://en.wikipedia.org/wiki/Operations_security}}, social
+engineering attacks, anti-tempest\cite{Wikipedia:Tempest} attack techniques,
protecting against different side-channel attacks (timing--, cache timing--,
-differential fault analysis or power monitoring attacks), downgrade attacks,
-jamming the encrypted channel or other similar attacks which are typically
-employed to circumvent strong encryption. The authors can not overstate the
-importance of these other techniques. Interested readers are advised to read
-about these attacks in detail since they give a lot of insight into other parts
-of cryptography engineering which need to be dealt with.\footnote{An easy to
-read yet very insightful recent example is the "FLUSH+RELOAD" technique \cite{yarom2013flush+} for
-leaking cryptographic keys from one virtual machine to another via L3 cache
-timing attacks.}
+differential fault analysis, differntial power analysis or power monitoring
+attacks), downgrade attacks, jamming the encrypted channel or other similar
+attacks which are typically employed to circumvent strong encryption. The
+authors can not overstate the importance of these other techniques. Interested
+readers are advised to read about these attacks in detail since they give a lot
+of insight into other parts of cryptography engineering which need to be dealt
+with.\footnote{An easy to read yet very insightful recent example is the
+"FLUSH+RELOAD" technique \cite{yarom2013flush+} for leaking cryptographic keys
+from one virtual machine to another via L3 cache timing attacks.}
This guide does not talk about the well-known insecurities of trusting a
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 explain how to run your own Certificate Authority (CA).
+Most of this zoo of IT security issues are addressed in the very comprehensive
+book ``Security Engineering'' by Ross Anderson \cite{anderson2008security}.
For some experts in cryptography this text might seem too informal. However, we
strive to keep the language as non-technical as possible and fitting for our
+++ /dev/null
-%%\subsection{Webservers}
-
-\subsubsection{Apache}
-
-\begin{description}
-\item[Tested with Version:]
-
-\item[Settings:] \mbox{}
-
-%-All +TLSv1.1 +TLSv1.2
-\begin{lstlisting}[breaklines]
- SSLProtocol All -SSLv2 -SSLv3
- SSLHonorCipherOrder On
- SSLCompression off
- # Add six earth month HSTS header for all users...
- Header add Strict-Transport-Security "max-age=15768000"
- # If you want to protect all subdomains, use the following header
- # ALL subdomains HAVE TO support https if you use this!
- # Strict-Transport-Security: max-age=15768000 ; includeSubDomains
-
-old:
- SSLCipherSuite 'EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EDH+CAMELLIA256:EECDH:EDH+aRSA:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128:!ECDSA:AES256-SHA'
-new:
- SSLCipherSuite '@@@CIPHERSTRINGB@@@'
-
-\end{lstlisting}
-
-Note again, that any cipher suite starting with ECDHE can be omitted, if in doubt.
-%% XXX NOTE TO SELF: remove from future automatically generated lists!
-
-\item[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:
-
-\begin{lstlisting}[breaklines]
- <VirtualHost *:80>
- #...
- RewriteEngine On
- RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R=permanent]
- #...
- </VirtualHost>
-\end{lstlisting}
-
-\item[Justification for special settings (if needed):]
-
-\item[References:]
-
-\item[How to test:]
-
-See ssllabs in section \ref{section:Tools}
-
-\end{description}
-%XXXX ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS
-
-
-\subsubsection{lighttpd}
-
-
-
-\begin{description}
-\item[Tested with Version:]
-
-\todo{version?}
-
-\item[Settings:] \mbox{}
-
-
-%% Complete ssl.cipher-list with same algo than Apache
-\todo{FIXME: this string seems to be wrongly formatted??}
-
-\begin{lstlisting}[breaklines]
- $SERVER["socket"] == "0.0.0.0:443" {
- ssl.engine = "enable"
- ssl.use-sslv2 = "disable"
- ssl.use-sslv3 = "disable"
- #ssl.use-compression obsolete >= 1.4.3.1
- ssl.pemfile = "/etc/lighttpd/server.pem"
- ssl.cipher-list = 'EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EDH+CAMELLIA256:EECDH:EDH+aRSA:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128:!ECDSA:AES256-SHA'
- ssl.honor-cipher-order = "enable"
- setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=31536000")
- }
-\end{lstlisting}
-
-
-\item[Additional settings:]
-
-As for any other webserver, you should automatically redirect http traffic toward httpS://
-
-\begin{lstlisting}[breaklines]
- $HTTP["scheme"] == "http" {
- # capture vhost name with regex conditiona -> %0 in redirect pattern
- # must be the most inner block to the redirect rule
- $HTTP["host"] =~ ".*" {
- url.redirect = (".*" => "https://%0$0")
- }
- }
-\end{lstlisting}
-
-
-\item[References:]
-\todo{add references}.
-lighttpd httpS:// redirection: \url{http://redmine.lighttpd.net/projects/1/wiki/HowToRedirectHttpToHttps}
-
-% add any further references or best practice documents here
-
-\item[How to test:] See ssllabs in section \ref{section:Tools}
-
-% 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}
-
-
-\subsubsection{nginx}
-
-\begin{description}
-\item[Tested with Version:] 1.4.4 with OpenSSL 1.0.1e on OS X Server 10.8.5
-
-1.2.1-2.2+wheezy2 with OpenSSL 1.0.1e on Debian Wheezy
-1.4.4 with OpenSSL 1.0.1e on Debian Wheezy
-1.4.4 with OpenSSL 1.0.1e on Debian Wheezy
-1.4.4 with OpenSSL 1.0.1e on Debian Wheezy
-1.4.4 with OpenSSL 1.0.1e on Debian Wheezy
-
-\todo{version?}
-
-\item[Settings:] \mbox{}
-
-\begin{lstlisting}[breaklines]
- ssl_prefer_server_ciphers on;
- ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
- ssl_ciphers 'EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EDH+CAMELLIA256:EECDH:EDH+aRSA:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128:!ECDSA:AES256-SHA';
- add_header Strict-Transport-Security max-age=2592000;
-\end{lstlisting}
-
-%% XXX FIXME: do we need to specify dhparams? Parameter: ssl_dhparam = file. See: http://wiki.nginx.org/HttpSslModule#ssl_protocols
-%% NO, use IETF/IKE
-
-If you absolutely want to specify your own DH parameters, you can specify them via
-
-\begin{lstlisting}[breaklines]
- ssl_dhparam file;
-\end{lstlisting}
-
-However, we advise you to read section \ref{section:DH} and stay with the standard IKE/IETF parameters (as long as they are $ > 1024 $ bits).
-
-
-\item[Additional settings:]
-
-If you decide to trust NIST's ECC curve recommendation, you can add the following line to nginx's configuration file to select special curves:
-
-\begin{lstlisting}[breaklines]
- ssl_ecdh_curve secp384r1;
-\end{lstlisting}
-
-You should redirect everything to httpS:// if possible. In Nginx you can do this with the following setting:
-
-\begin{lstlisting}[breaklines]
- rewrite ^(.*) https://$host$1 permanent;
-\end{lstlisting}
-
-
-\item[References:] \todo{add references}
-
-\item[How to test:] See ssllabs in section \ref{section:Tools}
-
-\end{description}
-
-
-
-
-
-\subsubsection{MS IIS}
-\label{sec:ms-iis}
-
-
-\todo{Daniel: add screenshots and registry keys}
-
-\begin{description}
-
-\item[Tested with Version:] \todo{Daniel: add tested version}
-
-\item[Settings:] \mbox{}
-
-
-When trying to avoid RC4 and CBC (BEAST-Attack) and requiring perfect
-forward secrecy, Microsoft Internet Information Server (IIS) supports
-ECDSA, but does not support RSA for key exchange (consider ECC suite
-B doubts\footnote{\url{http://safecurves.cr.yp.to/rigid.html}}).
-
-Since \verb|ECDHE_RSA_*| is not supported, a SSL certificate based on
-elliptic curves needs to be used.
-
-The configuration of cipher suites MS IIS will use, can be configured in one
-of the following ways:
-\begin{enumerate}
-\item Group Policy \footnote{\url{http://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx}}
-\item Registry
-\item IIS Crypto~\footnote{\url{https://www.nartac.com/Products/IISCrypto/}}
-\end{enumerate}
-
-
-Table~\ref{tab:MS_IIS_Client_Support} shows the process of turning on
-one algorithm after another and the effect on the supported clients
-tested using https://www.ssllabs.com.
-
-\verb|SSL 3.0|, \verb|SSL 2.0| and \verb|MD5| are turned off.
-\verb|TLS 1.0| and \verb|TLS 2.0| are turned on.
-
-\begin{table}[h]
- \centering
- \small
- \begin{tabular}{ll}
- \toprule
- Cipher Suite & Client \\
- \midrule
- \verb|TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256| & only IE 10,11, OpenSSL 1.0.1e \\
- \verb|TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256| & Chrome 30, Opera 17, Safari 6+ \\
- \verb|TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA| & FF 10-24, IE 8+, Safari 5, Java 7\\
- \bottomrule
- \end{tabular}
- \caption{Client support}
- \label{tab:MS_IIS_Client_Support}
-\end{table}
-
-Table~\ref{tab:MS_IIS_Client_Support} shows the algoriths from
-strongest to weakest and why they need to be added in this order. For
-example insisting on SHA-2 algorithms (only first two lines) would
-eliminate all versions of Firefox, so the last line is needed to
-support this browser, but should be placed at the bottom, so capable
-browsers will choose the stronger SHA-2 algorithms.
-
-\verb|TLS_RSA_WITH_RC4_128_SHA| or equivalent should also be added if
-MS Terminal Server Connection is used (make sure to use this only in a
-trusted environment). This suite will not be used for SSL, since we do
-not use a RSA Key.
-
-
-% \verb|TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256| ... only supported by: IE 10,11, OpenSSL 1.0.1e
-% \verb|TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256| ... Chrome 30, Opera 17, Safari 6+
-% \verb|TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA| ... Firefox 10-24, IE 8+, Safari 5, Java 7
-
-
-Clients not supported:
-\begin{enumerate}
-\item Java 6
-\item WinXP
-\item Bing
-\end{enumerate}
-
-\item[Additional settings:]
-
-%Here you can add additional settings
-
-\item[Justification for special settings (if needed):]
-
-% 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:] See ssllabs in section \ref{section:Tools}
-
-
-\end{description}
git.bettercrypto.org / ach-master.git / commitdiff