Merge branch 'master' of https://git.bettercrypto.org/ach-master
authorPepi Zawodsky <git@maclemon.at>
Fri, 6 Dec 2013 20:12:19 +0000 (21:12 +0100)
committerPepi Zawodsky <git@maclemon.at>
Fri, 6 Dec 2013 20:12:19 +0000 (21:12 +0100)
17 files changed:
src/ECC.tex
src/PKIs.tex
src/cipher_suites/architecture.tex
src/cipher_suites/choosing.tex
src/cipher_suites/recommended.tex
src/disclaimer.tex
src/howtoread.tex
src/keylengths.tex
src/methods.tex
src/practical_settings.tex
src/practical_settings/GPG.tex
src/practical_settings/ipmi.tex
src/practical_settings/mailserver.tex
src/practical_settings/proxy_solutions.tex
src/practical_settings/ssh.tex [new file with mode: 0644]
src/practical_settings/vpn.tex
src/scope.tex

index cbb5420..65f0b9b 100644 (file)
@@ -16,8 +16,7 @@ to understand - luckily there have been some great introductions on the topic la
 \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 
-on keylengths to get an idea)
+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
index 805c546..4efe3c9 100644 (file)
@@ -2,17 +2,24 @@
 \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 for creating a signature chain from the CA down to the server (or client).
+a certificates 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.
 
-This section deals with settings related to trusting CAs.  However, our main
+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 is mostly possible in any machine 2 machine
-communication system where compatibility with externalities is not an issue.
+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 \todo{insert reference}.
+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 
index e9b0b87..e04eefd 100644 (file)
@@ -1,8 +1,8 @@
 %%\subsection{Architectural overview }
 
-A cipher suite is a standardised collection of key exchange algorithms, ciphers,
-Message authentication code (MAC) that provides authenticated encryption schemes. 
-It consists of the following components:
+A cipher suite is a standardised collection of key exchange algorithms, encryption 
+algorithms (ciphers) and Message authentication codes (MAC) that provides authenticated 
+encryption schemes. It consists of the following components:
 
 \begin{description}
 \item{Key exchange protocol:}
@@ -22,9 +22,7 @@ Example: RSA ECDSA DSA
 \item{Cipher:}
 The cipher is used to encrypt the message stream. It also contains the key size
 and mode used by the suite.
-
-Example: AES128 AES128\_GCM Camellia128 
-
+Example: AES128 AES128\_GCM Camellia128
 
 \item{Message authentication code (MAC):}
 A MAC ensures that the message has not been tampered with (integrity).
@@ -33,6 +31,6 @@ Examples: SHA256 SHA384 SHA
 \todo{find a good visualisation for a cipher suite composition}
 
 \item{Authenticated encryption scheme:}
-An encryption scheme which provides confidentiality, integrity and authenticity.
+An encryption scheme which provides for confidentiality, integrity and authenticity.
 
 \end{description}
\ No newline at end of file
index e2bb92d..146de95 100644 (file)
@@ -3,28 +3,30 @@
 
 \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 mechanism, an authentication, a
-stream cipher (or a block cipher with a chaining mode) and a message authentication
-mechanism.
+%%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 those mechanisms are interchangeable like the key exchange in this example:
+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 about every crypto library, most of
-them for historic reasons like the crypto export embargo
+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 
 \footnote{\url{http://en.wikipedia.org/wiki/Export_of_cryptography_in_the_United_States}}.
-For the following chapter support of those is assumed to be disabled by having
+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}
+\subsubsection{Key Exchange}
 
-Many algorithms allow a secure key exchange. Among those are RSA, DSA, DH, EDH, ECDSA,
-ECDH, EECDH and a few others. During the key exchange, keys for authentication and for
-encryption are exchanged. For RSA and DSA those keys are the same.
+Many algorithms allow secure key exchange. Among those are RSA, DH, EDH, ECDSA,
+ECDH, EECDH among others. During the key exchange, keys for authentication and for
+encryption are exchanged. %%For RSA and DSA those keys are the same. %% WHAT?
 
 \todo{explain this section}
 
@@ -49,17 +51,17 @@ encryption are exchanged. For RSA and DSA those keys are the same.
 \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
-gets the server key. \\
-All ephemeral key exchange mechanisms base on Diffie-Hellman algorithm and require
+obtains the server key. \\
+All ephemeral key exchange schemes are based on the Diffie-Hellman algorithm and require
 pre-generated Diffe-Hellman parameter (which allow fast ephemeral key generation). It
-is important to note that the Diffie-Hellman parameters need to be at least as strong
-(speaking in number of bits) as the RSA host key. \todo{TODO: reference!}
+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}\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 NSA). \\
+weren't properly explained (by the NSA).\todo{TODO: reference!} \\
 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
index 218ccba..870246f 100644 (file)
@@ -62,7 +62,7 @@ This results in the string:
 
 \textbf{Compatibility}
 
-Only clients which support TLS1.2 are covered by these cipher suites (Chrome 30,
+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).
 
index 76b6868..008f373 100644 (file)
@@ -1,8 +1,8 @@
 \section{Disclaimer}
 \label{section:disclaimer}
-This guide specifically does not address physical security issues, protecting software and hardware against exploits, basic IT security housekeeping tasks, anti-tempest\footnote{\url{https://en.wikipedia.org/wiki/Tempest\_(codename)}} attack techniques, protecting against side-channel attacks, downgrade attacks, jamming the encrypted channel or other similar attacks which are usually employed to circumvent strong encryption. The authors can not overstate the importance of these other techniques. 
+This guide specifically does not address physical security, protecting software and hardware against exploits, basic IT security housekeeping, anti-tempest\footnote{\url{https://en.wikipedia.org/wiki/Tempest\_(codename)}} attack techniques, protecting against side-channel 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.
 
-This guide can only describe what the authors currently \emph{believe} to be the best settings based on their personal experience. This guide was cross checked by multiple people. For a complete list, see the section ``reviewers''. Even though, multiple specialists reviewed the guide, the authors can give \emph{no guarantee} whatsover that they made the right recommendations. Keep in mind that tomorrow there might be new attacks on some ciphers and many of the recommendations in this guide might turn out to be wrong.
+This guide can only describe what the authors currently \emph{believe} to be the best settings based on their personal experience. This guide was cross checked by multiple people. For a complete list, see the section \ref{section:Reviewers}. Even though, multiple specialists reviewed the guide, the authors can give \emph{no guarantee} whatsover that they made the right recommendations. Keep in mind that tomorrow there might be new attacks on some ciphers and many of the recommendations in this guide might turn out to be wrong.
 
 
 %% should we keep that sentence?
index 13a89a2..1e95126 100644 (file)
@@ -1,5 +1,5 @@
 \section{How to read this guide}
 
-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 read some of the background information, especially on how to choose your own cipher string in section \ref{section:CipherSuites} and then adapt the settings in section \ref{section:PracticalSettings} to your own needs.
+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 read through the background information we provide in this publication, especially on how to choose your own cipher string in section \ref{section:CipherSuites} and then adapt the settings in section \ref{section:PracticalSettings} to your own needs.
 
 
index 35c8d05..94a7a2c 100644 (file)
@@ -2,28 +2,27 @@
 \label{section:keylengths}
 
 Recommendations on keylengths need to be adapted regularly. Since this document
-is static, we will rather refer to existing publications and websites.
-Recommending the right key length is a hit-and-miss issue.
+is static, we rather want refer to existing publications and websites.
+Recommending a safe key length is a hit-and-miss issue.
 
-\url{http://www.keylength.com/} offers a good overview of approximations for
-key size security based on recommendations by standardization bodies and
+The website \url{http://www.keylength.com/} offers a good overview of approximations for
+key lenght security based on recommendations by different standardization bodies and
 academic publications.
 
 \begin{itemize}
-\item For RSA cryptography we consider any key length below 2048 bits to be
+\item For traditional asymmetric public-key cryptography we consider any key length below 2048 bits to be
 deprectated at the time of this writing.  
-\item For ECC we consider key length below
-224 bits to be deprectated.  
-\item For symmetric algorithms, consider anything below
-128 bits to be deprecated.
+\item For elliptic curve cryptography we consider key lengths below 224 bits to be deprectated.  
+\item For symmetric algorithms we consider anything below 128 bits to be deprecated.
 \end{itemize}
 
 
-One special remark is necessary for 3DES: here we want to note that it
+One special remark is necessary for 3DES: here we want to note that 3DES
 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.
+pages 63 and 64}, it is clear that 3DES can only be considered to provide for 
+80 bits / 112 bits security.
 
 
 
index 412dd0f..e058a45 100644 (file)
@@ -1,17 +1,16 @@
 \section{Methods}
 \label{section:Methods}
 
+For writing this guide, we chose to collect the most well researched facts about 
+cryptography settings and let as many trusted specialists as possible review those settings.  
+The review process is completely open and done on a public mailing list. The
+document is available (read-only) to the public Internet on a git server, GitHub (mirror) 
+and open for public scrutiny. However, write permissions to the document are only
+granted to vetted people. The list of editors can be found in section \ref{section:Reviewers}.  
+Every write operation to the document is logged via the ``git'' version control system 
+and can thus be traced to a specific author.  We do not trust an unknown git server. 
 
-For writing this guide, we chose to collect the most well known facts about crypto-settings
-and let as many trusted specialists as possible review these settings.  The
-review process is completely open and done on a public mailing list. The
-document is available (read-only) to the public Internet on a git server and
-open for public scrutiny. However, write permissions to the document are only
-granted to trusted people. The list of editors is made public.  Every write
-operation to the document is logged via the ``git'' version control system and
-thus can be traced back to a specific author.  We do not trust an unknown git
-server. 
-
-Public peer-review and  ``multiple eyes'' checking our recommendation is the best
-strategy we can imagine at the moment\footnote{\url{http://www.wired.com/opinion/2013/10/how-to-design-and-defend-against-the-perfect-backdoor/}}.
+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/}}.
 
index ce21e29..b7eb474 100644 (file)
@@ -6,6 +6,8 @@
 \subsection{Webservers}
 \input{"./practical_settings/webserver.tex"}
 
+\subsection{SSH}
+\input{"./practical_settings/ssh.tex"}
 
 \subsection{Mail Servers}
 \input{"./practical_settings/mailserver.tex"}
index 7bcde99..d9ef7c2 100644 (file)
@@ -1,6 +1,8 @@
 
-PGP uses asymetric encryption to protecte a sesion key which is used to encipher a message . Additionally, it signs messages via asymetric encryption and hash functions.
-Since SHA-1 as hash function has been broken already in 2005\footnote{\url{https://www.schneier.com/blog/archives/2005/02/sha1\_broken.html}}, there are a couple of settings a PGP user can change to use different hashes.
+The PGP protocol
+\footnote{url{http://tools.ietf.org/search/rfc4880}}
+ uses asymmetric encryption to protect a sesion key which is used to encrypt a message. Additionally, it signs messages via asymmetric encryption and hash functions. %% what? - azet
+Research on SHA-1 has showen that collision attacks are a real threat to the security of this hash function back in 2005\footnote{\url{https://www.schneier.com/blog/archives/2005/02/sha1\_broken.html}}, there are a PGP settings a user should change to avoid using SHA-1:
 
 When using PGP, there are a couple of things to take care of:
 \begin{itemize}
index ece3f37..c48265e 100644 (file)
@@ -1,5 +1,5 @@
 %%\subsection{IPMI, ILO and other lights out management solutions}
 
 
-We \textbf{strongly} recommend that any remote management system for servers such as ILO, IPMI and similar never be connected to a public IP address.
-Consider creating a management VLAN and access that only via a VPN.
\ No newline at end of file
+We \textbf{strongly} recommend that any remote management system for servers such as ILO, iDRAC, IPMI based solutions and similar systems never be connected to the public internet.
+Consider creating an unrouted management VLAN and access that only via a VPN.
\ No newline at end of file
index 02d9098..2a6b66b 100644 (file)
@@ -19,7 +19,7 @@ Dovecot 2.1: Almost as good as dovecot 2.2. Does not support ssl\_prefer\_server
 \paragraph*{Limitations}\mbox{}\\
 
 Dovecot currently does not support disabling TLS compression. Furthermore, DH parameters
-greater than 1024bit aren't possible. The most recent version 2.2.7 of Dovecot implements
+greater than 1024bit are not supported. The most recent version 2.2.7 of Dovecot implements
 configurable DH parameter length
 \footnote{\url{http://hg.dovecot.org/dovecot-2.2/rev/43ab5abeb8f0}}.
 
@@ -68,7 +68,7 @@ To support POP3S/IMAPS on ports 995/993 add
 
 \paragraph*{Limitations}\mbox{}\\
 
-cyrus-imapd currently (2.4.17, trunk) does not support elliptic curves. ECDHE will not work even if defined in your cipher list.\\
+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.\\
 
 Currently there is no way to prefer server ciphers or to disable compression.\\
 
@@ -87,7 +87,7 @@ There is a working patch for all three features:
 
 \subsubsection{SMTP in general}
 
-SMTP usually uses 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.\\
+SMTP usually makes use of opportunistic TLS. This means that an MTA will accept TLS connections when asked for it during handshake but will not require it. One should always support incoming opportunistic TLS and always try TLS handshake outgoing.\\
 
 Furthermore a mailserver can operate in three modes:
 \begin{itemize}
@@ -271,7 +271,7 @@ Add the following rules on top of your acl\_smtp\_mail:
   warn    hosts           = *
           control         = submission/sender_retain
 \end{lstlisting}
-This switches Exim to submission mode and allows addition of missing Message-ID: and Date: headers.\\
+This switches Exim to submission mode and allows addition of missing ``Message-ID'' and ``Date'' headers.\\
 
 It is not advisable to restrict the default cipher list for MSA mode if you don't know all connecting MUAs. If you still want to define one please consult the Exim documentation or ask on the exim-users mailinglist.\\
 % Exim maintainers do not recommend to change default ciphers
@@ -390,24 +390,3 @@ There already is a working patch to provide support:\\
 % do we need to documment starttls in detail?
 %\subsubsection{starttls?}
 
-\subsection{OpenSSH}
-\paragraph*{sshd_config}
-\begin{lstlisting}[breaklines]
-       # ...
-
-       Protocol 2
-       PermitEmptyPasswords no
-       PermitRootLogin no
-       StrictModes yes
-       HostKey /etc/ssh/ssh_host_rsa_key
-       ServerKeyBits 4096
-       Ciphers aes256-gcm@openssh.com aes128-gcm@openssh.com aes256-ctr aes128-ctr
-       MACs umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
-       KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
-\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 support for DSA keys stronger than 1024bit
-\footnote{\url{https://bugzilla.mindrot.org/show_bug.cgi?id=1647}} 
-which is far below current standards (see section \ref{section:keylengths}). Legacy systems can use this configuration and simply omit unsupported ciphers, key exchange algorithms and MACs.
-\\
index 3557026..1d9b003 100644 (file)
@@ -1,8 +1,8 @@
 %%\subsection{Intercepting proxy solutions and reverse proxies}
 
-Within enterprise networks and corporations with increased levels of paranoia or at least some defined security requirements it is common, NOT to allow direct connections to the public internet.
+Within enterprise networks and corporations with increased levels of paranoia or at least some defined security requirements it is common NOT to allow direct connections to the public internet.
 
-For this reason proxy-solutions are installed, to intercept ans (hopefully also) scan the traffic for potential threats within the sessions.
+For this reasons proxy solutions are installed to intercept and scan the traffic for potential threats within the sessions.
 
 As soon as one wants to establish an encrypted connection to a server, there are three choices:
 
@@ -14,7 +14,7 @@ As soon as one wants to establish an encrypted connection to a server, there are
 
 While the latest solution might be the most "up to date", it arises a new front in the context of this paper, because the most secure part of a client's connection could only be within the corporate network, if the proxy-server handles the connection to the destination server in an insecure manner.
 
-Conclusio: Don't forget to check your proxy solutions ssl-capabilities. Also do so for your reverse-proxies!
+Conclusion: Don't forget to check your proxy solutions SSL-capabilities. Also do so for your reverse proxies!
 
 \subsubsection{squid}
 
diff --git a/src/practical_settings/ssh.tex b/src/practical_settings/ssh.tex
new file mode 100644 (file)
index 0000000..b127ffc
--- /dev/null
@@ -0,0 +1,21 @@
+\subsubsection{OpenSSH}
+\paragraph*{sshd_config}
+\begin{lstlisting}[breaklines]
+       # ...
+
+       Protocol 2
+       PermitEmptyPasswords no
+       PermitRootLogin no
+       StrictModes yes
+       HostKey /etc/ssh/ssh_host_rsa_key
+       ServerKeyBits 4096
+       Ciphers aes256-gcm@openssh.com aes128-gcm@openssh.com aes256-ctr aes128-ctr
+       MACs umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
+       KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
+\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 support for DSA keys stronger than 1024bit
+\footnote{\url{https://bugzilla.mindrot.org/show_bug.cgi?id=1647}} 
+which is far below current standards (see section \ref{section:keylengths}). Legacy systems can use this configuration and simply omit unsupported ciphers, key exchange algorithms and MACs.
+\\
index de1af22..0795b14 100644 (file)
@@ -10,7 +10,7 @@
 
 \paragraph*{Assumptions}\mbox{}\\
 
-We assume the usage of IKE (v1 or v2) for this document, and ESP.
+We assume the use of IKE (v1 or v2) and ESP for this document.
 
 \paragraph*{Authentication}\mbox{}\\
 
index 8db492d..670fcb3 100644 (file)
@@ -5,7 +5,7 @@ In this guide, we restricted ourselves to:
 \begin{itemize}
 \item Internet-facing services
 \item Commonly used services
-\item Devices which are used in business environments (this mostly excludes XBoxes, Playstations and similar common consumer devices)
+\item Devices which are used in business environments (this specifically excludes XBoxes, Playstations and similar  consumer devices)
 \item OpenSSL 
 \end{itemize}