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

Remove mentioning the authors

This commit is contained in:
Jan Philipp Timme 2018-11-06 14:29:54 +01:00
parent 9af6473288
commit dbaf81eeac
1 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
MA-Inhalt.tex
View File

@ -661,8 +661,8 @@ Diese Voraussetzung wird durch einen aktuellen Bericht\footnote{Dieser Bericht l
\textbf{Anmerkung}: TLS-Chiffren mit Ephemeral-Diffie-Hellman-Verfahren auf Basis von elliptischen Kurven (ECDHE) können im Rahmen dieser Arbeit nicht verwendet werden. \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}}. 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. 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}. 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. 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. Diese Chiffre ist eine \textit{Authenticated Encryption with Associated Data} (AEAD)-Chiffre.
@ -670,8 +670,8 @@ Deshalb wird die Authentisierungsfunktion der Chiffre anstelle der zuvor beschri
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. 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 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. Gelingt es einem Angreifer den Datenkanal 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. Die Vertraulichkeit der über den VPN-Dienst übertragenen Daten hängt demnach gleichermaßen von der Verschlüsselung beider Kanäle ab.
Der logische Schluss daraus ist die Verwendung der selben Chiffre zur Verschlüsselung beider Kanäle. Der logische Schluss daraus ist die Verwendung der selben Chiffre zur Verschlüsselung beider Kanäle.
\paragraph{Statische Konfiguration kryptografischer Parameter:} \paragraph{Statische Konfiguration kryptografischer Parameter:}
@ -701,7 +701,7 @@ Die Prüfung, ob alle erlaubten Chiffren noch ausreichend sicher sind, wird dadu
Für einen Angreifer steigt die Angriffsfläche, da ältere VPN-Clients durch die Wahl einer älteren Chiffre von modernen Clients unterschieden werden könnten. Für einen Angreifer steigt die Angriffsfläche, da ältere VPN-Clients durch die Wahl einer älteren Chiffre von modernen Clients unterschieden werden könnten.
Gleichzeitig können in einer VPN-Sitzung unterschiedliche Chiffren für den Schutz von Kontroll- und Datenkanal ausgehandelt werden, sodass die effektive Vertraulichkeit von der jeweils schwächeren Chiffre bestimmt wird. Gleichzeitig können in einer VPN-Sitzung unterschiedliche Chiffren für den Schutz von Kontroll- und Datenkanal ausgehandelt werden, sodass die effektive Vertraulichkeit von der jeweils schwächeren Chiffre bestimmt wird.
Insgesamt bringt der Ansatz zur flexiblen Aushandlung und Anpassung von Chiffren mehr kontinuierlichen Arbeitsaufwand mit sich, während die statische Konfiguration der Chiffren für Klarheit in Bezug auf die verwendeten Parameter sorgt und im schlimmsten Fall, der nur sehr selten eintreten sollte, eine große Konfigurationsanpassung für alle VPN-Benutzer erfordert. Insgesamt bringt der Ansatz zur flexiblen Aushandlung und Anpassung von Chiffren mehr kontinuierlichen Arbeitsaufwand mit sich, während die statische Konfiguration der Chiffren für Klarheit in Bezug auf die verwendeten Parameter sorgt und im schlimmsten Fall, dessen Eintrittswahrscheinlichkeit als hinreichend gering eingeschätzt wird, eine große Konfigurationsanpassung für alle VPN-Benutzer erfordert.
Deshalb wird die statische Konfiguration aller kryptografischen Parameter, und der damit verbundene Verzicht auf jegliche dynamische Aushandlung beim Sitzungsaufbau, für den VPN-Dienst gewählt. Deshalb wird die statische Konfiguration aller kryptografischen Parameter, und der damit verbundene Verzicht auf jegliche dynamische Aushandlung beim Sitzungsaufbau, für den VPN-Dienst gewählt.
@ -714,21 +714,21 @@ 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 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. 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. 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. Die Serverzertifikate sollen den \textit{vollqualifizierten Domainnamen} (FQDN) des Servers enthalten.
\paragraph{Auswahl des Kryptosystems:} \paragraph{Auswahl des Kryptosystems:}
EasyRSA unterstützt sowohl RSA-Schlüsselpaare als auch Schlüsselpaare auf Basis der \textit{Elliptische-Kurven-Kryptografie} (EKK). 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. 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}}. 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. 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. 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. 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. 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. 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 ersetzt werden.
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. 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. 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. 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. Ein weiterer Grund für die Wahl von RSA liegt darin, dass lediglich die Schlüssellänge als Parameter gewählt werden muss.
@ -765,7 +765,7 @@ Für alle weiteren Felder werden folgende Vorgaben festgelegt:
\texttt{OU}: \enquote{Abteilung Informatik}. \texttt{OU}: \enquote{Abteilung Informatik}.
\paragraph{Gültigkeitsdauer der CRL:} \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. OpenVPN kann die von der CA ausgestellte \textit{Certificate Revocation List} (CRL) benutzen, 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. 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}. 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}.
@ -774,7 +774,7 @@ Dabei sollte eine aktualisierte CRL noch vor Erreichen des \enquote{Next Update}
Für EasyRSA kann die Gültigkeitsdauer der CRL in Tagen konfiguriert werden. 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. 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. 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. 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.
\chapter{Konfiguration des OpenVPN-Servers} \label{cpt:implement_vpn_server} \chapter{Konfiguration des OpenVPN-Servers} \label{cpt:implement_vpn_server}