diff --git a/CA-DOC-Inhalt.tex b/CA-DOC-Inhalt.tex index 260f903..ce80b6c 100644 --- a/CA-DOC-Inhalt.tex +++ b/CA-DOC-Inhalt.tex @@ -1,25 +1,37 @@ -\chapter{Aufbau einer CA für den VPN-Dienst} +\chapter{Vorwort} +Dieses Dokument wurde im Rahmen der Masterarbeit \enquote{Konzeption und Umsetzung eines IPv6-VPN für die Abteilung Informatik} erzeugt. +Im Rahmen der Masterarbeit wird beschrieben, wie ein IP6-VPN-Dienst auf Basis von OpenVPN konzipiert und eingerichtet wird. -\begin{itemize} -\item Beschaffung der gewünschten Version von EasyRSA + Verifikation -\item Integration der eigenen Anleitungen und Konfiguration -\item Verpacken für Clients/Server und CA selbst -\item Installation von easy-rsa -\end{itemize} +Für den Betrieb dieses Dienst wird eine Zertifizierungsstelle (\textit{Certificate Authority, kurz CA}) benötigt, die für Benutzer und den Serverbetreiber SSL-Zertifikate ausstellt. +In diesem Dokument wird beschrieben, wie die Zertifizierungsstelle aufgebaut und konfiguriert wird. +Weiterhin sind Anleitungen für die Benutzer und die Serveradministratoren des VPN-Dienst enthalten, mit deren Hilfe Zertifikate bei der Zertifizierungsstelle beantragt werden können. +Für die Zertifizierungsstelle ist eine Anleitung enthalten, anhand derer Zertifikate für eingereichte Zertifikatsanträge ausgestellt werden können. -Voraussetzung: openssl muss bereits installiert sein und im Pfad eingetragen sein. -Unter Windows kann das von OpenVPN mitgebrachte openssl verwendet werden - dazu kann der Ordner "bin" einfach in den Pfad eingetragen werden. -Ein Neustart des Computers ist notwendig, um die Änderung zu übernehmen. -Mehr dazu unter https://github.com/OpenVPN/easy-rsa/blob/v3.0.4/distro/windows/README-Windows.txt +\todo{Improve this section} + +\chapter{Einrichtung der CA} + + + +\section{Beschaffen von EasyRSA3} +Aktuelle Releases sind unter \url{https://github.com/OpenVPN/easy-rsa/releases} zu finden. +GPG-Schlüssel zur Authentisierung der Releases sind im easy-rsa Repository unterhalb von \texttt{./release-keys/README.md} aufgeführt. +\url{https://github.com/OpenVPN/easy-rsa/tree/master/release-keys} -OpenSSL setzt eine Konfigurationsdatei voraus - unter Windows fehlt diese gegebenenfalls. -Unter Windows ist es ggf. möglich den Pfad der openssl.exe in der vars-Datei zu hinterlegen. -Das könnte einige Probleme lösen. \begin{lstlisting} -# Diese Zeile ist unter Windows notwendig. -set_var EASYRSA_OPENSSL "C:/Program Files/OpenVPN/bin/openssl.exe" +# Aktuelles Release v3.0.4 beschaffen und den dazu passenden GPG-Key +gpg --recv-keys 6F4056821152F03B6B24F2FCF8489F839D7367F3 +wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.4/EasyRSA-3.0.4.tgz +wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.4/EasyRSA-3.0.4.tgz.sig +gpg --verify EasyRSA-3.0.4.tgz.sig EasyRSA-3.0.4.tgz +tar xzf EasyRSA-3.0.4.tgz +cd EasyRSA-3.0.4 \end{lstlisting} + + +\section{Konfiguration der CA} + \begin{lstlisting} # Vorgeschlagene Einstellungen, die in der vars-Datei getätigt werden sollten. set_var EASYRSA_DN "org" @@ -39,74 +51,14 @@ set_var EASYRSA_CERT_EXPIRE 180 set_var EASYRSA_CRL_DAYS 180 \end{lstlisting} -Daher muss durch die CA mindestens diese Datei bereitgestellt werden. -In dem Zug kann man auch gleich ein vorkonfiguriertes Paket mit EasyRSA bereitstellen. - -\section{Beschaffung/Installation von EasyRSA} - -Aktuelle Releases sind unter \url{https://github.com/OpenVPN/easy-rsa/releases} zu finden. -GPG-Schlüssel zur Authentisierung der Releases sind im easy-rsa Repository unterhalb von \texttt{./release-keys/README.md} aufgeführt. -\url{https://github.com/OpenVPN/easy-rsa/tree/master/release-keys} - -\begin{lstlisting} -# Aktuelles Release v3.0.4 beschaffen und den dazu passenden GPG-Key -gpg --recv-keys 6F4056821152F03B6B24F2FCF8489F839D7367F3 -wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.4/EasyRSA-3.0.4.tgz -wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.4/EasyRSA-3.0.4.tgz.sig -gpg --verify EasyRSA-3.0.4.tgz.sig EasyRSA-3.0.4.tgz -tar xzf EasyRSA-3.0.4.tgz -cd EasyRSA-3.0.4 -\end{lstlisting} - -\section{Initialisierung der CA} - \begin{lstlisting} cp vars.example vars vim vars # Konfiguration der CA anpassen: -# * Standardgültigkeit für ausgestellte Zertifikate -EASYRSA_CERT_EXPIRE=730 ./easyrsa sign-req server aither.inform.hs-hannover.de - -# * Name der CA, etc \end{lstlisting} -Frage: Welche Einstellungen sind anzupassen? -RSA vs EC? (Geht das mit allen OpenVPN-Clients?) -* Die Wahl der Algorithmen wirkt sich höchstens auf die Dauer der Authentisierung beim Verbindungsaufbau aus, der reguläre Betrieb wird davon nicht berührt. -* Da OpenVPN-Clients für alle Plattformen den selben Code verwenden, sollte bei gleichbleibenden Versionen von OpenSSL (bzw. kompatiblen mbed-TLS-Bibliotheken) die Wahl sich nicht auf die Kompatibilität auswirken. -* RSA ist lange erprobt, Patente sind ausgelaufen. Schlüssel sind etwas größer (2-4Kbit), nicht gegen Angriffe durch Quantencomputer beständig (Primfaktorzerlegung) -* Elliptic Curve-Verfahren sind noch relativ neu (10 Jahre?). Schlüssel sind kleiner, es gab schon einen Fall mit einer Backdoor in einer Curve, nicht gegen Angriffe durch Quantencomputer beständig (diskreter Logarithmus). -Empfehlungen des BSI%\cite{bsi:tr-02102} - -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. - - -Welche Angaben werden für Benutzerzertifikate übernommen? Namen? Benutzerkennungen? --> Falls es möglich sein soll, Zertifikate bei Missbrauch/Verlust/etc zu sperren, dann braucht man einen eindeutigen Identifier -* Voller Name -> Konflikte selten aber möglich, personenbezogene Daten -* E-Mail-Adresse: Eindeutig, aber personenbezogene Daten -* Benutzername/LUH-ID: Eindeutig, kein Konfliktpotential, personenbeziehbar. (Nur "alte" Studenten haben noch Benutzernamen mit Namen drin) -* Matrikelnummer (bei Studenten): Eindeutig, ggf. hat ein Student mehrere, aber das ist kein Thema. personenbeziehbar. Nachteil: Gibt es für Mitarbeiter nicht. - -Laufzeit für Serverzertifikate? -* 10 Jahre ist etwas viel. Vielleicht 1 oder 2 Jahre? - -Laufzeit für Clientzertifikate individuell oder je nach Zielgruppe? -* Studenten: 6 Monate (immer bis zum Ende des Semesters). -* Mitarbeiter: selbe Laufzeit würde den Prozess vereinfachen. Ansonsten vllt sogar 1-2 Jahre? - -Laufzeit der CA - sinnvolle Werte? -10 Jahre ist akzeptabel. Wenn man die Laufzeit bestehender Zertifikate im Auge behält, kann der Wechsel einer CA zu einem Stichtag hin funktionieren. - -Gültigkeitsdauer der CRL - falls Zertifikate überhaupt zurückgezogen werden sollen: maximal 180 Tage, kann ja vorher jederzeit aktualisiert werden (->Cronjob oder so) +\section{Initialisierung der CA} \begin{lstlisting} @@ -117,7 +69,34 @@ Gültigkeitsdauer der CRL - falls Zertifikate überhaupt zurückgezogen werden s ./easyrsa build-ca \end{lstlisting} -\section{Regelbetrieb der CA} + +\section{Bereitstellung der Konfiguration für Benutzer} +Die Datei \texttt{vars} wird benötigt. +Zusätzlich wäre es für einige Benutzer ggf. hilfreich, die Windows- und Unix-Version konfiguriert zum Download anzubieten. + +Daher muss durch die CA mindestens diese Datei bereitgestellt werden. +In dem Zug kann man auch gleich ein vorkonfiguriertes Paket mit EasyRSA bereitstellen. + + +\chapter{Beantragen von Clientzertifikaten} +Dinge, die der Benutzer auf seinem Gerät tun muss, um einen Zertifikatsantrag zu erzeugen. + +Voraussetzung: Auf dem Computer ist openssl installiert. +Gegebenenfalls muss der Pfad zu openssl in der \texttt{vars}-Datei von EasyRSA hinterlegt werden. +Unter Windows kann auf das durch OpenVPN installierte OpenSSL zurückgegriffen werden\footnote{Mehr dazu unter \url{https://github.com/OpenVPN/easy-rsa/blob/v3.0.4/distro/windows/README-Windows.txt}}: +\begin{lstlisting} +set_var EASYRSA_OPENSSL "C:/Program Files/OpenVPN/bin/openssl.exe" +\end{lstlisting} + + +\chapter{Beantragen von Serverzertifikaten} +Dinge, die der Benutzer auf seinem Gerät tun muss, um einen Zertifikatsantrag zu erzeugen. + + +\chapter{Ausstellen von Zertifikaten} +Ein Benutzer kommt mit einem Antrag bei der CA an. Welche Schritte werden durchlaufen, damit ein gültiges Client/Server-Zertifikat ausgestellt wird? + + \begin{lstlisting} # Request importieren (erfordert einen eindeutigen Namen - hier "timmeja") @@ -146,3 +125,9 @@ Daher ist eine hohe Gültigkeitsdauer mit on-demand-replacement eine Option. Ansonsten empfiehlt es sich, diesen Kram zu automatisieren. Regelmäßig eine neue CRL durch CA bereitstellen, von dieser beziehen und den VPN-Server ggf. neustarten. In der Serverkonfiguration: \texttt{verify-crl /path/to/crl.pem} + + +Die Gültigkeitsdauer kann in begründeten Einzelfällen (z.B. für Serverzertifikate) auf 730 Tage (etwa 2 Jahre) gesetzt werden. +\begin{lstlisting} +EASYRSA_CERT_EXPIRE=730 ./easyrsa sign-req server aither.inform.hs-hannover.de +\end{lstlisting} diff --git a/MA-Inhalt.tex b/MA-Inhalt.tex index 675ef89..fbe0ff6 100644 --- a/MA-Inhalt.tex +++ b/MA-Inhalt.tex @@ -257,6 +257,45 @@ Da für die Anfertigung von Zertifikatsanträgen einige Details beachtet werden Danach: Wie funktioniert die CA mit EasyRSA? --> Dokumente: Benutzerdokumentation, CA-Admin-Dokumentation, Serverdokumentation +Frage: Welche Einstellungen sind anzupassen? + +RSA vs EC? (Geht das mit allen OpenVPN-Clients?) +* Die Wahl der Algorithmen wirkt sich höchstens auf die Dauer der Authentisierung beim Verbindungsaufbau aus, der reguläre Betrieb wird davon nicht berührt. +* Da OpenVPN-Clients für alle Plattformen den selben Code verwenden, sollte bei gleichbleibenden Versionen von OpenSSL (bzw. kompatiblen mbed-TLS-Bibliotheken) die Wahl sich nicht auf die Kompatibilität auswirken. +* RSA ist lange erprobt, Patente sind ausgelaufen. Schlüssel sind etwas größer (2-4Kbit), nicht gegen Angriffe durch Quantencomputer beständig (Primfaktorzerlegung) +* Elliptic Curve-Verfahren sind noch relativ neu (10 Jahre?). Schlüssel sind kleiner, es gab schon einen Fall mit einer Backdoor in einer Curve, nicht gegen Angriffe durch Quantencomputer beständig (diskreter Logarithmus). +Empfehlungen des BSI\cite{bsi:tr-02102} + +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. + + +Welche Angaben werden für Benutzerzertifikate übernommen? Namen? Benutzerkennungen? +-> Falls es möglich sein soll, Zertifikate bei Missbrauch/Verlust/etc zu sperren, dann braucht man einen eindeutigen Identifier +* Voller Name -> Konflikte selten aber möglich, personenbezogene Daten +* E-Mail-Adresse: Eindeutig, aber personenbezogene Daten +* Benutzername/LUH-ID: Eindeutig, kein Konfliktpotential, personenbeziehbar. (Nur "alte" Studenten haben noch Benutzernamen mit Namen drin) +* Matrikelnummer (bei Studenten): Eindeutig, ggf. hat ein Student mehrere, aber das ist kein Thema. personenbeziehbar. Nachteil: Gibt es für Mitarbeiter nicht. + +Laufzeit für Serverzertifikate? +* 10 Jahre ist etwas viel. Vielleicht 1 oder 2 Jahre? + +Laufzeit für Clientzertifikate individuell oder je nach Zielgruppe? +* Studenten: 6 Monate (immer bis zum Ende des Semesters). +* Mitarbeiter: selbe Laufzeit würde den Prozess vereinfachen. Ansonsten vllt sogar 1-2 Jahre? + +Laufzeit der CA - sinnvolle Werte? +10 Jahre ist akzeptabel. Wenn man die Laufzeit bestehender Zertifikate im Auge behält, kann der Wechsel einer CA zu einem Stichtag hin funktionieren. + +Gültigkeitsdauer der CRL - falls Zertifikate überhaupt zurückgezogen werden sollen: maximal 180 Tage, kann ja vorher jederzeit aktualisiert werden (->Cronjob oder so) + + \section{Einrichtung des VPN-Servers} \paragraph{Planung der Umsetzung mit dem IT-Team der Abteilung Informatik}