mirror of https://github.com/2martens/uni.git
376 lines
43 KiB
TeX
376 lines
43 KiB
TeX
%!TEX encoding = UTF-8 Unicode
|
|
\documentclass[12pt]{scrartcl}
|
|
\usepackage[utf8]{inputenc} % Unicode funktioniert unter Windows, Linux und Mac
|
|
\usepackage[T1]{fontenc}
|
|
\usepackage{times}
|
|
\usepackage[ngerman]{babel}
|
|
\usepackage[german]{fancyref}
|
|
\usepackage{csquotes}
|
|
\usepackage[
|
|
backend=biber,
|
|
bibstyle=ieee,
|
|
citestyle=ieee
|
|
]{biblatex}
|
|
%\usepackage{ngerman}
|
|
\usepackage{graphicx}
|
|
\usepackage[hidelinks]{hyperref}\urlstyle{rm}
|
|
\usepackage{times}
|
|
\usepackage[scaled]{helvet}
|
|
\usepackage{a4wide}
|
|
\usepackage{rotating}
|
|
\usepackage{listings}\lstset{breaklines=true,breakatwhitespace=true,frame=leftline,captionpos=b,xleftmargin=6ex,tabsize=4,numbers=left,numberstyle=\ttfamily\footnotesize,basicstyle=\ttfamily\footnotesize}
|
|
\sloppy
|
|
\setlength{\parindent}{0em}
|
|
\setlength{\parskip}{1.2ex plus 0.5ex minus 0.5ex}
|
|
\pagestyle{plain}
|
|
\addbibresource{sem.bib}
|
|
|
|
\begin{document}
|
|
\hyphenation{in-te-res-sant in-te-res-san-te}
|
|
|
|
\newpage
|
|
\thispagestyle{empty}
|
|
\begin{center}\Large
|
|
Universität Hamburg \par
|
|
Fachbereich Informatik
|
|
\vfill
|
|
Seminararbeit
|
|
\vfill
|
|
{\Large\textsf{\textbf{Vergleich von IPsec und OpenVPN}}\par}
|
|
\vfill
|
|
von
|
|
\par\bigskip
|
|
Mustafa Eris, Jim Martens, Benjamin Scholz \par
|
|
Betreuer: Hannes Federrath \par
|
|
%Matrikelnummern 6420323 \par
|
|
%Studiengang BSc. Informatik
|
|
\end{center}
|
|
|
|
\newpage
|
|
\section*{Zusammenfassung}
|
|
IPsec VPNs und OpenVPN bzw. TLS-basierte VPNs sind weit verbreitet. Dennoch gibt es kaum einen Vergleich zwischen diesen beiden Technologien. Im Rahmen dieser Seminararbeit haben wir daher diesen Vergleich unternommen und kommen zu dem Ergebnis, dass sowohl IPsec als auch OpenVPN ihre jeweiligen Stärken und Schwächen haben. Es gibt daher keinen klaren Gewinner des Vergleichs.
|
|
|
|
Im Bereich der Performance schneidet IPsec besser ab, da IPsec näher am Kernel angesiedelt ist. Dafür ist OpenVPN besser geeignet für Remoteverbindungen zwischen einem Computer und einem Netzwerk, da die Verschlüsselung von Anwendung (z.B. Browser) bis Anwendung (z.B. Webserver) stattfindet, währenddessen bei IPsec der Netzwerkverkehr auf den höheren Schichten im OSI-Referenzmodell unverschlüsselt übertragen wird.
|
|
|
|
Entgegen der weit verbreiteten Vorurteile hat IPsec nicht mehr ein so großes Kompatibilitätsproblem, wie zu den Anfangszeiten. Allerdings gibt es für IPsec noch Aufholpotential gegenüber OpenVPN.
|
|
|
|
\newpage
|
|
\tableofcontents
|
|
|
|
\newpage
|
|
\section{Vorbemerkung}
|
|
Mit den Enthüllungen von Edward Snowden hat sichere Kommunikation eine ganz neue Bedeutung bekommen. War es vorher hauptsächlich für Informatiker und Unternehmen von Interesse, so ist sichere Kommunikation mittlerweile im Bewusstsein der meisten Menschen angekommen. Doch wie sieht sichere Kommunikation überhaupt aus? Eine Möglichkeit ist die Verschlüsselung von E-Mails zur Sicherung der darin enthaltenen Korrespondenz. Dieses zugegeben sehr interessante Themengebiet wird uns aber in diesem Paper nicht beschäftigen.
|
|
|
|
Stattdessen schauen wir uns die sichere Kommunikation zwischen zwei Rechnern an. Diese ist nämlich im Gegensatz zu E-Mail-Verschlüsselung nicht so offensichtlich und kann auf unterschiedliche Weise realisiert werden. Bei räumlich nicht weit entfernten Rechnern kann die Kommunikation über ein LAN-Kabel und nicht über das Internet erfolgen. Damit ist die Kommunikation solange sicher, wie die beiden Rechner und die Verbindung physisch sicher sind.
|
|
|
|
Doch in den meisten Fällen stehen die beiden Rechner so weit voneinander entfernt, dass die Kommunikation über das Internet läuft. Doch spätestens am Router haben wir keine Kontrolle mehr über die Verbindungsstrecke und die Gegenstelle hat erst wieder am dem Router eine Kontrolle über die Verbindung. Wie also die unkontrollierbare Zwischenstrecke nutzen und gleichzeitig sicher kommunizieren? Geht das überhaupt? Die Lösung ist, wie bei E-Mail-Verschlüsselung, eine Ende-zu-Ende-Verschlüsselung, wobei das Ende hier nicht zwei Mailprogramme sind, sondern zwei Rechner.
|
|
|
|
Eine solche durch Verschlüsselung gesicherte Kommunikation zwischen zwei Rechnern über ein unsicheres Zwischennetz wird auch Virtual Private Network oder kurz VPN genannt. In diesem Paper werden wir uns mit zwei VPN-Lösungen beschäftigen: IPsec und OpenVPN. Im nächsten Abschnitt werden zunächst ein paar Grundbegriffe geklärt, um dann genauer in IPsec und anschließend in OpenVPN einzusteigen. Diesen beiden Vorstellungen folgt ein Vergleich, um dann mit den Schlussbemerkungen zu schließen.
|
|
|
|
\section{Grundlagen}
|
|
Ein VPN ist eine gesicherte Kommunikationsverbindung zwischen zwei privaten Netzwerken. Das in der Vorbemerkung genannte Beispiel mit den zwei Rechnern ist eine Verkürzung, wenngleich sie korrekt ist. Der Internetzugang wird in den allermeisten Fällen durch Router sichergestellt. Diese sind selber kleine Computer und stehen im Internet repräsentativ für das Netzwerk, dem sie angehören. Daher passt dann auch wieder das in der Vorbemerkung genannte Beispiel mit den zwei Rechnern.
|
|
|
|
Die VPN-Verbindung zwischen zwei privaten Netzwerken funktioniert in einer Weise, dass beide Netzwerke so miteinander verbunden werden, dass sie für Rechner in einer der beiden Netze wie ein großes privates Netz wirken. Daher ist auch der Zugriff auf die Rechner des anderen Netzes mit ihren privaten IP-Adressen (Adressen aus dem nicht-öffentlichen Bereich, meistens mit 192.168 beginnend) möglich. Dabei ist der Weg, den die IP-Pakete von einem Netz zum anderen nehmen, für die Rechner auf beiden Seiten irrelevant.
|
|
|
|
VPNs werden für verschiedenste Dinge eingesetzt. Bei Unternehmen kommen sie häufig zum Einsatz, um Inhalte aus dem Intranet auch von zu Hause oder unterwegs aus abrufen zu können. Diese Verwendung macht sich zunutze, dass die IP-Pakete mit der IP-Adresse der Endstelle des VPNs unterwegs sind (in diesem Fall der Router im Netzwerk des Unternehmens. Für z.B. den Webserver scheint es so, als ob man sich innerhalb des Netzwerks befindet, obgleich man physisch einige hundert Kilometer entfernt sein kann.
|
|
|
|
Diese gleiche Eigenschaft wird auch genutzt, um IP-Sperren zu umgehen. Viele Streamingdienste bieten unterschiedliche Produkte je geographischer Region an. Die Separierung geschieht durch die Kontrolle der IP-Adressräume, da jede geographische Region gewisse IP-Adressräume zur Verfügung hat. Mithilfe des VPNs kann nun bspw. von Europa aus eine Verbindung in die USA aufgebaut werden, sodass auf die USA beschränkte Angebote plötzlich sichtbar werden. Eine verwandte Anwendung ist die Umgehung von staatlichen Zensurmaßnahmen, in dem durch eine VPN-Verbindung aus dem abgeschotteten Netz "`ausgebrochen"' werden kann. Allerdings hängt der Erfolg davon stark von den staatlichen Gegenmaßnahmen ab. Ist VPN-Verkehr als solcher zu erkennen, dann kann dieser gezielt geblockt werden, auch wenn der Inhalt nicht erkannt wird.
|
|
|
|
Es ist erkennbar, dass es eine Reihe von Anwendungsmöglichkeiten gibt. Die konkrete Umsetzung der VPN-Verbindung hängt jedoch stark von der verwendeten Technologie, in unserem Fall IPsec und OpenVPN ab. Im Folgenden daher eine Vorstellung von IPsec und OpenVPN.
|
|
|
|
\section{IPsec}
|
|
%TODO Referenzen
|
|
\subsection{Entstehungsgeschichte}
|
|
IPsec ist unter der Aufsicht eines Komitees entstanden. Diese Vorgehensweise wurde dabei gezwungenermaßen auferlegt und erschwerte nach Ansicht vieler Mitwirkender die Arbeit erheblich. \footnote{Ferguson, Niels, and Bruce Schneier. ``A cryptographic evaluation of IPsec."' Counterpane Internet Security, Inc 3031 (2000).}
|
|
|
|
Die Entstehungsweise führte dazu, dass IPsec unnötig kompliziert wurde. Die einen Mitglieder wollten die eine Lösung implementieren und andere plädierten für eine andere Lösung, was dazu führte, dass beide Lösungen implementiert wurden. Dies geht jedoch zu Lasten der Nutzbarkeit. Zu viele Optionen führen nicht nur zur Verwirrung und Komplizierung der Implementation von IPsec bei den Nutzern, es kann vor allem auch zu Sicherheitslücken führen. Experten bemängelten diese Komplexität.
|
|
|
|
Die erste Version von IPsec ist 1995\cite{RFC1825} spezifiziert worden. Doch über die Jahre ist der Standard immer weiter entwickelt worden und so gibt es eine zweite Version aus 1998\cite{RFC2401} und eine dritte aus 2005\cite{RFC4301}. Diese gelten zwar allgemein als V2 und V3, jedoch sind verschiedene Aspekte von IPsec in verschiedenen sogenannten ``Request for Comments"', kurz RFC, spezifiziert. So gibt es beispielsweise ein RFC, dass sich allgemein auf IPsec bezieht, aktuell RFC 4301 aus 2005, und es gibt beispielsweise ein RFC, dass sich auf die zu verwendenden Verschlüsselungsalgorithmen bezieht, aktuell RFC 7321 bereits aus 2014. So ist gewährleistet, dass IPsec weiterhin auf dem neuesten Stand gehalten werden kann, ohne dass man jedes mal die komplette Spezifikation überarbeiten muss.
|
|
|
|
Die folgenden RFCs sind für IPsec relevant:
|
|
\begin{itemize}
|
|
\item RFC 4301: Beschreibt den grundsätzlichen Aufbau von IPsec\cite{RFC4301}
|
|
\item RFC 4302: Beschreibt den Authentication Header (AH)\cite{RFC4302}
|
|
\item RFC 4303: Beschreibt Encapsulating Security Payload (ESP)\cite{RFC4303}
|
|
\item RFC 7321: Gibt vor welche Algorithmen für AH und ESP verwendet werden sollten\cite{RFC7321}
|
|
\item RFC 5996: Beschreibt das Internet Key Exchange Protocol Version 2 (IKEv2)\cite{RFC5996}
|
|
\item RFC 4307: Gibt vor welche Algorithmen für IKEv2 verwendet werden sollten\cite{RFC4307}
|
|
\end{itemize}
|
|
Es gibt noch viel mehr RFCs, die man IPsec zuordnen kann, doch dies sind die Wichtigsten. Im folgenden Abschnitt werden wir auf die technischen Aspekte von IPsec eingehen und die Themen der einzelnen RFCs näher betrachten.
|
|
|
|
\subsection{Technischer Aufbau}
|
|
\subsubsection{Tunnel Modus und Transport Modus}
|
|
IPsec kann in zwei verschiedenen Modi betrieben werden: Transport Modus oder Tunnel Modus. \cite{RFC4301}
|
|
|
|
Im Tunnel Modus werden die IP-Pakete als Nutzlast neuen Paketen mit anderen Headern übergeben. Dabei werden die Pakete jedoch von den einzelnen Gateways bearbeitet. Das bedeutet im Endeffekt, dass die Sicherheit nur von Gateway zu Gateway und nicht vom einem Ende zum anderen Ende gewährleistet ist. Der Vorteil davon ist, dass die Anwendung für den Nutzer transparent geschieht und beispielsweise vom Router übernommen werden kann.
|
|
|
|
Im Transport Modus ist die Sicherheit vom einen zum anderen Ende gewährleistet. Dabei werden die eigentlichen IP-Pakete beibehalten und einige sicherheitsrelevante Felder hinzugefügt.
|
|
|
|
\subsubsection{Authentication Header}
|
|
Der Authentication Header (kurz: AH) kann dazu verwendet werden, die Authentizität und Integrität von Daten zu gewährleisten und Replay-Angriffe abzuwehren. Er ist in RFC 4302 spezifiziert.\cite{RFC4302} Er muss jedoch im Gegensatz zur Alternative Encapsulating Security Payload (kurz: ESP) nicht von IPsec-Implementationen unterstützt werden.\cite{RFC4301} Der Grund hierfür ist, dass ESP neben dem was AH leistet, zusätzlich noch die Vertraulichkeit der Pakete sicherstellt. Der Authentication Header wird an die IP-Pakete angehängt und sieht wie folgendermaßen aus (entnommen aus \cite{RFC4302}):
|
|
|
|
\begin{addmargin}[-2em]{0em}
|
|
\begin{verbatim}
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Next Header | Payload Len | RESERVED |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Security Parameters Index (SPI) |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number Field |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
+ Integrity Check Value-ICV (variable) |
|
|
| |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
\end{verbatim}
|
|
\end{addmargin}
|
|
Das 8 Bit lange Feld "`Next Header"' gibt an welche Art Nutzdaten nach dem AH folgen. Eine 4 bedeutet zum Beispiel IPv4 und eine 41 IPv6. Das 8 Bit lange Feld "`Payload Length"' gibt die Anzahl an 32 Bit Worten - 2 im Authentication Header an. Das 16 Bit lange Feld "`Reserved"' ist reserviert, damit man es in Zukunft nutzen kann, falls es benötigt wird. Das 32 Bit lange Feld "`Security Parameters Index"' (SPI) enthält die verwendete Security Association, die beim Versenden des Paketes verwendet wurde. Die Security Association beschreibt dabei, welche Sicherheitsdienste verwendet wurden, damit der Empfänger das Paket verarbeiten kann.
|
|
|
|
Das 32 Bit lange Feld "`Sequence Number"' wird bei jedem versendeten Paket um 1 erhöht, um so Replay-Angriffe zu verhindern. Der Empfänger akzeptiert das Paket dabei nur, wenn die Sequence Number dabei in einem bestimmten Fenster liegt. Dieses Fenster ist daher vorhanden, da Pakete oft nicht in der selben Reihenfolge empfangen, wie sie versendet werden. Außerdem ist die Nummer mit einer MAC geschützt. Das heißt, wenn der Angreifer die Nummer ändert, dann stimmt der MAC nicht, und wenn er sie nicht ändert, dann fällt diese nicht mehr in das Fenster. Es gibt auch die Möglichkeit ein erweitertes 64 Bit langes Feld für die Sequence Number zu verwenden.
|
|
|
|
Das Feld "`Integrity Check Value"' (ICV) enthält den MAC-Wert. Da dieser je nach verwendetem Algorithmus unterschiedlich lang ist, hat das Feld ebenfalls eine Variable Länge, dessen Beschränkung allerdings ist, dass es ein Vielfaches von 32 Bit sein muss, und dass der komplette AH ebenfalls ein vielfaches von 32 Bit bei IPv4 und ein vielfaches von 64 Bit bei IPv6 sein muss. Der MAC-Wert wird zur Überprüfung der Authentizität der Daten verwendet, das heißt es wird überprüft, ob das Paket auch tatsächlich vom Absender und nicht von einem Angreifer stammt.
|
|
|
|
\subsubsection{Encapsulating Security Payload}
|
|
Die Alternative zum AH ist "`Encapsulating Security Payload"', kurz ESP. Wie schon erwähnt muss ESP von IPsec-Implementationen unterstützt werden. ESP ist in RFC 4303 spezifiziert.\cite{RFC4303}
|
|
ESP schützt auch wie AH die Integrität und Authentizität der Daten. Zusätzlich bietet es auch noch einen Schutz der Vertraulichkeit. Um dies zu erreichen können die Daten verschlüsselt werden. Der Aufbau von ESP ist wie folgt (entnommen aus \cite{RFC4303}):
|
|
|
|
\begin{addmargin}[-1em]{0em}
|
|
\begin{verbatim}
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Security Parameters Index (SPI) |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Payload Data* (variable) |
|
|
+ +
|
|
| |
|
|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| | Padding (0-255 bytes) |
|
|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| | Pad Length | Next Header |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Integrity Check Value-ICV (variable) |
|
|
+ +
|
|
| |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
\end{verbatim}
|
|
\end{addmargin}
|
|
Im Allgemeinen wird zwischen dem Header, der vor den Nutzdaten kommt, dem Trailer, welcher nach den Nutzdaten angelegt ist, und dem Feld zum Prüfen der Authentizität unterschieden. Das bedeutet, dass die Nutzdaten bei ESP von diesen Feldern umgeben sind.
|
|
|
|
Das 32 Bit lange Feld "`Security Parameters Index"' (SPI) wird genau wie beim AH verwendet. Das 32 Bit lange Feld "`Sequence Numbers"' ist ebenfalls sehr ähnlich zu dem entsprechenden Feld im AH, allerdings muss der Empfänger die Nummer ignorieren, wenn der Algorithmus zur Überprüfung der Integrität Null ist. Es gibt auch die Option zu einer Erweiterung zu einem 64 Bit langem Feld.
|
|
|
|
Das Feld "`Payload Data"' hat eine variable Länge. Es enthält die Nutzdaten des Paketes. Das Feld "`Padding"' ist 0 bis 255 Bytes lang und kann für verschiedene Zwecke verwendet werden. Es gibt einige Verschlüsselungsalgorithmen die nur Inhalte verschlüsseln können, deren Länge ein Vielfaches einer bestimmten Bit-Zahl ist. Mit dem Padding-Feld können die Nutzdaten entsprechend aufgefüllt werden, sodass diese Algorithmen angewendet werden können. Es ist als weitere Anwendungsmöglichkeit auch möglich die tatsächliche Länge einem Angreifer gegenüber zu verbergen. Davon wird allerdings im RFC 4303 abgeraten, da dies nicht effektiv genug ist und das optionale Feld "`TFC Padding"' dafür bereits vorgesehen ist.\cite{RFC4303} Jenes Feld ist anders als das normale Padding-Feld nicht auf 255 Bytes limitiert und kann so einen Angreifer, der die Verkehrsdaten analysiert, abwehren. Jedoch kann das Feld im Transport Modus nicht immer angewendet werden. Eine weitere Möglichkeit die Verkehrsdatenanalyse zu verhindern ist der Versand von dummy-Paketen, die keinen nützlichen Inhalt enthalten. Diese Tatsache ist aber nur für den Absender und Empfänger ersichtlich.
|
|
|
|
Das Feld "`Pad Length"' enthält die Länge des normalen Padding-Feldes. Die Länge des TFC Padding Feldes wird in dem Payload Data-Feld gespeichert. Das Feld "`Next Header"' ist 8 Bit lang. Es funktioniert ähnlich wie das entsprechende Feld des AH. Es wird benutzt um den Typ der Nutzdaten zu speichern. Wie schon beim AH gibt es zum Beispiel Werte für IPv4 und IPv6. Zusätzlich gibt es beim ESP noch den Wert 59, welcher auf ein dummy-Paket hinweist. Das Feld "`Integrity Check Value"' hat eine variable Länge und enthält den Message Authentication Code, der benutzt wird um die Authentizität und Integrität der Nachricht zu prüfen. Der MAC wird dabei aus allen vorigen Feldern berechnet und wenn der Inhalt verschlüsselt wird, dann wird der MAC erst nach dem Verschlüsseln generiert (encrypt-then-MAC).
|
|
|
|
\subsubsection{Algorithmen}
|
|
In RFC 7321 ist festgehalten welche Algorithmen implementiert werden können, sollen oder müssen.\cite{RFC7321} Dabei sind die Algorithmen mit den Bewertungen must, must not, should, should not und may versehen. Zusätzlich gibt es zum Beispiel must-, was bedeutet, dass es zwar noch implementiert werden muss, aber wahrscheinlich bald zu should herabgestuft wird. Dabei wird unterschieden zwischen Verschlüsselungsalgorithmen und Authentifizierungsalgorithmen für ESP und Authentifizierungsalgorithmen für AH.
|
|
|
|
Für ESP muss aktuell für Verschlüsselung AES-CBC unterstützt werden. Hierbei werden die Felder Payload Data, Padding, TFC Padding, Pad Length und Next Header verschlüsselt. Der RFC 7321 besagt ebenfalls, dass der Algorithmus Null unterstützt werden muss. Dies bedeutet lediglich, dass es auch möglich ist die Daten nicht zu verschlüsseln.
|
|
|
|
Die Algorithmen zum Authentifizieren sind bei AH und ESP gleich. Unterstützt werden muss HMAC-SHA1-96. Es sind jeweils noch weitere Hinweise zu Algorithmen im RFC vorhanden -- zum Beispiel welche unterstützt werden sollten oder auch nicht unterstützt werden dürfen.
|
|
|
|
\subsubsection{Internet Key Exchange Version 2}
|
|
Es gibt bei IPsec die SPD\footnote{Security Policy Database}. Diese legt fest welche Verfahren angewendet und damit welche Security Associations erstellt werden dürfen. Die SAs\footnote{Security Associations} werden wiederum in einer eigenen Datenbank gespeichert -- der SAD\footnote{Security Associations Database}. Die SAs enthalten unter anderem auch die verwendeten Schlüssel. Die SPD wird üblicherweise per Hand eingerichtet, da diese eher statisch ist und man während der Kommunikation keine Einträge vornehmen muss. Für die SAD wird üblicherweise IKEv2\footnote{Internet Key Exchange Version 2} verwendet, welches die SAs automatisch verwaltet. IKEv2 wird in RFC 5996 spezifiziert.\cite{RFC5996}
|
|
|
|
IKE legt dabei fest, wie eine Verbindung aufzubauen ist: Zunächst wird eine Prozedur durchlaufen, um eine Verbindung zwischen den Kommunizierenden herzustellen. Die einzelnen Schritte bestehen immer aus einer Nachricht des Senders und einer Nachricht des Empfängers. Der erste Austausch wird IKE\_SA\_INIT genannt. Hierbei werden zunächst Daten ausgetauscht, um zu vereinbaren wie die Verbindung hergestellt wird, also z.B. welche Algorithmen verwendet werden. Dazu schickt der Initiator dem Empfänger Vorschläge wie die Verbindung aussehen soll und der Empfänger bestätigt dann seine Auswahl. Außerdem werden Diffie-Hellman Werte und Noncen ausgetauscht. Anhand von diesen Werten und den Noncen wird SKEYSEED generiert. Mit Hilfe dieses SKEYSEEDs werden nun mehrere Schlüssel erstellt, die zum Verschlüsseln und Authentifizieren nachfolgender Kommunikation verwendet werden.
|
|
|
|
Der nächste Austausch wird IKE\_AUTH genannt. Dieser Austausch ist mit den vorher generierten Schlüssel geschützt und die Kommunizierenden können sich jetzt anhand der vorher generierten Schlüssel authentifizieren. Anschließend wird eine SA ausgemacht, die in die SAD eingetragen und später genutzt wird, um die eigentliche Datenkommunikation zu regeln.
|
|
|
|
Nachfolgende Kommunikation bezüglich IKE wird CREATE\_CHILD\_SA genannt und kann dazu genutzt werden um weitere SAs zu vereinbaren. Außerdem gibt es noch INFORMATIONAL, welches z.B. für Fehlermeldungen von IKEv2 genutzt wird.
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\section{OpenVPN}
|
|
|
|
In dem folgenden Abschnitt wird OpenVPN vorgestellt. Es ist eine konkrete Implementation eines SSL/TLS-basierten VPNs. Die eigentliche Arbeit wird daher von TLS übernommen, weswegen es im Gegensatz zu IPsec auch nicht so einfach ist die technischen Hintergründe darzulegen -- zumindest ohne auf TLS einzugehen. Aus diesem Grund werden wir die Grundlagen von TLS erklären, damit dem späteren Vergleich besser gefolgt werden kann. Dabei folgen wir Böhmer\cite{Boehmer2005}, da er eine gut verständliche Beschreibung von TLS bietet. Obwohl das Buch von 2005 ist, hat dies in diesem Zusammenhang keine negativen Auswirkungen, da wir uns lediglich auf die Beschreibung des Standards beziehen und sich dieser nicht wesentlich geändert hat.
|
|
|
|
Wir werden zunächst die Konzepte, die einer TLS-Verbindung zugrundeliegen, vorstellen, um dann das Handshake-Protokoll und abschließend das Record-Protokoll vorzustellen.
|
|
|
|
\subsection{TLS-Verbindung}
|
|
|
|
Eine TLS-Verbindung oder auch TLS-Connection ist im Sinne des OSI-Referenzmodells eine Transportverbindung. In diesem Fall ist es eine transparente Punkt-zu-Punkt-Verbindung, die durch mehrere Parameter bestimmt ist:
|
|
|
|
\begin{itemize}
|
|
\item Connection-Kennung
|
|
\item Bytes-Sequence (von Server und Client ausgewählt)
|
|
\item geheime Schlüssel (MAC-Secrets) für Integritätsüberprüfungen
|
|
\item symmetrische Schlüssel (server write key, client write key) zur Ver- bzw. Entschlüsselung
|
|
\item Initialisierungsvektor (IV) bei Benutzung von Blockverschlüsselung im CBC-Modus
|
|
\item Message-Sequence-Number (mehrere Nachrichten können ausgetauscht werden)
|
|
\end{itemize}
|
|
|
|
Jede TLS-Verbindung ist an eine TLS-Session gekoppelt.
|
|
|
|
\subsection{TLS-Session}
|
|
|
|
Eine TLS-Session stellt die Verbindung zwischen einem Browser und einem Webserver dar und wird durch das Handshake-Protokoll ausgehandelt. Sie legt die kryptographischen Parameter fest, die für mehrere TLS-Connections gültig sind. Dadurch kann verhindert werden, dass bei einem wiederholten Verbindungsaufbau alle Sicherheitsparameter neu ausgehandelt werden müssen. Jede Session ist durch die folgenden Parameter gekennzeichnet:
|
|
|
|
\begin{itemize}
|
|
\item Session Identifier (aus willkürlicher Byte-Sequence vom Server erzeugt)
|
|
\item X.509v3-Zertifikat (kann ungenutzt bleiben)
|
|
\item compression method (Algorithmus zur Datenkompression)
|
|
\item Schlüsselspezifikation (cipher spec.)
|
|
\item Session-Schlüssel (Master-Secret)
|
|
\item Flag, ob die Session für Initiierung von neuer TLS-Connection genutzt werden kann
|
|
\end{itemize}
|
|
|
|
\subsection{TLS Handshake}
|
|
Bevor Daten von einer Anwendung über TLS zum Server transportiert werden können, muss zunächst die Verbindung aufgebaut werden. Dabei kommt das TLS-Handshake-Protokoll zum Einsatz. Der Ablauf ist dabei in mehrere Phasen unterteilt. Während der Phasen werden Nachrichten zwischen Server und Client versendet, die nach einem bestimmten Muster aufgebaut sind. Jede Nachricht enthält ein Typenfeld von 1 Byte Länge, ein Feld, welches die Länge der Nachricht angibt, von 3 Byte Länge und ein Inhaltsfeld von mindestens einem Byte Länge, welches die Parameter des Typenfeldes enthält. In der \fref{tab:handshake-1} sind die verschiedenen Nachrichtentypen und ihre Parameter zu sehen.
|
|
|
|
\begin{table}
|
|
\caption{Unterschiedliche Nachrichtentypen, die im TLS-Handshake-Protokoll während der Phasen zwischen Client und Server ausgetauscht werden}
|
|
\label{tab:handshake-1}
|
|
\begin{tabular}{|l|l|}
|
|
\hline
|
|
Nachrichtentyp & Parameter \\
|
|
\hline
|
|
hello\_request & null \\
|
|
client\_hello & client\_version, random, session\_id, cipher\_suite, \\
|
|
& compression\_method \\
|
|
server\_hello & server\_version, random, session\_id, cipher\_suite, \\
|
|
& compression\_method \\
|
|
certificate & RSA, DHE\_DSS, DHE\_RSA, DH\_DSS, DH\_RSA, certificate\_list \\
|
|
server\_key\_exchange & DHE\_DSS, DHE\_RSA, DH\_anon \\
|
|
certificate\_request & type, authorities \\
|
|
server\_done & null \\
|
|
certificate\_verify & signature \\
|
|
client\_key\_exchange & parameters, signature \\
|
|
finished & hash\_value \\
|
|
\hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
In Phase 1 sendet der Client die \texttt{client\_hello}-Nachricht an den Server. In Phase 2 erfolgt die Server-Identifizierung mithilfe der \texttt{server\_hello}-Nachricht. Zusätzlich sendet der Server die \texttt{certificate}, \texttt{server\_key\_exchange} und \texttt{certificate\_request} Nachrichten. Abschließend sendet der Server die \texttt{server\_hello\_done} Nachricht.
|
|
|
|
Es folgt Phase 3, die der Client-Identifizierung dient. In dieser Phase verifiziert der Client die vom Server geschickten Zertifikate und überprüft die in der \texttt{server\_hello} mitgeschickten Parameter. Sofern keine Probleme auftreten, schickt der Client einige Nachrichten an den Server. Hat der Server nach einem Zertifikat gefragt, dann wird eine \texttt{certificate}-Nachricht an den Server gesandt. Kann der Client diese Anfrage nicht erfüllen, erfolgt eine \texttt{no\_certificate\_alert}-Meldung.
|
|
|
|
In jedem Fall wird die \texttt{client\_key\_exchange}-Nachricht zurückgesendet. Deren Inhalt hängt vom verwendeten Austauschverfahren ab: Bei RSA wird ein 48-Byte großer Zwischenschlüssel (Pre-Master-Secret) und bei Ephemeral Diffie-Hellman bzw. Anonymous Diffie-Hellman werden die globalen Diffie-Hellman-Parameter (g, p) geschickt. Im Fall von Fixed Diffie-Hellman wurden die globalen Parameter bereits in der \texttt{certificate}-Nachricht verschickt, sodass der Inhalt der Nachricht null ist.
|
|
|
|
Abschließend kann optional die \texttt{certificate\_verify}-Nachricht mitgeschickt werden, um das Client-Zertifikat explizit zu überprüfen. Dies ist jedoch nur möglich, wenn das Client-Zertifikat eine Signatur erstellen kann, was außer bei Fixed Diffie-Hellman jedoch bei allen Zertifikaten möglich ist.
|
|
|
|
In den meisten Fällen endet der Handshake hier. Wurde aber vom Client zusätzlich noch eine \texttt{change\_cipher\_spec}-Nachricht mitgeschickt, dann schließt sich noch eine Phase 4 an. In dieser Phase aktualisieren Server und Client ihre Informationen über die kryptographischen Spezifikationen. So schickt der Server ebenfalls eine \texttt{change\_cipher\_spec}-Nachricht zum Client. Zum Abschluss wird die \texttt{finished}-Nachricht versendet, die die aktuellen Algorithmen, Schlüssel und Geheimnisse enthält. Noch einmal werden der Schlüsselaustausch und der erfolgreiche Authentifizierungsprozess überprüft. Der Server sendet die gleiche Überprüfungsnachricht zum Client.
|
|
|
|
\subsection{Record-Protokoll}
|
|
|
|
Nachdem eine TLS-Verbindung erfolgreich aufgebaut wurde, kommt das Record-Protokoll zum Einsatz, um die Anwendungsdaten sicher zum Server zu transportieren. Die Daten werden in Blöcke geeigneter Größe aufgeteilt und bei Bedarf komprimiert. Anschließend wird der MAC hinzugefügt und der Verbund aus MAC und Datenblock mit dem im Handshake-Protokoll vereinbarten Algorithmus verschlüsselt. Abschließend wird ein Header hinzugefügt, der den Content-Type, die Major- und Minor-Version und die Länge des komprimierten Inhalts enthält. Dieses fertige Paket wird dann dem TCP übergeben. Auf der Gegenseite läuft das Protokoll in umgekehrter Reihenfolge ab.
|
|
|
|
Auf diese Weise bietet das Record-Protokoll die beiden Schutzziele Vertraulichkeit und Integrität. Die Vertraulichkeit ist durch den gemeinsam ausgehandelten Sitzungsschlüssel und den dazugehörigen Verschlüsselungsmechanismus sichergestellt.
|
|
|
|
Die Integrität ist durch den gemeinsam ausgehandelten Sitzungsschlüssel, der für die Generierung der MACs verwendet wird, gegeben.
|
|
|
|
\section{Vergleich von IPsec mit OpenVPN}
|
|
|
|
In den vorangegangenen Abschnitten wurden IPsec und OpenVPN vorgestellt. In diesem Abschnitt widmen wir uns dem Vergleich der beiden. Damit ein solcher Vergleich jedoch sinnvoll stattfinden kann, muss im Voraus klar sein, was verglichen wird. Wir benötigen daher Kriterien. Im Folgenden werden die Kriterien erarbeitet und erläutert, warum wir das jeweilige Kriterium für wichtig befinden.
|
|
|
|
\subsection{Kriterien}
|
|
Ein Hauptziel von VPNs ist die sichere Kommunikation zwischen zwei privaten Netzen. In dem Ziel selber steckt daher bereits Sicherheit als Anforderung. Es muss sichergestellt sein, dass Nachrichten von einem Netz zum anderen gelangen, ohne dass sie unterwegs in irgendeiner Weise beeinträchtigt werden. Aus diesem Grund ist natürlich von großem Interesse, wie sicher IPsec bzw. OpenVPN sind und weitergehend, ob eine der beiden Varianten sicherer ist als die andere.
|
|
|
|
Aus was setzt sich die Sicherheit jedoch zusammen? Zur Sicherheit gehören einerseits die Schutzziele in der IT-Sicherheit: Vertraulichkeit, Integrität, Verfügbarkeit. Andererseits gehören aber auch das Vorhandensein von Sicherheitslücken zur Sicherheit. Denn was nutzt ein theoretisch sicheres Verfahren, wenn es in der Implementation reihenweise Sicherheitslücken gibt?
|
|
|
|
Allerdings ist es nicht wirklich gangbar IPsec und OpenVPN anhand von Sicherheitslücken zu vergleichen, denn während IPsec ein Standard ist\cite{RFC4301}, handelt es sich bei OpenVPN um eine konkrete Implementation eines SSL/TLS-basierten VPNs\cite{Kotuliak2011}. Daher haben wir uns dagegen entschieden Sicherheitslücken in den Vergleich mit einzubeziehen.
|
|
|
|
Allerdings sind wir damit noch nicht am Ende unserer Kriterien angelangt. Aus dem Schutzziel der Verfügbarkeit lässt sich die Performance als Kriterium ableiten. Schließlich interessiert es neben der Sicherheit auch, wie schnell die Nachrichten von A nach B kommen. Was konkrete Werte bei einem Performancevergleich angeht, verweisen wir auf einen solchen Vergleich von 2011, welcher im Rahmen der ICETA Konferenz von Kotuliak\cite{Kotuliak2011} unternommen wurde.
|
|
|
|
Ein weiteres Kriterium ist die Kompatibilität zwischen Lösungen unterschiedlicher Hersteller. Dies liegt darin begründet, dass es aus Gründen der Sicherheit sinnvoll ist, Hardware unterschiedlicher Hersteller zu benutzen, da somit Sicherheitslücken bei einem Hersteller sich nicht auf das gesamte Netzwerk auswirken. Dies ist jedoch nur möglich, wenn die Implementationen der verschiedenen Hersteller zueinander kompatibel sind. In der Hinsicht hat auch Kompatibilität etwas mit Sicherheit zu tun.
|
|
|
|
Wir haben die Kriterien in dem obigen Abschnitt herausgearbeitet. Zusammengefasst sind es: Vertraulichkeit, Integrität, Verfügbarkeit, Performance und Kompatibilität.
|
|
|
|
\subsection{Vertraulichkeit}
|
|
Wir beginnen den Vergleich mit der Vertraulichkeit. Interessant sind da die unterstützten Verschlüsselungsalgorithmen und die maximalen Schlüssellängen der Algorithmen.
|
|
|
|
Im Abschnitt über IPsec wurde bereits eingeführt, dass IPsec grundlegend zwei Mechanismen unterstützt: ESP\footnote{Encapsulated Security Payload} und AH\footnote{Authentication Header}. Das Schutzziel der Vertraulichkeit wird dabei nur von ESP gewährleistet, weswegen wir AH beim Vergleich bzgl. der Vertraulichkeit ignorieren.
|
|
|
|
OpenVPN ist eine Implementation eines TLS-basierten VPNs. Die Verschlüsselung wird hierbei von dem TLS-Protokoll übernommen. Deswegen werden wir in diesem Punkt IPsec mit TLS vergleichen.
|
|
|
|
Für jedes Verschlüsselungsverfahren wird ein Schlüssel benötigt. Daher werden wir uns zunächst die verwendeten Verfahren zum Schlüsselaustausch ansehen. IPsec verwendet meistens Diffie-Hellman, unterstützt aber auch KINK\footnote{Auf Kerberos basierendes Protokoll, dass Schlüsselaustausch- und Authentifizierungsmechanismen bereitstellt. Es wurde noch nicht standardisiert\cite{Alshamsi2005}.}. TLS unterstützt mehrere Verfahren. In diesem Paper beschränken wir uns auf zwei davon: RSA und DH\footnote{Diffie-Hellman}\cite{Alshamsi2005}.
|
|
|
|
Es ist ersichtlich, dass IPsec und TLS DH unterstützen. Zusätzlich unterstützt IPsec KINK und TLS RSA. Ein wirklicher Vor- oder Nachteil kann in diesem Fall weder IPsec noch TLS zugesprochen werden. Wenn wir die Verbreitung von KINK bzw. RSA vergleichen, dann liegt RSA vorne, da es seit langem standardisiert ist und es etliche Implementationen gibt.
|
|
|
|
Ein weiterer Punkt bei der Vertraulichkeit ist die Authentifizierungsmethode. IPsec unterstützt lediglich die gegenseitige Authentifizierung. TLS hingegen unterstützt eine reine Server-Authentifizierung, eine gegenseitige Authentifizierung, die auch Client-Authentifizierung genannt wird, und eine anonyme Authentifizierung, bei der nichts authentifiziert wird.\cite{Alshamsi2005}
|
|
|
|
Bei den Authentifizierungsalgorithmen hat jedoch IPsec einen Vorteil, denn es wird sowohl die Nutzung einer digitalen Signatur als auch die Verwendung eines Algorithmus, der auf einem geheimen Schlüssel basiert, ermöglicht. TLS benötigt hingegen zwangsweise eine digitale Signatur. Sollten alle Algorithmen mit digitaler Signatur ausfallen, kann IPsec weiterhin implementiert werden, TLS jedoch nicht.\cite{Alshamsi2005}
|
|
|
|
Abseits der Verschlüsselung selber ist jedoch auch die Reichweite der Verschlüsselung von Interesse. Hier vergleichen wir IPsec mit OpenVPN. Bei IPsec werden die Pakete verschlüsselt, nicht jedoch ihr Inhalt. Werden zwei Netze verbunden, so ist nur der VPN-Tunnel selber vor einem Angriff geschützt. Aber der Weg von der Anwendung zum VPN-Tunnel und vom VPN-Tunnel zur Anwendung ist nicht geschützt. Sobald sich also ein Angreifer innerhalb eines der beiden Netzwerke befindet, ist IPsec ohne Schutzwirkung.
|
|
Im Gegensatz dazu verschlüsselt OpenVPN von Anwendung zu Anwendung und damit wirklich Ende-zu-Ende. Da ist es dann auch nicht mehr wichtig, ob sich der Angreifer im Netzwerk befindet, da er nur verschlüsselte Daten sehen kann.\cite{Sun2011}
|
|
|
|
Zusammenfassend kann für den Bereich der Vertraulichkeit gesagt werden, dass sowohl IPsec als auch TLS hinreichende Vertraulichkeit bieten. Allerdings unterliegt IPsec bei der Effizienz der Vertraulichkeit ganz klar OpenVPN.
|
|
|
|
\subsection{Integrität}
|
|
Neben der Vertraulichkeit ist auch die Integrität wichtig. Daher werden wir im folgenden Abschnitt vergleichen, welche Methoden von IPsec und OpenVPN zur Wahrung der Integrität verwendet werden.
|
|
|
|
Analog zur Vertraulichkeit wird auch hier nicht direkt OpenVPN verglichen, sondern TLS, da dieses zuständig dafür ist.
|
|
|
|
Als Authentifizierungsverfahren zur Überprüfung der Integrität werden von beiden Message Authentication Codes (kurz: MACs) verwendet. Bei MACs hängt es von dem verwendeten Hashverfahren an, ob die Integrität zuverlässig überprüft werden kann. Sowohl IPsec als auch TLS erfordern die Implementation von HMAC-SHA-1 und HMAC-MD5. HMAC ist eine kryptographische Hashfunktion, die einen geheimen Schlüssel erfordert. Die Sicherheit bzw. Stärke des Algorithmus hängt dabei von der Länge des Schlüssels und des Outputs ab.\cite{Alshamsi2005}
|
|
|
|
Als Fazit für die Integrität kann gelten, dass es keine wirklichen Unterschiede zwischen IPsec und TLS in diesem Bereich gibt.
|
|
|
|
\subsection{Verfügbarkeit}
|
|
Das dritte Schutzziel ist Verfügbarkeit. Traditionell fallen Dinge wie DDOS-Angriffe\footnote{Distributed-Denial-of-Service-Angriffe} unter dieses Schutzziel bzw. beeinträchtigen es. In unserem Zusammenhang ist die Durchlässigkeit bei Firewalls von Interesse, also ob ein VPN durch eine der beiden Technologien gezielt geblockt werden kann. Auch die Verbreitung spielt eine Rolle, denn eine weit verbreitete Technologie macht es intuitiv gesehen erst einmal "`einfacher"' eine Verbindung zwischen zwei Netzen aufzubauen.
|
|
|
|
Beginnen wir bei Firewalls. Dort gilt, dass IPsec in geringem Maße im Nachteil ist, da es feste Protokolle und Ports benötigt. Ein gezieltes Blocken von IPsec-basierten VPNs ist daher praktikabel. Im Vergleich dazu kann OpenVPN auf jedem Port mit UDP oder TCP laufen. Um restriktive Firewalls zu überwinden, kann der Port 443 und TCP benutzt werden. Dadurch sieht der Traffic von OpenVPN wie normaler HTTPS-Traffic aus und kann nicht gezielt gefiltert werden.\cite{Sun2011}
|
|
|
|
Bei der Verfügbarkeit auf unterschiedlichen Betriebssystemen und Implementationen ist zu beachten, wofür das VPN eingesetzt wird. Wenn es für eine Remoteverbindung genutzt wird, dann liegt IPsec hinten, da es auf beiden Geräten der Verbindung einen entsprechenden Client benötigt. OpenVPN bedarf nur der Einrichtung in dem privaten Netz, auf das man zugreifen möchte. Für den Remotezugriff muss keine extra Software installiert werden. Wird das VPN stattdessen für eine feste Verbindung zwischen zwei Endpunkten mit statischen IP-Adressen verwendet (z.B. zwei Router), dann ist IPsec aufgrund der Standardisierung und vielen Möglichkeiten im Vorteil.\cite{Sun2011}
|
|
|
|
Vor diesem Hintergrund gewinnte OpenVPN eindeutig das Rennen, wenn es um Remoteverbindungen geht. Bei Verbindungen zwischen zwei festen Endpunkten hat IPsec jedoch die Nase vorn, da es beidseitig hohe Standards voraussetzt.
|
|
|
|
\subsection{Performance}
|
|
Nachdem wir IPsec und OpenVPN bezüglich der Schutzziele verglichen haben, widmen wir uns jetzt der Performance.
|
|
|
|
Mit diesem technischen Hintergrundwissen ausgestattet, können wir die Ergebnisse des Vergleichs betrachten. Der durchschnittliche Durchsatz kann in \fref{tab:tp} gesehen werden. Es fällt auf, dass der Durchsatz ohne Verschlüsselung weit über dem der Verschlüsselung liegt. Allerdings ist das auch nicht anders zu erwarten. Zum Verständnis ist jedoch noch wichtig, dass die verwendete Ethernetverbindung nicht für die Verwendung von Jumbo-Frames eingerichtet wurde. Ohne diese Frames ist solch eine Gigabit-Verbindung jedoch erheblich langsamer als der theoretische Wert (1 GBit/s).\cite{Kotuliak2011}
|
|
|
|
Eine weitere Auffälligkeit ist die im Vergleich zu den übrigen Algorithmen schlechte Performance von 3DES. Dies liegt schlichtweg daran, dass 3DES ein veraltetes Verfahren ist und nicht weiter benutzt werden sollte. Bei diesem konkreten Verfahren ist IPsec (45 Mbps) langsamer als OpenVPN (60,98 Mbps), allerdings hat das kaum eine Relevanz, da 3DES wie gesagt veraltet ist.
|
|
|
|
Interessanter ist dort der Unterschied zwischen dem Durchsatz von IPsec AES (142 Mbps) bzw. IPsec Blowfish (121,76 Mbps) und OpenVPN AES (98 Mbps) bzw. OpenVPN Blowfish (96 Mbps). Dieser signifikante Unterschied liegt an der Hardwarenähe von IPsec und ist dementsprechend auch erwartbar gewesen.
|
|
|
|
Anhand dieser Zahlen ist auch ersichtlich, dass es keinen ernstzunehmenden Unterschied zwischen AES und Blowfish gibt. AES hat von beiden den Vorteil, dass das Verfahren standardisiert ist und von vielen Regierungen und im privaten Sektor größtenteils unterstützt wird.
|
|
|
|
\begin{table}
|
|
\caption{Vergleich des durchschnittlichen Throughputs in Megabit pro Sekunde. Werte von Kotuliak\cite{Kotuliak2011}}
|
|
\label{tab:tp}
|
|
\begin{tabular}{c|c}
|
|
Szenario & Throughput (Mbps) \\
|
|
\hline
|
|
Ethernet ohne Verschlüsselung & 553 \\
|
|
OpenVPN 3DES & 60,98 \\
|
|
OpenVPN AES & 98 \\
|
|
OpenVPN Blowfish & 96 \\
|
|
IPsec 3DES & 45 \\
|
|
IPsec AES & 142 \\
|
|
IPsec Blowfish & 121,76
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\subsection{Kompatibilität}
|
|
Abschließend gehen wir auf die Kompatibilität der Implementationen verschiedener Hersteller untereinander ein. Uns war es nicht möglich eigene Vergleiche hinsichtlich der Kompatibilität durchzuführen, daher werden wir nur oberflächlich darauf eingehen.
|
|
|
|
OpenVPN benutzt TLS und dieses Protokoll ist seit langem erprobt und von einer Vielzahl an Herstellern implementiert. Obgleich es mit Heartbleed eine Sicherheitslücke in der bekannten Implementation OpenSSL gab, tut das der Kompatibilität keinen Abbruch. Es ist demnach vollkommen egal welche Hardware und welche Software verwendet wird, denn TLS wird mittlerweile in allen gängigen Systemen nativ unterstützt.
|
|
|
|
Bei IPsec sieht das anders aus. Zwar ist auch IPsec standardisiert, ebenso wie TLS, aber der Umfang der RFCs macht ein Verständnis relativ schwer. Daraus ist auch zu begründen, warum es zu Beginn kaum untereinander kompatible Lösungen gab\cite{Alshamsi2005}. Mittlerweile ist der Standard jedoch älter und auf breiterer Schicht umgesetzt, sodass es zwar noch Unterschiede zwischen TLS und IPsec gibt, diese jedoch nicht mehr ins Gewicht fallen.
|
|
|
|
Bezüglich der Kompatibilität kommen wir zu dem Fazit, dass IPsec noch im Vergleich zu TLS aufholen muss, allerdings bereits viele der anfänglichen Kompatibilitätsprobleme überwunden hat.
|
|
|
|
\section{Schlussbemerkungen}
|
|
Aus dem Vergleich geht hervor, dass IPsec und OpenVPN abhängig von dem Verwendungsszenario des VPN unterschiedlich gut abschneiden. Für Remoteverbindungen zwischen einem einzelnen Rechner und einem Netzwerk ist OpenVPN die bessere Wahl, da Ende-zu-Ende verschlüsselt wird, obgleich die Verschlüsselung selber bei IPsec und OpenVPN sich nicht viel gibt. Im Bereich der Performance hat IPsec aufgrund der Kernelnähe die Nase vorn. Im Bereich der Kompatibilität bestätigt IPsec nur zum Teil das Vorurteil der Inkompatibilität. Gleichwohl gibt es noch Aufholpotential.
|
|
|
|
Es gibt noch eine weitere Erkenntnis, die im Vergleich nicht auftaucht, aber auch nicht unerwähnt bleiben sollte: Basierend auf neuen Enthüllungen vom 31C3 muss davon ausgegangen werden, dass IPsec mit Pre-Shared-Keys nicht länger vor der NSA schützt. In diesem Zusammenhang ist auch die Komplexität von IPsec wichtig, da sie eine sichere Implementation sehr schwierig macht.
|
|
|
|
Für die Zukunft können wir uns vorstellen, dass es eine weitere Überarbeitung von IPsec geben wird, um es leichter verständlich zu machen. Außerdem sind wir der Meinung, dass sich die teilweise noch bestehenden Kompatibilitätsprobleme auflösen werden, sodass es für eine immer größere Menge von Leuten möglich sein wird sichere Verbindungen zwischen zwei Netzwerken aufzubauen.
|
|
|
|
Aus wissenschaftlicher Sicht wäre ein umfassender Vergleich zwischen allen existierenden VPN-Lösungen wünschenswert, um für ein komplettes Bild nicht auf teilweise bereits veraltete Daten zurückgreifen zu müssen. Darüber hinaus wäre eine zentrale Anlaufstelle hilfreich, über die entsprechende Forschung koordiniert wird, um doppelte Arbeit zu vermeiden.
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\newpage
|
|
|
|
\printbibliography
|
|
\addcontentsline{toc}{section}{Literaturverzeichnis}
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\newpage
|
|
\addcontentsline{toc}{section}{Anhang}
|
|
|
|
\end{document}
|