Die Menge der noch verfügbaren IPv4-Adressen neigt sich dem Ende zu.
Laut Angaben des RIPE NCC\footnote{RIPE Network Coordination Centre} vom Juni 2018 sind noch ungefähr 8,63 Millionen IPv4-Adressen verfügbar\footnote{\url{https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph}, abgerufen am 03.06.2018}.
Das entspricht etwa der Hälfte der nutzbaren Host-Adressen eines \texttt{/8}-Blocks.
Betrachtet man die Vergabegeschwindigkeit von IPv4-Adressen aus den letzten drei Jahren, so könnte man den Zeitpunkt der Erschöpfung von IPv4-Adressen zwischen 2019 und 2021 vermuten\footnote{\url{https://ipv4.potaroo.net/}, abgerufen am 03.06.2018}.
Vor diesem Hintergrund findet die Verwendung von IPv6 eine zunehmende Verbreitung als Nachfolger von IPv4:
Immer mehr Internetdienste können über IPv6 erreicht werden, und auch die Internetanbieter stellen ihren Kunden IPv6-fähige Internetanschlüsse zur Verfügung.
Der Anteil von Suchanfragen, die über IPv6 an Google gestellt wurden, hat von 5,84\% am 1. Januar 2015 auf 21,11\% am 1. Juni 2018 zugenommen\footnote{\url{https://www.google.com/intl/en/ipv6/statistics.html}, abgerufen am 03.06.2018}.
Am AMS-IX\footnote{Amsterdam Internet Exchange}, dem Internet-Austauschpunkt in Amsterdam, hat sich der Durchfluss von IPv6-Verkehr in den letzten 12 Monaten im Durchschnitt von etwa 55~Gbit/s im August 2017 auf etwa 85~Gbit/s im Mai 2018 gesteigert\footnote{\url{https://ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic},\\abgerufen am 03.06.2018}.
Auch das Netz der Abteilung Informatik an der Hochschule Hannover ist Vorreiter in der Erprobung von IPv6: Seit Anfang 2015 ist das Netz schon über IPv6 an das Internet angebunden.
Mitarbeitern und Studenten der Abteilung Informatik steht ein VPN-Dienst zur Ver\-fü\-gung, um Zugang in das Netz der Abteilung aus dem Internet heraus zu erhalten.
Bisher ist dieser Dienst nur über IPv4 erreichbar und ermöglicht den Zugang in das Abteilungsnetz ausschließlich über IPv4.
\newpage
Im Rahmen dieser Masterarbeit soll ein neuer, IPv6-fähiger VPN-Dienst konzipiert werden, der die Idee des bisherigen IPv4-VPN-Dienst aufgreift.
Dafür wird zunächst die Netzarchitektur der Abteilung Informatik inklusive dem Firewallkonzept vorgestellt.
Anschließend werden alle Rahmenbedingungen und Anforderungen erfasst, die bei der Konzeption des neuen VPN-Dienst berücksichtigt werden sollen.
In der darauf folgenden Konzeptphase werden zunächst grundlegende, lösungsunabhängige Entscheidungen getroffen, auf Basis derer dann eine technischen Lösung ausgewählt wird.
\todo{Danach geht es weiter mit der Planung der konkreten Lösung, der Installation und der Dokumentation.}
\chapter{Netzarchitektur der Abteilung Informatik}\label{cpt:netarchitecture}
Das Netz der Abteilung Informatik wird durch eine Firewall vom Netz der Hochschule Hannover und dem Internet getrennt.
An der Firewall sind zwei lokale Netze angeschlossen: Die Demilitarisierte Zone (DMZ) und das interne Abteilungsnetz, welches durch einen zentralen Switch in mehrere virtuelle Netze (VLANs) unterteilt wird.
Zusätzlich sind die Netze des Netzwerklabors und des IT-Sicherheitslabors über je einen eigenen Router an den Switch angeschlossen.
Eine Skizze der Netztopologie mit den für diese Arbeit relevanten Teilen ist in Abbildung~\ref{fig:topology_simple} zu sehen.
\begin{figure}[ht]
\centering
% Trim, da diese Grafik als PDF auf DIN A4 vorliegt.
\caption{Skizze der Netztopologie der Abteilung Informatik}
\label{fig:topology_simple}
\end{figure}
\section{Firewallkonzept}\label{sct:firewall}
Die im Netz der Abteilung Informatik verwendeten LANs und VLANs werden im Firewallkonzept als verschiedene Sicherheitszonen betrachtet.
Im Rahmen dieser Arbeit sind die folgenden Zonen relevant:
\paragraph{Internet}
Das \enquote{Internet} bezeichnet den Bereich außerhalb des Netzes der Abteilung Informatik.
Diese Zone umfasst neben dem Internet auch das Netz der Hochschule Hannover.
Verbindungen in das Internet sind aus allen Zonen außer der DMZ erlaubt.
Verbindungen aus dem Internet werden nur zu Diensten in der DMZ (wie zum Beispiel VPN), sowie zu dem SSH-Dienst im Mitarbeiter-Netz zugelassen.
\paragraph{DMZ}
Von der Abteilung Informatik betriebenen Server stellen in diesem Netz Dienste zur Verfügung, die sowohl innerhalb der Abteilung als auch über das Internet erreichbar sind.
Verbindungen in die DMZ zu Diensten wie VPN sind aus allen anderen Zonen heraus erlaubt.
Verbindungen aus der DMZ in alle anderen Zonen sind verboten, um im Fall eines Sicherheitsvorfalls Angriffe auf alle anderen Zonen zu verhindern.
Eine Ausnahme für dieses Verbot sind Verbindungen vom VPN-Dienst, die in das Mitarbeiter-Netz aufgebaut werden dürfen.
\paragraph{Mitarbeiter-Netz}
Die Rechner aller Mitarbeiter der Abteilung Informatik sind an dieses Netz angeschlossen.
Verbindungen in das Mitarbeiter-Netz aus dem Pool-PC-Netz und den Labor-Netzen sind erlaubt.
Außerdem sind Verbindungen von dem VPN-Dienst aus der DMZ in das Mitarbeiter-Netz erlaubt.
Verbindungen aus dem Mitarbeiter-Netz sind in alle anderen Zonen erlaubt.
\paragraph{Pool-PC-Netz}
Enthält die Rechner aus allen Poolräumen.
Verbindungen in das Pool-PC-Netz sind aus dem Mitarbeiter-Netz und den Labor-Netzen erlaubt.
Verbindungen aus dem Pool-PC-Netz sind in alle anderen Zonen erlaubt.
\paragraph{Labor-Netze}
Das Netzwerklabor und das Labor für IT-Sicherheit werden für diese Arbeit unter der Zone \enquote{Labor-Netze} zusammengefasst.
Verbindungen aus den Labornetzen heraus sind in alle anderen Zonen erlaubt.
Verbindungen in die Labornetze sind aus dem Mitarbeiter-Netz und aus dem Pool-PC-Netz heraus erlaubt.
Ein Überblick der erlaubten Verbindungen zwischen den Sicherheitszonen ist in Tabelle~\ref{tab:firewall_zone_access} skizziert.
\begin{table}[ht]
\centering
\caption{Überblick über erlaubte Verbindungen zwischen Sicherheitszonen}
In diesem Abschnitt werden alle Anforderungen und Rahmenbedingungen vorgestellt, die bei der Konzeption des neuen VPN-Dienst berücksichtigt werden müssen.
\item\label{req:dualstack}\textbf{Dual-Stack-Betrieb:} Der VPN-Dienst soll aus dem Internet über IPv4 und IPv6 erreichbar sein und auch innerhalb des VPN diese beiden Protokolle anbieten.
\item\label{req:routing}\textbf{VPN-interner Datenverkehr:} Nur die internen Netzbereiche der Abteilung Informatik sollen für Benutzer über das VPN erreichbar sein.
Das betrifft alle Sicherheitszonen außer dem Internet.
\item\label{req:traffic}\textbf{VPN-externer Datenverkehr:} Die Kommunikation zwischen VPN-Client und VPN-Server soll authentisiert und vertraulich stattfinden.
\item\label{req:users}\textbf{Benutzer:} Der VPN-Dienst soll von autorisierten Mitarbeitern und Studenten aus der Abteilung Informatik benutzt werden können.
Die Benutzer des VPN-Dienst sollen durch die Administratoren des VPN-Dienst einfach verwaltet werden können.
\item\label{req:serveros}\textbf{Betrieb des VPN-Servers:} Die Serverkomponente des VPN-Dienst soll auf einer aktuellen Version von Debian (9 oder höher) betrieben werden.
\item\label{req:clientos}\textbf{Betrieb der VPN-Clients:} Die VPN-Clientsoftware soll für aktuelle Versionen gängiger Betriebssysteme zur Verfügung stehen.
\item\label{req:logging}\textbf{Betriebsprotokoll:} Während des Betrieb des VPN-Dienst sollen keine Daten protokolliert werden, die Rückschlüsse auf das Benutzerverhalten zulassen. Im Rahmen einer laufenden Fehlersuche soll es möglich sein, mehr Daten zu protokollieren.
\item\label{req:finance}\textbf{Finanzieller Rahmen:} Es stehen keine finanziellen Mittel für den Erwerb einer VPN-Lösung zur Verfügung.
\end{enumerate}
Anhand der Anforderungen~\ref{req:dualstack} bis \ref{req:finance} werden vorhandene Programme ermittelt, die sich als Kandidat zur Umsetzung des VPN-Dienstes eignen.
Aufgrund des finanziellen Rahmens (\ref{req:finance}) kommt nur kostenfreie Software in Frage, deren Serverkomponente mit aktuellem Debian (\ref{req:serveros}) kompatibel ist.
Die Vorgabe von vertraulicher und authentisierter Kommunikation zwischen VPN-Client und VPN-Server (\ref{req:traffic}) impliziert, dass in der gesuchten Software Algorithmen zum Verschlüsseln und Signieren von Daten verwendet werden.
Jedermann kann öffentlich lesbaren Quellcode auf mögliche Sicherheitslücken untersuchen; dadurch erhöht sich die Wahrscheinlichkeit bestehende Sicherheitslücken zu finden.
Außerdem kann vermutet werden, dass gefundene und behobene Sicherheitslücken besser kommuniziert werden, da alle Änderungen am Quellcode ohnehin sichtbar sind.
Das wirkt sich auch auf Reaktionszeiten der Software-Distributoren aus: Entsprechend aktualisierte Softwarepakete stehen in der Regel zeitnah bereit und können sofort installiert werden.
Weiterhin soll die gesuchte Software IPv4 und IPv6 unterstützen (\ref{req:dualstack}), die Routingtabellen der VPN-Clients (\ref{req:routing}) anpassen können und in Bezug auf Protokollierung (\ref{req:logging}) konfigurierbar sein.
Ausgangspunkt für die Suche nach passender VPN-Software ist die Wahl der Serverkomponente: Sie soll quelloffen sein und auf einem Server mit aktuellem Debian eingesetzt werden können.
Deshalb sind die Debian-Paketquellen die erste Anlaufstelle für die Suche.
Durch die Nutzung der Paketquellen ist das Installieren von Sicherheitsaktualisierungen über den Debian-Paketmanager möglich.
Arbeitsschritte wie das Anpassen und Kompilieren des Quellcodes, sowie Tests und das Paketieren der Software werden von den Verwaltern der Debian-Pakete ausgeführt.
Um den Wartungsaufwand des VPN-Servers zu reduzieren, kann die Installation von Updates durch den Debian-Paketmanager automatisiert werden\cite[][Kapitel 6.7 und 6.8]{book:debian}.
Somit muss der Systemadministrator lediglich Upgrades zur nächsthöheren Debian-Version durchführen, da dabei Anpassungen an der Systemkonfiguration notwendig werden.
Im Folgenden werden mögliche Software-Kandidaten aus den Debian-Paketquellen vorgestellt.
Strongswan\footnote{\url{https://wiki.strongswan.org/projects/strongswan/wiki/IntroductionTostrongSwan},\\zuletzt abgerufen am 18.07.2018} ist eine quelloffene, modular aufgebaute Software, die unter den in \ref{req:serveros} und \ref{req:clientos} genannten Betriebssystemen lauffähig ist.
Sie kann verwendet werden, um in Kombination mit IPsec-fähigen Betriebssystem-Kerneln geschützte Verbindungen zwischen zwei oder mehr Computern einzurichten.
Strongswan wird unter quelloffen der Lizenz GPLv2 verbreitet\footnote{\url{https://wiki.strongswan.org/projects/strongswan/wiki/Contributions},\\ zuletzt abgerufen am 04.09.2018}.
Das beinhaltet unter anderem Vertraulichkeit übertragener Daten durch den Einsatz von Verschlüsselung, Authentisierung von Paketen durch Prüfung von Prüfsummen, und Schutz vor Replay-Angriffen\cite[Vergleich][Kapitel 2.1]{RFC4301}.
Das Protokoll \enquote{IP Authentication Header} (AH) ist in \cite[][]{RFC4302} definiert und ermöglicht den Versand von authentisierbaren Paketen an eine Gegenstelle.
Vor dem Versand wird über den Inhalt der beim Transport unveränderlichen Felder des IP-Pakets eine Prüf\-sum\-me gebildet.
Die Gegenstelle kann die Prüfsumme des empfangenen Pakets berechnen und mit der im Paket enthaltenen Prüfsumme abgleichen\cite[Siehe][Kapitel 3.3.3]{RFC4302}.
Die Funktion zur Berechnung der Prüfsumme wird nicht explizit definiert und kann daher anhand der zur Zeit aktuellen Vorgaben\cite[definiert in][]{RFC8221} gewählt werden.
Abhängig von der gewählten Funktion fließen bereits im Vorfeld ausgehandelte gemeinsame Geheimnisse oder Signaturalgorithmen in die Berechnung der Prüfsumme ein, sodass eine korrekte Prüfsumme ein Paket authentisiert.
Das Protokoll \enquote{IP Encapsulating Security Payload} (ESP) ist in \cite[][]{RFC4303} definiert und ermöglicht den Versand von Paketen mit vertraulichen Inhalten an eine Gegenstelle.
Ähnlich wie bei dem AH-Protokoll ist auch im ESP-Protokoll die Authentisierung von Paketen mit einer Prüfsumme vorgesehen\cite[Siehe][Kapitel 2.8]{RFC4303}.
Da die Sender- und Empfängeradressen der IP-Pakete hierbei nicht verändert wird, kann dieser Modus nur für direkte Ende-zu-Ende-Kommunikation verwendet werden.
Im Tunnelmodus werden die IP-Paketen selbst in AH- beziehungsweise ESP-Pakete gekapselt.
Im Anschluss werden die AH- beziehungsweise ESP-Pakete dann in neue IP-Pakete gekapselt, deren Sender- und Empfängeradressen sich von denen des inneren IP-Paketes unterscheiden dürfen.
Die Protokolle AH und ESP definieren selbst kein Verfahren zum Aushandeln von verwendeten Prüfsummenfunktionen, kryptografischen Algorithmen oder allgemeiner Konfigurationsparameter.
Auch der Austausch gemeinsamer Geheimnisse beziehungsweise Schlüsselmaterial wird nicht definiert.
Diese Aufgabe übernimmt Strongswan als IKEv2-Dienst.
Strongswan implementiert das Protokoll IKEv2\footnote{Internet Key Exchange Protokoll Version~2, definiert in \cite[][]{RFC7296}} und kann darüber authentisiert und verschlüsselt mit IKEv2-Gegenstellen kommunizieren.
Dabei werden mit der Gegenstelle Schlüssel- und Konfigurationsparameter ausgehandelt beziehungsweise ausgetauscht, anhand derer Strongswan IPsec-Verbindungen im Kernel des Host-Betriebssystems konfigurieren kann.
Die Verarbeitung des durch IPsec geschützten Da\-ten\-ver\-kehrs über die Protokolle AH oder ESP wird jedoch direkt im IPsec-Stack des Kernels abgewickelt.
OpenVPN ist eine quelloffene Software zur Einrichtung von VPNs in Peer-to-Peer oder Client-Server-Architektur\cite[][Abschnitt \enquote{Server Mode}]{man:openvpn}.
Sie ist unter den in \ref{req:serveros} und \ref{req:clientos} genannten Betriebssystemen lauffähig und wird quelloffen unter der GPLv2-Lizenz verbreitet.
Des Weiteren läuft es vollständig im Benutzerkontext und unterstützt nach dem Programmstart den Wechsel in einen nicht-privilegierten Benutzerkontext\cite[Siehe][\texttt{--user}]{man:openvpn}, um im Fall eines erfolgreichen Angriffs den potentiellen Schaden zu begrenzen.
Für lokal ausgeführte Programme entspricht der Einsatz von OpenVPN der Installation einer zusätzlichen Netzwerkkarte im lokalen Rechner - gegebenenfalls müssen die neuen IP-Adressen der virtuellen Netzwerkkarte berücksichtigt werden.
Die Kommunikation zwischen OpenVPN-Client und -Server enthält zwei Kanäle: Einen Datenkanal und einen Kontrollkanal\cite[][Abschnitt \enquote{TLS Mode Options}]{man:openvpn}.
Über ihn werden Konfigurationsparameter übertragen\cite[][\texttt{--pull}]{man:openvpn} und überprüft, ob der jeweils andere OpenVPN-Prozess aktiv ist\cite[][\texttt{--keepalive}]{man:openvpn}.
Im \enquote{TLS Mode} wird über den Kontrollkanal eine TLS-Sitzung aufgebaut, in der Chiffren und Schlüssel ausgetauscht werden, mit denen der Datenkanal geschützt werden soll.
Dadurch ist die Authentisierung von Client und Server mit X.509-Public-Key-Zertifikaten\footnote{X.509-Public-Key-Zertifikate werden oft als \enquote{SSL-Zertifikate} bezeichnet} möglich.
Zusätzlich kann Perfect Forward Secrecy durch Einsatz des Diffie-Hellman-Verfahren für den Schlüsselaustausch erreicht werden\cite[Vergleich][Abschnitt \enquote{TLS Mode Options}]{man:openvpn}.
Im \enquote{Static Key Mode} wird beiden Prozessen beim Start ein zuvor geteiltes gemeinsames Geheimnis als Parameter gegeben, mit dem der Datenkanal zwischen den beiden Prozessen symmetrisch verschlüsselt wird\cite[][\texttt{--secret}]{man:openvpn}.
Alle kryptografische Operationen zur Verarbeitung des VPN-Datenverkehrs, sowie zur Authentisierung werden nur in OpenVPN durchgeführt, welches diese zu großen Teilen an die ebenfalls quelloffene Bibliothek openssl auslagert\cite[][Abschnitt \enquote{Introduction}]{man:openvpn}.
Die zuvor vorgestellten VPN-Softwarelösungen werden nun in den folgenden Kategorien miteinander verglichen, um im Anschluss die Software zu ermitteln, mit der das Vorhaben dieser Masterarbeit umgesetzt wird.
Strongswan kommuniziert mit kompatiblen Gegenstellen über das IKEv2-Protokoll, welches über UDP auf Port~500 (bei stattfindender Network Address Translation (NAT) auf Port~4500) übertragen wird.
Der durch IPsec geschützte Datenverkehr lässt sich daran erkennen, dass in den übertragenen IPv4- beziehungsweise IPv6-Paketen das Protokoll AH oder ESP enthalten ist.
Für die Freigabe von IPsec-Datenverkehr in einer Firewall sind somit mehrere Regeln notwendig, während die Freigabe von OpenVPN-Verkehr über UDP-Port~1194 deutlich übersichtlicher ausfällt.
Je nach Plattform stehen unterschiedliche grafische Oberflächen zur Verfügung, welche die Benutzung von OpenVPN zusätzlich erleichtern können: Für Linux kann NetworkManager verwendet werden, unter Windows kann OpenVPN-Gui genutzt werden, und unter Mac OS steht Tunnelblick zur Verfügung.
Strongswan hingegen muss für die Benutzung unter Windows zuvor vom Anwender mit Hilfe einer MinGW\footnote{Minimalist GNU for Windows, siehe \url{http://www.mingw.org}}-W64-Umgebung kompiliert werden\cite{strongswan:onwindows}.
Die Mac-Version kann über \texttt{brew}\footnote{\enquote{The missing package manager for macOS}, siehe \url{https://brew.sh}} bezogen werden\cite{strongswan:onmac}.
Wurde Strongswan auf den jeweiligen Clientbetriebssystemen erfolgreich installiert, so läuft die Konfiguration wie bei OpenVPN auf allen Betriebssystemen nach den selben Prinzipien ab.
Da unter Mac OS und Windows bereits IPsec-Funktionalität durch das Betriebssystem zur Verfügung gestellt wird, wird seitens Strongswan keine grafische Oberfläche entwickelt.
Unter Linux kann NetworkManager als grafische Oberfläche für Strongswan verwendet werden.
In der Kategorie Benutzerfreundlichkeit schneidet OpenVPN durch die Bereitstellung von vorkompilierter Software und die Verfügbarkeit grafischer Oberflächen besser als Strongswan ab.
Der Quellcode von OpenVPN ist inklusive der durch OpenVPN verwendeten Bibliotheken, wie zum Beispiel OpenSSL, öffentlich verfügbar.
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.
Sowohl OpenVPN als auch Strongswan sind für alle in \ref{req:clientos} und \ref{req:serveros} genannten Betriebssysteme verfügbar.
Sollten Sicherheitslücken innerhalb von beiden Softwareprojekten bekannt werden, können diese in vergleichbarer Zeit geschlossen werden und auf Client- und Serverrechnern gleichermaßen installiert 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.
Auch der Kernel des eingesetzten Betriebssystems wird zur Umsetzung eines solchen VPN benötigt.
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.
Insgesamt kann für VPN 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}.
Somit muss entschieden werden, ob die Authentisierung von VPN-Benutzern über Zertifikate oder über Zugangsdaten in Form von Benutzername und Passwort durchgeführt werden soll.
Die Verwendung von Zugangsdaten zur Authentisierung bietet dem Benutzer einen hohen Komfort:
Die Eingabe einer Kombination aus Benutzername und Passwort erfordert keine individuellen Konfigurationen am OpenVPN-Client.
Zusätzlich ist denkbar, dass bereits existierende Zugangsdaten - wie zum Beispiel das Hochschulkonto des Benutzers - zur Authentisierung verwendet weden könnte.
Eine Benutzerverwaltung auf dieser Form der Authentisierung erfordert nur wenige Handgriffe durch den Systemadministrator, da eine Liste berechtigter VPN-Benutzer auf Basis aktuell zur Verfügung stehender Verzeichnisdienste automatisch generiert werden könnte.
Alternativ wäre auch die manuelle Pflege einer Whitelist von Benutzerkonten denkbar, die in einem bestehenden Verzeichnisdienst bereits existieren.
Ein weiterer Vorteil bestünde darin, dass man sich auf den Aktivitätsstatus der Benutzerkonten in bestehenden Verzeichnisdiensten verlassen kann um Benutzer auszuschließen, die keine Mitgliedschaft an der Hochschule Hannover besitzen.
Die genannten Vorteile ziehen allerdings auch einige Nachteile mit sich, die nicht außer Acht gelassen werden dürfen:
Ein VPN-Dienst, der Benutzer über eingegebene Zugangsdaten authentisiert kann zu einem Ziel für einen Brute-Force-Angriff werden.
Kompromittierte Zugangsdaten können in diesem Fall mindestens für den Missbrauch des VPN-Dienst verwendet werden.
Zusätzlich ist je nach konkreter Implementierung denkbar, dass kompromittierte Zugangsdaten auch für den Missbrauch anderer Systeme verwendet werden können, für die diese Zugangsdaten gültig sind.
Das Schadenspotential umfasst in diesem Fall zusätzlich zu über den VPN-Zugang begangene Straftaten auch das Ausspähen von persönlichen Daten, die über die kompromittierten Zugangsdaten zugänglich sind.
Ein weiterer Nachteil ergibt sich dadurch, dass Zugangsdaten zum Zweck der Benutzerauthentisierung durch OpenVPN-Client und -Server, sowie zusätzlich auf dem Server eingebundene Authentisierungsprogramme verarbeitet und übertragen werden müssen.
Die involvierten Programme erhöhen die Menge des Quellcodes, der aufgrund seiner Position als Angriffsfläche keine Schwachstellen enthalten darf.
Da die Abwesenheit von Schwachstellen in Quellcode nicht garantiert werden kann, ergibt sich der Verwendung von Zugangsdaten zur Benutzerauthentisierung ein erhöhtes Bedrohungsrisiko.
Die Authentisierung von Benutzern anhand von Zertifikaten erfordert den Aufbau und die Verwaltung einer \textit{Public-Key-Infrastructure} (PKI) und bringt somit erst einmal eine Reihe Nachteile mit sich:
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 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.
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.
Aufgrund der Länge der verwendeten Schlüssel ist es mit herkömmlichen Brute-Force-Angriffen nicht in für Angreifer akzeptabler Zeit möglich, diese zu erraten.
Auch das Stehlen von privaten Schlüsseln kann einem Angreifer weniger attraktiv gemacht werden, wenn man den privaten Schlüssel nur in verschlüsselter Form ablegt.
Sollte ein privater Schlüssel dennoch kompromittiert werden, besteht jederzeit die Möglichkeit, diesen durch eine Ergänzung der CRL von der CA unbrauchbar zu machen.
Zusätzlich gilt, dass ein kompromittierter Schlüssel lediglich zur Benutzung des VPN-Dienst berechtigt.
Dadurch reduziert sich der potentielle Schaden, den ein Angreifer mit einem kompromittierten Schlüssel anrichten könnte.
Insgesamt bringt die Authentisierung von Benutzern mit Zertifikaten im Vergleich zur Authentisierung auf Basis von Zugangsdaten einen höheren Arbeitsaufwand mit sich.
Dafür besteht ein reduziertes Bedrohungsrisiko bei kompromittierten privaten Schlüsseln als im Vergleich zu kompromittierten Zugangsdaten, welche gegebenenfalls für weitere Dienste gültig sein können.
Außerdem ist die Angriffsfläche beim Einsatz von Zertifikaten geringer, da kein zusätzlicher Code in das System integriert wird, durch das Zugangsdaten verarbeitet würden.
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.
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.
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 vereinfachter Konfiguration und erleichterter Bedienung für CA-Betreiber und Benutzer im Vergleich zur manuellen Umsetzung einer CA wird entschieden, EasyRSA für den Aufbau der Zertifizierungsstelle zu verwenden.
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.
Die zum aktuellen Zeitpunkt (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 Elliptic-Curve-Kryptosystems, 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}}.
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.
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}}, die im Dezember 2016 veröffentlicht wurde\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.
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.
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 den 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}.
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 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.
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 eine gültige CRL immer zur Verfügung steht.
Grund\-sätz\-lich 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{Betriebskonzept für die 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 Abschnitt~\ref{sct: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.
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.
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.
In diesem Kapitel wird gezeigt, wie der Server für den VPN-Dienst installiert und konfiguriert wird. Wie in Abschnitt~\ref{sct:requirements} bereits geklärt, wird laut Anforderung \ref{req:serveros} Debian~9 als Betriebssystem verwendet.
Die Konfiguration des Betriebssystems erfolgt dabei nach den Vorgaben des IT-Teams, damit der Dienst ohne zusätzliche Arbeiten als Produktivsystem übernommen werden kann.
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 ein Paar aus je einer IPv4- und IPv6-Adresse kann der phyische Server angesprochen werden, um zum Beispiel für administrative Aufgaben eine SSH-Sitzung zu dem Server aufzubauen.
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 Adressen zugewiesen bekommen können.
Für IPv4 wurde der private Adressbereich \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.
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.
Um bei einem Defekt von Server~A ein Failover auf den Server~B durchzuführen, 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 muss lediglich ein weiteres IPv6-Netz für VPN-Clients bereitgestellt werden und neue IP-Dienstadressen für einen weiteren VPN-Dienst vergeben werden.
Damit ist ein Parallelbetrieb von zwei OpenVPN-Diensten möglich, die sich in der Konfiguration nur durch ihre IP-Dienst\-adresse und das verwendete IPv6-Netz für VPN-Clients unterscheiden.
In der OpenVPN-Client\-kon\-fi\-gu\-ra\-tion 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 Absprache mit dem Erstprüfer dieser Arbeit wurde die folgende Firewall-Richtlinie für den VPN-Server geplant und wird unter Nutzung von \texttt{iptables} umgesetzt.
Diese lokale Richtlinie wird durch die Firewall der Abteilung Informatik ergänzt.
Zuerst werden allgemeine Regeln definiert:
Als Standardverhalten wird festgelegt, dass alle Pakete verworfen werden.
Datenverkehr aus oder in die lokale Loopback-Schnittstelle wird zugelassen.
Datenverkehr mit den Protokollen ICMP und ICMPv6 wird zugelassen.
SSH-Zugriffe auf den Server über TCP-Port~22 werden zugelassen.
UDP-Pakete an den OpenVPN-Dienst auf Port~1194 werden zugelassen.
Vom Server ausgehender Datenverkehr wird grundsätzlich zugelassen, um die Grundfunktionen (beispielsweise: Installieren von Updates, DNS, NTP, \dots) des Betriebssystems zu ermöglichen.
Im Anschluss werden Regeln für die Behandlung des VPN-Datenverkehrs definiert:
Bei IPv4-Verkehr vom VPN-Netz zum Netz der Abteilung Informatik wird via NAT die Absenderadresse auf die IPv4-Dienstadresse übersetzt.
Datenverkehr, der aus dem VPN-Netz wieder in das VPN-Netz geroutet wird, soll verworfen werden.
Datenverkehr aus dem VPN-Netz über TCP oder UDP auf Port~2049 (NFS) wird verworfen.
Jeglicher weiterer Datenverkehr aus dem VPN-Netz heraus ist gestattet.
Laut Anforderung~\ref{req:dualstack} aus Abschnitt~\ref{sct:requirements} soll der VPN-Dienst über IPv4 und IPv6 aus dem Internet erreichbar sein.
Als Ausgangspunkt dafür wird der DNS-Name des VPN-Dienst verwendet, der auf die IPv4- und IPv6-Dienstadresse zeigt.
\textbf{Server}
In der Serverkonfiguration reichen die ersten drei Zeilen aus, um über IPv4 und IPv6 auf UDP-Port~1194 den VPN-Dienst anzubieten:
\begin{lstlisting}
port 1194
proto udp
proto udp6
multihome
\end{lstlisting}
OpenVPN beantwortet damit Anfragen für alle auf dem Server konfigurierten IP-Adressen.
Da auf dem Server neben den Dienstadressen auch die Maschinenadressen existieren, wird OpenVPN mit \texttt{multihome} angewiesen, eingehende Pakete mit der IP-Adresse zu beantworten, an die diese Pakete gerichtet waren.
\textbf{Client}
In der Clientkonfiguration wird OpenVPN mit \texttt{nobind} angewiesen, den Clientsocket nicht an eine lokale Adresse zu binden. Die Angaben \texttt{port} und \texttt{proto} legen fest, wie der VPN-Server zu erreichen ist.
Über \texttt{remote} wird dann der zu verwendende VPN-Server explizit genannt.
Die Erreichbarkeit über IPv4 und IPv6 ergibt sich aus den im DNS eingetragenen IP-Adressen.
Das UDP-Protokoll 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.
Die vom IT-Team vergebenen IP-Adressbereiche für VPN-Clients werden durch den OpenVPN-Server an die Clients vergeben. In der Clientkonfiguration sind keine Anweisungen notwendig.
Mit \texttt{topology subnet} wird festgelegt, dass die IPv4-Adressvergabe so durchgeführt werden soll, als wären alle VPN-Clients mit dem VPN-Server in einem Subnetz.
Anschließend werden mit \texttt{server} und \texttt{server-ipv6} die IP-Netze festgelegt, die an die VPN-Clients vergeben werden sollen.
In der Serverkonfiguration werden \texttt{push}-Anweisungen eingetragen, über die IPv4- und IPv6-Routen an die VPN-Clients bekannt gegeben werden können.
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.
Auf Kompression wird verzichtet, da es bereits am 03.06.2018 Hinweise in der Manpage hinzugefügt wurden\footnote{\url{https://github.com/OpenVPN/openvpn/commit/6795a5f3d55f658fc1a28eb9f3b11d1217e3329c}}, in denen vor der Verwendung von Kompression gewarnt wird.
Zum Vergleich: OpenVPN Version~2.4.6 wurde von den Entwicklern am 19.04.2018\footnote{\url{https://github.com/OpenVPN/openvpn/releases/tag/v2.4.6}} freigegeben.
Auf der DEFCON~26 wird mit \enquote{VORACLE} ein in dieser Richtung 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}}.
Eine Nutzung von ECDHE-Verfahren fällt leider Flach\footnote{Es existiert ein Problem in Kombination mit OpenSSL~1.1.x. Siehe \url{https://community.openvpn.net/openvpn/ticket/963}}.
Dateiangaben, die TLS-Rolle, welche Sorte von Zertifikat erwartet wird, gegen welches CA das präsentierte Zertifikat geprüft wird.
\paragraph{Sitzungsparameter}
Mit keepalive wird ständig geprüft, ob der Sitzungspartner noch da ist.
Das connect-timeout von 20 Sekunden sollte ausreichen und macht Verbindungsprobleme schneller sichtbar.
explicit-exit-notify wird verwendet, um dem Sitzungspartner das Ende der Sitzung mitzuteilen - damit kann ein neuer Sitzungsaufbau früher wieder versucht werden.
duplicate-cn, um mehr als eine gleichzeitige Sitzung pro Benutzer zu erlauben
Der Einsatz von IPsec ist für die Umsetzung eines VPN in das Netzwerk einer Fakultätsabteilung ein Schuss mit einer Kanone auf Spatzen.
In großen Umgebungen eines Konzerns kann die Situation schon etwas anders aussehen: Sofern die IT-Landschaft in einem Konzern homogen aufgestellt ist, könnten auf IPsec spezialisierte Administratoren über Konfigurationsmanagement wie zum Beispiel das Active Directory von Microsoft eine Steigerung der Netzwerksicherheit erzielen oder Außendienstmitarbeitern einen nahtlosen Anschluss an das Firmennetzwerk bieten.
Es gibt da noch etwas mit dem schönen Namen Wireguard. Mit gewollt geringer Komplexität und einem aktuellen Umfang von etwa 4000 Zeilen Code ist es eine würdige Alternative zu IPsec.
Auch OpenVPN in Version~3 ist schon in der Beta - das könnte man auch im Auge behalten.
