unify markup for abreviated terms

This commit is contained in:
Jan Philipp Timme 2018-10-11 11:12:48 +02:00
parent 706b3c670e
commit 6bb9bbe3f7

View File

@ -24,7 +24,7 @@ In der darauf folgenden Konzeptphase werden zunächst grundlegende, lösungsunab
\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.
An der Firewall sind zwei lokale Netze angeschlossen: Die \textit{Demilitarisierte Zone} (DMZ) und das interne Abteilungsnetz, welches durch einen zentralen Switch in mehrere \textit{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]
@ -150,14 +150,14 @@ Das beinhaltet unter anderem Vertraulichkeit übertragener Daten durch den Einsa
Mit IPsec können Richtlinien definiert werden, ob und wie Datenverkehr von einem Host zu einem anderen Host geschützt werden soll.
Zum Schutz des Datenverkehrs können die Protokolle AH und ESP benutzt werden, die in den folgenden Absätzen kurz vorgestellt werden.
Das Protokoll \enquote{IP Authentication Header} (AH) ist in \cite[][]{RFC4302} definiert und ermöglicht den Versand von authentisierbaren Paketen an eine Gegenstelle.
Das Protokoll \textit{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.
Eine Verschlüsselung der Paketinhalte ist im AH-Protokoll nicht vorgesehen.
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.
Das Protokoll \textit{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}.
Aktuell empfohlene Algorithmen zum Berechnen der Prüfsumme oder zum Verschlüsseln der Paketinhalte sind in \cite[][]{RFC8221} aufgeführt.
Durch die Verschlüsselung der Paketinhalte vor dem Transport wird die Vertraulichkeit der übertragenen Inhalte gewährleistet.
@ -201,7 +201,7 @@ Der Kontrollkanal wird zur Kommunikation zwischen zwei OpenVPN-Prozessen verwend
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}.
Zusätzlich kann \textit{Perfect Forward Secrecy} (PFS) durch Einsatz des Diffie-Hellman-Verfahren für den Schlüsselaustausch erreicht werden \cite[Vergleich][Abschnitt \enquote{TLS Mode Options}]{man:openvpn}.
Außerdem können die zur Verschlüsselung des Datenkanals ausgehandelten Schlüssel während der Sitzung mehrfach erneuert werden.
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}.
@ -228,7 +228,7 @@ Die zuvor vorgestellten VPN-Softwarelösungen werden nun in den folgenden Katego
OpenVPN kommuniziert über ein eigenes Protokoll auf über UDP (oder in Ausnahmefällen über TCP) auf Port~1194.
Eine Trennung zwischen Kontrollnachrichten und Datenübertragung erfolgt innerhalb der Software.
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.
Strongswan kommuniziert mit kompatiblen Gegenstellen über das IKEv2-Protokoll, welches über UDP auf Port~500 (bei stattfindender \textit{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 übersichtlicher ausfällt.
@ -328,7 +328,7 @@ Da die Abwesenheit von Schwachstellen in Quellcode nicht garantiert werden kann,
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.
Zusätzlich ist der Systemadministrator mit der Betreuung der \textit{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:
@ -366,7 +366,7 @@ Die Notwendigkeit zum selbstständigen Entwickeln von Skripten zum Erreichen ein
Das über Debian~9 beziehbare Paket enthält EasyRSA in Version~2.3.x.
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}}.
Zusätzlich hinzugekommen sind neue Features wie etwa die Unterstützung des \textit{Elliptische-Kurven-Kryptosystems} (EKK), Unterstützung von UTF-8 oder die Verwendung von AES256 zum Verschlüsseln von privaten Schlüsseln\footnote{Vergleich \url{https://github.com/OpenVPN/easy-rsa/blob/v3.0.5/ChangeLog}}.
Die Installation von EasyRSA wird durch das Kopieren sämtlicher Dateien von EasyRSA in ein neues Verzeichnis durchgeführt.
Eine auf diese Weise eingerichtete CA kann aus diesem Grund nicht durch den Debian-Paketmanager mit Updates versorgt werden.
@ -423,7 +423,7 @@ Im Modus \enquote{org} wird ein \texttt{Distinguished Name} in dem \texttt{Subje
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.
Für Serverzertifikate wird festgelegt, dass der \textit{vollqualifizierte Domainname} (FQDN) im Feld \texttt{Common Name} abgelegt wird.
Das Feld \texttt{Email Address} wird mit der Hochschul-E-Mail-Adresse der für den Server zuständigen Administratoren gefüllt.
Für alle weiteren Felder werden folgende Vorgaben festgelegt:
\texttt{Country}: \enquote{DE},