view doc/help/client/techn-referenz.rst @ 1213:57879b3ae12a

Icons, src: Small Makefile improvement.
author Bernhard Reiter <bernhard@intevation.de>
date Tue, 23 Sep 2014 21:23:42 +0200
parents cf1fdb254c41
children
line wrap: on
line source
===================
Technische Referenz
===================


Welche Zertifikatsspeicher werden verwendet?
============================================

Damit Zertifikaten in Anwendungen (wie z.B. Browser oder E-Mail-Klient)
vertraut werden kann, müssen die zugehörigen Wurzelzertifikate in den passenden
Zertifikatsspeichern des Systems installiert werden.
TrustBridge übernimmt diesen Zugriff auf die Zertifikatsspeicher.

Es gibt zwei gängige Zertifikatsspeicher, die von TrustBridge und den meisten
Anwendungen unterstützt werden:

* der Mozilla NSS-Zertifikatsspeicher ("Network Security Services") und 
* der Windows-System-Zertifikatsspeicher.


Chrome bzw. Chromium verwendet unter Windows den Windows-System-Speicher und unter
Ubuntu den NSS-Zertifikatsspeicher. Die nachfolgende Abbildung veranschaulicht 
die verwendeten Zertifikatsspeicher unter Windows und GNU/Linux.

.. figure:: _static/stores.png
   :width: 100%
   :alt: Übersicht der Zertifikatsspeicher

   *Abbildung 1: Übersicht der Zertifikatsspeicher*

Windows-Zertifikatsspeicher
---------------------------

Der Windows 7 und 8 Zertifikatsspeicher kann in drei große Gruppen aufgeteilt werden:

#. Zertifikate des aktuellen Benutzers
#. Zertifikate für alle Benutzer (Lokaler Computer)
#. Zertifikate für Systemdienste

Diese Gruppen unterteilen sich wieder in eine Reihe von logischen Speichern.

Für die Installation von vertrauenswürdigen Wurzelzertifikaten ist der
logische *Root*-Speicher relevant. Nur dort eingetragene Zertifikate
werden als *Trust Anchor* (Vertrauensanker) angesehen und zur
Validierung des Vertrauenspfads zu den weiteren Zertifikaten
verwendet.

Der logische *Disallowed*-Speicher hat immer Vorrang. Befindet sich ein Zertifikat
sowohl im *Root* als auch im *Disallowed*-Speicher, gilt es als nicht vertrauenswürdig.


**Einschränkungen:** 
Um unbefugte Manipulationen am Zertifikatsspeicher zu verhindern, werden von Microsoft
seit Windows XP SP2 folgende Schutzmaßnahmen vorgesehen:

#. Um Zertifikate für alle Benutzer des lokalen Computers zu
   bearbeiten, sind erhöhte Privilegien (Administrationsrechte)
   erforderlich.
#. Änderungen (Löschen / Hinzufügen von Zertifikaten) am
   *Root*-Speicher des aktuellen Nutzers erfordern die explizite
   Einwilligung des Nutzers (siehe nachfolgende Abbildung), sofern der
   Prozess keine erhöhten Privilegien besitzt.


.. figure:: _static/sicherheitswarnung.png
   :alt: Windows-Sicherheitswarnung 

   *Abbildung 2: Sicherheitswarnung beim Hinzufügen eines Wurzelzertifikats ohne Administrator-Rechte*



Mozilla NSS-Zertifikatsspeicher
-------------------------------
Die Mozilla-Anwendungen Thunderbird und Firefox, sowie Chromium unter
Ubuntu, verwenden die Mozilla "Network Security
Services" (NSS) Zertifikatsspeicher. 

Mozilla liefert den NSS-Zertifikatsspeicher mit einer Auswahl von
voreingesetllten vertrauenswürdigen bzw. nicht
vertrauenswürdigen Zertifikaten aus.

**Einschränkungen:**

* Anwendungen, die den NSS-Zertifikatsspeicher verwenden, sollten vor dem Zugriff geschlossen
  werden.
* Um den NSS-Speicher anderer Nutzer zu manipulieren, sind erhöhte Rechte nötig.
* Um den NSS-Standard für neue Profile vorzugeben, sind abhängig vom Installationsort 
  ggf. erhöhte Rechte nötig.



Wie wird der Transport abgesichert?
===================================
TrustBridge sucht regelmäßig (alle 24 Stunden) auf dem offiziellen TrustBridge-Update-Server
nach aktualisierten Zertifikatslisten und neuen Softwareversionen. 

Sämtliche Transportprozesse sind kryptografisch nach aktuellem Stand
der Technik gegen unbefugte Manipulationen (Authentizität und
Integrität) gesichert. Es gibt drei Transportwege, die abgesichert
werden müssen:

#. Verfügbarkeit von Aktualisierungen prüfen:
   Die regelmäßige Übertragung der Information, ob neue Aktualisierungen
   von Zertifikatsliste oder Software verfügbar sind, wird über eine
   HTTPS-Verbindung per TLS 1.2 (mit ECDSA brainpoolP256r1) durchgeführt.
#. Zertifikatslisten-Update durchführen:
   Ist eine neue Zertifikatsliste verfügbar, wird die ganze Liste
   gebündelt übertragen. Die Zertifikatslistendatei ist signiert (RSA 3076). 
   Vor einem Zertifikatslisten-Update wird sichergestellt, dass TrustBridge bereits in der
   neusten Version installiert ist.
#. Software-Update durchführen:
   Ist eine neue TrustBridge-Version verfügbar, kann diese mit einem
   Klick auf eine entsprechende Meldung heruntergeladen und installiert
   werden. Es wird eine vollständige TrustBridge-Installationsdatei übertragen 
   und im Hintergrund ausgeführt. Jede Software-Installationsdatei ist signiert.
   Bei Fehlschlagen der Signaturprüfung (z.B. durch fehlerhaftes
   Herunterladen) wird TrustBridge nicht aktualisiert. 



Wie sieht das Datenformat einer Zertifikatsliste aus?
=====================================================

Die Zertifikatsliste ist eine einzelne Text-Datei, welche von der
TrustBridge-Verwaltungsanwendung erzeugt wird. Diese Datei enthält
alle benötigten Informationen und basiert auf einer zeilenbasierten
Textformat. Dabei bleibt die Struktur für Menschen lesbar und die
meisten Inhalte können mit Standardwerkzeugen sowohl de- als auch
enkodiert werden.

In der ersten Zeile der Datei ist die Base64-kodierte, kryptografische
Signatur über alle folgenden Zeilen (inklusive der Zeilenenden)
angegeben. So wird die Integrität und Authentizität dieser Daten vor
der Verarbeitung gesichert.

Einzelne Zeilen haben das Format ``<Buchstabe>:<Wert><CR><LF>``, wobei
der Buchstabe angibt, welche Art von Wert folgt. Die Länge der Zeilen
ist (für Version 1) auf 9999 Zeichen begrenzt, inklusive der beiden
Zeichen für Zeilenenden.  Die Anzahl der Zeilen ist auf 1000
beschränkt, was einer Dateigröße von maximal 10 Megabyte entspricht.
(In der Praxis wird die Dateigröße aber deutlich unter 100 Kilobyte
liegen.) Der Text wird in 7Bit-ASCII kodiert.

Die Zertifikate selbst werden als Base64- und DER-kodierte Daten
aufgeführt. Dies entspricht dem Inhalt gängiger .pem-Dateien - jedoch
ohne den umschließenden BEGIN CERTIFICATE und END CERTIFICATE sowie
ohne den Zeilenumbrüchen.

Jede Zeile muss mit einem der folgenden gültigen Buchstaben beginnen:

* ``S:`` Die Signatur der Zertifikatsliste.
* ``F:`` Format-Version
* ``D:`` Zeitpunkt der Listenerstellen (UTC)
* ``I:`` Zu installierendes Zertifikat
* ``R:`` Zu entfernendes Zertifikat


Im Folgenden ein Beispiel für den Aufbau der Zertifikatslisten-Datei
mit zwei zu installierenden Zertifikaten und einem zu löschenden
Zertifikat. Die Signatur- und Zertifikatszeilen sind, aus Gründen der
Übersichtlichkeit, in diesem Beispiel gekürzt:

.. parsed-literal::
    S:EjzX0sTkstnnGbPIC7n1a5WlYCFsthPl8OYplLyihR1RdqcUsSnikrVowFo8QgpMutcz0...
    F:1
    D:2014-01-03T12:30Z
    I:MIIEiTCCA3GgAwIBAgIDAWn+MA0GCSqGSIb3DQBQUAMEAxCzAJBVBAYTAlVTMRcwFQYDV...
    I:MIIHojCCBoqgAwIBAgIDAW96MA0GCSqGSIb3DQEBBQUAGMMQswCDVQQGEwJJTDEWMBQGA...
    R:MIIGUjCCBTqgAwIBAgIODocAAQACqS54FrSbGvYwDQKoZIhvcNAQBQAwfDELMAkGA1UEB...

http://wald.intevation.org/projects/trustbridge/