Zertifikate über das TCS

Um im Internet Daten vertraulich (d. h. nur für Berechtigte lesbar) übertragen zu können, müssen sie verschlüsselt transportiert werden, dafür hat sich im Bereich Webserver SSL (die neueren Versionen heißen inzwischen TLS) durchgesetzt: ein hybrides Verschlüsselungsverfahren, bei dem per (langsamer) asymmetrischer Verschlüsselung ein schneller symmetrischer Schlüssel (sitzungsbezogen) ausgetauscht wird.

Damit asymmetrische Verschlüsselungen funktionieren, müssen Sie dem öffentlichen Schlüssel der Seite vertrauen (nämlich, daß das wirklich z. B. der Schlüssel der Bank ist, mit der Sie kommunizieren wollen und daß somit nur die Bank die übermittelten Daten auch wieder entschlüsseln kann). Dies kann entweder über gegenseitiges Vertrauen geschehen (WoT) oder durch Zertifikate, mit denen eine Certificate Authority (CA) bestätigt, daß ein Schlüssel gültig ist und der richtigen Stelle gehört, Sie müssen dann „nur“ dieser CA vertrauen.
Solche CAs müssen bei den Browser-Herstellern viel Geld einzahlen, damit der Browser ihren Stamm-Zertifikaten (root certificate) automatisch vertraut - wenn man von einem solchen Anbieter dann einen öffentlichen Schlüssel zertifizieren lassen will, kostet das dann natürlich entsprechend.

Als Teilnehmer von ACOnet haben wir die Möglichkeit gratis solche Zertifikate zu beziehen. Grundsätzlich basiert das Service auf einem Vertrag zwischen DigiCert Inc. (Lehi, Utah, USA) und GEANT (früher TERENA), dem Verband europäischer Wissenschaftsnetze (den sog. NRENs), den auch ACOnet (der Betreiber des österreichischen Wissenschaftsnetzes und somit Provider der TU Graz) unterzeichnet hat.

Dabei gilt:

  • Für Zertifikate, die auf diesem Weg ausgestellt werden, fallen für den Endbenutzer keine Kosten an.
    Für die TU Graz, als ACOnet-Teilnehmer, gilt dies für alle Server in der Domain tugraz.at; weiters verwalten wir Zertifikate für Server im VCG.
  • Weitere Domains wären prinzipiell möglich, aber nur, wenn wir die Domain auch verwalten (was wir i. Allg. aber nicht machen).
  • Die Zertifikate dürfen nicht für kommerzielle Zwecke genutzt werden (z. B. für ein Webshop o. ä.)
  • Die Zertifikate dürfen zwar für Finanztransaktionen (z. B. Übermittlung von Kreditkartendaten bei Tagungsanmeldungen) verwendet werden - beachten Sie aber, daß diese Daten danach auch sicher verarbeitet und verschlüsselt gespeichert werden müssen, Sie haften sonst im Falle eines Datenlecks eventuell für Schäden!
    Wir raten daher dringend davon ab ohne professionelle Verarbeitungssoftware Kreditkartendaten abzufragen und zu verarbeiten!
  • Vertragspartner ist immer die TU Graz, Institute müssen die ACOnet-Zusatzvereinbarung also nicht unterzeichnen!

Bis auf E-Mail-Zertifikate werden alle Zertifikate nur auf Antrag von EDV-Beauftragten ausgestellt, für EV-Multidomain-SSL-Zertifikate für Institute steht dafür ein Webinterface zur Verfügung, weitere Infos gibt es im ACOnet-Wiki.

Anmerkung

Die Verschlüsselung (z. B. HTTPS) sagt nichts über die Sicherheit der Daten an sich aus und auch nichts darüber, was z. B. der Empfänger mit den Daten tun wird (unverschlüsselt speichern, veröffentlichen, verkaufen, …), sondern nur etwas darüber, wie die Daten vom Client (z. B. Ihrem Browser) zum Server (z. B. einer Bank-Webseite) übertragen werden.

Und auch bei HTTPS gibt es unterschiedliche Sicherheitsniveaus, die Sie sich anschauen sollten. Für den Browser Firefox gibt es dafür z. B. das Add-on Calomel SSL Validation.

Das bedeutet aber, daß es eine ganze Reihe von Angriffspunkten gibt:

  • Das Schloßsymbol sagt nichts aus - das Zertifikat kann wirklich gültig sein - überprüfen Sie die Domain (z. B. tugraz.al statt tugraz.at oder tugrɑz.at statt tugraz.at) und auf wen das Zertifikat ausgestellt ist!
  • Die Daten können auf Ihrem Rechner (z. B. im Browser oder im Betriebssystem) schon vor der Übertragung manipuliert werden, wenn Sie sich Malware eingefangen haben:
    Wenn Ihr Browser oder Ihre Grafikkarte Ihnen ein anderes Konto anzeigt, als dann tatsächlich übermittelt wird, können Sie das kaum überprüfen.
  • Die Übertragung findet vielleicht gar nicht zum richtigen Server statt:
    Der Nameserver, den Sie verwenden, wurde manipuliert und Sie verbinden sich daher gar nicht zum richtigen Server mybank.at, dieser Server hat aber selbst auch ein (scheinbar) gültiges Zertifikat (weil z. B. die CA kompromittiert wurde).
  • Die eingesetzte Verschlüsselung könnte bereits geknackt sein: Überprüfen Sie, ob Ihr Programm nur sichere oder auch unsichere Methoden unterstützt.
  • Die Daten können nach der Übertragung manipuliert werden:
    Der Server der Bank wurde „gehackt“ und Ihre Daten werden manipuliert oder …

SSL- bzw. TLS-Server-Zertifikate

Neben den bekannten SSL-/TLS-Server-Zertifikaten (https statt http für Webserver) gibt es auch Multi-Domain-Zertifikate (ein Zertifikat für mehrere virtuelle Server auf einer gemeinsamen Hardware), aber auch Wild-Card-Zertifikte (in der Art *.institut.tugraz.at).

Wie Sie einen CSR erstellen (den Sie zur Beantragung eines Zertifikates benötigen) und das Zertifikat dann installieren, ist z. B. bei DigiCert beschrieben.

Neue Vorgaben

Aufgrund neuer Vorgaben durch das CAB-Forum (ein Verband von Browser-Herstellern) gibt es nun 3 Arten von Server-Zertifikaten:

  1. DV-Zertifikate
  2. OV-Zertifikate
  3. EV-Zertifikate

Bei DV-Zertifikaten wird zwar die Richtigkeit des Zertifikats für die Domain der TU Graz bestätigt, die (Unter-)Organisation, der das Zertifikat gehört, ist aber nicht mehr Teil des Zertifikats.
Wir unterstützen derzeit nur EV-Zertifikate (die höchste Kategorie), da deren Bezug nun auch einfach und schnell geht. Sollten Sie ein anderes Zertifikat brauchen, dann setzen Sie sich bitte mit uns in Verbindung.

Bestellung

Die Bestellung führen Sie über https://ssl.tugraz.at/ durch.

Installation

Am Beispiel Apache:
Wenn Sie Ihr Zertifikat myserver.crt, das zum Key myserver.key gehört, erhalten, dann ist es notwendig dieses zusammen mit dem Intermediate-Zertifikat als Zertifikatskette am Server zu hinterlegen:
Sie laden sich das TERENA_SSL_High_Assurance_CA_3.pem herunter und tragen dann die Zertifikatsdateien in der Konfig-Datei des Apache ein, z. B.:

SSLCACertificateFile /etc/ssl/certs/TERENA_SSL_High_Assurance_CA_3.pem
SSLCertificateFile /etc/ssl/certs/myserver.crt
SSLCertificateKeyFile /etc/ssl/certs/myserver.key

Das zugehörige Root-Zertifikat DigiCertHighAssuranceEVRootCA.crt sollte der Browser dann schon kennen.

Bei Problemen

Falls Browser das DigiCert-Root-Zertifikat nicht kennen, kann man es von der DigiCert- oder TERENA-Homepage heruntergeladen und im Client installieren - wenn am Server die „Certificate-Chain“ (Server- und Intermediate- bzw. Root-Zertifikat) stimmt, dann sollte das Server-Zertifikat dann vom Client (dem Browser bzw. dem E-Mail-Programm etc.) akzeptiert werden.

Smartphones

Falls Ihr Smartphone dem Root-Zertifikat von DigiCert nicht vertraut, können Sie dieses Zertifikat installieren, indem Sie von Ihrem Mobiltelefon aus ebenfalls die Seite mit den Root-Zertifikaten öffnen und von dort das Root-Zertifikat herunter laden. Je nach Betriebssystem des Mobiltelefons müssen Sie dann das Zertifikat noch von der SD-Karte installieren (und z. B. einem WLAN-Profil zuweisen).

Test

Client

Beim Aufruf der Seite https://online.tugraz.at/ sollte dann im Browser neben der Location auch der Name der Organisation (Technische Universität Graz (AT)) angezeigt werden (EV-Zertifikat), außerdem dürfte es keine Fehlermeldung geben.

Server

Auf der DigiCert-Homepage gibt es Tools zum Testen der Installation.

Revoken

Alte Zertifikate können Sie zurückziehen, indem Sie uns die Zertifikatsnummer melden.

top

Code Signing-Zertifikate

Aktuell muß man vorab definieren, welche Zertifikate man für End-User zugänglich macht - damit das einfach bleibt, haben wir uns für Multi-Domain-EV-Zertifikate entschieden, die fast für alle Anwendungen passen. Andere Zertifikate (z. B. Code Signing-Zertifikate) müssen Sie über die TCS-Admins bestellen, indem Sie einen CSR an die TCS-Admins übermitteln.

top

E-Mail-Zertifikate

Man kann als Angehöriger der TU Graz (Personen mit Dienst-/Rechtsverhältnis bzw. Studierende) gratis persönliche E-Mail-Zertifikate über DigiCert beantragen um E-Mails per S/MIME signieren oder auch verschlüsseln zu können. Verfügbar sind diese Zertifikate allerdings nur für ausgewiesene Personen der TU Graz, d. h. Personen, bei denen in TUGRAZonline hinterlegt ist, daß von der Personalabteilung oder dem Studienservice ein Ausweis kontrolliert wurde - dies trifft für alle Personen zu, die in ihrer TUGRAZonline-Visitenkarte den Punkt „E-Mail-Zertifikat“ finden. Weiters dürfen wir (durch den Vertrag geregelt) Zertifikate nur für E-Mail-Adressen ausgeben, für die wir zentral die Zuordnung E-Mail-Adresse ⇆ Person garantieren können, das trifft nur für Adressen auf den beiden zentralen E-Mail-Servern der TU Graz zu.
Falls sowohl eine Studierenden- als auch eine Bedienstetenadresse im System hinterlegt sind, dann kann (derzeit) nur für die Bedienstetenadresse ein Zertifikat beantragt werden.

Warum verwenden?

Eine normale Übertragung einer E-Mail läuft über viele Punkte, hier schematisch und vereinfacht dargestellt:

PC Switch Server Router Internet Router Server Switch Server Switch PC
Abs.   Switch   SMTP   Router   Internet   Router   MX   Switch   IMAP   Switch   Empf.

Ist die E-Mail weder verschlüsselt noch signiert, dann kann sie bei jedem der Zwischenpunkte gelesen und auch verändert werden. Ist sie wenigstens signiert, dann kann man nachweisen, ob die E-Mail wirklich vom Absender stammt und ob sie verändert wurde.
Wird beim Versenden verschlüsseltes SMTP und zum Abholen z. B. verschlüsseltes IMAP verwendet, dann ist die E-Mail vom Absender bis zum ersten Server (SMTP) und vom letzten Server (IMAP) bis zum Empfänger auch gegen das unautorisierte Lesen sicher, dazwischen aber angreifbar und auch am Server des Absenders (Gesendet-Ordner) und des Empfängers (Inbox) liegt die E-Mail im Klartext vor.
Verwendet der SMTP-Server des Absenders ESMTP/TLS und unterstützt das auch der MX-Server des Empfängers, dann ist die E-Mail auch am Weg vom SMTP-Server des Absenders bis zum MX-Server des Empfängers (also auch im Internet) sicher (sie können das im Header einer E-Mail überprüfen: in den Received:-Zeilen steht dann etwas mit TLS).
Unterstützt nun auch noch der IMAP-Server des Empfängers ESMTP/TLS, dann ist die E-Mail am gesamten Weg (also den Teilstrecken zwischen den Servern, nicht aber auf den Servern selbst) sicher - diese an der TU bereits seit Jahren eingesetzte Kombination von Standards wird seit 2013 in Deutschland von einigen Anbietern als „E-Mail made in Germany“ beworben:

  1. Sicher vom Absender bis zu seinem SMTP-Server (secure SMTP),
  2. sicher vom SMTP-Server bis zum MX-Server (ESMTP/TLS),
  3. sicher vom MX-Server zum IMAP-/Exchange-Server (ESMTP/TLS) und
  4. sicher vom IMAP-/Exchange-Server zum Empfänger (secure IMAP/EAS).

Beim Absender (Gesendet-Ordner) und beim Empfänger (Inbox) liegen die E-Mails aber noch immer am Server im Klartext vor und teilweise auch im Cache des verwendeten Clients und auch bei den anderen betroffenen Servern (SMTP, MX) könnten die E-Mails im Klartext gelesen und auch modifiziert werden.

Obwohl die TU Graz in ihrem Teilbereich überall Verschlüsselung unterstützt (bzw. auch verlangt), ist die E-Mail nur bei einer End-to-End-Verschlüsselung wirklich sicher - wie sicher hängt dann aber natürlich noch vom verwendeten Verfahren (S/MIME, PGP oder einem symmetrischen Verfahren) ab und wie man inzwischen weiß, haben Geheimdienste wie die NSA eventuell Zugriff auf die S/MIME-Zertifikate von kommerziellen Anbietern, insofern ist die derzeit sicherste asymmetrische Methode vermutlich die Open-Source-Variante von PGP (also GnuGP).

Als Absender haben Sie - wenn Sie keine End-to-End-Verschlüsselung verwenden - nur auf die erste Wegstrecke Einfluß, beim Rest sind Sie von den Einstellungen der Provider abhängig!

Zusammengefaßt

Vorteile:
  1. Signierung ermöglicht dem Empfänger zu überprüfen, ob die E-Mail tatsächlich vom vermeintlichen Sender kommt (Urheberschaft) und ob die E-Mail verändert wurde (Unversehrtheit).
  2. Verschlüsselung hilft dagegen, daß Dritte Zugriff auf den Inhalt bekommen (Vertraulichkeit).
Zum Signieren brauche ich selbst ein Zertifikat, zum Verschlüsseln brauche ich (bei asymmetrischer Verschlüsselung) das Zertifikat des Kommunikationspartners.

Nachteile:

  1. Wenn ich meinen privaten Key verliere (Rechnertausch etc.), dann kann ich (auch früher) verschlüsselt an mich geschickte E-Mails nicht mehr lesen!
  2. Verschlüsselte E-Mails können weder auf Spam noch auf Malware untersucht werden!

Lesen Sie auch den Artikel „Mail-Verschlüsselung auf dem Rechner und mobil“.

top