diff options
Diffstat (limited to 'files/de/web/security')
| -rw-r--r-- | files/de/web/security/certificate_transparency/index.html | 64 | ||||
| -rw-r--r-- | files/de/web/security/index.html | 17 | ||||
| -rw-r--r-- | files/de/web/security/public_key_pinning/index.html | 147 |
3 files changed, 228 insertions, 0 deletions
diff --git a/files/de/web/security/certificate_transparency/index.html b/files/de/web/security/certificate_transparency/index.html new file mode 100644 index 0000000000..14d180f9ea --- /dev/null +++ b/files/de/web/security/certificate_transparency/index.html @@ -0,0 +1,64 @@ +--- +title: Certificate Transparency +slug: Web/Security/Certificate_Transparency +tags: + - Security + - Sicherheit + - Web + - Zertifikate +translation_of: Web/Security/Certificate_Transparency +--- +<p><span class="seoSummary"><strong>Certificate Transparency</strong> (kurz; CT) ist ein offenes Framework, das entwickelt wurde, um vor Zertifikatsfehlausstellungen schützen und diese Überwachung zu können. Neu ausgestellte Zertifikate werden dabei in öffentlich geführten, oft unabhängigen CT-Protokollen "protokolliert". An diese Protokolle werden immer nur neue Datensätze angefügt, die jeweils kryptografisch gesichert sind und die einzelnen ausgestellten TLS-Zertifikate dokumentieren.</span></p> + +<p>Auf diese Weise können die Zertifizierungsstellen (CAs) einer viel stärkeren öffentlichen Kontrolle und Aufsicht unterliegen. Potenziell böswillige Zertifikate, z.B. solche, die gegen die <em>Grundanforderungen</em> des CA/B-Forums verstoßen, können viel schneller entdeckt und widerrufen werden. Browser-Hersteller und Root-Store-Betreuer sind auch in der Lage, fundiertere Entscheidungen über problematische CAs zu treffen, denen sie möglicherweise misstrauen.</p> + +<h2 id="Hintergrund">Hintergrund</h2> + +<p>CT-Protokolle bauen auf dem Fundament der <em>Merkle</em>-<em>Baum</em>-Datenstruktur auf. Die Knoten sind mit den <em>kryptographischen Hashes</em> ihrer Kindknoten gekennzeichnet. Blattknoten enthalten Hashes von tatsächlichen Datenstücken. Die Beschriftung des Wurzelknotens hängt daher von allen anderen Knoten im Baum ab.</p> + +<p>Im Zusammenhang mit der Transparenz von Zertifikaten sind die von den Blattknoten gehashten Daten die Zertifikate, die von den verschiedenen heute tätigen CAs ausgestellt wurden. Die Einbeziehung von Zertifikaten kann über einen Audit-Beweis verifiziert werden, der effizient in logarithmischer O(log n)-Zeit generiert und verifiziert werden kann.</p> + +<p>Certificate Transparency kam ursprünglich im Jahr 2013 vor dem Hintergrund kompromittierter Zertifizeirungsstellen (DigiNotar breach, 2011), fragwürdiger Entscheidungen (Trustwave subordinate root incident, 2012) und technischer Probleme beim Ausstellen von Zertifikaten (schwache<span class="entry-content">, 512 bit Zertifikate von Digicert Sdn Bhd aus </span>Malaysia).</p> + +<h2 id="Implementation">Implementation</h2> + +<p>Wenn Zertifikate an ein CT-Protokoll übermittelt werden, wird ein signierter Zertifikat-Zeitstempel (<em>signed certificate timestamp</em>, SCT) erzeugt und zurückgeschickt. Dieser wird dem Protokoll hinzugefügt und dient als Nachweis, dass das Zertifikat eingereicht wurde.</p> + +<p>Die Spezifikation besagt, dass konforme Server den TLS-Clients beim Verbindungsaufabeu eine Reihe dieser SCTs zur Verfügung stellen müssen. Dies kann über eine Reihe verschiedener Mechanismen erfolgen:</p> + +<ul> + <li>X.509v3 certificate extension: signierte SCTs werden direkt in das Zertifikat einbettet</li> + <li>Eine TLS-Erweiterung des Typs <code>signed_certificate_timestamp</code> wird während des handshakes gesendet</li> + <li>OCSP stapling (über die <code>status_request</code> TLS-Erweiterung) und das Bereitstellen einer <code>SignedCertificateTimestampList</code> mit einem oder mehreren SCTs</li> +</ul> + +<p>Mit der oben genannten X.509 certificate extension entscheidet die Zertifizierungsstelle darüber, welche SCTs eingebunden werden. Dieser Mechanismus kann verwendet werden, ohne eine Anpassung am Webserver vornehmen zu müssen.</p> + +<p>Bei den anderen beiden Methoden hingegen müssen die Server aktualisiert werden, um die erforderlichen Daten zu senden. Der Vorteil der Methoden besteht darin, dass der Serverbetreiber die CT-Protokollquellen für die bereitgestellten SCTs selbst auswählen und definieren kann.</p> + +<h2 id="Browser_Anforderungen">Browser Anforderungen</h2> + +<p>Google Chrome erfordert die Einbeziehung des CT-Protokolls für alle Zertifikatsausgaben mit einem nicht vor dem 30. April 2018 liegenden Datum. Nutzer werden daran gehindert, Websites zu besuchen, die nicht konforme TLS-Zertifikate verwenden. Chrome hatte zuvor die CT-Einbeziehung für <em>Extended Validation</em> (EV) und von Symantec ausgestellte Zertifikate verlangt.</p> + +<p>Apple <a href="https://support.apple.com/en-gb/HT205280">verlangt</a> eine unterschiedliche Anzahl von SCTs, damit Safari und andere Server den einzelnen Serverzertifikaten vertrauen können.</p> + +<p>Firefox <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1281469">prüft aktuell nicht</a> bzw. erfordert nicht, dass CT-Protokolle verwendet werden, wenn Nutzer die Webseiten besuchen.</p> + +<p>Der <a href="/en-US/docs/Web/HTTP/Headers/Expect-CT">Expect-CT header </a>kann verwendet werden, um vom Browser zu verlangen, dass dieser <em>immer</em> die<em> </em>Certificate Transparency erfordert (z.B. in Chrome, selbst wenn das Zertifikat ausgestellt wurde mit einem <em>notBefore Datum</em> vor April).</p> + +<h2 id="Spezifikationen">Spezifikationen</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Status</th> + <th scope="col">Comment</th> + </tr> + <tr> + <td><a class="external external-icon" href="https://tools.ietf.org/html/rfc6962" hreflang="en" lang="en" rel="noopener">Certificate Transparency</a></td> + <td><span class="spec-RFC">IETF RFC</span></td> + <td></td> + </tr> + </tbody> +</table> diff --git a/files/de/web/security/index.html b/files/de/web/security/index.html new file mode 100644 index 0000000000..0167d156d6 --- /dev/null +++ b/files/de/web/security/index.html @@ -0,0 +1,17 @@ +--- +title: Web security +slug: Web/Security +tags: + - Landing + - Security + - TopicStub + - Web +translation_of: Web/Security +--- +<div class="summary"> +<p>Es ist wichtig, dass Ihre Website oder Ihre offene Webanwendung sicher ist. Selbst einfache Fehler in Ihrem Code können dazu führen, dass private Informationen durchsickern und böse Leute sind da draußen versuchen Wege zu finden, diese Daten zu stehlen. Diese Artikel enthalten Informationen, die Ihnen helfen können, Ihren Code zu schützen.</p> +</div> + +<p>{{LandingPageListSubpages}}</p> + +<p>{{QuickLinksWithSubpages}}</p> diff --git a/files/de/web/security/public_key_pinning/index.html b/files/de/web/security/public_key_pinning/index.html new file mode 100644 index 0000000000..337b9b600e --- /dev/null +++ b/files/de/web/security/public_key_pinning/index.html @@ -0,0 +1,147 @@ +--- +title: HTTP Public Key Pinning (HPKP) +slug: Web/Security/Public_Key_Pinning +tags: + - Anleitung + - HPKP + - HTTP + - Sicherheit + - Webentwicklung +translation_of: Web/HTTP/Public_Key_Pinning +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary"><span class="seoSummary">Die <strong>Public Key Pinning Erweiterung für HTTP</strong> (</span>{{Glossary("HPKP")}}<span class="seoSummary">) ist ein Sicherheitsfeature, das einem Webclient mitteilt, einen spezifischen kryptographischen Schlüssel mit einem bestimmten Webserver in Verbindung zu bringen um </span>{{Glossary("MITM")}}<span class="seoSummary"> mit gefälschten Zertifikaten zu vermeiden.</span></p> + +<p>Um die Echtheit des öffentlichen Schlüssels eines Servers in {{Glossary("TLS")}}-Sessions sicherzustellen, wird dieser in ein X.509-Zertifikat gepackt, welches meistens von einer Zertifizierungsstelle ({{GLossary("CA")}}) signiert wird. Webclients wie Browser vertrauen vielen Zertifizierungsstellen, die Zertifikate für beliebige Domainnamen erstellen können. Wenn ein Angreifer dazu in der Lage ist, eine einzelne Zertifizierungsstelle zu infiltrieren, kann er MITM-Angriffe auf verschiedene TLS-Verbindungen starten. HPKP kann diese Gefahr für das {{Glossary("HTTPS")}}-Protokoll dadurch umgehen, dass dem Client mitgeteilt wird, welcher öffentliche Schlüssel zu einem bestimmten Webserver gehört.</p> + +<p>HPKP is ein <em>Trust on First Use</em> ({{Glossary("TOFU")}}) ("Bei der ersten Benutzung vertrauen") Verfahren. Beim ersten Webseitenbesuch übermittelt der Server einen HTTP-Header um dem Client zu zeigen, welche öffentliche Schlüssel zu ihm gehören. Der Client speichert diese Information für eine angegebene Zeit. Wenn der Client die Webseite erneut besucht, erwartet er, dass mindestens ein Zertifikat der Zertifikatkette einen öffentlichen Schlüssel enthält, dessen Fingerprint dem Client bereits per HPKP bekannt ist. Wenn der Server einen unbekannten öffentlichen Schlüssel liefert, sollte der Client einen Fehler anzeigen.</p> + +<p class="note">Firefox (und Chrome)<strong> deaktivieren die Pin Validierung</strong> für Pinned Hosts mit Zertifikatketten, die bei einem <strong>benutzerdefinierten trust anchor</strong> terminieren (anstatt bei einem eingebauten trust anchor). Dies bedeutet, dass alle Pinning-Nichteinhaltungen für Nutzer ignoriert werden, welche ein Root-Zertifikat importiert haben.</p> + +<h2 id="HPKP_aktivieren">HPKP aktivieren</h2> + +<p>Dieses Feature kann einfach aktiviert werden indem ein {{HTTPHeader("Public-Key-Pins")}} HTTP-Header beim Aufruf der Seite über HTTPS zurückgegeben wird:</p> + +<pre>Public-Key-Pins: pin-sha256="base64=="; max-age=<em>expireTime</em> [; includeSubdomains][; report-uri="<em>reportURI"</em>] +</pre> + +<dl> + <dt><code>pin-sha256</code></dt> + <dd>Der Parameter beinhaltet einen Base64 codierten <em>Subject Public Key Information</em> ({{Glossary("SPKI")}}) Fingerprint. Es ist auch möglich mehrere Pins zu verschiedenen öffentlichen Schlüsseln zu definieren. Einige Browser werden hier zukünftig neben SHA-256 evtl. weitere Hash-Algorithmen erlauben. Weiter unten ist beschrieben, wie diese Informationen entweder aus dem Zertifikat oder der Schlüsseldatei extrahiert werden können.</dd> + <dt><code>max-age</code></dt> + <dd>Die Zeit (in Sekunden) in Sekunden, die ein Browser sich merken soll, dass auf diese Seite nur bei Benutzung eines der öffentlichen Schlüssel zugegriffen werden darf.</dd> + <dt><code>includeSubdomains</code> {{ optional_inline() }}</dt> + <dd>Wenn dieser optionale Parameter angegeben wird, wird die Regel auch auf alle Subdomains der Site angewandt.</dd> + <dt><code>report-uri</code> {{ optional_inline() }}</dt> + <dd>Wenn dieser optionale Parameter angegeben wird, werden Pinvalidierungsfehlschläge an die angegebene URL gemeldet.</dd> +</dl> + +<div class="note"> +<p><strong>Anmerkung:</strong> Die aktuelle Spezifikation verlangt die Aufnahme eines zweiten Pins für einen Backup-Schlüssel, der noch nicht in der Produktion verwendet wird. Dies ermöglicht es, den öffentlichen Schlüssel des Servers zu ändern, ohne die Zugänglichkeit für Clients zu beeinträchtigen, die die Pins bereits bemerkt haben. Dies ist z.B. dann wichtig, wenn der alte Schlüssel beschädigt wird.</p> +</div> + +<h3 id="Base64-enkodierte_Public_Key_Informationen_extrahieren">Base64-enkodierte Public Key Informationen extrahieren</h3> + +<div class="note"> +<p><strong>Note:</strong> Während das folgende Beispiel zeigt, wie man einen Pin auf ein Serverzertifikat setzt, wird empfohlen, den Pin auf das Zwischenzertifikat der CA zu setzen, die das Serverzertifikat ausgestellt hat, um Verlängerungen und Rotationen von Zertifikaten zu erleichtern.</p> +</div> + +<p>First you need to extract the public key information from your certificate or key file and encode them using Base64.</p> + +<p>The following commands will help you extract the Base64 encoded information from a key file, a certificate signing request, or a certificate.</p> + +<pre><code>openssl rsa -in my-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | </code>openssl enc -base64</pre> + +<pre><code>openssl req -in my-signing-request.csr -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64</code></pre> + +<pre><code>openssl x509 -in my-certificate.crt -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64</code></pre> + +<p>The following command will extract the Base64 encoded information for a website.</p> + +<pre><code>openssl s_client -connect www.example.com:443 | openssl x509 -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64</code></pre> + +<h3 id="Beispiel_für_ein_HPKP-Header">Beispiel für ein HPKP-Header</h3> + +<pre>Public-Key-Pins: pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs="; pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE="; max-age=5184000; includeSubdomains; report-uri="<em>https://www.example.net/hpkp-report"</em></pre> + +<p>In this example, <strong>pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs="</strong> pins the server's public key used in production. The second pin declaration <strong>pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE="</strong> also pins the backup key. <strong>max-age=5184000</strong> tells the client to store this information for two month, which is a reasonable time limit according to the IETF RFC. This key pinning is also valid for all subdomains, which is told by the <strong>includeSubdomains</strong> declaration. Finally, <strong>report-uri="https://www.example.net/hpkp-report"</strong> explains where to report pin validation failures.</p> + +<h3 id="Setting_up_your_webserver_to_include_the_HPKP_header">Setting up your webserver to include the HPKP header</h3> + +<p>The concrete steps necessary to deliver the HPKP header depend on the web server you use.</p> + +<div class="note"> +<p><strong>Note:</strong> These examples use a max-age of two months and include all subdomains. It is advised to verify that this setup will work for your server.</p> +</div> + +<div class="warning"> +<p id="HPKP_hat_das_Potential_Nutzer_für_eine_lange_Zeit_auszusperren_wenn_es_inkorrekt_genutzt_wird!_Die_Benutzung_von_Backup-Zertifikaten_undoder_das_Pinnen_der_Zertifizierungsstelle_wird_dringend_empfohlen.">HPKP hat das Potential Nutzer für eine lange Zeit auszusperren, wenn es inkorrekt genutzt wird! Die Benutzung von Backup-Zertifikaten und/oder das Pinnen der Zertifizierungsstelle wird dringend empfohlen.</p> +</div> + +<h4 id="Apache">Apache</h4> + +<p>HPKP kann im Apache Webserver beispielsweise mit der folgenden Konfiguration aktiviert werden. Die Parameter müssen dann nur noch auf das Zielsystem angepasst werden. Das Apache Modul <code>mod_headers</code> wird benötigt.</p> + +<pre>Header always set Public-Key-Pins "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains" +</pre> + +<h4 id="Nginx">Nginx</h4> + +<p>Adding the following line and inserting the appropriate <code>pin-sha256="..."</code> values will enable HPKP on your nginx. This requires the <code>ngx_http_headers_module.</code></p> + +<pre>add_header Public-Key-Pins 'pin-sha256="base64+primary=="; pin-sha256="base64+backup=="; max-age=5184000; includeSubDomains';</pre> + +<h4 id="Lighttpd">Lighttpd</h4> + +<p>The following line with your relevant key information (pin-sha256="..." fields) will enable HPKP on lighttpd.</p> + +<pre>setenv.add-response-header = ( "Public-Key-Pins" => "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains")</pre> + +<p><strong>Note:</strong> This requires the <code>mod_setenv</code> server.module loaded which can be included by the following if not already loaded.</p> + +<pre><code>server.modules += ( "mod_setenv" )</code></pre> + +<h4 id="IIS">IIS</h4> + +<p>Add the following line to the Web.config file to send the <code>Public-Key-Pins</code> header:</p> + +<pre class="brush: xml line-numbers language-xml"><code class="language-xml"><system.webServer> + ... + + <span class="tag token"><span class="tag token"><span class="punctuation token"><</span>httpProtocol</span><span class="punctuation token">></span></span> + <span class="tag token"><span class="tag token"><span class="punctuation token"><</span>customHeaders</span><span class="punctuation token">></span></span> + <span class="tag token"><span class="tag token"><span class="punctuation token"><</span>add</span> <span class="attr-name token">name</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>Public-Key-Pins<span class="punctuation token">"</span></span> <span class="attr-name token">value</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>pin-sha256<span class="punctuation token">=</span>&quot;base64+primary<span class="punctuation token">=</span><span class="punctuation token">=</span>&quot;; pin-sha256<span class="punctuation token">=</span>&quot;base64+backup<span class="punctuation token">=</span><span class="punctuation token">=</span>&quot;; max-age<span class="punctuation token">=</span>5184000; includeSubDomains<span class="punctuation token">"</span></span> <span class="punctuation token">/></span></span> + <span class="tag token"><span class="tag token"><span class="punctuation token"></</span>customHeaders</span><span class="punctuation token">></span></span> + <span class="tag token"><span class="tag token"><span class="punctuation token"></</span>httpProtocol</span><span class="punctuation token">></span></span> + + ... +</system.webServer></code></pre> + +<h2 id="Browserkompatibilität">Browserkompatibilität</h2> + +<p class="hidden">Die Kompatibilitätstabelle wird von strukturierten Daten generiert. Wenn Du zu diesen beitragen willst checke <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> aus und sende uns einen Pull Request.</p> + +<p>{{Compat("http.headers.Public-Key-Pins")}}</p> + +<h2 id="Spezifikationen">Spezifikationen</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Spezifikation</th> + <th scope="col">Titel</th> + </tr> + <tr> + <td>{{RFC("7469", "Public-Key-Pins", "2.1")}}</td> + <td>Public Key Pinning Erweiterung für HTTP</td> + </tr> + </tbody> +</table> + +<h2 id="Siehe_auch">Siehe auch</h2> + +<ul> + <li>{{HTTPHeader("Public-Key-Pins")}}</li> + <li>{{HTTPHeader("Public-Key-Pins-Report-Only")}}</li> +</ul> |