comparison manuals/help-manual/techn-referenz.rst @ 1080:898b1ddcca11

help-de: new introduction; switched faq to tech-ref and added arbeitsweise.
author Bernhard Reiter <bernhard@intevation.de>
date Thu, 11 Sep 2014 12:00:10 +0200
parents manuals/help-manual/faq.rst@0b2169f7ce09
children
comparison
equal deleted inserted replaced
1079:6d5b305e9430 1080:898b1ddcca11
1 ===================
2 Technische Referenz
3 ===================
4
5
6 Welche Zertifikatsspeicher werden verwendet?
7 ============================================
8
9 Damit Zertifikaten in Anwendungen (wie z.B. Browser oder E-Mail-Klient)
10 vertraut werden kann, müssen die zugehörigen Wurzelzertifikate in den passenden
11 Zertifikatsspeichern des Systems installiert werden.
12 TrustBridge übernimmt diesen Zugriff auf die Zertifikatsspeicher.
13
14 Es gibt zwei gängige Zertifikatsspeicher, die von TrustBridge und den meisten
15 Anwendungen unterstützt werden:
16
17 * der Mozilla NSS-Zertifikatsspeicher ("Network Security Services") und
18 * der Windows-System-Zertifikatsspeicher.
19
20
21 Chrome bzw. Chromium verwendet unter Windows den Windows-System-Speicher und unter
22 Ubuntu den NSS-Zertifikatsspeicher. Die nachfolgende Abbildung veranschaulicht
23 die verwendeten Zertifikatsspeicher unter Windows und GNU/Linux.
24
25 .. figure:: _static/stores.png
26 :width: 100%
27 :alt: Übersicht der Zertifikatsspeicher
28
29 *Abbildung 1: Übersicht der Zertifikatsspeicher*
30
31 Windows-Zertifikatsspeicher
32 ---------------------------
33
34 Der Windows 7 und 8 Zertifikatsspeicher kann in drei große Gruppen aufgeteilt werden:
35
36 #. Zertifikate des aktuellen Benutzers
37 #. Zertifikate für alle Benutzer (Lokaler Computer)
38 #. Zertifikate für Systemdienste
39
40 Diese Gruppen unterteilen sich wieder in eine Reihe von logischen Speichern.
41
42 Für die Installation von vertrauenswürdigen Wurzelzertifikaten ist der
43 logische *Root*-Speicher relevant. Nur dort eingetragene Zertifikate
44 werden als *Trust Anchor* (Vertrauensanker) angesehen und zur
45 Validierung des Vertrauenspfads zu den weiteren Zertifikaten
46 verwendet.
47
48 Der logische *Disallowed*-Speicher hat immer Vorrang. Befindet sich ein Zertifikat
49 sowohl im *Root* als auch im *Disallowed*-Speicher, gilt es als nicht vertrauenswürdig.
50
51
52 **Einschränkungen:**
53 Um unbefugte Manipulationen am Zertifikatsspeicher zu verhindern, werden von Microsoft
54 seit Windows XP SP2 folgende Schutzmaßnahmen vorgesehen:
55
56 #. Um Zertifikate für alle Benutzer des lokalen Computers zu
57 bearbeiten, sind erhöhte Privilegien (Administrationsrechte)
58 erforderlich.
59 #. Änderungen (Löschen / Hinzufügen von Zertifikaten) am
60 *Root*-Speicher des aktuellen Nutzers erfordern die explizite
61 Einwilligung des Nutzers (siehe nachfolgende Abbildung), sofern der
62 Prozess keine erhöhten Privilegien besitzt.
63
64
65 .. figure:: _static/sicherheitswarnung.png
66 :alt: Windows-Sicherheitswarnung
67
68 *Abbildung 2: Sicherheitswarnung beim Hinzufügen eines Wurzelzertifikats ohne Administrator-Rechte*
69
70
71
72 Mozilla NSS-Zertifikatsspeicher
73 -------------------------------
74 Die Mozilla-Anwendungen Thunderbird und Firefox, sowie Chromium unter
75 Ubuntu, verwenden die Mozilla "Network Security
76 Services" (NSS) Zertifikatsspeicher.
77
78 Mozilla liefert den NSS-Zertifikatsspeicher mit einer Auswahl von
79 voreingesetllten vertrauenswürdigen bzw. nicht
80 vertrauenswürdigen Zertifikaten aus.
81
82 **Einschränkungen:**
83
84 * Anwendungen, die den NSS-Zertifikatsspeicher verwenden, sollten vor dem Zugriff geschlossen
85 werden.
86 * Um den NSS-Speicher anderer Nutzer zu manipulieren, sind erhöhte Rechte nötig.
87 * Um den NSS-Standard für neue Profile vorzugeben, sind abhängig vom Installationsort
88 ggf. erhöhte Rechte nötig.
89
90
91
92 Wie wird der Transport abgesichert?
93 ===================================
94 TrustBridge sucht regelmäßig (alle 24 Stunden) auf dem offiziellen TrustBridge-Update-Server
95 nach aktualisierten Zertifikatslisten und neuen Softwareversionen.
96
97 Sämtliche Transportprozesse sind kryptografisch nach aktuellem Stand
98 der Technik gegen unbefugte Manipulationen (Authentizität und
99 Integrität) gesichert. Es gibt drei Transportwege, die abgesichert
100 werden müssen:
101
102 #. Verfügbarkeit von Aktualisierungen prüfen:
103 Die regelmäßige Übertragung der Information, ob neue Aktualisierungen
104 von Zertifikatsliste oder Software verfügbar sind, wird über eine
105 HTTPS-Verbindung per TLS 1.2 (mit ECDSA brainpoolP256r1) durchgeführt.
106 #. Zertifikatslisten-Update durchführen:
107 Ist eine neue Zertifikatsliste verfügbar, wird die ganze Liste
108 gebündelt übertragen. Die Zertifikatslistendatei ist signiert (RSA 3076).
109 Vor einem Zertifikatslisten-Update wird sichergestellt, dass TrustBridge bereits in der
110 neusten Version installiert ist.
111 #. Software-Update durchführen:
112 Ist eine neue TrustBridge-Version verfügbar, kann diese mit einem
113 Klick auf eine entsprechende Meldung heruntergeladen und installiert
114 werden. Es wird eine vollständige TrustBridge-Installationsdatei übertragen
115 und im Hintergrund ausgeführt. Jede Software-Installationsdatei ist signiert.
116 Bei Fehlschlagen der Signaturprüfung (z.B. durch fehlerhaftes
117 Herunterladen) wird TrustBridge nicht aktualisiert.
118
119
120
121 Wie sieht das Datenformat einer Zertifikatsliste aus?
122 =====================================================
123
124 Die Zertifikatsliste ist eine einzelne Text-Datei, welche von der
125 TrustBridge-Verwaltungsanwendung erzeugt wird. Diese Datei enthält
126 alle benötigten Informationen und basiert auf einer zeilenbasierten
127 Textformat. Dabei bleibt die Struktur für Menschen lesbar und die
128 meisten Inhalte können mit Standardwerkzeugen sowohl de- als auch
129 enkodiert werden.
130
131 In der ersten Zeile der Datei ist die Base64-kodierte, kryptografische
132 Signatur über alle folgenden Zeilen (inklusive der Zeilenenden)
133 angegeben. So wird die Integrität und Authentizität dieser Daten vor
134 der Verarbeitung gesichert.
135
136 Einzelne Zeilen haben das Format ``<Buchstabe>:<Wert><CR><LF>``, wobei
137 der Buchstabe angibt, welche Art von Wert folgt. Die Länge der Zeilen
138 ist (für Version 1) auf 9999 Zeichen begrenzt, inklusive der beiden
139 Zeichen für Zeilenenden. Die Anzahl der Zeilen ist auf 1000
140 beschränkt, was einer Dateigröße von maximal 10 Megabyte entspricht.
141 (In der Praxis wird die Dateigröße aber deutlich unter 100 Kilobyte
142 liegen.) Der Text wird in 7Bit-ASCII kodiert.
143
144 Die Zertifikate selbst werden als Base64- und DER-kodierte Daten
145 aufgeführt. Dies entspricht dem Inhalt gängiger .pem-Dateien - jedoch
146 ohne den umschließenden BEGIN CERTIFICATE und END CERTIFICATE sowie
147 ohne den Zeilenumbrüchen.
148
149 Jede Zeile muss mit einem der folgenden gültigen Buchstaben beginnen:
150
151 * ``S:`` Die Signatur der Zertifikatsliste.
152 * ``F:`` Format-Version
153 * ``D:`` Zeitpunkt der Listenerstellen (UTC)
154 * ``I:`` Zu installierendes Zertifikat
155 * ``R:`` Zu entfernendes Zertifikat
156
157
158 Im Folgenden ein Beispiel für den Aufbau der Zertifikatslisten-Datei
159 mit zwei zu installierenden Zertifikaten und einem zu löschenden
160 Zertifikat. Die Signatur- und Zertifikatszeilen sind, aus Gründen der
161 Übersichtlichkeit, in diesem Beispiel gekürzt:
162
163 .. parsed-literal::
164 S:EjzX0sTkstnnGbPIC7n1a5WlYCFsthPl8OYplLyihR1RdqcUsSnikrVowFo8QgpMutcz0...
165 F:1
166 D:2014-01-03T12:30Z
167 I:MIIEiTCCA3GgAwIBAgIDAWn+MA0GCSqGSIb3DQBQUAMEAxCzAJBVBAYTAlVTMRcwFQYDV...
168 I:MIIHojCCBoqgAwIBAgIDAW96MA0GCSqGSIb3DQEBBQUAGMMQswCDVQQGEwJJTDEWMBQGA...
169 R:MIIGUjCCBTqgAwIBAgIODocAAQACqS54FrSbGvYwDQKoZIhvcNAQBQAwfDELMAkGA1UEB...
170

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