Merge branch 'master' of https://git.bettercrypto.org/ach-master
authorAaron Kaplan <aaron@lo-res.org>
Wed, 20 Nov 2013 16:20:47 +0000 (17:20 +0100)
committerAaron Kaplan <aaron@lo-res.org>
Wed, 20 Nov 2013 16:20:47 +0000 (17:20 +0100)
Resolved a conflict
Conflicts:
src/practical_settings.tex

src/.gitignore
src/cipher_suites.tex
src/practical_settings.tex
src/proxy_solutions.tex [new file with mode: 0644]

index 5fb7d16..da1aa5f 100644 (file)
@@ -4,3 +4,4 @@ applied-crypto-hardening.log
 applied-crypto-hardening.out
 applied-crypto-hardening.pdf
 applied-crypto-hardening.toc
+*.gummi
\ No newline at end of file
index f33fa8c..48a2500 100644 (file)
@@ -209,7 +209,7 @@ Many algorithms allow a secure key exchange. Among those are RSA, DSA, DH, EDH,
 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.
 
-\begin{WrapText}
+\begin{center}
 \begin{tabular}{| l | l | l | l |}
     \toprule
  & \textbf{Key}  & \textbf{\cellcolor{orange}EC}  & \textbf{\cellcolor{green}ephemeral} \\ \cmidrule(lr){1-4}
@@ -222,10 +222,10 @@ encryption are exchanged. For RSA and DSA those keys are the same.
     \cellcolor{red}    ECDSA & DSA  & \cellcolor{orange}yes & \cellcolor{red} no         \\
 \bottomrule
 \end{tabular}
-\\
-\\
-disabled: \texttt{!PSK:!SRP}
-\end{WrapText}
+%\\
+%\\
+%disabled: \texttt{!PSK:!SRP}
+\end{center}
 
 \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
index 6deb371..74588bc 100644 (file)
@@ -682,6 +682,9 @@ Adi?? }
 
 \input{DBs}
 
+\subsection{Intercepting proxy solutions}
+\todo{write this!! }
+\input{proxy_solutions}
 
 
 
diff --git a/src/proxy_solutions.tex b/src/proxy_solutions.tex
new file mode 100644 (file)
index 0000000..37f031e
--- /dev/null
@@ -0,0 +1,26 @@
+
+\subsubsection{General thoughts}
+\todo{sure?}
+
+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.
+
+As soon as one wants to establish an encrypted connection to a server, there are three choices:
+
+\begin{itemize}
+\item Block the connection, because it cannot be scanned for threats
+\item Bypass the threat-mitigation and pass the encrypted session to the client, which results in a situation where malicious content is transferred directly to the client without visibility for the security system.
+\item Intercept (i.e. terminate) the session at the proxy, scan there and re-encrypt the session towards the client.
+\end{itemize}
+
+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.
+
+\subsubsection{squid}
+\todo{sure?}
+
+\subsubsection{Bluecoat}
+\todo{sure?}
+