JPT
/
masterthesis
0
0
Fork 0
Code Issues Pull Requests Activity

More spelling

This commit is contained in:
Jan Philipp Timme 2018-10-11 11:47:00 +02:00
parent 478962e366
commit add4204a24
1 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
MA-Inhalt.tex
View File

@ -218,7 +218,7 @@ Alle kryptografische Operationen zur Verarbeitung des VPN-Datenverkehrs, sowie z
\todo{Wenn Zeit übrig ist.}
\subsection{OpenSSH}
\todo{Wenn Zeit übrig ist; TCP in TCP ist ein Problem wegen ECN, könnte unter Window nicht funktionieren?}
\todo{Wenn Zeit übrig ist; TCP in TCP ist ein Problem wegen ECN, könnte unter Windows nicht funktionieren?}
\end{comment}
@ -330,7 +330,7 @@ Die Authentisierung von Benutzern anhand von Zertifikaten erfordert den Aufbau u
Für die Benutzer ergibt sich ein zusätzlicher Aufwand durch das regelmäßige Beantragen von neuen Zertifikaten, sowie die Notwendigkeit der Anpassung der OpenVPN-Clientkonfiguration.
Auch für den Systemadministrator ergibt sich dieser zusätzliche Aufwand in Bezug auf die regelmäßige Erneuerung des Serverzertifikats und der \textit{Certificate Revocation List} (CRL).
Zusätzlich ist der Systemadministrator mit der Betreuung der \textit{Zertifizierungsstelle} (CA) beschäftigt, nimmt die Zertifikatsanträge der Benutzer entgegen, prüft diese und stellt Benutzerzertifikate aus.
Der daraus resultierende Aufwand erhöhts sich proportional zu der Anzahl der VPN-Benutzer.
Der daraus resultierende Aufwand erhöht sich proportional zu der Anzahl der VPN-Benutzer.
Dennoch gibt es eine Reihe von Vorteilen, die diesen zusätzlichen Aufwand rechtfertigen:
Zertifikate haben eine klar definierte Laufzeit, die bei Ausstellung des Zertifikates festgelegt wird.
@ -348,7 +348,7 @@ Unter Abwägung dieser Vor- und Nachteile werden im Rahmen dieser Arbeit Zertifi
\section{Zertifikatgestützte Benutzerauthentisierung} \label{sct:ca_concept}
Die VPN-Software OpenVPN bringt OpenSSL als Abhängigkeit mit.
OpenSSL stellt eine Menge von Funktionen als Kommandozeilenwerkzeug zur Verfügung, mit denen alle Basisfunktionen einer Zertifizierungsstelle wie zum Beipiel die Erzeugung von Schlüssel\-paaren und Zertifikatsanträgen, sowie das Ausstellen von Zertifikaten auf Basis von Zertifikatsanträgen möglich ist.
OpenSSL stellt eine Menge von Funktionen als Kommandozeilenwerkzeug zur Verfügung, mit denen alle Basisfunktionen einer Zertifizierungsstelle wie zum Beispiel die Erzeugung von Schlüssel\-paaren und Zertifikatsanträgen, sowie das Ausstellen von Zertifikaten auf Basis von Zertifikatsanträgen möglich ist.
Im Prinzip ist es möglich, durch manuelle Bedienung von OpenSSL eine \textit{Zertifizierungsstelle} (CA) zu betreiben.
Diese Vorgehensweise verlangt jedoch Fachwissen und Sorgfalt von den Betreibern der CA und eignet sich aufgrund des hohen Aufwands nur für die Verwaltung weniger Benutzer oder zu Zwecken der Lehre.
@ -465,7 +465,7 @@ Neben dem Wurzelzertifikat der CA und der aktuellen CRL benötigen Benutzer eine
Um diese Daten zur Verfügung zu stellen, wird auf der virtuellen Maschine der Webserver \texttt{apache2} installiert, welcher ausschließlich das für diesen Zweck erzeugte Verzeichnis \texttt{/public} über HTTP ausliefern soll.
Alle in \texttt{/public} platzierten Dateien und Verzeichnisse gehören dem Benutzer \texttt{root} und der Gruppe \texttt{root}.
Alle Dateien werden mit den Dateirechten \texttt{444} versehen, Verzeichnisse erhalten die Rechtemaske \texttt{555}.
Alle Dateien werden mit den Dateirechten \texttt{444} versehen, Verzeichnisse erhalten die Dateirechte \texttt{555}.
Dadurch werden Manipulationen durch nicht privilegierte, lokale Benutzer verhindert.
Gleichzeitig signalisieren die Dateirechte, dass die Inhalte unter \texttt{/public} nur durch \texttt{root} verändert werden dürfen und für alle anderen lediglich lesbar zur Verfügung stehen sollen.
@ -488,13 +488,13 @@ Aus diesen Gründen fällt die Wahl auf VPN-Tunnel auf OSI-Layer~3.
\paragraph{Netzwerkkonfiguration}
Da der OpenVPN-Dienst aus dem Internet heraus erreichbar sein soll, wird der Server an das DMZ-Netz angeschlossen.
Das IT-Team hat dafür insgesamt vier IPv4- und IPv6-Adressen vergeben, um den Server und den darauf existierenden Dienst logisch zu trennen.
Über die vergebenen IPv4- und IPv6-Hostadressen kann der phyische Server angesprochen werden, um zum Beispiel für administrative Aufgaben eine SSH-Sitzung zu dem Server aufzubauen.
Über die vergebenen IPv4- und IPv6-Hostadressen kann der physische Server angesprochen werden, um zum Beispiel für administrative Aufgaben eine SSH-Sitzung zu dem Server aufzubauen.
Über ein weiteres Paar von IP-Dienstadressen wird der eigentliche OpenVPN-Dienst zur Verfügung gestellt.
Um Datenverkehr zwischen den VPN-Clients und dem Netz der Abteilung Informatik routen zu können, wird für IPv4 und IPv6 jeweils ein IP-Adressbereich benötigt, aus dem die VPN-Clients ihre Clientadressen zugewiesen bekommen können.
Für IPv4 wurde das private Netz \texttt{10.2.0.0/16} durch das IT-Team vergeben.
Für IPv6 wurde das Netz \texttt{2001:638:614:1750::/64} vergeben, welches durch die Firewall der Abteilung Informatik an die zuvor vergebene IPv6-Dienstadresse geroutet wird.
Damit VPN-Clients über IPv4 mit dem Abteilungsnetz kommunizieren können, wird der private IPv4-Adressebereich für die VPN-Clients durch den VPN-Server via \textit{Network Address Translation} (NAT) auf die IPv4-Dienstadresse übersetzt.
Damit VPN-Clients über IPv4 mit dem Abteilungsnetz kommunizieren können, wird der private IPv4-Adressbereich für die VPN-Clients durch den VPN-Server via \textit{Network Address Translation} (NAT) auf die IPv4-Dienstadresse übersetzt.
\paragraph{Failover}
Durch die Unterscheidung zwischen physischem Server und Dienst bezüglich der vergebenen IP-Adressen kann ein manuelles Failover zwischen zwei identisch konfigurierten Servern (in diesem Beispiel A und B genannt) durchgeführt werden.
@ -608,7 +608,7 @@ Um die in Kapitel~\ref{cpt:user_concept} konzipierte Zertifizierungsstelle zur B
In der \textbf{Clientkonfiguration} wird dafür der Parameter \texttt{tls-client} gesetzt, in der \textbf{Serverkonfiguration} wird analog dazu der Parameter \texttt{tls-server} verwendet.
Anschließend werden in der \textbf{Client- und Serverkonfiguration} über die Parameter \texttt{ca}, \texttt{cert} und \texttt{key} Dateipfade konfiguriert, unter denen das Wurzelzertifikat, das Client- beziehungsweise Serverzertifikat und der dazugehörige private Schlüssel abgelegt sind.
In der \textbf{Serverkonfiguration} werden zusätzlich über die Parameter \texttt{dh} und \texttt{crl-verify} Dateipfade angegeben, unter dene die im Voraus berechneten Parameter für den Diffie-Hellman-Schlüsselaustausch und die aktuelle Kopie der von der CA herausgegebenen CRL abgespeichert sind.
In der \textbf{Serverkonfiguration} werden zusätzlich über die Parameter \texttt{dh} und \texttt{crl-verify} Dateipfade angegeben, unter denen die im Voraus berechneten Parameter für den Diffie-Hellman-Schlüsselaustausch und die aktuelle Kopie der von der CA herausgegebenen CRL abgespeichert sind.
\begin{lstlisting}
ca inform/ca.crt
cert inform/aither.inform.hs-hannover.de.crt
@ -639,7 +639,7 @@ tls-version-min "1.2"
\end{lstlisting}
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 Peudozufallszahlen für den \textit{Keyed-Hash Message Authentication Code} (HMAC) \cite[][Kapitel 5]{RFC5246}.
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}.
@ -654,7 +654,7 @@ Somit wird die zuvor genannte TLS-Chiffre mit DHE-Verfahren verwendet:
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
\end{lstlisting}
OpenVPN verwendet einen HMAC mit einem zuvor ausgetauschen, gemeinsamen Geheimnis um für Daten- und Kontrollkanal eingehende Datenpakete vor ihrer Verarbeitung zu authentisieren.
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}.
\begin{lstlisting}
@ -722,14 +722,14 @@ group nogroup
\end{lstlisting}
Für die \textbf{Clientkonfiguration} kann es sinnvoll sein, dass OpenVPN das Passwort, mit dem ein privater Schlüssel geschützt wurde, nicht im Speicher behält.
Mit der folgenden Option kann OpenVPN gezwungen werden, ein solches Passwort nicht im Spicher zu halten.
Mit der folgenden Option kann OpenVPN gezwungen werden, ein solches Passwort nicht im Speicher zu halten.
\begin{lstlisting}
auth-nocache
\end{lstlisting}
\paragraph{Protokollierung}
Um die Gesprächigkeit 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 Debugging in der Entwicklung).
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).
Standardmäßig wird der Wert 1 verwendet; der Wert 3 wird für übersichtliche Protokolle mit mehr Informationen 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.