Merge branch 'master' of https://git.bettercrypto.org/ach-master
authorDavid Durvaux <info@autopsit.org>
Thu, 14 Nov 2013 17:20:53 +0000 (18:20 +0100)
committerDavid Durvaux <info@autopsit.org>
Thu, 14 Nov 2013 17:20:53 +0000 (18:20 +0100)
presentations/20131113 ACH project2.pptx
src/PKIs.tex
src/abstract.tex
src/practical_settings.tex

index 8115aff..dbfab0c 100644 (file)
Binary files a/presentations/20131113 ACH project2.pptx and b/presentations/20131113 ACH project2.pptx differ
index 6edbe4c..c5fd3e0 100644 (file)
@@ -1,62 +1,19 @@
 \section{Public Key Infrastructures}
 
-Public-Key Infrastructures aim to provide a way to simplify the
-verification of a certificate's trustworthiness.  In general, if the
-authenticity of a given public key is to be established by a user (say,
-Alice), it is necessary to contact the owner (say, Bob) of the public key
-directly and compare the public key's fingerprint.  This, obviously, is
-cumbersome and does not scale.
+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).
+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.
 
-In practice, there are two approaches to address this scale-out problem.
-Both solutions are based on the assumption that Alice can delegate the
-verification of the authenticity of a given public key to another party
-(say, Trent).  This requires that Alice have a certain amount of faith in
-Trent.  In particular, she must trust him to do a proper job when verifying
-authenticity.
+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 systems where compatibility with externalities is not an issue.
 
-The first approach to help the scale-out problem puts a little more work on
-Alice's and Bob's shoulders.  The idea is that every user can act as a
-trusted third party to verify the authenticity of other users' public keys.
-If a number of other users have verified and signed off on the authenticity
-of Bob's public key, then Alice can be somewhat confident in the
-authenticity as well.  Obviously, the more users have verified and signed
-any given public key, the more trustworthy that key becomes; this concept
-is called a ``Web of Trust.''  On the other hand, this means that in order
-for a public key to become reasonably trustworthy in practice, it is
-necessary that a fairly large number of users need to verify its
-authenticity.  This is where the additional work for Alice and Bob comes
-in: For the entire scheme to work, it is necessary that a sufficiently
-large number of users generally participate in cross-verification and
-signing.  The number of signatures needed to obtain a given level of
-confidence in the authenticity of a public key also depends on how good a
-job participating users on average do when verifying keys.  Thus, the more
-knowledgeable, experienced and accurate users are expected to be in terms
-of key verification, the fewer signatures are necessary.  In particular,
-there is no practical way to set common standards for verification.
+A good background on PKIs can be found in \todo{insert reference}.
 
-The other approach to solve the problem of scale-out introduces a
-structured and organized set of trusted third parties called
-``Certification Authorities'' (CAs).  CAs offer verification services to
-all users, adhering to a published set of standard rules and procedures.
-Of course, each CA is free to specify its own standard operating
-procedures, which generally are referred to as ``Certification Practice
-Statement''\footnote{\url{http://en.wikipedia.org/wiki/Certification_Practice_Statement}}
-(CPS) and denotes the rules that the CA adheres to when verifying the
-authenticity of public keys.  When the authenticity of a public key has
-been established in accordance to the CA's CPS, it may issue a certificate,
-which is essentially the public key, usually combined with some
-meta-information about the owner of the key, and the CA's cryptographic
-signature by which the CA assures the accuracy of the information contained
-in the certificate.  Therefore, if Alice is sufficiently convinced that a
-given CA is doing a proper job of verification in accordance with its
-published CPS and the CPS are sufficiently strict so that Alice feels
-comfortable with the level of assurance they provide, then Alice may
-consider all public keys that that CA has issued certificates for as
-authentic.  This reduces the work that Alice has to do to verify $n$~public
-keys from $n$~verifications (one per other user) to just one verification
-(that to verify the authenticity of the CA's public key).  Accepting a CA
-as a generally-trusted mediator therefore solves the scaling problem at the
-cost of introducing an actor that magically is more trustworthy.
+\todo{write the actual recommendations: certificate pinning, TLSA, ...}
 
 
 
index 35bc73a..2f8f08a 100644 (file)
@@ -19,4 +19,9 @@ information systems: getting the crypto settings right. Other attacks, as the
 above mentioned, require different protection schemes which are not covered in
 this whitepaper. 
 
-
+This whitepaper is \textbf{not} an introduction to cryptography, on how to use
+PGP nor SSL. Its focus is merely to give current best practices with
+configuring complex cipher suites and related parameters in a \textbf{copy \&
+paste-able manner}.  For background information on cryptography,
+cryptoanalysis, PGP and SSL we would like to refer the reader to the list of
+books at the end of this document.
index 48e6189..da691eb 100644 (file)
@@ -45,7 +45,8 @@ You should redirect everything to httpS:// if possible. In Apache you can do thi
 %% Note: need to be checked / reviewed
 
 %% Complete ssl.cipher-list with same algo than Apache
-%% Currently this is only the default proposed lighttpd config for SSL
+\todo{FIXME: this string seems to be wrongly formatted}
+
 \begin{lstlisting}[breaklines]
   $SERVER["socket"] == "0.0.0.0:443" {
     ssl.engine  = "enable"
@@ -55,6 +56,7 @@ You should redirect everything to httpS:// if possible. In Apache you can do thi
     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}