Add space before all \cite

MA-Inhalt.tex

@@ -132,9 +132,9 @@ Ausgangspunkt für die Suche nach passender VPN-Software ist die Wahl der Server
 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.
-Die Authentizität der Pakete wird anhand von GPG-Signaturen durch den Paketmanager vor der Installation überprüft\cite[][Kapitel 6.5]{book:debian}.
+Die Authentizität der Pakete wird anhand von GPG-Signaturen durch den Paketmanager vor der Installation überprüft \cite[][Kapitel 6.5]{book:debian}.
 
-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}.
+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.
@@ -146,19 +146,19 @@ Sie kann verwendet werden, um in Kombination mit IPsec-fähigen Betriebssystem-K
 Strongswan wird unter quelloffen der Lizenz GPLv2 verbreitet\footnote{\url{https://wiki.strongswan.org/projects/strongswan/wiki/Contributions},\\ zuletzt abgerufen am 04.09.2018}.
 
 IPsec ist ein Internetstandard, der kryptografische Sicherheit für IPv4 und IPv6 (sowie darüber übertragenen Daten) bieten soll.
-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 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}.
 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.
 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.
+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.
-Ä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}.
+Ä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.
 Als Schlüssel wird ein zwischen Sender und Empfänger im Vorfeld ausgehandeltes gemeinsames Geheimnis verwendet.
@@ -183,30 +183,30 @@ Dadurch ist der Einsatz von IPsec für lokal ausgeführte Programme transparent.
 
 
 \subsection{OpenVPN} \label{ssct:openvpn}
-OpenVPN ist eine quelloffene Software zur Einrichtung von VPNs in Peer-to-Peer oder Client-Server-Architektur\cite[][Abschnitt \enquote{Server Mode}]{man:openvpn}.
+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.
 OpenVPN ist unterstützt IPv4 und IPv6 sowohl innerhalb eines VPN als auch zur Kommunikation zwischen OpenVPN-Prozessen.
 
 Als Transportprotokoll kommt UDP zum Einsatz.
-Unter besonderen Umständen kann entgegen der Empfehlungen\cite[][\texttt{--proto}]{man:openvpn} auch TCP als Transportprotokoll verwendet werden.
-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.
+Unter besonderen Umständen kann entgegen der Empfehlungen \cite[][\texttt{--proto}]{man:openvpn} auch TCP als Transportprotokoll verwendet werden.
+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 die Bereitstellung einer virtuellen Netzwerkkarte als Schnittstelle zum VPN wird ein TUN/TAP-Treiber verwendet.
 Um bestimmten Datenverkehr durch das VPN zu leiten können auf Client und Server Einträge in die Routingtabelle für IPv4 und IPv6 hinzugefügt werden.
 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}.
+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}.
 Der Kontrollkanal wird zur Kommunikation zwischen zwei OpenVPN-Prozessen verwendet.
-Ü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}.
+Ü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}.
+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}.
 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}.
+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}.
+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}.
 
 
 \begin{comment}
@@ -240,8 +240,8 @@ Da OpenVPN auf allen Clientbetriebssystemen verfügbar ist, gelten die selben Pr
 Wird OpenVPN mit X.509-Public-Key-Zer\-ti\-fi\-ka\-ten verwendet, so reicht es aus, diese als Datei im PEM-Format bereitzustellen.
 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}.
+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}.
 Für Linux/Unix stehen kompilierte Versionen zur Verfügung.
 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.
@@ -276,7 +276,7 @@ Die in \ref{req:clientos} und \ref{req:serveros} genannten Betriebssysteme entha
 Aus diesem Grund kann nicht garantiert werden, dass die verschiedenen Kernel die aktuellen Empfehlungen \cite[Aktuell aus][]{RFC8221} zeitnah gemeinsam unterstützen.
 Ebenso sind unterschiedliche Reaktionszeiten auf auftretende Sicherheitslücken zu erwarten, die einen oder mehrere Kernel betreffen.
 Insgesamt kann für VPN auf Basis von IPsec nicht garantiert werden, dass ein einheitliches Sicherheitsniveau über die verschiedenen Betriebssysteme aufrecht erhalten werden kann.
-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}.
+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}.
 
 In diesem Abschnitt wurden OpenVPN und Strongswan als Lösungen für die Umsetzung eines VPN gegenübergestellt.
 Dabei hat sich gezeigt, dass OpenVPN in vielen Kategorien deutlich besser schlägt als Strongswan.
@@ -398,13 +398,13 @@ 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.
 
-Laut BSI kann RSA über das Jahr 2023 hinaus eingesetzt werden\cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
+Laut BSI kann RSA über das Jahr 2023 hinaus eingesetzt werden \cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
 
 \paragraph{Festlegen der Schlüssellänge}
 Im nächsten Schritt wird die Länge der RSA-Schlüssel festgelegt, die in allen durch die CA ausgestellten Zertifikaten zum Einsatz kommen soll.
 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}.
+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}.
 
 \paragraph{Metadaten}
 EasyRSA unterstützt zwei Varianten, um den Inhalt des \texttt{Subject}-Felds eines X.509-Zertifikat zu füllen.
@@ -427,8 +427,8 @@ Für alle weiteren Felder werden folgende Vorgaben festgelegt:
 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}.
+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.
@@ -542,7 +542,7 @@ proto udp
 remote vpn-test.inform.hs-hannover.de 1194
 \end{lstlisting}
 
-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}.
+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.
 
 \paragraph{IP-Adressen im VPN-Tunnel}
@@ -588,7 +588,7 @@ Da der Platzhalter \texttt{vpn\_gateway} für IPv6-Routen leider nicht funktioni
 Auf die Kompression des VPN-Datenverkehrs wird aufgrund der in diesem Absatz aufgeführten Punkte verzichtet.
 Am 03.06.2018 wurden Hinweise in der Manpage von OpenVPN eingefügt\footnote{\url{https://github.com/OpenVPN/openvpn/commit/6795a5f3d55f658fc1a28eb9f3b11d1217e3329c}}, in denen vor der Verwendung von Kompression gewarnt wird.
 Diese Hinweise sind in der Manpage von OpenVPN in Version~2.4.6 noch nicht enthalten, da diese Version von den Entwicklern bereits am 19.04.2018\footnote{\url{https://github.com/OpenVPN/openvpn/releases/tag/v2.4.6}} freigegeben wurde.
-Zusätzlich wird in der \enquote{Best Current Practice} RFC~7525 zur Deaktivierung der Kompression von TLS geraten\cite[Vergleich][Kapitel 3.3]{RFC7525}.
+Zusätzlich wird in der \enquote{Best Current Practice} RFC~7525 zur Deaktivierung der Kompression von TLS geraten \cite[Vergleich][Kapitel 3.3]{RFC7525}.
 
 Auf der DEFCON~26 wurde mit \enquote{VORACLE} ein in diesem Kontext relevanter Angriff auf OpenVPN vorgestellt\footnote{\url{https://media.defcon.org/DEF\%20CON\%2026/DEF\%20CON\%2026\%20presentations/Nafeez/DEFCON-26-Nafeez-Compression-Oracle-attacks-on-VPN-Networks.pdf}}, der auf aktivierter Kompression aufbaut.
 
@@ -623,18 +623,18 @@ Das gemeinsame Geheimnis für den Schutz des Datenkanals wird dabei über den du
 Mit den in diese Absatz definierten Parametern soll die Kommunikation zwischen Clients und Server unabhängig von den verwendeten Betriebssystemen einheitlich geschützt werden.
 Um Konfigurationsprobleme durch abweichende Konfiguration von Client und Server auszuschließen, werden alle folgenden Parameter in \textbf{Client- und Serverkonfiguration} eingetragen.
 
-Die TLS-Kommunikation wird nach Empfehlung des BSI über TLS-Version~1.2 oder höher durchgeführt\cite[][Abschnitt 2.3]{bsi:tls-checkliste}.
+Die TLS-Kommunikation wird nach Empfehlung des BSI über TLS-Version~1.2 oder höher durchgeführt \cite[][Abschnitt 2.3]{bsi:tls-checkliste}.
 \begin{lstlisting}
 tls-version-min "1.2"
 \end{lstlisting}
 
-Aus der Liste der in RFC~7525 empfohlenen Chiffren\cite[][Abschnitt 4.2]{RFC7525} wird die TLS-Chiffre TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 gewählt.
-Diese Chiffre verwendet \textit{Ephemeral Diffie Hellman} (DHE) für den Schlüsselaustausch\cite[][Abschnitt A.5]{RFC5246}, RSA als Signaturalgorithmus zur Authentisierung\cite[][Abschnitt A.5]{RFC5246}, AES-256-GCM für die Verschlüsselung und SHA384 als Funktion für Peudozufallszahlen für den \textit{Keyed-Hash Message Authentication Code} (HMAC)\cite[][Kapitel 5]{RFC5246}.
+Aus der Liste der in RFC~7525 empfohlenen Chiffren \cite[][Abschnitt 4.2]{RFC7525} wird die TLS-Chiffre TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 gewählt.
+Diese Chiffre verwendet \textit{Ephemeral Diffie Hellman} (DHE) für den Schlüsselaustausch \cite[][Abschnitt A.5]{RFC5246}, RSA als Signaturalgorithmus zur Authentisierung \cite[][Abschnitt A.5]{RFC5246}, AES-256-GCM für die Verschlüsselung und SHA384 als Funktion für Peudozufallszahlen für den \textit{Keyed-Hash Message Authentication Code} (HMAC) \cite[][Kapitel 5]{RFC5246}.
 
-Durch die Verwendung von DHE kann \textit{Perfect Forward Secrecy} (PFS) gewährleistet werden\cite[][Abschnitt F.1.1.2]{RFC5246}.
+Durch die Verwendung von DHE kann \textit{Perfect Forward Secrecy} (PFS) gewährleistet werden \cite[][Abschnitt F.1.1.2]{RFC5246}.
 
-Die gewählte Chiffre kann laut BSI\cite[][Kapitel 3]{bsi:tls-checkliste} durch Dienstanbieter optional unterstützt werden.
-Die eng verwandte Chiffre TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 setzt PFS mit ECDHE anstelle von DHE um und wird laut BSI für Dienstanbieter empfohlen\cite[][Kapitel 3]{bsi:tls-checkliste}.
+Die gewählte Chiffre kann laut BSI \cite[][Kapitel 3]{bsi:tls-checkliste} durch Dienstanbieter optional unterstützt werden.
+Die eng verwandte Chiffre TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 setzt PFS mit ECDHE anstelle von DHE um und wird laut BSI für Dienstanbieter empfohlen \cite[][Kapitel 3]{bsi:tls-checkliste}.
 
 \textbf{Anmerkung}: TLS-Chiffren mit Ephemeral-Diffie-Hellman-Verfahren auf Basis von elliptischen Kurven (ECDHE) können im Rahmen dieser Arbeit nicht verwendet werden.
 Grund dafür sind Kompatibilitätsprobleme zwischen OpenVPN und OpenSSL~1.1.x auf der Clientseite\footnote{Siehe \url{https://community.openvpn.net/openvpn/ticket/963}}.
@@ -646,13 +646,13 @@ tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
 
 OpenVPN verwendet einen HMAC mit einem zuvor ausgetauschen, gemeinsamen Geheimnis um für Daten- und Kontrollkanal eingehende Datenpakete vor ihrer Verarbeitung zu authentisieren.
 
-Die im HMAC verwendete Hashfunktion wird auf SHA-256 festgelegt, weil SHA-1, trotz seiner weiterhin bestehenden theoretischen Eignung zur Verwendung in einem HMAC, laut BSI nicht mehr verwendet werden sollte\cite[][Abschnitt 1.4, Punkt 3]{bsi:tr-02102-1}.
+Die im HMAC als Quelle für Pseudozufallszahlen verwendete Hashfunktion wird auf SHA-256 festgelegt, weil SHA-1, trotz seiner weiterhin bestehenden theoretischen Eignung zur Verwendung in einem HMAC, laut BSI nicht mehr verwendet werden sollte \cite[][Abschnitt 1.4, Punkt 3]{bsi:tr-02102-1}.
 \begin{lstlisting}
 auth SHA256
 \end{lstlisting}
 
 Zur Verschlüsselung des Datenkanals kommt AES-256-GCM zum Einsatz.
-Wird eine Chiffre mit \textit{Authenticated Encryption with Associated Data} (AEAD) gewählt, so wird die Authentisierungsfunktion der Chiffre anstelle der zuvor beschriebenen HMAC-Funktion für den Datenkanal benutzt\cite[][Option \texttt{--auth}]{man:openvpn}.
+Wird eine Chiffre mit \textit{Authenticated Encryption with Associated Data} (AEAD) gewählt, so wird die Authentisierungsfunktion der Chiffre anstelle der zuvor beschriebenen HMAC-Funktion für den Datenkanal benutzt \cite[][Option \texttt{--auth}]{man:openvpn}.
 \begin{lstlisting}
 cipher AES-256-GCM
 \end{lstlisting}