Autosave
This commit is contained in:
parent
d67d0a9f34
commit
1aaeea8fe5
269
MA-Inhalt.tex
269
MA-Inhalt.tex
@ -471,139 +471,8 @@ Dadurch ist OpenVPN besser für die Umsetzung eines VPN-Dienst geeignet, der die
|
||||
Somit wird OpenVPN als VPN-Software zur Umsetzung des VPN-Dienst gewählt.
|
||||
|
||||
|
||||
\chapter{Implementieren der Benutzerverwaltung} \label{cpt:implement_ca}
|
||||
OpenVPN benötigt zur Laufzeit die Bibliothek OpenSSL.
|
||||
OpenSSL stellt seine Funktionen auch als Kommandozeilenwerkzeug zur Verfügung, mit denen alle Basisfunktionen einer Zertifizierungsstelle wie zum Beispiel die Erzeugung von Schlüsselpaaren und Zertifikatsanträgen, sowie das Ausstellen von Zertifikaten auf Basis von Zertifikatsanträgen möglich ist.
|
||||
Man kann mit OpenSSL eine \textit{Zertifizierungsstelle} (CA) 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.
|
||||
|
||||
|
||||
\section{Zertifizierungsstelle mit EasyRSA} \label{sct:easyrsa_intro}
|
||||
Mit der Installation von OpenVPN wird die Installation der Software \enquote{EasyRSA} durch den Debian-Paketmanager empfohlen, welches ebenfalls von den OpenVPN-Entwicklern geschrieben wurde.
|
||||
Dieses Paket enthält eine Sammlung von Shellskripten, welche die Funktionalität von OpenSSL kapseln, um damit einen erleichterten Betrieb einer CA zu ermöglichen.
|
||||
Die enthaltenen Skripte abstrahieren allgemeine Aufgaben für den Betrieb einer CA.
|
||||
Das enthält die Erzeugung eines Wurzelzertifikats, das Erzeugen von Zertifikatsanträgen, das Ausstellen von Client- oder Serverzertifikaten auf Basis von Zertifikatsanträgen und das Erzeugen einer \textit{Certificate Revocation List}(CRL).
|
||||
Dabei ist es durch Anpassen von Konfigurationsdateien möglich, eine CA ganz nach den eigenen Bedürfnissen zu betreiben und Einfluss auf Parameter wie zum Beispiel Schlüssellängen, Laufzeiten von Zertifikaten oder verwendete kryptografische Algorithmen zu nehmen.
|
||||
|
||||
Aufgrund der Vorteile von EasyRSA in Bezug auf einfachere Konfiguration und erleichterte Bedienung für CA-Betreiber und Benutzer im Vergleich zur manuellen Umsetzung einer CA, soll EasyRSA für den Aufbau der Zertifizierungsstelle verwendet werden.
|
||||
Diese Entscheidung wird untermauert von der Tatsache, dass sowohl EasyRSA als auch OpenVPN von den selben Entwicklern weiterentwickelt wird, sodass Kompatibilität zwischen den beiden Softwareprojekten zu erwarten ist.
|
||||
Die Notwendigkeit zum selbstständigen Entwickeln von Skripten zum Erreichen eines ähnlichen Funktionsumfangs ergibt sich somit nicht.
|
||||
|
||||
Das über Debian~9 beziehbare Paket enthält EasyRSA in Version~2.3.x.
|
||||
Die heute (01.10.2018) über GitHub\footnote{\url{https://github.com/OpenVPN/easy-rsa/releases/tag/v3.0.5}} beziehbare Version von EasyRSA trägt die Nummer 3.0.5.
|
||||
EasyRSA wurde in Version~3 von Grund auf neu geschrieben und verfügt über ein im Vergleich zu EasyRSA Version~2 vereinfachtem Benutzerinterface, welches nun von einem einzigen Kommandozeilenbefehl zur Verfügung gestellt wird.
|
||||
Zusätzlich hinzugekommen sind neue Features wie etwa die Unterstützung des \textit{Elliptische-Kurven-Kryptosystems} (EKK), Unterstützung von UTF-8 oder die Verwendung von AES256 zum Verschlüsseln von privaten Schlüsseln\footnote{Vergleich \url{https://github.com/OpenVPN/easy-rsa/blob/v3.0.5/ChangeLog}}.
|
||||
|
||||
Die Installation von EasyRSA wird durch das Kopieren sämtlicher Dateien von ~EasyRSA in ein neues Verzeichnis durchgeführt.
|
||||
Eine auf diese Weise eingerichtete CA kann aus diesem Grund nicht durch den Debian-Paketmanager mit Updates versorgt werden.
|
||||
Aufgrund des Installationsprozess und den in EasyRSA Version~3.0.5 enthaltenen Vorteilen wird entschieden, dass EasyRSA Version~3.0.5 zum Aufbau der CA für den VPN-Dienst eingesetzt wird.
|
||||
|
||||
|
||||
\section{Konfiguration von EasyRSA} \label{sct:easyrsa_config}
|
||||
Bevor mit EasyRSA~3.0.5 eine CA aufgebaut werden kann, muss die Konfiguration von EasyRSA an die Bedürfnisse der CA angepasst werden.
|
||||
Die anzupassenden Parameter werden in diesem Abschnitt beschrieben und die dazu getroffenen Entscheidungen erläutert.
|
||||
|
||||
\paragraph{Vorgaben:}
|
||||
Die folgenden Vorgaben für die CA wurden in Absprache mit dem Auftraggeber und Erstprüfer dieser Arbeit festgelegt:
|
||||
Das Wurzelzertifikat soll für 20 Jahre gültig sein.
|
||||
Ausgestellte Clientzertifikate sollen für Beschäftigte 5 Jahre lang gültig sein, für Studierende 2 Jahre lang.
|
||||
Ausgestellte Serverzertifikate sollen 5 Jahre lang gültig sein.
|
||||
In den ausgestellten Benutzerzertifikaten soll der volle Name und die Hochschul-E-Mail-Adresse des Benutzers abgelegt werden.
|
||||
Die Serverzertifikate sollen den \textit{vollqualifizierten Domainnamen} (FQDN) enthalten.
|
||||
|
||||
\paragraph{Auswahl des Kryptosystems:}
|
||||
EasyRSA unterstützt sowohl RSA-Schlüsselpaare als auch Schlüsselpaare auf Basis der \textit{Elliptische-Kurven-Kryptografie} (EKK).
|
||||
Somit stehen RSA und EKK als Kryptosystems zur Auswahl, mit denen die CA aufgebaut werden kann.
|
||||
|
||||
OpenVPN unterstützt die Verwendung von Zertifikaten mit Schlüsseln auf Basis der EKK ab Version~2.4.0\footnote{Vergleich \url{https://github.com/OpenVPN/openvpn/blob/v2.4.6/README.ec}} vom Dezember 2016 \footnote{Siehe \url{https://github.com/OpenVPN/openvpn/releases/tag/v2.4.0}}.
|
||||
Die Unterstützung von Zertifikaten mit RSA-Schlüsseln ist jedoch schon in Version~1.2.0 vorhanden gewesen\footnote{Vergleich \url{https://github.com/OpenVPN/openvpn/blob/v2.4.6/ChangeLog}}, und existiert somit spätestens seit Mai 2002.
|
||||
Zertifikate auf Basis des RSA-Kryptosystems wurden im OpenVPN-Umfeld also mindestens 14 Jahre länger erprobt als Zertifikate auf Basis von EKK.
|
||||
Die daraus resultierenden Erfahrungswerte sind für die Auswahl des Kryptosystems der VPN-CA ausschlaggebend, da die Zertifikate für den VPN-Dienst, abhängig von ihrem Verwendungszweck, für Zeiträume von 5 bis 20 Jahren gültig sein sollen.
|
||||
|
||||
Für das gewählte Kryptosystem müssen Parameter wie die gewünschte Schlüssellänge und, im Fall von EKK, eine elliptische Kurve gewählt werden.
|
||||
Sollten die Parameter des Kryptosystems oder das Kryptosystem selbst während des Betriebszeitraums nicht mehr als sicher gelten, so muss eine neue CA aufgebaut werden und die unsichere CA ersetzen.
|
||||
Tritt dieser Fall ein, so ist er mit einem hohen Arbeitsaufwand verbunden, da neue Betriebsparameter für die CA gewählt werden müssen und alle gültigen Zertifikate der alten CA entsprechend ersetzt werden müssen.
|
||||
Deshalb ist es geboten das Risiko für diesen Fall zu minimieren.
|
||||
|
||||
Aus diesem Grund fällt die Wahl auf RSA, da mit RSA im Vergleich zu EKK mehr Erfahrungswerte vorliegen, die für die langfristige Stabilität von RSA sprechen.
|
||||
Ein weiterer Grund für die Wahl von RSA liegt darin, dass lediglich die Schlüssellänge als Parameter gewählt werden muss.
|
||||
Mögliche Fehler bei der Wahl einer elliptischen Kurve, wie sie bei EKK notwendig ist, entfallen bei RSA.
|
||||
|
||||
Die Vorteile von EKK sind bei dem Anwendungsfall der CA hingegen nicht relevant:
|
||||
Die im Vergleich zu RSA geringeren Schlüssellängen bei gleichem Sicherheitsniveau werden nicht zwingend benötigt, da die Schlüssel beider Kryptosysteme auf modernen Computern in mehr als ausreichender Anzahl abgespeichert werden können.
|
||||
Auch auf die im Vergleich zu RSA effizienteren Verfahren in EKK zum Signieren und Verschlüsseln von Daten kann verzichtet werden, da alle diese Operationen auf modernen Computern in wenigen Sekunden berechnet werden können.
|
||||
|
||||
Laut BSI kann RSA über das Jahr 2023 hinaus eingesetzt werden \cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
|
||||
|
||||
\paragraph{Festlegen der Schlüssellänge:}
|
||||
Im nächsten Schritt wird die Länge der RSA-Schlüssel festgelegt, die in allen durch die CA ausgestellten Zertifikaten zum Einsatz kommen soll.
|
||||
OpenVPN empfiehlt eine Schlüssellänge von mindestens 2048 Bit: \textit{\enquote{OpenVPN will migrate to 'preferred' as default in the future. Please ensure that your keys already comply.}}.
|
||||
Das Profil \enquote{preferred} ist dabei wie folgt definiert: \textit{\enquote{SHA2 and newer, RSA 2048-bit+, any elliptic curve.}} \cite[Aus][Option \texttt{--tls-cert-profile}]{man:openvpn}.
|
||||
Das BSI empfiehlt Schlüssellängen von mindestens 3000 Bit für Verwendungen über das Jahr 2023 hinaus \cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
|
||||
Damit die CA für 20 Jahre sicher betrieben werden kann, wird auf Basis dieser Empfehlungen die Schlüssellänge auf 4096 Bit festgelegt.
|
||||
|
||||
\paragraph{Metadaten:}
|
||||
EasyRSA unterstützt zwei Varianten, um den Inhalt des \texttt{Subject}-Felds eines X.509-Zertifikat zu füllen.
|
||||
Im Modus \enquote{cn\_only} wird nur der \texttt{Common Name} in das \texttt{Subject}-Feld gesetzt.
|
||||
Im Modus \enquote{org} wird ein \texttt{Distinguished Name} in dem \texttt{Subject}-Feld abgelegt, der die Felder \texttt{Country}, \texttt{Province}, \texttt{City}, \texttt{Org}, \texttt{OU}, \texttt{email} und \texttt{CN} beinhaltet.
|
||||
|
||||
Laut Vorgaben soll der volle Name und die Hochschul-E-Mail-Adresse der Benutzer in den Clientzertifikaten abgelegt werden.
|
||||
Somit muss EasyRSA auf den Modus \enquote{org} eingestellt werden.
|
||||
Für Clientzertifikate wird festgelegt, dass der volle Name im Feld \texttt{Common Name} abgelegt wird, und die E-Mail-Adresse im Feld \texttt{Email Address}.
|
||||
Für Serverzertifikate wird festgelegt, dass der \textit{vollqualifizierte Domainname} (FQDN) im Feld \texttt{Common Name} abgelegt wird.
|
||||
Das Feld \texttt{Email Address} wird mit der Hochschul-E-Mail-Adresse der für den Server zuständigen Administratoren gefüllt.
|
||||
Für alle weiteren Felder werden folgende Vorgaben festgelegt:
|
||||
\texttt{Country}: \enquote{DE},
|
||||
\texttt{Province}: \enquote{Niedersachsen},
|
||||
\texttt{City}: \enquote{Hannover},
|
||||
\texttt{Org}: \enquote{Hochschule Hannover},
|
||||
\texttt{OU}: \enquote{Abteilung Informatik}.
|
||||
|
||||
\paragraph{Gültigkeitsdauer der CRL:}
|
||||
OpenVPN kann die von der CA ausgestellte \textit{Certificate Revocation List} (CRL) benutzen kann um die Gültigkeit von Clientzertifikaten zu überprüfen.
|
||||
Da dieses Feature benutzt werden soll, sind Einstellungen in Bezug auf die CRL für diese Arbeit relevant.
|
||||
|
||||
Die CRL enthält Informationen über alle von der CA zurückgerufenen Zertifikate und ist nur für einen begrenzten Zeitraum gültig, der anhand der Felder \enquote{Last Update} und \enquote{Next Update} begrenzt wird \cite[][Kapitel 5.1.2]{RFC5280}.
|
||||
Dabei sollte eine aktualisierte CRL noch vor Erreichen des \enquote{Next Update}-Zeitpunkt der vorherigen CRL durch die CA veröffentlicht werden \cite[][Kapitel 5.1.2.5]{RFC5280}.
|
||||
|
||||
Für EasyRSA kann die Gültigkeitsdauer der CRL in Tagen konfiguriert werden.
|
||||
Da OpenVPN bei einer abgelaufenen CRL den Dienst verweigert, ist für einen unterbrechungsfreien Betrieb wichtig, dass immer eine gültige CRL zur Verfügung steht.
|
||||
Grundsätzlich stellt dies kein Problem dar: Sowohl das Ausstellen, als auch das Installieren der CRL auf dem OpenVPN-Server können automatisiert werden.
|
||||
Um auch bei manueller Installation der CRL einen unterbrechungsfreien Betrieb des VPN-Dienst zu gewährleisten wird für die CRL eine Gültigkeitsdauer von 180 Tagen festgelegt.
|
||||
|
||||
|
||||
\section{Betrieb der Zertifizierungsstelle} \label{sct:running_ca}
|
||||
Für den Betrieb der Zertifizierungsstelle wird in Absprache mit dem IT-Team eine virtuelle Maschine exklusiv für diesen Zweck erzeugt und im Mitarbeiter-Netz platziert.
|
||||
Unter Berücksichtigung der Anforderung \ref{req:serveros} aus Kapitel~\ref{par:requirements} wird Debian~9 nach den Vorgaben des IT-Teams auf der virtuellen Maschine installiert.
|
||||
Das EasyRSA-Paket wird unterhalb von \texttt{/root} ausgepackt und für den Einsatz als CA für den VPN-Dienst konfiguriert.
|
||||
|
||||
\paragraph{Berechtigungen:}
|
||||
Durch die Platzierung der CA unterhalb von \texttt{/root} kann nur der Benutzer \texttt{root} die Zertifizierungsstelle benutzen und auf den privaten Schlüssel des Wurzelzertifikats zugreifen.
|
||||
Lokale Benutzer können über \texttt{sudo} für die Benutzung der CA berechtigt werden.
|
||||
Zusätzlich können direkte Zugriffsrechte durch die Verwendung von SSH-Schlüsseln für den \texttt{root}-Login verteilt werden.
|
||||
|
||||
Gleichzeitig beinhaltet der \texttt{root}-Benutzer eine Warnfunktion: Die Berechtigung für Zugriffe auf die CA impliziert viel Verantwortung und verlangt sorgfältiges Vorgehen bei der Benutzung der CA.
|
||||
Auch die regelmäßige Kontrolle aller erteilten Berechtigungen und die überlegte Erteilung von Berechtigungen soll zusätzlich motiviert werden.
|
||||
|
||||
\paragraph{Öffentliche Daten:}
|
||||
VPN-Benutzer benötigen bestimmte Dateien, um die CA zu verwenden.
|
||||
Neben dem Wurzelzertifikat der CA und der aktuellen CRL benötigen Benutzer eine vorkonfigurierte Version des EasyRSA-Pakets zur Erzeugung von Zertifikatsanträgen.
|
||||
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 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.
|
||||
|
||||
Die Veröffentlichung von Konfigurationsdateien und Anleitungen für VPN-Benutzer kann über diesen Webserver ebenfalls stattfinden.
|
||||
|
||||
\paragraph{Aktualisierung der CRL:}
|
||||
Damit der OpenVPN-Server immer Zugriff auf eine aktuelle CRL hat, wird ein Cronjob via \texttt{crontab -e} unter dem Benutzer \texttt{root} eingerichtet, der über die EasyRSA-Skripte eine neue CRL erzeugt und diese anschließend mit den zuvor erläuterten Dateirechten in \texttt{/public} platziert.
|
||||
|
||||
Auf dem OpenVPN-Server wird ebenfalls ein Cronjob eingerichtet, der die aktuelle CRL von dem Webserver der CA herunterlädt und in das Konfigurationsverzeichnis von OpenVPN integriert.
|
||||
|
||||
Details zur Benutzung der CA sind in dem Dokument \enquote{Dokumentation der Zertifizierungsstelle für den IPv6-VPN-Dienst} im Anhang dieser Arbeit zu finden.
|
||||
|
||||
\chapter{Konzept OpenVPN} \label{cpt:openvpn_concept}
|
||||
\todo{Hier kommt die Umsetzung des Konzepts als Beschreibung rein, damit die Konfiguration nur noch die Details erläutert, aber nicht begründen muss. Begründungen kommen hier hin.}
|
||||
|
||||
\chapter{Konfiguration des OpenVPN-Servers} \label{cpt:implement_vpn_server}
|
||||
In diesem Kapitel wird gezeigt, wie der Server für den VPN-Dienst installiert und konfiguriert wird. Wie in Kapitel~\ref{par:requirements} bereits geklärt, wird laut Anforderung~\ref{req:serveros} Debian~9 als Betriebssystem verwendet.
|
||||
@ -888,6 +757,140 @@ Damit ist die Erzeugung der OpenVPN-Konfiguration für Client und Server abgesch
|
||||
Die resultierenden Konfigurationdateien befinden sich im Anhang dieser Arbeit.
|
||||
|
||||
|
||||
\chapter{Implementieren der Benutzerverwaltung} \label{cpt:implement_ca}
|
||||
OpenVPN benötigt zur Laufzeit die Bibliothek OpenSSL.
|
||||
OpenSSL stellt seine Funktionen auch als Kommandozeilenwerkzeug zur Verfügung, mit denen alle Basisfunktionen einer Zertifizierungsstelle wie zum Beispiel die Erzeugung von Schlüsselpaaren und Zertifikatsanträgen, sowie das Ausstellen von Zertifikaten auf Basis von Zertifikatsanträgen möglich ist.
|
||||
Man kann mit OpenSSL eine \textit{Zertifizierungsstelle} (CA) 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.
|
||||
|
||||
|
||||
\section{Zertifizierungsstelle mit EasyRSA} \label{sct:easyrsa_intro}
|
||||
Mit der Installation von OpenVPN wird die Installation der Software \enquote{EasyRSA} durch den Debian-Paketmanager empfohlen, welches ebenfalls von den OpenVPN-Entwicklern geschrieben wurde.
|
||||
Dieses Paket enthält eine Sammlung von Shellskripten, welche die Funktionalität von OpenSSL kapseln, um damit einen erleichterten Betrieb einer CA zu ermöglichen.
|
||||
Die enthaltenen Skripte abstrahieren allgemeine Aufgaben für den Betrieb einer CA.
|
||||
Das enthält die Erzeugung eines Wurzelzertifikats, das Erzeugen von Zertifikatsanträgen, das Ausstellen von Client- oder Serverzertifikaten auf Basis von Zertifikatsanträgen und das Erzeugen einer \textit{Certificate Revocation List}(CRL).
|
||||
Dabei ist es durch Anpassen von Konfigurationsdateien möglich, eine CA ganz nach den eigenen Bedürfnissen zu betreiben und Einfluss auf Parameter wie zum Beispiel Schlüssellängen, Laufzeiten von Zertifikaten oder verwendete kryptografische Algorithmen zu nehmen.
|
||||
|
||||
Aufgrund der Vorteile von EasyRSA in Bezug auf einfachere Konfiguration und erleichterte Bedienung für CA-Betreiber und Benutzer im Vergleich zur manuellen Umsetzung einer CA, soll EasyRSA für den Aufbau der Zertifizierungsstelle verwendet werden.
|
||||
Diese Entscheidung wird untermauert von der Tatsache, dass sowohl EasyRSA als auch OpenVPN von den selben Entwicklern weiterentwickelt wird, sodass Kompatibilität zwischen den beiden Softwareprojekten zu erwarten ist.
|
||||
Die Notwendigkeit zum selbstständigen Entwickeln von Skripten zum Erreichen eines ähnlichen Funktionsumfangs ergibt sich somit nicht.
|
||||
|
||||
Das über Debian~9 beziehbare Paket enthält EasyRSA in Version~2.3.x.
|
||||
Die heute (01.10.2018) über GitHub\footnote{\url{https://github.com/OpenVPN/easy-rsa/releases/tag/v3.0.5}} beziehbare Version von EasyRSA trägt die Nummer 3.0.5.
|
||||
EasyRSA wurde in Version~3 von Grund auf neu geschrieben und verfügt über ein im Vergleich zu EasyRSA Version~2 vereinfachtem Benutzerinterface, welches nun von einem einzigen Kommandozeilenbefehl zur Verfügung gestellt wird.
|
||||
Zusätzlich hinzugekommen sind neue Features wie etwa die Unterstützung des \textit{Elliptische-Kurven-Kryptosystems} (EKK), Unterstützung von UTF-8 oder die Verwendung von AES256 zum Verschlüsseln von privaten Schlüsseln\footnote{Vergleich \url{https://github.com/OpenVPN/easy-rsa/blob/v3.0.5/ChangeLog}}.
|
||||
|
||||
Die Installation von EasyRSA wird durch das Kopieren sämtlicher Dateien von ~EasyRSA in ein neues Verzeichnis durchgeführt.
|
||||
Eine auf diese Weise eingerichtete CA kann aus diesem Grund nicht durch den Debian-Paketmanager mit Updates versorgt werden.
|
||||
Aufgrund des Installationsprozess und den in EasyRSA Version~3.0.5 enthaltenen Vorteilen wird entschieden, dass EasyRSA Version~3.0.5 zum Aufbau der CA für den VPN-Dienst eingesetzt wird.
|
||||
|
||||
|
||||
\section{Konfiguration von EasyRSA} \label{sct:easyrsa_config}
|
||||
Bevor mit EasyRSA~3.0.5 eine CA aufgebaut werden kann, muss die Konfiguration von EasyRSA an die Bedürfnisse der CA angepasst werden.
|
||||
Die anzupassenden Parameter werden in diesem Abschnitt beschrieben und die dazu getroffenen Entscheidungen erläutert.
|
||||
|
||||
\paragraph{Vorgaben:}
|
||||
Die folgenden Vorgaben für die CA wurden in Absprache mit dem Auftraggeber und Erstprüfer dieser Arbeit festgelegt:
|
||||
Das Wurzelzertifikat soll für 20 Jahre gültig sein.
|
||||
Ausgestellte Clientzertifikate sollen für Beschäftigte 5 Jahre lang gültig sein, für Studierende 2 Jahre lang.
|
||||
Ausgestellte Serverzertifikate sollen 5 Jahre lang gültig sein.
|
||||
In den ausgestellten Benutzerzertifikaten soll der volle Name und die Hochschul-E-Mail-Adresse des Benutzers abgelegt werden.
|
||||
Die Serverzertifikate sollen den \textit{vollqualifizierten Domainnamen} (FQDN) enthalten.
|
||||
|
||||
\paragraph{Auswahl des Kryptosystems:}
|
||||
EasyRSA unterstützt sowohl RSA-Schlüsselpaare als auch Schlüsselpaare auf Basis der \textit{Elliptische-Kurven-Kryptografie} (EKK).
|
||||
Somit stehen RSA und EKK als Kryptosystems zur Auswahl, mit denen die CA aufgebaut werden kann.
|
||||
|
||||
OpenVPN unterstützt die Verwendung von Zertifikaten mit Schlüsseln auf Basis der EKK ab Version~2.4.0\footnote{Vergleich \url{https://github.com/OpenVPN/openvpn/blob/v2.4.6/README.ec}} vom Dezember 2016 \footnote{Siehe \url{https://github.com/OpenVPN/openvpn/releases/tag/v2.4.0}}.
|
||||
Die Unterstützung von Zertifikaten mit RSA-Schlüsseln ist jedoch schon in Version~1.2.0 vorhanden gewesen\footnote{Vergleich \url{https://github.com/OpenVPN/openvpn/blob/v2.4.6/ChangeLog}}, und existiert somit spätestens seit Mai 2002.
|
||||
Zertifikate auf Basis des RSA-Kryptosystems wurden im OpenVPN-Umfeld also mindestens 14 Jahre länger erprobt als Zertifikate auf Basis von EKK.
|
||||
Die daraus resultierenden Erfahrungswerte sind für die Auswahl des Kryptosystems der VPN-CA ausschlaggebend, da die Zertifikate für den VPN-Dienst, abhängig von ihrem Verwendungszweck, für Zeiträume von 5 bis 20 Jahren gültig sein sollen.
|
||||
|
||||
Für das gewählte Kryptosystem müssen Parameter wie die gewünschte Schlüssellänge und, im Fall von EKK, eine elliptische Kurve gewählt werden.
|
||||
Sollten die Parameter des Kryptosystems oder das Kryptosystem selbst während des Betriebszeitraums nicht mehr als sicher gelten, so muss eine neue CA aufgebaut werden und die unsichere CA ersetzen.
|
||||
Tritt dieser Fall ein, so ist er mit einem hohen Arbeitsaufwand verbunden, da neue Betriebsparameter für die CA gewählt werden müssen und alle gültigen Zertifikate der alten CA entsprechend ersetzt werden müssen.
|
||||
Deshalb ist es geboten das Risiko für diesen Fall zu minimieren.
|
||||
|
||||
Aus diesem Grund fällt die Wahl auf RSA, da mit RSA im Vergleich zu EKK mehr Erfahrungswerte vorliegen, die für die langfristige Stabilität von RSA sprechen.
|
||||
Ein weiterer Grund für die Wahl von RSA liegt darin, dass lediglich die Schlüssellänge als Parameter gewählt werden muss.
|
||||
Mögliche Fehler bei der Wahl einer elliptischen Kurve, wie sie bei EKK notwendig ist, entfallen bei RSA.
|
||||
|
||||
Die Vorteile von EKK sind bei dem Anwendungsfall der CA hingegen nicht relevant:
|
||||
Die im Vergleich zu RSA geringeren Schlüssellängen bei gleichem Sicherheitsniveau werden nicht zwingend benötigt, da die Schlüssel beider Kryptosysteme auf modernen Computern in mehr als ausreichender Anzahl abgespeichert werden können.
|
||||
Auch auf die im Vergleich zu RSA effizienteren Verfahren in EKK zum Signieren und Verschlüsseln von Daten kann verzichtet werden, da alle diese Operationen auf modernen Computern in wenigen Sekunden berechnet werden können.
|
||||
|
||||
Laut BSI kann RSA über das Jahr 2023 hinaus eingesetzt werden \cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
|
||||
|
||||
\paragraph{Festlegen der Schlüssellänge:}
|
||||
Im nächsten Schritt wird die Länge der RSA-Schlüssel festgelegt, die in allen durch die CA ausgestellten Zertifikaten zum Einsatz kommen soll.
|
||||
OpenVPN empfiehlt eine Schlüssellänge von mindestens 2048 Bit: \textit{\enquote{OpenVPN will migrate to 'preferred' as default in the future. Please ensure that your keys already comply.}}.
|
||||
Das Profil \enquote{preferred} ist dabei wie folgt definiert: \textit{\enquote{SHA2 and newer, RSA 2048-bit+, any elliptic curve.}} \cite[Aus][Option \texttt{--tls-cert-profile}]{man:openvpn}.
|
||||
Das BSI empfiehlt Schlüssellängen von mindestens 3000 Bit für Verwendungen über das Jahr 2023 hinaus \cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
|
||||
Damit die CA für 20 Jahre sicher betrieben werden kann, wird auf Basis dieser Empfehlungen die Schlüssellänge auf 4096 Bit festgelegt.
|
||||
|
||||
\paragraph{Metadaten:}
|
||||
EasyRSA unterstützt zwei Varianten, um den Inhalt des \texttt{Subject}-Felds eines X.509-Zertifikat zu füllen.
|
||||
Im Modus \enquote{cn\_only} wird nur der \texttt{Common Name} in das \texttt{Subject}-Feld gesetzt.
|
||||
Im Modus \enquote{org} wird ein \texttt{Distinguished Name} in dem \texttt{Subject}-Feld abgelegt, der die Felder \texttt{Country}, \texttt{Province}, \texttt{City}, \texttt{Org}, \texttt{OU}, \texttt{email} und \texttt{CN} beinhaltet.
|
||||
|
||||
Laut Vorgaben soll der volle Name und die Hochschul-E-Mail-Adresse der Benutzer in den Clientzertifikaten abgelegt werden.
|
||||
Somit muss EasyRSA auf den Modus \enquote{org} eingestellt werden.
|
||||
Für Clientzertifikate wird festgelegt, dass der volle Name im Feld \texttt{Common Name} abgelegt wird, und die E-Mail-Adresse im Feld \texttt{Email Address}.
|
||||
Für Serverzertifikate wird festgelegt, dass der \textit{vollqualifizierte Domainname} (FQDN) im Feld \texttt{Common Name} abgelegt wird.
|
||||
Das Feld \texttt{Email Address} wird mit der Hochschul-E-Mail-Adresse der für den Server zuständigen Administratoren gefüllt.
|
||||
Für alle weiteren Felder werden folgende Vorgaben festgelegt:
|
||||
\texttt{Country}: \enquote{DE},
|
||||
\texttt{Province}: \enquote{Niedersachsen},
|
||||
\texttt{City}: \enquote{Hannover},
|
||||
\texttt{Org}: \enquote{Hochschule Hannover},
|
||||
\texttt{OU}: \enquote{Abteilung Informatik}.
|
||||
|
||||
\paragraph{Gültigkeitsdauer der CRL:}
|
||||
OpenVPN kann die von der CA ausgestellte \textit{Certificate Revocation List} (CRL) benutzen kann um die Gültigkeit von Clientzertifikaten zu überprüfen.
|
||||
Da dieses Feature benutzt werden soll, sind Einstellungen in Bezug auf die CRL für diese Arbeit relevant.
|
||||
|
||||
Die CRL enthält Informationen über alle von der CA zurückgerufenen Zertifikate und ist nur für einen begrenzten Zeitraum gültig, der anhand der Felder \enquote{Last Update} und \enquote{Next Update} begrenzt wird \cite[][Kapitel 5.1.2]{RFC5280}.
|
||||
Dabei sollte eine aktualisierte CRL noch vor Erreichen des \enquote{Next Update}-Zeitpunkt der vorherigen CRL durch die CA veröffentlicht werden \cite[][Kapitel 5.1.2.5]{RFC5280}.
|
||||
|
||||
Für EasyRSA kann die Gültigkeitsdauer der CRL in Tagen konfiguriert werden.
|
||||
Da OpenVPN bei einer abgelaufenen CRL den Dienst verweigert, ist für einen unterbrechungsfreien Betrieb wichtig, dass immer eine gültige CRL zur Verfügung steht.
|
||||
Grundsätzlich stellt dies kein Problem dar: Sowohl das Ausstellen, als auch das Installieren der CRL auf dem OpenVPN-Server können automatisiert werden.
|
||||
Um auch bei manueller Installation der CRL einen unterbrechungsfreien Betrieb des VPN-Dienst zu gewährleisten wird für die CRL eine Gültigkeitsdauer von 180 Tagen festgelegt.
|
||||
|
||||
|
||||
\section{Betrieb der Zertifizierungsstelle} \label{sct:running_ca}
|
||||
Für den Betrieb der Zertifizierungsstelle wird in Absprache mit dem IT-Team eine virtuelle Maschine exklusiv für diesen Zweck erzeugt und im Mitarbeiter-Netz platziert.
|
||||
Unter Berücksichtigung der Anforderung \ref{req:serveros} aus Kapitel~\ref{par:requirements} wird Debian~9 nach den Vorgaben des IT-Teams auf der virtuellen Maschine installiert.
|
||||
Das EasyRSA-Paket wird unterhalb von \texttt{/root} ausgepackt und für den Einsatz als CA für den VPN-Dienst konfiguriert.
|
||||
|
||||
\paragraph{Berechtigungen:}
|
||||
Durch die Platzierung der CA unterhalb von \texttt{/root} kann nur der Benutzer \texttt{root} die Zertifizierungsstelle benutzen und auf den privaten Schlüssel des Wurzelzertifikats zugreifen.
|
||||
Lokale Benutzer können über \texttt{sudo} für die Benutzung der CA berechtigt werden.
|
||||
Zusätzlich können direkte Zugriffsrechte durch die Verwendung von SSH-Schlüsseln für den \texttt{root}-Login verteilt werden.
|
||||
|
||||
Gleichzeitig beinhaltet der \texttt{root}-Benutzer eine Warnfunktion: Die Berechtigung für Zugriffe auf die CA impliziert viel Verantwortung und verlangt sorgfältiges Vorgehen bei der Benutzung der CA.
|
||||
Auch die regelmäßige Kontrolle aller erteilten Berechtigungen und die überlegte Erteilung von Berechtigungen soll zusätzlich motiviert werden.
|
||||
|
||||
\paragraph{Öffentliche Daten:}
|
||||
VPN-Benutzer benötigen bestimmte Dateien, um die CA zu verwenden.
|
||||
Neben dem Wurzelzertifikat der CA und der aktuellen CRL benötigen Benutzer eine vorkonfigurierte Version des EasyRSA-Pakets zur Erzeugung von Zertifikatsanträgen.
|
||||
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 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.
|
||||
|
||||
Die Veröffentlichung von Konfigurationsdateien und Anleitungen für VPN-Benutzer kann über diesen Webserver ebenfalls stattfinden.
|
||||
|
||||
\paragraph{Aktualisierung der CRL:}
|
||||
Damit der OpenVPN-Server immer Zugriff auf eine aktuelle CRL hat, wird ein Cronjob via \texttt{crontab -e} unter dem Benutzer \texttt{root} eingerichtet, der über die EasyRSA-Skripte eine neue CRL erzeugt und diese anschließend mit den zuvor erläuterten Dateirechten in \texttt{/public} platziert.
|
||||
|
||||
Auf dem OpenVPN-Server wird ebenfalls ein Cronjob eingerichtet, der die aktuelle CRL von dem Webserver der CA herunterlädt und in das Konfigurationsverzeichnis von OpenVPN integriert.
|
||||
|
||||
Details zur Benutzung der CA sind in dem Dokument \enquote{Dokumentation der Zertifizierungsstelle für den IPv6-VPN-Dienst} im Anhang dieser Arbeit zu finden.
|
||||
|
||||
|
||||
\chapter{Fazit} \label{cpt:conclusion}
|
||||
In dieser Arbeit wird ein IPv6-VPN-Dienst für die Abteilung Informatik anhand von gegebenen Anforderungen mit OpenVPN konzipiert und umgesetzt.
|
||||
Alle für die Installation und den Betrieb notwendigen Anleitungen befinden sich im Anhang dieser Arbeit:
|
||||
|
||||
Loading…
Reference in New Issue
Block a user