From d116945999bdbde7f5e71567aeb5f67ae457c76d Mon Sep 17 00:00:00 2001 From: Ulrich Date: Wed, 20 Nov 2013 16:59:19 +0100 Subject: [PATCH] Insert chapter for proxy solutions and their ssl-capabilities. --- src/proxy_solutions.tex | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 src/proxy_solutions.tex diff --git a/src/proxy_solutions.tex b/src/proxy_solutions.tex new file mode 100644 index 0000000..37f031e --- /dev/null +++ b/src/proxy_solutions.tex @@ -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?} + -- 2.20.1