ssl-ca=/etc/mysql/ssl/ca-cert.pem
ssl-cert=/etc/mysql/ssl/client-cert.pem
ssl-key=/etc/mysql/ssl/client-key.pem
-ssl-cipher=EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EDH+CAMELLIA256:EECDH:EDH+aRSA:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128:!ECDSA:AES256-SHA
+ssl-cipher=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
\end{lstlisting}
After restarting the server run the following query to see if the ssl settings are correct:
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)
+on keylenghts to get an idea)
The security of ECC relies on the elliptic curves and curve points chosen
-PGP uses asymetric encryption to protect a session key which is used to encipher a message. Additionally, it signs messages via digital signatures and hash functions.
+PGP uses assymetric encryption to protecte a sesion key which is used to encipher a message . Additionally, it signs messages via assymetric 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.
When using PGP, there are a couple of things to take care of:
\item preferences for hashing
\end{itemize}
-Properly dealing with key material, passphrases and the web-of-trust is outside of the scope of this document. The GnuPG website\footnote{\url{http://www.gnupg.org/}} has a good tutorial on PGP.
+Properly dealing with key material, passphrases and the web-of-trust is outside of the scope of this document. The GnuPG website\footnote{\url{http://www.gnupg.org/}} has a good tutorial on PGP.
\subsubsection{Keylengths}
We do not recommend any key length $\le$ 2048 bits. In fact, 4096 bits are probabaly a good choice at the time of this writing.
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 external entities is not an issue.
+communication systems where compatibility with externalities is not an issue.
A good background on PKIs can be found in \todo{insert reference}.
\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,
+ (CACert, StartSSL), Best-practices how to create CA and how to generate private keys/CSRs,
Discussion about OCSP and CRLs. TD: Useful Firefox plugins: CipherFox, Conspiracy, Perspectives.}
\section{Random Number Generators}
\label{section:RNGs}
-There are currently 2 practical ways to verify whether a random number generator is broken or good enough for security applications:
-
-Dieharder from Robert G. Brown is a tool that runs a large number of statistical tests on your PC against a single file which contains random numbers.
-CAcert operates a random number testing service website which also runs a number of statistical tests against sumitted files, and makes the results publically comparable.
-But please keep in mind, that such statistical tests cannot detect deliberately rigged random number generators like DRBG, they only detect broken generators like the old Debian OpenSSL.
-
-
-Embedded systems like routers often have the problem that they do not have a good random number generator, and most generators take some time to collect enough entropy, so there were recent cases of such routers where they automatically generated (bad) keys directly after bootup. In case of doubt, we suggest that you manually generate good keys on a normal Laptop/PC, and copy them over to the handicapped system.
-
-Regarding servers and virtualized and cloudified environments, be careful with cloned images and paused/cloned VM's, to make sure that they do not clone the random number pool, so that all cloned machines are generating the same key after continueing/booting them.
-
-In case you measured that your random number generator is really too slow, we suggest to take a look at HAVEGE.
-
-(All Links can be found in the Tools section)
+\todo{still write this section}
\vskip 0.5em
-The focus of this guide is merely to give current best practices for
+The focus of this guide is merely to give current best practices for
configuring complex cipher suites and related parameters in a \textbf{copy \&
paste-able manner}. The guide tries to stay as concise as is possible for such
a complex topic as cryptography. There are many guides and best practice
cipher suite security levels or supporting as many users as possible while
lowering some settings. \url{https://www.ssllabs.com/} gives administrators a
tool to test out different settings. The authors used ssllabs.com to arrive at
-a set of cipher suites which we will recommend throughout this document.
+a set of cipher suites which we will recommend throught this document.
\textbf{Caution: these settings can only represent a subjective choice of the
authors at the time of this writing. It might be a wise choice to select your
own cipher suites based on the instructions in section
\begin{tabular}{lllllll}
\toprule
-\textbf{ID} & \textbf{OpenSSL Name} & \textbf{Version} & \textbf{KeyEx} & \textbf{Auth} & \textbf{Cipher} & \textbf{MAC}\\\cmidrule(lr){1-7}
+\textbf{ID} & \textbf{OpenSSL Name} & \textbf{Version} & \textbf{KeyEx} & \textbf{Auth} & \textbf{Cipher} & \textbf{Hash}\\\cmidrule(lr){1-7}
\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|0x009F| & DHE-RSA-AES256-GCM-SHA384 & TLSv1.2 & DH & RSA & AESGCM(256) & AEAD \\
\subsubsection{Configuration B: weaker ciphers, many clients}
-In this section we propose a slightly "weaker" set of cipher suites. There are
-some known weaknesses for example SHA-1 which is included in this set.
+In this section we propose a slighly "weaker" set of cipher suites. There are
+some known weaknesses of for example SHA-1 which is included in this set.
However, the advantage of this set of cipher suites is its wider compatibility
with clients.
\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}
+\textbf{ID} & \textbf{OpenSSL Name} & \textbf{Version} & \textbf{KeyEx} & \textbf{Auth} & \textbf{Cipher} & \textbf{Hash}\\\cmidrule(lr){1-7}
\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|0x009F| & DHE-RSA-AES256-GCM-SHA384 & TLSv1.2 & DH & RSA & AESGCM(256) & AEAD \\
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.
-\url{http://www.keylength.com/} offers a good overview of approximations for key size security based on recommendations by standardization bodies and academic publications.
+\url{http://www.keylength.com/} offers a good comparable overview of approximations for key size security based on recommendations by standardization bodies and academic publications.
-In general, for RSA cryptography, any key length below 2048 bits is deprectated at the time of this writing.
-For symmetric ciphers, any key length below 128 bits is deprecated, and 256 bits are suggested for higher needs.
+In general, for asymmetric cryptography, any key length below 2048 bits is deprectated at the time of this writing.
%% NOTE XXXX FILL ME XXX
\item Perfect Forward Secrecy (PFS) f\"ur Postfix und Dovecot: \url{https://www.heinlein-support.de/blog/security/perfect-forward-secrecy-pfs-fur-postfix-und-dovecot/#more-1085}
\item Elliptic curves and their implementation (04 Dec 2010): \url{https://www.imperialviolet.org/2010/12/04/ecc.html}
\item A (relatively easy to understand) primer on elliptic curve cryptography: \url{http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography}
-\item Duraconf, A collection of hardened configuration files for SSL/TLS services (Jake Applebaum's github): \url{https://github.com/ioerror/duraconf}
+\item Duraconf (Jake Applebaum's github): \url{https://github.com/ioerror/duraconf}
\item Attacks on SSL a comprehensive study of BEAST, CRIME, TIME, BREACH, LUCKY 13 \& RC4 Biases: \url{https://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf}
\item EFF How to deploy HTTPS correctly: \url{https://www.eff.org/https-everywhere/deploying-https}
\item Bruce Almighty: Schneier preaches security to Linux faithful (on not recommending to use Blowfish anymore in favour of Twofish): \url{https://www.computerworld.com.au/article/46254/bruce_almighty_schneier_preaches_security_linux_faithful/?pp=3}
Motivation
==========
-Cryptography (the word stems from the greek word "kryptos" (hidden, secret)) is an ancient art dealing with obscuring messages. Amongst the oldest known cryptography examples are texts in the Kamasutra detailing how to encode love letters. If we jump forward to the computer age, we will find that the development of computers was always strongly intertwined with the developments of cryptography and cryptanalysis (the art of breaking codes).
+Cryptography (the word stems from the greek word "kryptos" (hidden, secret)) is an ancient art dealing with hiding messages. Amongst the oldest known cryptography examples are textst in the Kamasutra detailing how to encode love letters. If we jump forward to the computer age, we will find that the development of computers was always strongly intertwined with the developments of cryptoraphy and cryptanalysis (the art of breaking codes).
-The introduction of asymetric encryption in the 70s allowed us as a society to secure a significant part of our online communication. However, there are two problems with this:
+The introduction of assymetric encryption in the 70s allowed us to as a society to secure a significant part of our online communication. However, there are two problems with this:
1. most people don't use cryptography nevertheless. It is considered "hard" and [MerkelPhone]cumbersome.
2. getting the settings right is a non trivial task.
-This guide aims at helping *system administrators* to find the right settings for the most common cryptosystems. System administrators are in a unique position to "do something good" for many people (their users).
+This guide aims at helping *system administrators* to find the right settings for the most common cryptosystems. System administrators are in a unique position to "do something good" for many people (their users).
[MerkelPhone]: derstandard.at/1381370254041/Bundeskanzler-Fayman-sind-Krypto-Handys-zu-kompliziert "Bundeskanzler Faymann sind Krypto-Handys zu kompliziert"
# ALL subdomains HAVE TO support https if you use this!
# Strict-Transport-Security: max-age=15768000 ; includeSubDomains
- SSLCipherSuite 'EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EDH+CAMELLIA256:EECDH:EDH+aRSA:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128:!ECDSA:AES256-SHA'
+ 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'
\end{lstlisting}
Note again, that any cipher suite starting with ECDHE can be omitted in case of doubt.
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:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128:!ECDSA:AES256-SHA'
+ 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")
}
\begin{lstlisting}[breaklines]
ssl_prefer_server_ciphers on;
ssl_protocols -SSLv2 -SSLv3;
- ssl_ciphers 'EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EDH+CAMELLIA256:EECDH:EDH+aRSA:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128:!ECDSA:AES256-SHA';
+ 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;
add_header X-Frame-Options DENY;
\end{lstlisting}
\label{tab:MS_IIS_Client_Support}
\end{table}
-Table~\ref{tab:MS_IIS_Client_Support} shows the algorithms from
+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
+example insiting 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.
% Example: http://dovecot.org/list/dovecot/2013-October/092999.html
\begin{lstlisting}[breaklines]
- 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:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128:!ECDSA:AES256-SHA'
+ 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_prefer_server_ciphers = yes
\end{lstlisting}
% XXX config von Adi?
% sslVersion = TLSv1
-% ciphers = EDH+CAMELLIA256:EDH+aRSA:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:-AES128:!CAMELLIA128:!ECDSA:AES256-SHA:EDH+AES128;
+% ciphers = EDH+CAMELLIA256:EDH+aRSA:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:-AES128:!CAMELLIA128:!ECDSA:AES256-SHA:EDH+AES128;
% options = CIPHER_SERVER_PREFERENCE
% TIMEOUTclose = 1
\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. For opportunistic encryption, any ciphersuite is acceptable, but you should make sure that the good ciphersuites are at the top of the list. \\
+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.\\
Furthermore a mailserver can operate in three modes:
\begin{itemize}
\begin{lstlisting}[breaklines]
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers=high
- tls_high_cipherlist='EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EDH+CAMELLIA256:EECDH:EDH+aRSA:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128:!ECDSA:AES256-SHA'
+ tls_high_cipherlist='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'
\end{lstlisting}
Then, we configure the MSA smtpd in \verb|master.cf| with two
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 and (hopefully also) scan the traffic for potential threats within the sessions.
+For this reason proxy-solutions are installed, to intercept ans (hopefully also) 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:
\todo{UNTESTED!}
\begin{lstlisting}[breaklines]
options=NO_SSLv2,NO_TLSv1,NO_Compression,CIPHER_SERVER_PREFERENCE
-cipher=EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EDH+CAMELLIA256:EECDH:EDH+aRSA:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128:!ECDSA:AES256-SHA
+cipher=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
\end{lstlisting}
End
End
End
-\end{lstlisting}
+\end{lstlisting}
\ No newline at end of file
\subsection{Keylength}
-\url{http://www.keylength.com} comprehensive online resource for comparison of keylengths according to common recommendatons and standards in cryptography.
+\url{http://www.keylength.com} comprehensive online resource for comparison of keylenghts according to common recommendatons and standards in cryptography.
\subsection{RNGs}
%% NOTE: should we merge that with chapter 6.6??
\begin{itemize}
\item \href{http://www.fourmilab.ch/random/}{ENT} is a pseudo random number generator sequence tester.
-\item \href{http://www.phy.duke.edu/~rgb/General/dieharder.php}{Dieharder} is the preferred random number generator testing tool.
-\item \href{http://www.cacert.at/random/}{CAcert Random} is a online random number generator testing service.
\item \href{http://www.issihosts.com/haveged/}{HaveGE} is a tool which increases the Entropy of the Linux random number generator devices. It is based on the HAVEGE algorithm. \url{http://dl.acm.org/citation.cfm?id=945516}
\end{itemize}
“aes256-cbc”, “aes128-ctr”, “aes192-ctr”, “aes256-ctr”, “arcfour128”, “arcfour256”,
“arcfour”, “blowfish-cbc”, and “cast128-cbc”. The default is:
- Those Ciphers can be used:
- aes128-ctr,aes192-ctr,aes256-ctr
- Those Ciphers should not be used:
- aes128-cbc,3des-cbc,blowfish-cbc,aes256-cbc,cast128-cbc,aes192-cbc,
- arcfour256,arcfour128,arcfour
+ aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
+ aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
+ aes256-cbc,arcfour
+TODO: which of those should be used?
MACs Specifies the available MAC (message authentication code) algorithms. The MAC algo‐
rithm is used in protocol version 2 for data integrity protection. Multiple algo‐
rithms must be comma-separated. The default is:
- Those MACs can be used:
- hmac-sha2-256,hmac-sha2-512,hmac-sha256-96
- hmac-sha2-512-96,hmac-ripemd160
- Those MACs should not be used:
hmac-md5,hmac-sha1,umac-64@openssh.com,
- hmac-sha1-96,hmac-md5-96,
-
+ hmac-ripemd160,hmac-sha1-96,hmac-md5-96,
+ hmac-sha2-256,hmac-sha256-96,hmac-sha2-512,
+ hmac-sha2-512-96
+TODO: which of those should be used?
Regarding compression: the default for compression is "delayed" which means, that compression
will only kick in after successful authentication (possibilities: yes, no, delayed).
ForceCommand might help (especially with internal-sftp) to further limit possibilities of
a remote use. rssh might be used as a shell to achieve similar behaviour.
-
-Port <1100-65530>
-# We recommend to use a high and non-standard port for SSH. Test it against nmap defaults that it does not get detected
git.bettercrypto.org / ach-master.git / commitdiff