JPT
/
masterthesis
0
0
Fork 0
Code Issues Pull Requests Activity

Autosave

This commit is contained in:
Jan Philipp Timme 2018-09-12 11:52:41 +02:00
parent 92703a7432
commit 410b545240
2 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
Dokumentation-CA.tex
View File

@ -83,11 +83,8 @@ From man:openvpn:
--tls-cert-profile profile
OpenVPN will migrate to 'preferred' as default in the future. Please ensure that your keys already comply.
Wie groß soll der Schlüssel sein? [Welche Kurve?]
Zertifikate nur mit CN oder volles Schema?
* Eigentlich egal, keine Vorteile oder Nachteile. Volles Schema => Mehr Informationen darüber, wo der VPN-Dienst angesiedelt ist. Ändert nicht viel. Es spricht nichts gegen den Einsatz des vollen Schemas.

19
MA-Inhalt.tex
View File

@ -211,6 +211,7 @@ Anforderungen:
* Möglichst wenig personenbezogene Daten verarbeiten oder speichern
* Zielgruppe des Dienstes sind Beschäftigte und Studenten der Abteilung Informatik (Größenordnung: 20-200 Personen)
* Studenten sollen immer für ein (laufendes?) Semester Zugriff erhalten
* Für Beschäftigte wurde kein Kriterium genannt, allerdings könnten andere Gültigkeitsdauern erwünscht sein.
Möglichkeiten: User+Passwort oder SSL-Zertifikate
@ -226,36 +227,38 @@ Benutzer/Passwort:
* Bequemlichkeit: Kann über existierende Infrastruktur abgewickelt werden (Hochschulaccount)
* Einrichung von Benutzern kann quasi vollautomatisch oder durch eine Whitelist geschehen
* Benutzerkonten werden automatisch deaktiviert
* Nur Benutzername+Passwort reichen aus, gestohlene Zugangsdaten bedeuten großes Schadenspotential
* Nur Benutzername+Passwort reichen aus, gestohlene Zugangsdaten bedeuten großes Schadenspotential für betroffene Benutzer
* Zugangsdaten müssen zur Authentisierung an entsprechende Dienste "durchgereicht" werden, daher größere Angriffsfläche
Gewinner: Zertifikate
Für Zertifikate wird eine Zertifizierungsstelle benötigt.
\section{Umsetzung einer Zertifizierungsstelle}
\section{Konzeption und Umsetzung einer Zertifizierungsstelle}
OpenSSL ist aufgrund der Abhängigkeit von OpenVPN bereits gegeben.
Mit OpenSSL kann man Schlüsselpaare erzeugen, Zertifikatsanträge erzeugen und Zertifikate ausstellen.
Allerdings erfordert das viel Detailwissen und die Verwaltung der ausgestellten Zertifikate ist nicht einfach.
Da wir Zertifikate auch unbrauchbar machen wollen, müssen Revocations ebenfalls möglich sein.
Allerdings erfordert das viel Detailwissen und die Verwaltung der ausgestellten Zertifikate mit puren openssl-Befehlen ist nicht einfach.
Da wir Zertifikate auch unbrauchbar machen wollen, muss es möglich sein Zertifikate zu widerrufen.
Eine CRL muss erzeugt werden können, damit diese im OpenVPN-Dienst für die Prüfung der Gültigkeit der Zertifikate verwendet werden kann.
Jetzt kann man viel Zeit investieren, die notwendigen Skripte selbst zu schreiben.
Allerdings hat OpenVPN bereits eine Abhängigkeit auf die Skriptesammlung EasyRSA, welche exakt für diesen Zweck gebaut wurde.
Die von Debian 9 mitgelieferte Version 2.3.x ist schon etwas älter, könnte aber verwendet werden.
Allerdings gibt es auch eine modernere Neuentwicklung in Version 3.0.5, die langfristig vom OpenVPN-Team weiterentwickelt wird und einige Verbesserungen im Vergleich zur alten v2 mitbringt.
Allerdings gibt es auch eine modernere Neuentwicklung in Version 3.0.4(Stand 12.09.2018, siehe github.com/openvpn/easyrsa), die langfristig vom OpenVPN-Team weiterentwickelt wird und einige Verbesserungen im Vergleich zur alten v2 mitbringt.
Kurz: EasyRSA2.2.3 aus Debian vs EasyRSA3.x direkt von Github vs irgendwie selbst Skripte schreiben (Wieso das Rad neu erfinden?) - Vorteile/Nachteile
Ggf. kurz ein Blick darauf, was alles für Features benötigt werden.
EasyRSAv3 ist eine Neuentwicklung von EasyRSAv2.
EasyRSAv3 ist eine Neuentwicklung von EasyRSA2.
Die neue Version wird vom OpenVPN-Team weiter entwickelt werden.
Vereinfachte Benutzung der zur Verfügung gestellten Shellskripte
Viele Verbesserungen, wie z.B. Unterstützung für ECDSA (Siehe Changelog) oder UTF-8 ist jetzt standard, AES256 wird für die Verschlüsselung des CA-Keys verwendet, \dots
Da für die Anfertigung von Zertifikatsanträgen eine korrekte Konfiguration von OpenSSL benötigt wird und diverse Einstellungen vorgegeben werden sollen, ist es sinnvoll, dass die CA durch das IT-Team auf Basis von EasyRSA v3.0.5 kurz vorbereitet wird und dann als Paket für Benutzer bereitgestellt wird.
Da für die Anfertigung von Zertifikatsanträgen einige Details beachtet werden sollen und diverse Einstellungen durch die Zertifizierungsstelle vorgegeben bzw. vorausgesetzt werden, ist es sinnvoll, dass die CA durch das IT-Team auf Basis von EasyRSA3 kurz vorbereitet wird und dann als Paket für Benutzer bereitgestellt wird.
Danach: Wie funktioniert die CA mit EasyRSA?
--> Dokumente: Benutzerdokumentation, CA-Admin-Dokumentation, Serverdokumentation
\section{Einrichtung des VPN-Servers}
\paragraph{Planung der Umsetzung mit dem IT-Team der Abteilung Informatik}
* IP-Adressen und Routing geklärt
* Konzepte und Konfiguration des IT-Teams in das Konzept integriert