Big restructure part 1

MA-Inhalt.tex

@@ -600,25 +600,79 @@ Für die Bereitstellung der öffentlichen Daten der PKI wird ein Apache httpd al
 Damit die CRL der PKI aktualisiert wird, wird ein Cronjob auf dem CA-Server eingerichtet, der diese Aufgabe übernimmt und die aktuelle CRL anschließend über den Webserver veröffentlicht.
 Auf dem VPN-Server kommt ein weiterer Cronjob zum Einsatz, um die aktuelle CRL vom Webserver auf dem CA-Server zu beschaffen und in die Konfiguration des OpenVPN-Servers zu integrieren.
 
-Firewallregeln.
 
-\begin{draft}
+\section{OpenVPN-Server} \label{sct:plan_openvpn_server}
-\paragraph{Konfigurationsplanung für OpenVPN:}
+In diesem Abschnitt werden die in Kapitel~\ref{cpt:service_concept} bereits beschlossenen Konzepte für den VPN-Dienst auf die gewählte VPN-Software OpenVPN zugeschnitten.
+Die durch OpenVPN gegebenen Funktionen und Einschränkungen werden hierbei berücksichtigt, um später eine funktionsfähige Konfiguration für OpenVPN aus dieser Planung abzuleiten.
 
-Als Transportprotokoll kommt UDP zum Einsatz.
+\paragraph{VPN-Transportprotokoll:}
+OpenVPN bietet UDP und TCP als mögliche Transportprotokolle für den VPN-Datenverkehr an.
+Für diesen VPN-Dienst wird das UDP-Protokoll gewählt, weil das TCP-Protokoll in Kombination mit stark ausgelasteten Netzwerken oder beim Transport von TCP-Paketen durch den VPN-Tunnel Performanceeinbußen verursachen kann \cite[][Option \texttt{--proto}]{man:openvpn}.
+Bei Interesse kann eine detaillierte Analyse der Probleme der TCP-in-TCP-Situation in \cite[][]{analysis:tcpintcp} nachgelesen werden.
 
-Der VPN-Tunnel überträgt Datenverkehr auf OSI-Schicht~3.
+\paragraph{OSI-Schicht des VPN-Tunnels:}
+OpenVPN unterstützt den Aufbau eines VPN-Tunnels auf OSI-Schicht~2 und OSI-Schicht~3.
+Im Prinzip könnten beide Tunnelvarianten für den Anwendungsfall dieser Arbeit verwendet werden.
+Da im Rahmen dieser Arbeit nur die Erreichbarkeit über IPv4 und IPv6 relevant ist, wird ein VPN-Tunnel auf OSI-Schicht~2 nicht benötigt.
+Zusätzlich würde ein VPN-Tunnel auf OSI-Schicht~2 mehr Bandbreite benötigen: IP-Pakete würden inklusive der dazugehörigen Ethernet-Frames übermittelt.
+Aus diesen Gründen fällt die Wahl auf VPN-Tunnel auf OSI-Schicht~3.
 
-Verschlüsselung von Datenverkehr mit TLS-Chiffre und so - keine Verhandlungen, alles statisch.
+\paragraph{Kompression des VPN-Verkehrs:}
-Warum?
+Auf die Kompression des VPN-Datenverkehrs wird aufgrund der in diesem Absatz aufgeführten Punkte verzichtet.
+Am 03.06.2018 wurden Hinweise in der Manpage von OpenVPN eingefügt\footnote{\url{https://github.com/OpenVPN/openvpn/commit/6795a5f3d55f658fc1a28eb9f3b11d1217e3329c}}, in denen vor der Verwendung von Kompression gewarnt wird.
+Diese Hinweise sind in der Manpage von OpenVPN in Version~2.4.6 noch nicht enthalten, da diese Version von den Entwicklern bereits am 19.04.2018\footnote{\url{https://github.com/OpenVPN/openvpn/releases/tag/v2.4.6}} freigegeben wurde.
+Zusätzlich wird in der \enquote{Best Current Practice} RFC~7525 zur Deaktivierung der Kompression von TLS geraten \cite[Vergleich][Kapitel 3.3]{RFC7525}.
 
-TLS-Rolle für Server/Client
+Auf der DEFCON~26 wurde mit \enquote{VORACLE} ein in diesem Kontext relevanter Angriff auf OpenVPN vorgestellt\footnote{\url{https://media.defcon.org/DEF\%20CON\%2026/DEF\%20CON\%2026\%20presentations/Nafeez/DEFCON-26-Nafeez-Compression-Oracle-attacks-on-VPN-Networks.pdf}}, der auf aktivierter Kompression aufbaut.
+
+\paragraph{Kryptografische Parameter:}
+Wie in Kapitel~\ref{ssct:openvpn} bereits erläutert wurde, unterscheidet OpenVPN bei der Kommunikation zwischen zwei OpenVPN-Prozessen zwischen Datenkanal für Nutzdaten und Kontrollkanal für Steuernachrichten.
+Während OpenVPN im TLS-Modus über den Kontrollkanal den TLS-Sitzungsaufbau durchführt und den Kontrollkanal anschließend über TLS absichert, wird für den Datenkanal eine separat konfigurierbare, symmetrische Chiffre verwendet.
+Das gemeinsame Geheimnis für den Schutz des Datenkanals wird dabei über den durch TLS geschützten Kontrollkanal ausgetauscht.
+Mit den in diese Absatz definierten Parametern soll die Kommunikation zwischen Clients und Server unabhängig von den verwendeten Betriebssystemen einheitlich geschützt werden.
+
+Die TLS-Kommunikation wird nach Empfehlung des BSI über TLS-Version~1.2 oder höher durchgeführt \cite[][Abschnitt 2.3]{bsi:tls-checkliste}.
+Zur Absicherung des Kontrollkanals wird die TLS-Chiffre \texttt{TLS-DHE-RSA-WITH-AES-256-GCM-SHA384} ausgewählt.
+
+Diese Chiffre verwendet \textit{Ephemeral Diffie Hellman} (DHE) für den Schlüsselaustausch \cite[][Abschnitt A.5]{RFC5246}, RSA als Signaturalgorithmus zur Authentisierung \cite[][Abschnitt A.5]{RFC5246}, AES-256-GCM für die Verschlüsselung und SHA384 als Funktion für Pseudozufallszahlen für den \textit{Keyed-Hash Message Authentication Code} (HMAC) \cite[][Kapitel 5]{RFC5246}.
+Durch die Verwendung von DHE kann \textit{Perfect Forward Secrecy} (PFS) gewährleistet werden \cite[][Abschnitt F.1.1.2]{RFC5246}.
+
+Die gewählte TLS-Chiffre stammt aus der Liste der empfohlenen Chiffren in RFC~7525 \cite[][Abschnitt 4.2]{RFC7525}.
+Laut BSI kann diese Chiffre durch Dienstanbieter optional unterstützt werden \cite[][Kapitel 3]{bsi:tls-checkliste}.
+Die eng verwandte Chiffre TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 setzt PFS mit ECDHE anstelle von DHE um, und wird laut BSI für Dienstanbieter empfohlen \cite[][Kapitel 3]{bsi:tls-checkliste}, wodurch sich unter der Voraussetzung, dass ECDHE und DHE einen vergleichbar sicheren Schlüsselaustausch ermöglichen, auch für die gewählte TLS-Chiffre eine Eignung für die langfristige Verwendung ableiten lässt.
+Diese Voraussetzung wird durch einen aktuellen Bericht der ECRYPT-CSA\footnote{Siehe \url{http://www.ecrypt.eu.org/csa/}} vom Februar 2018 untermauert diese Voraussetzung \cite[][Kapitel 8.1]{ecrypt-csa:algorithms}.
+
+\textbf{Anmerkung}: TLS-Chiffren mit Ephemeral-Diffie-Hellman-Verfahren auf Basis von elliptischen Kurven (ECDHE) können im Rahmen dieser Arbeit nicht verwendet werden.
+Grund dafür sind Kompatibilitätsprobleme zwischen OpenVPN und OpenSSL~1.1.x auf der Clientseite\footnote{Siehe \url{https://community.openvpn.net/openvpn/ticket/963}}.
+
+OpenVPN verwendet einen HMAC mit einem zuvor ausgetauschtem, gemeinsamen Geheimnis um für Daten- und Kontrollkanal eingehende Datenpakete vor ihrer Verarbeitung zu authentisieren.
+Die im HMAC als Quelle für Pseudozufallszahlen verwendete Hashfunktion wird auf SHA-256 festgelegt, weil SHA-1, trotz seiner weiterhin bestehenden theoretischen Eignung zur Verwendung in einem HMAC, laut BSI nicht mehr verwendet werden sollte \cite[][Abschnitt 1.4, Punkt 3]{bsi:tr-02102-1}.
+
+Für die Verschlüsselung des Datenkanals wird auf Basis der zuvor gewählten TLS-Chiffre die Chiffre AES-256-GCM ausgewählt.
+Diese Chiffre ist eine \textit{Authenticated Encryption with Associated Data} (AEAD)-Chiffre.
+Deshalb wird die Authentisierungsfunktion der Chiffre anstelle der zuvor beschriebenen HMAC-Funktion für den Datenkanal benutzt \cite[][Option \texttt{--auth}]{man:openvpn}.
+
+Durch die Verwendung der selben Chiffre zur Verschlüsselung von Daten- und Kontrollkanal muss ein Angreifer für einen erfolgreichen Angriff - egal auf welchen Kanal - diese Chiffre brechen.
+Gelingt es einem Angreifer den Kontrollkanal zu dechiffrieren, so erhält er Kenntnis über die Schlüssel, mit denen der Datenkanal verschlüsselt wird.
+Gelingt es einem Angreifer den Kontrollkanal zu dechiffrieren, so erhält er Kenntnis über alle übertragenen Daten.
+Die Vertraulichkeit der über den VPN-Dienst übertragenen Daten hängt demnach von der Verschlüsselung beider Kanäle ab.
+Der logische Schluss daraus ist die Verwendung der selben Chiffre zur Verschlüsselung beider Kanäle.
+
+Damit alle VPN-Sitzungen die zuvor erläuterten, kryptografischen Parametern einhalten, werden diese Parameter in Client- und Serverkonfiguration hinterlegt.
+Zusätzlich wird die Aushandlung der Chiffren auf dem OpenVPN-Server explizit deaktiviert, um unsichere VPN-Sitzungen zu verhindern.
+
+\textbf{Erweiterbarkeit:} Sollten die hier gewählten, kryptografischen Parameter einzeln oder insgesamt nicht mehr als sicher gelten, so sollten \textbf{alle} diese Parameter nach aktuellem Stand der Technik und unter Berücksichtigung der verschiedenen Clientbetriebssysteme neu ausgewählt werden.
+In diesem Zuge ist es notwendig, alle aktiven VPN-Benutzer über die Änderungen der Parameter zu benachrichtigen und eine aktuelle Vorlage für die OpenVPN-Clientkonfiguration bereitzustellen.
+
+Dieser Ansatz wird gewählt, damit (1) all VPN-Sitzungen einheitlich geschützt werden, und (2) zusätzliche Komplexität durch flexible Verwendung von Chiffren und deren Aushandlung vermieden wird.
 
-Keine Kompression aus Sicherheitsgründen
 
 
 Es sollen Routen in Netze gepusht werden; es sollen Routen aus dem alten VPN-Dienst übernommen werden für die Aufwärtskompatibilität; IPV6-Netze sollen dann hinzugefügt werden.
-\end{draft}
+
+
+\section{PKI-Server} \label{sct:plan_pki_server}
+
 
 
 \chapter{Konfiguration des OpenVPN-Servers} \label{cpt:implement_vpn_server}
@@ -695,15 +749,8 @@ proto udp
 remote vpn-test.inform.hs-hannover.de 1194
 \end{lstlisting}
 
-Das UDP-Protokoll wird verwendet, weil das TCP-Protokoll in Kombination mit stark ausgelasteten Netzwerken oder beim Transport von TCP-Paketen durch den VPN-Tunnel Performanceeinbußen verursachen kann \cite[][Option \texttt{--proto}]{man:openvpn}.
-Bei Interesse kann eine detaillierte Analyse der Probleme der TCP-in-TCP-Situation in \cite[][]{analysis:tcpintcp} nachgelesen werden.
-
 \paragraph{OSI-Schicht des VPN-Tunnels:}
-OpenVPN unterstützt den Aufbau eines VPN-Tunnels auf OSI-Schicht~2 und OSI-Schicht~3.
+In \textbf{Client- und Serverkonfiguration} wird mit angegeben, dass eine virtuelle Netzwerkkarte auf OSI-Schicht~3 als Endpunkt für das VPN verwendet wird:
-Im Prinzip könnten beide Tunnelvarianten für den Anwendungsfall dieser Arbeit verwendet werden.
-Da im Rahmen dieser Arbeit nur die Erreichbarkeit über IPv4 und IPv6 relevant ist, wird ein VPN-Tunnel auf OSI-Schicht~2 nicht benötigt.
-Zusätzlich würde ein VPN-Tunnel auf OSI-Schicht~2 mehr Bandbreite benötigen: IP-Pakete würden inklusive der dazugehörigen Ethernet-Frames übermittelt.
-Aus diesen Gründen fällt die Wahl auf VPN-Tunnel auf OSI-Schicht~3 und wird mit der folgenden Anweisung in \textbf{Client- und Serverkonfiguration} eingestellt.
 \begin{lstlisting}
 dev tun
 \end{lstlisting}
@@ -755,14 +802,6 @@ push "route-ipv6 2001:638:614:1744::/64 2001:638:614:1750::1"	# experimental ipv
 \end{lstlisting}
 Da der Platzhalter \texttt{vpn\_gateway} für IPv6-Routen leider nicht funktioniert, muss hier die IPv6-Adresse des VPN-Servers im VPN direkt als Ziel der Route angegeben werden.
 
-\paragraph{Kompression:}
-Auf die Kompression des VPN-Datenverkehrs wird aufgrund der in diesem Absatz aufgeführten Punkte verzichtet.
-Am 03.06.2018 wurden Hinweise in der Manpage von OpenVPN eingefügt\footnote{\url{https://github.com/OpenVPN/openvpn/commit/6795a5f3d55f658fc1a28eb9f3b11d1217e3329c}}, in denen vor der Verwendung von Kompression gewarnt wird.
-Diese Hinweise sind in der Manpage von OpenVPN in Version~2.4.6 noch nicht enthalten, da diese Version von den Entwicklern bereits am 19.04.2018\footnote{\url{https://github.com/OpenVPN/openvpn/releases/tag/v2.4.6}} freigegeben wurde.
-Zusätzlich wird in der \enquote{Best Current Practice} RFC~7525 zur Deaktivierung der Kompression von TLS geraten \cite[Vergleich][Kapitel 3.3]{RFC7525}.
-
-Auf der DEFCON~26 wurde mit \enquote{VORACLE} ein in diesem Kontext relevanter Angriff auf OpenVPN vorgestellt\footnote{\url{https://media.defcon.org/DEF\%20CON\%2026/DEF\%20CON\%2026\%20presentations/Nafeez/DEFCON-26-Nafeez-Compression-Oracle-attacks-on-VPN-Networks.pdf}}, der auf aktivierter Kompression aufbaut.
-
 \paragraph{Zertifikatgestützte Authentisierung:}
 Um die in Kapitel~\ref{sct:user_concept} beschriebene Zertifizierungsstelle zur Benutzerauthentisierung zu verwenden und die VPN-Kommunikation nach Anforderung~\ref{req:traffic} aus Kapitel~\ref{par:requirements} abzusichern, wird OpenVPN im TLS-Modus betrieben.
 
@@ -788,53 +827,29 @@ remote-cert-tls client
 \end{lstlisting}
 
 \paragraph{Kryptografische Parameter:}
-Wie in Kapitel~\ref{ssct:openvpn} bereits erläutert wurde, unterscheidet OpenVPN bei der Kommunikation zwischen zwei OpenVPN-Prozessen zwischen Datenkanal für Nutzdaten und Kontrollkanal für Steuernachrichten.
-Während OpenVPN im TLS-Modus über den Kontrollkanal den TLS-Sitzungsaufbau durchführt und den Kontrollkanal anschließend über TLS absichert, wird für den Datenkanal eine separat konfigurierbare, symmetrische Chiffre verwendet.
-Das gemeinsame Geheimnis für den Schutz des Datenkanals wird dabei über den durch TLS geschützten Kontrollkanal ausgetauscht.
-Mit den in diese Absatz definierten Parametern soll die Kommunikation zwischen Clients und Server unabhängig von den verwendeten Betriebssystemen einheitlich geschützt werden.
 Um Konfigurationsprobleme durch abweichende Konfiguration von Client und Server auszuschließen, werden alle folgenden Parameter in \textbf{Client- und Serverkonfiguration} eingetragen.
 
-Die TLS-Kommunikation wird nach Empfehlung des BSI über TLS-Version~1.2 oder höher durchgeführt \cite[][Abschnitt 2.3]{bsi:tls-checkliste}.
+Die TLS-Kommunikation wird über TLS Version~1.2 oder höher durchgeführt:
 \begin{lstlisting}
 tls-version-min "1.2"
 \end{lstlisting}
 
-\todo{ECRYPT-CSA integrieren.}
+Die für den Kontrollkanal verwendete TLS-Chiffre wird konfiguriert:
-
-Der letzte Bericht der ENISA\footnote{Siehe \url{https://www.enisa.europa.eu/about-enisa}} zu Algorithmen, Schlüssellängen und Protokollen von 2014 \cite[][]{enisa:algorithms} wird durch einen aktuellen Nachfolger \cite[][]{ecrypt-csa:algorithms} der ECRYPT-CSA\footnote{Siehe \url{http://www.ecrypt.eu.org/csa/}} vom Februar 2018 abgelöst \cite[][Kapitel 1, \enquote{Executive Summary}]{ecrypt-csa:algorithms}.
-Empfehlungen zu TLS finden sich in \cite[][Kapitel 8.1]{ecrypt-csa:algorithms}.
-
-Aus der Liste der in RFC~7525 empfohlenen Chiffren \cite[][Abschnitt 4.2]{RFC7525} wird die TLS-Chiffre TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 gewählt.
-Diese Chiffre verwendet \textit{Ephemeral Diffie Hellman} (DHE) für den Schlüsselaustausch \cite[][Abschnitt A.5]{RFC5246}, RSA als Signaturalgorithmus zur Authentisierung \cite[][Abschnitt A.5]{RFC5246}, AES-256-GCM für die Verschlüsselung und SHA384 als Funktion für Pseudozufallszahlen für den \textit{Keyed-Hash Message Authentication Code} (HMAC) \cite[][Kapitel 5]{RFC5246}.
-
-Durch die Verwendung von DHE kann \textit{Perfect Forward Secrecy} (PFS) gewährleistet werden \cite[][Abschnitt F.1.1.2]{RFC5246}.
-
-Die gewählte Chiffre kann vom BSI \cite[][Kapitel 3]{bsi:tls-checkliste} durch Dienstanbieter optional unterstützt werden.
-Die eng verwandte Chiffre TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 setzt PFS mit ECDHE anstelle von DHE um und wird laut BSI für Dienstanbieter empfohlen \cite[][Kapitel 3]{bsi:tls-checkliste}.
-
-\textbf{Anmerkung}: TLS-Chiffren mit Ephemeral-Diffie-Hellman-Verfahren auf Basis von elliptischen Kurven (ECDHE) können im Rahmen dieser Arbeit nicht verwendet werden.
-Grund dafür sind Kompatibilitätsprobleme zwischen OpenVPN und OpenSSL~1.1.x auf der Clientseite\footnote{Siehe \url{https://community.openvpn.net/openvpn/ticket/963}}.
-
-Somit wird die zuvor genannte TLS-Chiffre mit DHE-Verfahren verwendet:
 \begin{lstlisting}
 tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
 \end{lstlisting}
 
-OpenVPN verwendet einen HMAC mit einem zuvor ausgetauschtem, gemeinsamen Geheimnis um für Daten- und Kontrollkanal eingehende Datenpakete vor ihrer Verarbeitung zu authentisieren.
+Als Quelle für Pseudozufallszahlen im HMAC für Kontroll- und Datenkanal kommt SHA-256 zum Einsatz:
-
-Die im HMAC als Quelle für Pseudozufallszahlen verwendete Hashfunktion wird auf SHA-256 festgelegt, weil SHA-1, trotz seiner weiterhin bestehenden theoretischen Eignung zur Verwendung in einem HMAC, laut BSI nicht mehr verwendet werden sollte \cite[][Abschnitt 1.4, Punkt 3]{bsi:tr-02102-1}.
 \begin{lstlisting}
 auth SHA256
 \end{lstlisting}
 
-Zur Verschlüsselung des Datenkanals kommt AES-256-GCM zum Einsatz.
+Zur Verschlüsselung des Datenkanals kommt die Chiffre AES-256-GCM zum Einsatz.
-Wird eine Chiffre mit \textit{Authenticated Encryption with Associated Data} (AEAD) gewählt, so wird die Authentisierungsfunktion der Chiffre anstelle der zuvor beschriebenen HMAC-Funktion für den Datenkanal benutzt \cite[][Option \texttt{--auth}]{man:openvpn}.
-Das ist bei AES-256-GCM der Fall.
 \begin{lstlisting}
 cipher AES-256-GCM
 \end{lstlisting}
 
-Um zu verhindern, dass eine veränderte Clientkonfiguration zu einer möglicherweise weniger sicheren VPN-Sitzung führt, wird die Aushandlung der mit \texttt{cipher} konfigurierten Chiffre in der \textbf{Serverkonfiguration} deaktiviert:
+Um zu verhindern, dass fehlerhaft konfigurierte VPN-Clients eine weniger sichere Verschlüsselung des Datenkanals aushandeln, wird in der \textbf{Serverkonfiguration} die Aushandlung der Chiffre zur Verschlüsselung des Datenkanals abgeschaltet.
 \begin{lstlisting}
 ncp-disable
 \end{lstlisting}
@@ -896,8 +911,10 @@ auth-nocache
 
 \paragraph{Protokollierung:}
 Um den Detailgrad der Protokolle von OpenVPN zu steuern, können in der \textbf{Client- und Serverkonfiguration} die Parameter \texttt{verb} und \texttt{mute} verwendet werden.
-Der Parameter \texttt{verb} steuert dabei den Detailgrad der protokollierten Meldungen über einen Bereit von 0 (keine Meldungen) über 1-4 (normale Meldungen), 5 (Für jedes verarbeitete Paket wird ein Buchstabe in das Log geschrieben) bis hin zu 6-11 (Für Fehlersuche in der Entwicklung).
+Der Parameter \texttt{verb} steuert dabei den Detailgrad der protokollierten Meldungen.
-Standardmäßig wird der Wert~1 verwendet; der Wert~3 wird für übersichtliche Protokolle mit mehr Informationen empfohlen.
+Der Bereich reicht von 0 (keine Meldungen) über 1-4 (normale Meldungen), 5 (Für jedes verarbeitete Paket wird ein Buchstabe in das Log geschrieben) bis hin zu 6-11 (Für Fehlersuche in der Entwicklung).
+
+Für DSGVO-konforme Protokolle wird der Wert~0 in der \textbf{Serverkonfiguration} verwendet; der Wert~3 wird für übersichtliche Protokolle mit mehr Informationen in der \textbf{Clientkonfiguration} empfohlen.
 Der Parameter \texttt{mute} gibt an, wie viele aufeinander folgende Nachrichten aus der selben Kategorie protokolliert werden sollen.
 Damit können aufeinander folgende, ähnliche Nachrichten unterdrückt werden, die sich wiederholen.
 Um einen guten Überblick zu erhalten, werden die folgenden Parameter gewählt: