Hypertext-Übertragungsprotokoll Sicher (HTTPS) ist eine Kombination des Hypertext-Übertragungsprotokolls (HTTP) mit dem SSL/TLS Protokoll. Es stellt encrypted Kommunikation und sichere Identifizierung eines Netzwebservers zur Verfügung. Historisch wurden HTTPS Verbindungen in erster Linie für Zahlungstransaktionen im World Wide Web und für empfindliche Transaktionen in korporativen Informationssystemen verwendet. Gegen Ende der 2000er Jahre und Anfang der 2010er Jahre hat HTTPS begonnen, weit verbreiteten Gebrauch zu sehen, um Rechnungen zu sichern, Benutzerkommunikationen behaltend und Geschichte privat durchsuchend, und Seitenechtheit auf allen Typen von Websites schützend.

HTTPS sollte mit dem wenig verwendeten Sicheren HTTP (S-HTTP) angegeben in RFC 2660 nicht verwirrt sein.

Übersicht

HTTPS ist ein URI Schema, das identische Syntax zum HTTP Standardschema beiseite von seinem Schema-Jeton hat. Jedoch gibt HTTPS dem Browser Zeichen, um eine zusätzliche Verschlüsselungsschicht von SSL/TLS zu verwenden, um den Verkehr zu schützen. SSL wird besonders für HTTP angepasst, da es etwas Schutz zur Verfügung stellen kann, selbst wenn nur eine Seite der Kommunikation beglaubigt wird. Das ist mit HTTP Transaktionen über das Internet der Fall, wo normalerweise nur der Server (vom Kunden beglaubigt wird, der das Zertifikat des Servers untersucht).

Die Hauptidee von HTTPS ist, einen sicheren Kanal über ein unsicheres Netz zu schaffen. Das sichert angemessenen Schutz vor Lauschern und Mann in den mittleren Angriffen, vorausgesetzt, dass entsprechende Ziffer-Gefolge verwendet werden, und dass das Server-Zertifikat nachgeprüft und vertraut wird.

WWW-Browser wissen, wie man HTTPS Websites vertraut, die auf Zertifikat-Behörden gestützt sind, die vorinstalliert in ihrer Software kommen. Zertifikat-Behörden (z.B. VeriSign/Microsoft/etc.) werden auf diese Weise von WWW-Browser-Schöpfern vertraut, um gültige Zertifikate zur Verfügung zu stellen. Logisch, hieraus folgt dass ein Benutzer einer HTTPS Verbindung zu einer Website vertrauen sollte, wenn, und nur wenn der ganze folgende wahr ist:

1. Der Benutzer glaubt, dass die Browser-Software richtig HTTPS mit richtig vorinstallierten Zertifikat-Behörden durchführt.
2. Der Benutzer vertraut der Zertifikat-Autorität, sich nur für legitime Websites zu verbürgen.
3. Die Website stellt ein gültiges Zertifikat zur Verfügung, was bedeutet, dass sie von einer vertrauten Autorität unterzeichnet wurde.
4. Das Zertifikat identifiziert richtig die Website (z.B, wenn der Browser "https://example.com" besucht, ist das erhaltene Zertifikat richtig für "Example Inc." und nicht eine andere Entität).
5. Entweder die vorläufigen Sprünge im Internet sind vertrauenswürdig, oder der Benutzer glaubt, dass die Verschlüsselungsschicht des Protokolls (TLS/SSL) gegen Lauscher genug sicher ist.

Browser-Integration

Die meisten Browser zeigen eine Warnung, wenn sie ein ungültiges Zertifikat erhalten. Ältere Browser, wenn sie zu einer Seite mit einem ungültigen Zertifikat in Verbindung stehen, würden dem Benutzer ein Dialogfeld bieten, das fragt, ob sie haben weitermachen wollen. Neuere Browser zeigen eine Warnung über das komplette Fenster. Neuere Browser zeigen auch prominent die Sicherheitsinformation der Seite in der Adressbar. Verlängerte Validierungszertifikate drehen die in neueren Browsern grüne Adressbar. Die meisten Browser zeigen auch eine Warnung dem Benutzer, wenn sie eine Seite besuchen, die eine Mischung von encrypted und unencrypted Inhalt enthält.

Das Elektronische Grenzfundament, dass" [ich] n eine ideale Welt meinend, konnte jede Webbitte zu HTTPS im Verzug gewesen werden", hat eine Erweiterung genannt "HTTPS Überall" nach Mozilla Firefox zur Verfügung gestellt, der HTTPS standardmäßig für Hunderte von oft verwendeten Websites ermöglicht. Eine Beta-Version davon Steck-ist auch für Google Chrom und Chrom verfügbar.

Technisch

Unterschied zu HTTP

HTTPS URL-ADRESSEN beginnen mit "https://" und verwenden Hafen 443 standardmäßig, wo HTTP URL-ADRESSEN mit "http://" beginnen und Hafen 80 standardmäßig verwenden.

HTTP ist unsicher und ist dem Mann in der Mitte und den lauschenden Angriffen unterworfen, die Angreifer Zugang zu Website-Rechnungen und empfindlicher Information können gewinnen lassen. HTTPS wird entworfen, um solchen Angriffen zu widerstehen, und wird sicher gegen solche Angriffe (mit Ausnahme von älteren missbilligten Versionen von SSL) betrachtet.

Netzschichten

HTTP funktioniert an der höchsten Schicht des OSI Modells, der Anwendungsschicht; aber das Sicherheitsprotokoll funktioniert an einer niedrigeren Teilschicht, encrypting eine HTTP Nachricht vor der Übertragung und dem Entschlüsseln einer Nachricht nach der Ankunft. Genau genommen ist HTTPS nicht ein getrenntes Protokoll, aber verweist auf den Gebrauch von gewöhnlichem HTTP über einen encrypted SSL/TLS Verbindung.

Alles in der HTTPS Nachricht ist encrypted, einschließlich der Kopfbälle und der Last der Bitte/Antwort. Mit Ausnahme vom möglichen CCA kryptografischen Angriff, der in der Beschränkungsabteilung unten beschrieben ist, kann der Angreifer nur die Tatsache wissen, dass eine Verbindung zwischen den zwei Parteien stattfindet, die bereits ihm, dem Domainnamen und den IP-Adressen bekannt sind.

Server-Einstellung

Um einen Webserver vorzubereiten, um HTTPS Verbindungen zu akzeptieren, muss der Verwalter ein öffentliches Schlüsselzertifikat für den Webserver schaffen. Dieses Zertifikat muss von einer vertrauten Zertifikat-Autorität für den WWW-Browser unterzeichnet werden, um es ohne Warnung zu akzeptieren. Die Autorität bescheinigt, dass der Zertifikat-Halter der Maschinenbediener des Webservers ist, der sie präsentiert. WWW-Browser werden allgemein mit einer Liste des Unterzeichnens von Zertifikaten von Hauptzertifikat-Behörden verteilt, so dass sie von ihnen unterzeichnete Zertifikate nachprüfen können.

Das Erwerben von Zertifikaten

Herrisch unterzeichnete Zertifikate können freier sein

oder gekostet zwischen 8 US$ und 1,500 $ pro Jahr.

Jedoch, im Fall von freien Zertifikat-Behörden wie CACert, populäre Browser (z.B. FireFox, Internet Explorer) kann die vertrauten Wurzelzertifikate nicht einschließen, die unvertraute Warnungsnachrichten veranlassen können, Endbenutzern gezeigt zu werden.

Organisationen können auch ihre eigene Zertifikat-Autorität besonders führen, wenn sie dafür verantwortlich sind, Browser aufzustellen, um auf ihre eigenen Seiten (zum Beispiel, Seiten auf einem Firmenintranet oder Hauptuniversitäten) zuzugreifen. Sie können Kopien ihres eigenen unterzeichnenden Zertifikats zu den vertrauten mit dem Browser verteilten Zertifikaten leicht hinzufügen.

Dort auch besteht eine Gleicher-zu-Gleicher-Zertifikat-Autorität, CACert.

Gebrauch als Zugriffskontrolle

Das System kann auch für die Kundenbeglaubigung verwendet werden, um Zugang zu einem Webserver autorisierten Benutzern zu beschränken. Um das zu tun, schafft der Seite-Verwalter normalerweise ein Zertifikat für jeden Benutzer, ein Zertifikat, das in seinen/ihren Browser geladen wird. Normalerweise enthält das den Namen und die E-Mail-Adresse des autorisierten Benutzers und wird durch den Server auf jedem automatisch überprüft stehen in Verbindung wieder, um die Identität des Benutzers potenziell nachzuprüfen, ohne sogar in ein Kennwort einzugehen.

Im Falle des in Verlegenheit gebrachten privaten Schlüssels

Ein Zertifikat kann widerrufen werden, bevor es zum Beispiel abläuft, weil die Geheimhaltung des privaten Schlüssels in Verlegenheit gebracht worden ist. Neuere Versionen von populären Browsern wie Google-Chrom, Firefox, Oper und Internet Explorer auf der Windows-Aussicht führen Online Certificate Status Protocol (OCSP) durch, um nachzuprüfen, dass das nicht der Fall ist. Der Browser sendet die Seriennummer des Zertifikats an die Zertifikat-Autorität oder seinen Delegierten über OCSP, und die Autorität antwortet, den Browser erzählend, ob das Zertifikat noch gültig ist.

Beschränkungen

SSL kommt in zwei Optionen, einfach und gegenseitig.

Die gegenseitige Version ist sicherer, aber verlangt, dass der Benutzer ein persönliches Zertifikat in ihrem Browser installiert, um sich zu beglaubigen.

Was auch immer Strategie verwendet wird (einfach oder gegenseitig), hängt das Niveau des Schutzes stark von der Genauigkeit der Durchführung des WWW-Browsers und der Server-Software und der wirklichen kryptografischen unterstützten Algorithmen ab.

SSL hält die komplette Seite nicht davon ab, mit einem Webkettenfahrzeug mit einem Inhaltsverzeichnis versehen zu werden, und in einigen Fällen kann der URI der encrypted Quelle durch das Wissen nur der abgefangenen Größe der Bitte/Antwort abgeleitet werden. Das erlaubt einem Angreifer, Zugang zum plaintext (der öffentlich verfügbare statische Inhalt), und der encrypted Text (die encrypted Version des statischen Inhalts) zu haben, einen kryptografischen Angriff erlaubend.

Weil SSL unter HTTP funktioniert und keine Kenntnisse von Protokollen des höheren Niveaus hat, können SSL Server nur ausschließlich anwesend ein Zertifikat für eine besondere IP/port Kombination. Das bedeutet, dass, in den meisten Fällen, es nicht ausführbar ist, namenbasierte virtuelle Bewirtung mit HTTPS zu verwenden. Eine Lösung genannt Server Name Indication (SNI) besteht, der den hostname an den Server vorher encrypting die Verbindung sendet, obwohl viele ältere Browser diese Erweiterung nicht unterstützen. Die Unterstützung für SNI ist seit Firefox 2, Oper 8, Safari 2.1, Google Chrom 6, und Internet Explorer 7 auf der Windows-Aussicht verfügbar.

Aus einem architektonischen Gesichtspunkt:

1. Eine SSL/TLS Verbindung wird durch die erste Vordermaschine geführt, die die SSL Verbindung beginnt. Wenn, aus irgendwelchen Gründen (Routenplanung, Verkehrsoptimierung, usw.), diese Vordermaschine nicht der Anwendungsserver ist und es Daten entziffern muss, wie man finden muss, pflanzen Lösungen Benutzerbeglaubigungsinformation oder Zertifikat zum Anwendungsserver fort, der wissen muss, wer dabei ist, verbunden zu werden.
2. Für SSL mit der gegenseitigen Beglaubigung wird die SSL/TLS Sitzung durch den ersten Server geführt, der die Verbindung beginnt. In Situationen, wo Verschlüsselung entlang verketteten Servern fortgepflanzt werden muss, wird Sitzungspause-Management äußerst heikel, um durchzuführen.
3. Mit gegenseitigem SSL/TLS ist Sicherheit, aber auf der Kundenseite maximal, es gibt keine Weise, die SSL Verbindung richtig zu beenden und den Benutzer außer durch das Warten auf die SSL Server-Sitzung zu trennen, um abzulaufen, oder das Schließen aller zusammenhängenden Client-Anwendungen.
4. Aus Leistungsgründen wird statischer Inhalt, der dem Benutzer oder der Transaktion nicht spezifisch, und so nicht privat ist, gewöhnlich durch einen non-crypted Vorderserver oder getrenntes Server-Beispiel ohne SSL geliefert. Demzufolge wird dieser Inhalt gewöhnlich nicht geschützt. Viele Browser warnen den Benutzer, als eine Seite encrypted und non-encrypted Mittel gemischt hat.

Ein hoch entwickelter Typ des Mannes im mittleren Angriff wurde auf der Blackhat Konferenz 2009 präsentiert. Dieser Typ des Angriffs vereitelt die durch HTTPS zur Verfügung gestellte Sicherheit durch das Ändern der Verbindung in eine Verbindung, das Ausnutzen die Tatsache, dass wenige Internetbenutzer wirklich Typ "https" in ihren Browser verbinden: Sie kommen zu einer sicheren Seite, indem sie auf eine Verbindung klicken, und werden so ins Denken zum Narren gehalten, dass sie HTTPS verwenden, wenn tatsächlich sie HTTP verwenden. Der Angreifer kommuniziert dann im klaren mit dem Kunden.

Im Mai 2010 hat eine Forschungsarbeit durch Forscher von der Universität von Microsoft Research und Indiana entdeckt, dass ausführlich berichtete empfindliche Benutzerdaten aus Seitenkanälen wie Paket-Größen abgeleitet werden können. Mehr spezifisch haben die Forscher gefunden, dass ein Lauscher die Krankheiten/Medikamente/Chirurgien des Benutzers, ihres Familieneinkommens und der Investitionsgeheimnisse, trotz des HTTPS Schutzes in mehreren bemerkenswert, Spitze der Linienwebanwendungen in Gesundheitsfürsorge, Besteuerung, Investition und Websuche ableiten kann.

Geschichte

Netscape Kommunikationen haben HTTPS 1994 für seinen Netscape Navigator-WWW-Browser geschaffen. Ursprünglich wurde HTTPS mit dem SSL Protokoll verwendet. Als in Transport Layer Security (TLS) entwickelter SSL wurde die jetzige Version von HTTPS durch RFC 2818 im Mai 2000 formell angegeben.

Siehe auch

Links

• RFC 2818: HTTP Über TLS
• SSL 3.0 Spezifizierung (IETF)
• HTTPS, der Überall durch das Elektronische Grenzfundament geschaffen ist
• Wikipedia mit dem HTTPS Protokoll
• Apachen-SSL Einstiegsseite (Nicht mehr aktiv entwickelt)
• Apache 2.2 mod_ssl Dokumentation
• HTTPS Protokoll in der Entwicklung des Internet Explorers - MSDN
• Manuell Konfigurierendes Windows Communication Foundation (WCF), wenn man HTTP und HTTPS - MSDN verwendet
• HTTPS Sicherheit Verbesserungen in Internet Explorer 7 & sein Vereinbarkeitseinfluss - MSDN
• HTTP gegen HTTPS, eine klare Erklärung