extended and corrected part on PKI/PKI hardening, added further research and references
authorAaron Zauner <azet@azet.org>
Tue, 17 Dec 2013 13:20:32 +0000 (14:20 +0100)
committerAaron Zauner <azet@azet.org>
Tue, 17 Dec 2013 13:20:32 +0000 (14:20 +0100)
src/PKIs.tex
src/further_research.tex
src/security.bib

index 257c641..6ccf9e6 100644 (file)
@@ -13,20 +13,19 @@ given how you can improve the security of PKIs.
 
 \section{Certificate Authorities}
 \label{sec:cas}
-In order to get a certificate, you either go to a CA which, will issue a certificate,
-or you run your own CA. In the later case you normally speak of self-signed 
-certificates. For both cases there are pro and contra points and the decision is
+In order to get a certificate, you either go to a CA which will issue a certificate for you,
+or you run your own CA. In the latter case one normally speaks of self-signed 
+certificates. For both cases there are pros and contras and the decision is
 as always security versus usability.
 
 \subsubsection{Signed Certificates form a trusted Certificate Authority}
 \label{sec:signcertfromca}
-Trusted certificates are mostly issued by commercial CAs, such as Verisign, Teletrust, etc.
-These certificates are mostly issued for specified time period and cost money. Nevertheless
+Trusted certificates are mostly issued by commercial CAs, such as Verisign, GoDaddy, Teletrust, etc.
+These certificates are mostly issued for specified time period and cost money. Nevertheless
 there are also free trusted CAs available, such as StartSSL, or CACert.
 
-If you consider getting a signed certificate from a trusted CA, you should not generate the 
-private key not on the CAs system. You can generate a private key and a corresponding 
-certificate request as follows:
+If you consider getting a signed certificate from a trusted CA, you should not let the CA generate the 
+private key for you. 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>
@@ -46,9 +45,9 @@ An optional company name []:
 
 \subsubsection{Setting up your own Certificate Authority}
 \label{sec:setupownca}
-In some situations it is sufficient to use your own CA certificates. An example is a own OpenVPN
-installation or if only systems communicate with each other, which do not act with users. Creating
-a own CA can be accomplished using OpenSSL:
+In some situations it is sufficient to use your own certificate authority. An example is an OpenVPN
+installation or if only internal systems communicate with each other, without interaction with users. 
+Creating a CA can be accomplished using OpenSSL:
 
 \begin{lstlisting}
 % cd /usr/lib/ssl/misc
@@ -66,18 +65,21 @@ issued a new root certificate. Now you can issue new certificates as follows:
 \subsection{Hardening PKI}
 \label{sec:hardeningpki}
 In recent years several CAs were compromised by attackers in order to
-get trusted certificates for malicious activities. In 2011 the Dutch
-CA Diginotar was hacked and all certificates were
+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.
+fail. Some CAs tend to issue certificates and keys that were designated
+to do a different job than what they were issued for~\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}.
+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}
index b746957..57896ba 100644 (file)
@@ -23,8 +23,9 @@ The following is a list of services, software packages, hardware devices or prot
 \item NNTP 
 \item NTPs tlsdate 
 \item BGP / OSPF 
-\item silc 
-\item LDAP 
+\item SILC
+\item LDAP
+\item Commerical network equipment vendors
 \end{itemize}
 \end{minipage}
 \begin{minipage}[b]{0.5\linewidth}
@@ -33,7 +34,7 @@ The following is a list of services, software packages, hardware devices or prot
 \item Moxa , APC, und co... ICS . Ethernet to serial 
 \item telnet (only sensible reocmmendation: \emph{DON't!!}
 \item rsyslog 
-\item v6 spoofing (look at work by Ferndo Gont et. al)
+\item v6 spoofing (look at work by Ferndo Gont, Marc Heuse, et. al.)
 \item tinc
 \item rsync 
 \item telnets 
index 70299df..9dbd614 100644 (file)
   year = 2013,
   month = Nov,
 }
+
+@misc{gocode,
+  author = {{Adam Langley, et. al.}},
+  title = {{Go X.509 Verification Source Code}},
+  howpublished = {\url{https://code.google.com/p/go/source/browse/src/pkg/crypto/x509/verify.go#173}},
+  year = 2013,
+  month = 12,
+}
+
+@misc{certtransparency,
+  author = {{Adam Langley, Ben Laurie, Emilia Kasper}},
+  title = {{Certificate Transparency}},
+  howpublished = "\url{http://www.certificate-transparency.org}
+               \url{http://datatracker.ietf.org/doc/rfc6962/}",
+  year = 2013,
+  month = 07,
+}