Remove mentioning the authors

This commit is contained in:
Jan Philipp Timme 2018-11-06 14:24:48 +01:00
parent 71a5d58cc1
commit 9af6473288
1 changed files with 23 additions and 23 deletions

View File

@ -517,9 +517,9 @@ Der Quellcode von OpenVPN ist inklusive der durch OpenVPN verwendeten Bibliothek
Auch der Quellcode von Strongswan ist einschließlich des Quellcode aller durch Strongswan eingesetzten Bibliotheken öffentlich verfügbar.
Die Umsetzung eines VPN auf Basis von IPsec impliziert, dass Code aus dem verwendeten Betriebssystemkernel den durch IPsec geschützten Datenverkehr kryptografisch verarbeitet.
Der Kernel des eingesetzten Betriebssystems gehört somit auch zur Menge der eingesetzten VPN-Software.
Die Verfügbarkeit des Quellcodes des Kernels hängt vom verwendeten Betriebssystem ab und ist somit nicht in jedem Fall garantiert.
Damit wird die Forderung nach ausschließlich quelloffener VPN-Software nicht erfüllt.
Der Kernel des eingesetzten Betriebssystems ist damit aktiv an der Umsetzung des VPNs beteiligt und sollte somit ebenfalls die an die VPN-Software gestellten Kriterien erfüllen.
Die Verfügbarkeit des Quellcodes des Kernels hängt vom verwendeten Betriebssystem ab und ist deshalb nicht in jedem Fall garantiert.
Damit wird die Forderung nach ausschließlich quelloffener VPN-Software von Strongswan nicht erfüllt.
\paragraph{Plattformabhängigkeit:}
Sowohl OpenVPN als auch Strongswan sind für alle in \ref{req:clientos} und \ref{req:serveros} genannten Betriebssysteme verfügbar.
@ -528,24 +528,24 @@ Sollten Sicherheitslücken innerhalb von beiden Softwareprojekten bekannt werden
Bei einem auf OpenVPN gestützten VPN ist es möglich, TLS-Chiffren, Hashfunktionen und Verschlüsselungsalgorithmen vorzugeben, die unabhängig vom eingesetzten Betriebssystem durch OpenVPN verwendet werden.
Für ein VPN mit Strongswan auf Basis von IPsec sieht die Situation anders aus:
Wie bereits in Kapitel~\ref{ssct:strongswan} erläutert wurde, kann Strongswan nur in Kombination mit dem Betriebssystem-Kernels ein IPsec-VPN aufbauen.
Wie bereits in Kapitel~\ref{ssct:strongswan} erläutert wurde, kann Strongswan nur in Kombination mit dem Betriebssystem-Kernel ein IPsec-VPN aufbauen.
Die in \ref{req:clientos} und \ref{req:serveros} genannten Betriebssysteme enthalten unterschiedliche Kernel, die jeweils eine individuelle Implementierung von IPsec enthalten.
Aus diesem Grund kann nicht garantiert werden, dass die verschiedenen Kernel die aktuellen Empfehlungen \cite[Aktuell aus][]{RFC8221} zeitnah gemeinsam unterstützen.
Aus diesem Grund kann nicht garantiert werden, dass die verschiedenen Kernel die aktuellen Empfehlungen \cite[Aktuell aus][]{RFC8221} bezüglich kryptografischer Algorithmen zeitnah gemeinsam unterstützen.
Ebenso sind unterschiedliche Reaktionszeiten auf auftretende Sicherheitslücken zu erwarten, die einen oder mehrere Kernel betreffen.
Insgesamt kann für VPN auf Basis von IPsec nicht garantiert werden, dass ein einheitliches Sicherheitsniveau über die verschiedenen Betriebssysteme aufrecht erhalten werden kann.
Insgesamt kann für VPNs auf Basis von IPsec nicht garantiert werden, dass ein einheitliches Sicherheitsniveau über die verschiedenen Betriebssysteme aufrecht erhalten werden kann.
Erschwerend kommt hinzu, dass Strongswan auf Windows keine Unterstützung für die Einrichtung virtueller IP-Adressen bietet, welche bei IPsec-VPNs im Tunnelmodus zum Einsatz kommen \cite[][Abschnitt \enquote{Important notes}]{strongswan:onwindows}.
\paragraph{Komplexität:}
Im Betrieb besteht OpenVPN aus einem Prozess, der über eine Konfigurationsdatei alle für den Betrieb notwendigen Informationen erhält.
Eine Konfigurationsdatei für OpenVPN besteht aus einer Liste von Optionen, die das OpenVPN-Programm als Argumente akzeptiert.
Alle Optionen werden in der Manpage von OpenVPN (nach meiner Meinung) ausführlich und leicht verständlich erklärt und sollten für Einsteiger mit Grundkenntnissen in Bezug auf Netzwerke und Linux kein Hindernis darstellen.
Alle Optionen werden in der Manpage von OpenVPN (nach meiner Meinung) ausführlich und leicht verständlich erklärt, und sollten für Einsteiger mit Grundkenntnissen in Bezug auf Netzwerke und Linux kein Hindernis darstellen.
Strongswan ist modular aus einer Sammlung von Programmen aufgebaut, die abhängig von einer Sammlung von Konfigurationsdateien (vorgegebene Beispielszenarien enthalten typischerweise Inhalte für vier verschiedene Konfigurationsdateien) zum Einsatz kommen.
Zusätzlich ist beim Einsatz von Strongswan immer der Kernel des Betriebssystems involviert, da die Verarbeitung des IPsec-Datenverkehrs im Kernel durchgeführt wird.
Die Konfigurationsdateien bestehen aus Zeilen mit Parametern.
Zusätzlich enthalten die Konfigurationsdateien durch Schweifklammern abgegrenzte Abschnitte, in denen Konfigurationen für bestimmte Kontexte hinterlegt werden.
Durch diese Konstrukte ist es beispielsweise möglich, Standardwerte für eine logische IPsec-Verbindung zu definieren, diese später als Grundlage für eine andere IPsec-Verbindung zu verwenden und bei Bedarf Teile der zuvor definierten Parameter zu überschreiben.
Die verschiedenen Konfigurationsdateien werden in ihren eigenen Manpages detailliert und technisch erläutert, wobei das zusätzlich notwendige Fachwissen für IPsec für einen Einsteiger (nach Meinung des Autors) ein unbequemes Hindernis darstellen kann.
Die verschiedenen Konfigurationsdateien werden in ihren eigenen Manpages detailliert und technisch erläutert, wobei das zusätzlich notwendige Fachwissen für IPsec für einen Einsteiger (nach meiner Ansicht) ein unbequemes Hindernis darstellen kann.
\section{Zusammenfassung und Auswahl der VPN-Software} \label{sct:vpn_software_choice}
@ -556,29 +556,29 @@ Somit wird OpenVPN als VPN-Software zur Umsetzung des VPN-Dienst ausgewählt.
\section{Auswahl von Software zur Benutzerverwaltung} \label{sct:choice_easyrsa}
Nach der Wahl der VPN-Software soll in diesem Abschnitt diskutiert werden, mit welcher Software eine PKI umgesetzt werden soll, über die später die VPN-Benutzer mit Zertifikaten ausgestattet werden.
Nach der Wahl der VPN-Software soll in diesem Abschnitt diskutiert werden, mit welcher Software eine PKI umgesetzt werden soll, über welche die VPN-Benutzer mit Zertifikaten ausgestattet werden.
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.
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.
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).
Die Skripte abstrahieren allgemeine Aufgaben für den Betrieb einer CA.
EasyRSA enthält Funktionen zur Erzeugung eines Wurzelzertifikats, zum Erzeugen von Zertifikatsanträgen, für das Ausstellen von Client- oder Serverzertifikaten auf Basis von Zertifikatsanträgen und für 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.
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 mit OpenSSL alleine, 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}}.
EasyRSA wurde in Version~3 von Grund auf neu geschrieben und verfügt über ein im Vergleich zu EasyRSA Version~2 vereinfachtes 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üsselten Speichern 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.
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.
@ -587,7 +587,7 @@ Um die öffentlichen Daten der CA über HTTP zur Verfügung zu stellen, kommt de
\chapter{Planung der Installation} \label{cpt:openvpn_concept}
Nach Abschluss der Konzeptphase kann die Installation des VPN-Dienstes und der dazugehörigen PKI konkret geplant werden.
Abbildung~\ref{fig:openvpn_full_deployment} zeigt eine Gesamtübersicht über die geplante Installation des VPN-Diensts und der dazugehörigen CA.
Abbildung~\ref{fig:openvpn_full_deployment} zeigt eine Gesamtübersicht über die geplante Installation des VPN-Dienstes und der dazugehörigen CA.
\begin{figure}[h]
\centering
@ -600,7 +600,7 @@ Im Vergleich mit Abbildung~\ref{fig:vpn_service_concept} aus Kapitel~\ref{sct:wh
Die PKI wird mit Hilfe der Software EasyRSA eingerichtet werden.
Für die Bereitstellung der öffentlichen Daten der PKI wird ein Apache httpd als Webserver verwendet.
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.
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.
@ -610,15 +610,15 @@ Die durch OpenVPN gegebenen Funktionen und Einschränkungen werden hierbei berü
\paragraph{Manuelles Failover:}
Um die Verfügbarkeit des VPN-Dienstes im Fall eines Hardwareausfalls zu erhöhen, soll ein manuelles Failover auf einen zweiten, identisch konfigurierten Server möglich sein.
Das IT-Team vergibt für diesen Zweck verschiedene IPv4 und IPv6-Adressen für den Dienst und den Host.
Dadurch kann ein manuelles Failover durch Übertragung der IP-Adresse des Dienstes von dem defekten Server auf einen weiteren Server durchgeführt werden.
Das IT-Team vergibt für diesen Zweck verschiedene IPv4- und IPv6-Adressen für den Dienst und den Host.
Dadurch kann ein manuelles Failover durch die Übertragung der IP-Adresse des Dienstes von dem defekten Server auf einen weiteren, identisch konfigurierten Server durchgeführt werden.
Im Beispiel sieht ein Failover von Server~A auf Server~B wie folgt aus:
Bei einem Defekt von Server~A werden zunächst die IP-Dienstadressen auf A deaktiviert.
Anschließend werden die IP-Dienstadressen auf B aktiviert.
Sollte dieses Verfügbarkeitsniveau nicht mehr ausreichen, so ist ein parallelbetrieb von zwei VPN-Servern möglich.
Sollte dieses Verfügbarkeitsniveau nicht mehr ausreichen, so ist ein Parallelbetrieb von zwei VPN-Servern möglich.
Dafür muss lediglich ein weiteres IPv6-Netz für VPN-Clients bereitgestellt werden und neue IP-Dienstadressen für einen weiteren VPN-Dienst vergeben werden.
In der OpenVPN-Clientkonfiguration können beide VPN-Dienste eingetragen werden, sodass die Clients bei Ausfall eines Servers automatisch eine Sitzung mit dem zweiten Server aufbauen können.
In der OpenVPN-Clientkonfiguration können beide VPN-Server eingetragen werden, sodass die Clients bei Ausfall eines Servers automatisch eine Sitzung mit dem zweiten Server aufbauen können.
Damit ist ein Parallelbetrieb von zwei OpenVPN-Diensten möglich, die sich in der Konfiguration nur durch ihre IP-Dienstadresse und das verwendete IPv6-Netz für VPN-Clients unterscheiden.
\paragraph{VPN-Transportprotokoll:}
@ -639,7 +639,7 @@ Am 03.06.2018 wurden Hinweise in der Manpage von OpenVPN eingefügt\footnote{\ur
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}}\footnote{Proof of Concept: \url{https://github.com/skepticfx/voracle}}, der auf aktivierter Kompression aufbaut.
Auf der DEFCON~26 wurde mit \enquote{VORACLE} ein in diesem Kontext relevanter Angriff\footnote{Proof of Concept: \url{https://github.com/skepticfx/voracle}} 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.