\item \emph{Failure} zum Signalisieren einer fehlgeschlagenen Authentifizierung.
\end{itemize}
-Die Authentifizierungsmechanismen können prinzipiell frei gewählt werden, der Standard erlaubt auch die Verwendung eines Backend-Servers wie z.~B. Kerberos. Innerhalb des eduroam-Verbundes werden allerdings aus Gründen der Sicherheit die Abwandlungen \acr{EAP-TLS} \cite{rfc-eap-tls}, \acr{EAP-TTLS} \cite{rfc-eap-ttls}, oder \acr{PEAP} \cite{draft-peap} eingesetzt, die die Authentifizierung zur Erhöhung der Sicherheit über eine verschlüsselte Verbindung abwickeln, und auch die Feststellung der Identität des Authenticators erlauben.
+Die Authentifizierungsmechanismen können prinzipiell frei gewählt werden, der Standard erlaubt auch die Verwendung eines Backend-Servers wie z.~B. Kerberos. Innerhalb des eduroam-Verbundes werden allerdings aus Gründen der Sicherheit die Abwandlungen \acr{EAP-TLS} \cite{rfc-eap-tls}, \acr{EAP-TTLS} \cite{rfc-eap-ttls}, oder \acr{PEAP} \cite{draft-peap} eingesetzt, die die Authentifizierung zur Erhöhung der Sicherheit über eine verschlüsselte Verbindung abwickeln, und auch die Feststellung der Identität des Authenticators erlauben. Bei EAP-TLS wird dabei vor dem Authentifizierungsschritt eine verschlüsselte Verbindung nach dem etablierten TSL-Verfahren aufgebaut, bei EAP-TTLS wird zuerst ein verschlüsselter TLS-Tunnel aufgebaut, sodass die gesamte EAP-Kommunikation geschützt ist (und nicht nur der Authentifizierungsschritt). Bei beiden Verfahren handelt es sich um Internet-Standards, die auf offenen Standards aufbauen. PEAP ähnelt EAP-TTLS sehr stark, es handelt sich hierbei aber um eine Entwicklung der Firmen Microsoft, RSA Security und Cisco.
Der Authenticator wird vom Service Provider bereitgestellt und ist in dessen Netz eingebunden, es kann sich dabei je nach Zugangsmedium um einen Access Point oder einen Router handeln. Er hat die Aufgabe, den Benutzer zu authentifizieren, indem er mit einen \emph{Authentication Server} (\acr{AS}) kommuniziert. Dieser wiederum kann mit dem Authenticator zusammenfallen, kann aber prinzipiell in der Netzwerktopologie auch beliebig weit entfernt sein.
-Beide Seiten, Supplicant und Authenticator, sind als State Machines realisiert, die über den Zustand des ihnen zugeordneten Netzwerkports Buch führen (es wird vorausgesetzt, dass zwischen ihnen eine Punkt-zu-Punkt-Verbindung aufgebaut werden kann, beispielsweise über Ethernet). Zu jedem physikalischen Port werden zwei virtuelle Ports definiert, der nicht verwaltete Port und der verwaltete Port, über die -- unabhängig voneinander -- Daten mit höheren Protokollschichten ausgetauscht werden können und die die essenzielle Zugriffskontrolle implementieren. Weiterhin wird für den kontrollierten Port gespeichert, ob er sich im authorisierten oder im nicht authorisierten Status befindet. Im nicht authorisierten Status wird der entsprechende Port gesperrt, sodass darüber liegende Protokollschichten keine Daten über ihn austauschen können; im authorisierten Status ist dies möglich. Beim Aufbau der Verbindung befinden sich die kontrollierten Ports beider Seiten im unauthorisierten Status.
+Beide Seiten, Supplicant und Authenticator, sind als State Machines realisiert, die über den Zustand des ihnen zugeordneten Netzwerkports Buch führen (es wird vorausgesetzt, dass zwischen ihnen eine Punkt-zu-Punkt-Verbindung aufgebaut werden kann, beispielsweise über Ethernet). Zu jedem physikalischen Port werden zwei virtuelle Ports definiert, der nicht verwaltete Port und der verwaltete Port, über die -- unabhängig voneinander -- Daten mit höheren Protokollschichten ausgetauscht werden können und die die essenzielle Zugriffskontrolle implementieren. Weiterhin wird für den kontrollierten Port gespeichert, ob er sich im autorisierten oder im nicht autorisierten Status befindet. Im nicht autorisierten Status wird der entsprechende Port gesperrt, sodass darüber liegende Protokollschichten keine Daten über ihn austauschen können; im autorisierten Status ist dies möglich. Beim Aufbau der Verbindung befinden sich die kontrollierten Ports beider Seiten im unautorisierten Status.
-Standardmäßig kann der Supplicant nur mit dem Authenticator kommunizieren und mit Systemen, für die keine weiteren Zugriffsregeln definiert sind, und die somit am nicht kontrollierten Port des Authenticators anliegen (welche Dienste dies sind ist eine Frage der spezifischen Systemkonfiguration). Falls der Supplicant mit Systemen kommunizieren möchte, die am kontrollierten Port des Authenticators anliegen, kann dies nur geschehen, sofern sich beide kontrollierten Ports -- sowohl der des Supplicants als auch der des Authenticators -- im authorisierten Status befindet. Dieser Fall tritt ein, nachdem sich der Supplicant authentifiziert und kein (optionales) Logoff angefordert hat.
+Standardmäßig kann der Supplicant nur mit dem Authenticator kommunizieren und mit Systemen, für die keine weiteren Zugriffsregeln definiert sind, und die somit am nicht kontrollierten Port des Authenticators anliegen (welche Dienste dies sind ist eine Frage der spezifischen Systemkonfiguration). Falls der Supplicant mit Systemen kommunizieren möchte, die am kontrollierten Port des Authenticators anliegen, kann dies nur geschehen, sofern sich beide kontrollierten Ports -- sowohl der des Supplicants als auch der des Authenticators -- im autorisierten Status befindet. Dieser Fall tritt ein, nachdem sich der Supplicant authentifiziert und kein (optionales) Logoff angefordert hat.
-Es ist aber auch für den Supplicant möglich, seinen kontrollierten Port in den nicht authorisierten Modus zu schalten und somit die Kommunikation mit den vom Authenticator angebotenen Diensten zu verweigern. Dies kann nützlich sein, falls der Authenticator seine Identität nicht bestätigen konnte und so nicht sichergestellt ist, ob der Kommunikation mit ihm vertraut werden kann oder ob ein Angreifer im Spiel ist (siehe dazu Kapitel~\ref{chap:sicherheit} für Angriffsszenarien).
+Es ist aber auch für den Supplicant möglich, seinen kontrollierten Port in den nicht autorisierten Modus zu schalten und somit die Kommunikation mit den vom Authenticator angebotenen Diensten zu verweigern. Dies kann nützlich sein, falls der Authenticator seine Identität nicht bestätigen konnte und so nicht sichergestellt ist, ob der Kommunikation mit ihm vertraut werden kann oder ob ein Angreifer im Spiel ist (siehe dazu Kapitel~\ref{chap:sicherheit} für Angriffsszenarien).
%% TODO: hier vielleicht noch Grafik hin mit kontrolliert/unkontrollierten Ports?
Weiterhin hängt es vom verwendeten Authentifizierungsmechanismus ab, ob die Kommunikation nach der Authentifizierung bidirektional oder unidirektional stattfinden kann. Falls ein Mechanismus verwendet wurde, der nur die Identität des Supplicants sicherstellt (wie z.~B. \acr{EAP MD5-CHALLENGE}), ist nur ein unidirektionaler Zugriff des Supplicants auf die Dienste des Authenticators möglich. Für einen bidirektionalen Zugriff müssen sich beide Seiten durch einen geeigneten Mechanismus (wie die oben genannten \acr{EAP-TLS}, \acr{EAP-TTLS} oder \acr{PEAP}) ausweisen. In eduroam ist dies immer der Fall, sodass auch der Benutzer sicher sein kann, dass er seine Login-Daten an das richtige System sendet.
\section{Benutzerauthentifizierung im Detail}
Dieses Kapitel erklärt die Vorgehensweise bei der Benutzerauthentifizierung im Detail.
-Sobald der Benutzer eine Einwahl in das eduroam-Netz anfordert, wird vom \acr{IEEE~802.1X}-Supplicant eine Verbindung zum Authenticator aufgebaut. Zu diesem Zeitpunkt befinden sich auf der Supplicant- und auf der Authenticator-Seite beide kontrollierten Ports im nicht authorisierten Status.
+Sobald der Benutzer eine Einwahl in das eduroam-Netz anfordert, wird vom \acr{IEEE~802.1X}-Supplicant eine Verbindung zum Authenticator aufgebaut. Zu diesem Zeitpunkt befinden sich auf der Supplicant- und auf der Authenticator-Seite beide kontrollierten Ports im nicht autorisierten Status.
Typischerweise beginnt nun der Authenticator die Authentifizierung über \acr{EAPOL}, aber auch der Supplicant kann die Authentifizierung starten, indem er ein \acr{EAPOL}-Start-Paket sendet. Alle nachfolgenden \acr{EAP}-Pakete werden durch \acr{EAPOL-EAP}-Pakete gekapselt, der Ablauf ist wie folgt:
\item \label{eap-auth} In jedem Fall prüft der Authenticator die Login-Daten und sendet ein \acr{EAP}-Success-Paket, falls der Vorgang erfolgreich war (in diesem Fall ist der Benutzer authentifiziert), oder ein \acr{EAP}-Failure-Paket andernfalls (der Benutzer wurde nicht authentifiziert).
\end{enumerate}
-Zu diesem Zeitpunkt wird der kontrollierte Port des Supplicants und des Authenticators auf den authorisierten bzw. nicht authorisierten Status gesetzt und dem Supplicant wird der Zugriff auf die entsprechenden Dienste gewährt oder verweigert.
+Zu diesem Zeitpunkt wird der kontrollierte Port des Supplicants und des Authenticators auf den autorisierten bzw. nicht autorisierten Status gesetzt und dem Supplicant wird der Zugriff auf die entsprechenden Dienste gewährt oder verweigert.
Interessant ist die Umsetzung bei der Prüfung der Authentifizierungsinformationen in Schritt~\ref{eap-auth}. Hier setzt in eduroam die \acr{RADIUS}-Authentifizierung ein. Der Authenticator kommuniziert mit seinem nächstgelegenen \acr{RADIUS}-Server (auf Institutionsebene), indem er eine \acr{RADIUS}-\emph{Access-Request}-Nachricht an ihn schickt, das die Login-Daten des Benutzers enthält. Der \acr{RADIUS}-Server antwortet entweder direkt oder fragt nach dem selben Prinzip beim \acr{RADIUS}-Server der nächsthöheren Ebene an, und antwortet schließlich entweder mit einer \emph{Access-Accept}-Nachricht (der Benutzer wurde authentifiziert), oder mit einer \emph{Access-Reject}-Nachricht (der Benutzer wurde nicht authentifiziert), oder mit einer \emph{Access-Challenge}-Nachricht, die die andere Seite auffordert, eine neue \emph{Access-Request}-Nachricht mit mehr Informationen zu schicken, um die Authentifizierung zu behandeln.
\label{fig:edugain}
\end{figure}
-Um erweiterte Benutzerautorisierung zu implementieren, wurde das \emph{eduGAIN}-Projekt gestartet. Es hat zum Ziel, existierende Institutionen durch eine Authentifizierungs- und Autorisierungs-Infrastuktur zu verbinden. Die Infrastruktur (siehe Abb. \ref{fig:edugain}) besteht aus \emph{Bridged Elements} (BE), die von den Institutionen gestellt werden und die Kommunikation zwischen Institutionen regeln sowie Authentifizierungs- und Autorisierungsinformationen bereitstellen; und zum anderen einem \emph{MetaData Service} (MDS), der Metadaten über existierende Bridged Elements sammelt und zwischen ihnen vermittelt. Er dient als zentraler Lokationsservice, den ein Bridged Element benutzt, um zum Austausch von Autorisierungsinformationen mit Bridged Elements anderer Institutionen Kontakt aufzunehmen.
+Um erweiterte Benutzerautorisierung zu implementieren, wurde das \emph{eduGAIN}-Projekt gestartet. Es hat zum Ziel, existierende Institutionen durch eine Authentifizierungs- und Autorisierungs-Infrastruktur zu verbinden. Die Infrastruktur (siehe Abb. \ref{fig:edugain}) besteht aus \emph{Bridged Elements} (BE), die von den Institutionen gestellt werden und die Kommunikation zwischen Institutionen regeln sowie Authentifizierungs- und Autorisierungsinformationen bereitstellen; und zum anderen einem \emph{MetaData Service} (MDS), der Metadaten über existierende Bridged Elements sammelt und zwischen ihnen vermittelt. Er dient als zentraler Lokationsservice, den ein Bridged Element benutzt, um zum Austausch von Autorisierungsinformationen mit Bridged Elements anderer Institutionen Kontakt aufzunehmen.
Im Kontext von eduGAIN führen López et al. \cite{Lopez2008418}\cite{Lopez2007900} ein weiteres Modell namens \emph{\acr{NAS-SAML}} ein, das zur Verwaltung und Abfrage von Autorisierungsattributen genutzt werden kann und auf den XML-basierten Sprachen SAML (\emph{Security Assertion Markup Language}) und XACML (\emph{eXtensible Access Control Markup Language}) basiert. Mittels SAML werden Authentifizierungs- und Autorisierungsinformationen ausgetauscht, während XACML dazu genutzt wird, Richtlinien für die Autorisierung zu definieren.
\item einen \emph{Policy Decision Point} in der besuchten Institution, der den Zugriff auf bestimmte Netzwerkressourcen regelt
\end{itemize}
-Die Kommunikation zwischen \acr{RADIUS}-Server und Bridged Element findet bevorzugt über \acr{LDAP} (Lightweight Directory Access Protocol) statt; einem weit verbreiteten Protokoll zur Abfrage von Daten aus einem Verzeichnis. Bridged Elements verständigen sich untereinader über \acr{SAML}, das im XML-basierten \acr{SOAP} über HTTP oder ähnliche Protokolle auf Anwendungsschicht gekapselt wird, um Prozeduren auf entfernten Systemen aufzurufen (sog. \emph{Remote Procedure Call}).
+Die Kommunikation zwischen \acr{RADIUS}-Server und Bridged Element findet bevorzugt über \acr{LDAP} (Lightweight Directory Access Protocol) statt; einem weit verbreiteten Protokoll zur Abfrage von Daten aus einem Verzeichnis. Bridged Elements verständigen sich untereinander über \acr{SAML}, das im XML-basierten \acr{SOAP} über HTTP oder ähnliche Protokolle auf Anwendungsschicht gekapselt wird, um Prozeduren auf entfernten Systemen aufzurufen (sog. \emph{Remote Procedure Call}).
Die Authentifizierungsphase über \acr{RADIUS} wird dahingehend erweitert, dass der Server der Home Institution dem anfragenden Server der Remote Institution in der RADIUS-\emph{Access-Accept}-Nachricht ein \emph{Handle} mitgibt, mit dem dieser über das Bridged Element seiner Institution weitere Attribute des Benutzers abfragen kann. Das Bridged Element der Remote Institution leitet die Autorisierungsanfragen über SAML an das Bridged Element der Heiminstitution weiter, wobei das vorher erhaltene Handle als Schlüssel dient, um dem Bridged Element der Heiminstitution die Berechtigung nachzuweisen.
\section{Einführung}
-\emph{eduroam} leitet sich von "`\emph{edu}cational \emph{roam}ing"' ab und ist ein Verbund von Netzwerken, der es Mitgliedern der teilnehmenden Institutionen (insbesondere Hochschulen und andere Forschungs- und Bildungseinrichtungen) einen unkomplizierten Netzzugang an allen anderen teilnehmenden Institutionen, beispielsweise über \acr{LAN} oder \acr{WLAN}, ermöglicht. Dabei erhält der Besucher mit den Login-Daten seiner Heimatinstitution Zugriff auf das Netz. So wird die Kommunikation in Forschung und Lehre auch bei Dienstreisen, Konferenzen oder Auslandssemestern nahtlos ermöglicht, und es entfällt die Notwendigkeit einer Einrichtung von (eventuell ungeschützten oder mit Standardpassworten versehenen) Gastzugängen, die missbraucht werden könnten, oder sonstigen zusätzlichen Benutzerkonten für Besucher.
+\emph{eduroam} leitet sich von "`\emph{edu}cational \emph{roam}ing"' ab und ist ein Verbund von Netzwerken, der es Mitgliedern der teilnehmenden Institutionen (insbesondere Hochschulen und andere Forschungs- und Bildungseinrichtungen) einen unkomplizierten Netzzugang an allen anderen teilnehmenden Institutionen, beispielsweise über \acr{LAN} oder \acr{WLAN}, ermöglicht. Dabei erhält der Besucher mit den Login-Daten seiner Heiminstitution Zugriff auf das Netz. So wird die Kommunikation in Forschung und Lehre auch bei Dienstreisen, Konferenzen oder Auslandssemestern nahtlos ermöglicht, und es entfällt die Notwendigkeit einer Einrichtung von (eventuell ungeschützten oder mit Standardpassworten versehenen) Gastzugängen, die missbraucht werden könnten, oder sonstigen zusätzlichen Benutzerkonten für Besucher.
Die Organisation \emph{\acr{TERENA}} (Trans-European Research and Education Networking Association), eine Dachorganisation, die sich aus den Organisationen der einzelnen nationalen Forschungsnetzwerke (\acr{NREN}, \emph{National Research and Education Network}) zusammensetzt, startete das eduroam-Programm im Jahr 2003. Sie pflegt auch die grundlegende Server-Infrastruktur. Nahezu alle europäischen \acr{NREN}s nehmen am eduroam-Programm teil; dessen Verbreitung ist aber nicht auf Europa an sich beschränkt, sodass eduroam auch in einigen asiatischen und pazifischen Ländern (insbesondere China, Japan und Australien) und in Kanada zur Verfügung steht.
-Innerhalb des eduroam-Netzes wird aber nicht nur auf Benutzerauthentifikation Wert gelegt, sondern es besteht auch die Möglichkeit der Benutzerautorisierung, um den Zugriff auf bestimmte Netzressourcen an Bedingungen zu koppeln. So sind Szenarien denkbar, wo bestimmte Ressourcen (z.~B. Drucker) nur von berechtigten Personen genutzt werden dürfen. Diese Autorisierungsmechanismen werden durch \emph{edu\acr{GAIN}} (\acr{GÉANT} Authorisation Infrastructure, \acr{GÉANT} bezeichnet das gesamte, pan-europäische Forschungsnetz) bereitgestellt.
+Innerhalb des eduroam-Netzes wird aber nicht nur auf Benutzerauthentifizierung Wert gelegt, sondern es besteht auch die Möglichkeit der Benutzerautorisierung, um den Zugriff auf bestimmte Netzressourcen an Bedingungen zu koppeln. So sind Szenarien denkbar, wo bestimmte Ressourcen (z.~B. Drucker) nur von berechtigten Personen genutzt werden dürfen. Diese Autorisierungsmechanismen werden durch \emph{edu\acr{GAIN}} (\acr{GÉANT} Authorisation Infrastructure, \acr{GÉANT} bezeichnet das gesamte, pan-europäische Forschungsnetz) bereitgestellt.
\begin{figure}[h]
\centering
\begin{enumerate}
\item Begriffsdefinitionen, Unterscheidung Identity Provider / Service Provider
\item Sicherer Netzzugang (IEEE 802.1X)
- \item Benutzerauthentifizierung und -authorisierung (IEEE 802.1X, RADIUS)
+ \item Benutzerauthentifizierung und -autorisierung (IEEE 802.1X, RADIUS)
\end{enumerate}
\item Benutzerauthentifizierung im Detail -- ca.~4--5 Seiten
\item Zugriff auf Heimatnetzwerk
\end{enumerate}
- \item Benutzerauthorisierung im Detail (eduGAIN) -- ca.~3-4 Seiten
+ \item Benutzerautorisierung im Detail (eduGAIN) -- ca.~3-4 Seiten
\begin{enumerate}
\item Benutzerattribute, XACML, SAML
\end{enumerate}
Lenstra and David Molnar and Dag Arne Osvik and Benne de Weger",
title = "{MD5 considered harmful today}",
howpublished = "\url{http://www.win.tue.nl/hashclash/rogue-ca/}"
-}
\ No newline at end of file
+}
\section{Sicherheitsaspekte}\label{chap:sicherheit}
\subsection{Gefälschte Zertifikate}
-Falls \acr{EAP-TLS} oder \acr{EAP-TTLS} zur Authentifizierung verwendet werden, ist es die Aufgabe des Benutzers, sicherzustellen, dass der Authenticator sich korrekt ausweist. Dies kann geschehen, indem der Service Provider den Fingerabdruck des genutzten Zertifikats veröffentlicht, der vom Benutzer geprüft werden kann. Alternativ kann der Service Provider sein Zertifikat mit einer digitalen Unterschrift durch eine Zertifizierungsstelle beglaubigen lassen und so seine Identität gegenüber dem Benutzer bezeugen. Ist dies beides nicht der Fall, gibt es für den Benutzer keine sichere Möglichkeit, festzustellen, ob der Authenticator, mit dem er kommuniziert, in irgend einer Form vertrauenwürdig ist.
+Falls \acr{EAP-TLS} oder \acr{EAP-TTLS} zur Authentifizierung verwendet werden, ist es die Aufgabe des Benutzers, sicherzustellen, dass der Authenticator sich korrekt ausweist. Dies kann geschehen, indem der Service Provider den Fingerabdruck des genutzten Zertifikats veröffentlicht, der vom Benutzer geprüft werden kann. Alternativ kann der Service Provider sein Zertifikat mit einer digitalen Unterschrift durch eine Zertifizierungsstelle beglaubigen lassen und so seine Identität gegenüber dem Benutzer bezeugen. Ist dies beides nicht der Fall, gibt es für den Benutzer keine sichere Möglichkeit, festzustellen, ob der Authenticator, mit dem er kommuniziert, in irgend einer Form vertrauenswürdig ist.
\subsection{Denial of Service durch gefälschte EAPOL-Pakete}
Falls das Netzwerkmedium von mehreren Teilnehmern gleichzeitig genutzt wird (wie z.~B. über \acr{WLAN} oder von mehreren Rechnern hinter einem Hub), ist es möglich, durch gefälschte \acr{EAPOL}-\emph{Logoff}-Pakete einen Denial of Service (Dienstverweigerung) hervorzurufen. In diesem Szenario nutzt ein Angreifer, der Zugriff auf das gemeinsam genutzte Medium hat, die Tatsache aus, dass \acr{EAPOL}-\emph{Logoff}-Pakete im Klartext gesendet werden und keinerlei Identitäts- oder Integritätsinformationen beinhalten, und sendet fortlaufend solche Pakete mit der \acr{MAC}-Adresse des Gerätes, das Ziel des Angriffs ist, als Absender. Dies hat zur Folge, dass der Authenticator für das Zielgerät den Zugriff auf die kontrollierten Netzwerkressourcen sperrt, obwohl dieses kein Logoff angefordert hat.
\section{Zusammenfassung}
-Die Sicherheit in eduroam findet durchgängig über verschlüsselte oder teilweise verschlüsselte Protokolle statt, so bei der Benutzerauthentifizierung über \acr{IEEE~802.1X} sowie dem dahinter geschalteten Verbund von \acr{RADIUS}-Servern in Form von MD5-verschlüsselten Passwörtern. Allerdings gibt es einige Schwachstellen im Design der IEEE~802.1X-Standards, die jedoch in der aktuellen Revision behoben sind. Weiterhin versucht das eduroam-ng-Projekt, die Sicherheit und Verlässlichkeit des Systems auszubauen, indem es stärkere Verschlüsselung mittels RadSec und Perr Review zur Verteilung der Anfragen an die Top-Level-RADIUS-Server einführt.
+Die Sicherheit in eduroam findet durchgängig über verschlüsselte oder teilweise verschlüsselte Protokolle statt, so bei der Benutzerauthentifizierung über \acr{IEEE~802.1X} sowie dem dahinter geschalteten Verbund von \acr{RADIUS}-Servern in Form von MD5-verschlüsselten Passwörtern. Allerdings gibt es einige Schwachstellen im Design der IEEE~802.1X-Standards, die jedoch in der aktuellen Revision behoben sind. Weiterhin versucht das eduroam-ng-Projekt, die Sicherheit und Verlässlichkeit des Systems auszubauen, indem es stärkere Verschlüsselung mittels RadSec und Peer Review zur Verteilung der Anfragen an die Top-Level-RADIUS-Server einführt.
Ebenso findet bei der Benutzerauthentifizierung ebenso nicht nur eine Überprüfung des Benutzers, sondern auch des Anbieters statt, sodass Betrugsfälle ausgeschlossen werden können, falls der Service Provider die entsprechenden Vorkehrungen dazu getroffen hat und sein Zertifikat vertrauenswürdig erscheinen lässt.
projects / seminar-bachelor.git / commitdiff