山东有线聊城分公司招聘劳务派遣22人

Hypertext Transfer Protocol Secure

Familie:	Internetprotokollfamilie
Einsatzgebiet:	verschlüsselte Datenübertragung
Port:	443/TCP
HTTPS im TCP/IP-Protokollstapel: Anwendung HTTP Transport SSL/TLS TCP Internet IP (IPv4, IPv6) Netzzugang Ethernet Token Bus Token Ring FDDI …
Standards:	RFC 9110 (HTTP Semantics, 2022)

百度 +1

Hypertext Transfer Protocol Secure (HTTPS; englisch für ?sicheres Hypertext-übertragungsprotokoll“) ist ein Netzwerkprotokoll im World Wide Web, mit dem Daten abh?rsicher übertragen werden k?nnen. Es stellt ein Verschlüsselungsprotokoll für die Transportverschlüsselung dar. Technisch baut HTTPS auf TLS auf, das eine zus?tzliche Kommunikationsschicht zwischen HTTP und TCP darstellt. Eine HTTPS-Adresse wird über das URI-Schema ?http“ identifiziert.

HTTPS wurde von Netscape entwickelt und zusammen mit SSL 1.0 erstmals 1994 mit deren Browser ver?ffentlicht. Eine formale Spezifikation wurde im Jahr 2000 als Request for Comments RFC 2818 ver?ffentlicht. Diese wurde im Jahr 2022 durch den Internetstandard RFC 9110 abgel?st.

Nutzen

Schloss als Icon der Adressleiste

HTTPS wird zur Herstellung von Vertraulichkeit und Integrit?t in der Kommunikation zwischen Webserver und Webbrowser (Client) im World Wide Web verwendet. Dies wird unter anderem durch Verschlüsselung und Authentifizierung erreicht.

Ohne Verschlüsselung sind Daten, die über das Internet übertragen werden, für jeden, der Zugang zum entsprechenden Netz hat, als Klartext lesbar. Mit der zunehmenden Verbreitung von offenen (d. h. unverschlüsselten) WLANs nimmt die Bedeutung von HTTPS zu, weil damit die Inhalte unabh?ngig vom Netz verschlüsselt werden k?nnen.

Die Authentifizierung dient dazu, dass beide Seiten der Verbindung beim Aufbau der Kommunikation die Identit?t des Verbindungspartners überprüfen k?nnen. Dadurch sollen Man-in-the-Middle-Angriffe und teilweise auch Phishing verhindert werden.

Technik

Syntaktisch ist HTTPS identisch mit dem Schema für HTTP, die zus?tzliche Verschlüsselung der Daten geschieht mittels SSL/TLS: Unter Verwendung des SSL-Handshake-Protokolls findet zun?chst eine geschützte Identifikation und Authentifizierung der Kommunikationspartner statt. Anschlie?end wird mit Hilfe asymmetrischer Verschlüsselung oder des Diffie-Hellman-Schlüsselaustauschs ein gemeinsamer symmetrischer Sitzungsschlüssel ausgetauscht. Dieser wird schlie?lich zur Verschlüsselung der Nutzdaten verwendet.

Der Standard-Port für HTTPS-Verbindungen ist 443.

Neben den Server-Zertifikaten k?nnen auch signierte Client-Zertifikate nach X.509.3 erstellt werden. Das erm?glicht eine Authentifizierung der Clients gegenüber dem Server, wird jedoch selten eingesetzt.

Eine ?ltere Protokollvariante von HTTPS war S-HTTP.

Client-Verarbeitung

Mit der Entwicklung von HTTPS durch Netscape wurde das Protokoll und die anwenderseitige Client-Software schon früh in Webbrowser integriert. Damit ist meist keine weitere Installation gesonderter Software notwendig.

Eine HTTPS-Verbindung wird durch eine http-URL angew?hlt und durch das SSL-Logo angezeigt. Dies wird bei allen gel?ufigen Browsern als kleines Schloss-Symbol in der Adresszeile dargestellt.

Varianten der HTTPS-Anwahl

Die Entscheidung, ob eine sichere HTTPS- statt einer HTTP-Verbindung genutzt wird, kann unterschiedlich erfolgen:

• Serverseitig wird ausschlie?lich HTTPS zugelassen; eine aufgerufene HTTP-Adresse wird automatisch auf HTTPS weitergeleitet. Dies entspricht dem Stand der Technik im Internet.
• Der Login wird über HTTPS erzwungen, bei dem ein HTTP-Cookie im Browser gesetzt wird, w?hrend die anderen Seitenaufrufe im Klartext gesendet werden. Dies war eine früher übliche Vorgehensweise, um sensible Informationen wie das Passwort oder Zahlungsdaten zu schützen, und ansonsten Rechenzeit zu sparen.
• HTTP Strict Transport Security (HSTS): Der Server signalisiert beim ersten Seitenaufruf, dass der Client für alle zukünftigen Aufrufe HTTPS verwenden muss. Der Client speichert diese Information und stellt bei zukünftigen Besuchen immer eine Verbindung über HTTPS her. Dies entspricht dem Sicherheitsmodell Trust on First Use. Einige Browser-Hersteller liefern eine vorinstallierte Liste von HSTS-Eintr?gen aus, mit der der Browser auch schon beim ersten Besuch die Verwendung von HTTPS erzwingt.
• Clientseitige Eingabe der HTTPS-Variante oder Browser-Plug-in (z. B. für Firefox und Chrome ?HTTPS Everywhere“), welches HTTP-Anfragen durch HTTPS-Anfragen ersetzt, bei Diensten, die beide Varianten unterstützen.
• Seit 2020 (Version 83) kann Firefox so eingestellt werden, dass es nur HTTPS verwendet. Falls eine Website nur über das unsichere HTTP erreicht werden kann, erfolgt der Zugriff erst nach expliziter Zustimmung durch den Nutzenden.

Vertrauensanker

Die Authentizit?t einer aufgerufenen HTTPS-Adresse ergibt sich durch ein Digitales Zertifikat des Webservers. Das Zertifikat ist Teil einer Public-Key-Infrastruktur (PKI) nach dem X.509-Standard. Serverzertifikate werden von Zertifizierungsstellen ausgestellt, deren Wurzelzertifikate dem Browser bekannt sein müssen und als Vertrauensanker dienen. Ist das Serverzertifikat authentisch, so zeigt der Browser die Verbindung als sicher an.

Ist das Wurzelzertifikat dem Browser nicht bekannt, so führt das zu einer Sicherheitswarnung beim Seitenaufruf. Je nach Einstellung der Browser und des Servers (HSTS, siehe oben) kann der Anwender die Seite entweder gar nicht aufrufen oder explizit auf eigenes Risiko eine ?Ausnahme hinzufügen“. Eine Website ohne ein im Browser eingetragenes Zertifikat ist damit für Massenanwendungen untauglich.

Je nach Browser und Betriebssystem liefern die Browser-Hersteller entweder eine Liste von vertrauenswürdigen Stammzertifikaten mit oder greifen auf den Zertifikatsspeicher des Betriebssystems zurück. Ob ein Wurzelzertifikat dem Browser bekannt ist, h?ngt somit von der Version des Browsers und des Betriebssystems ab. Die Liste der vertrauenswürdigen Wurzelzertifikate wird durch den Hersteller mit Softwareaktualisierungen auf den neuesten Stand gebracht.

Welche Wurzelzertifikate die Hersteller in ihre Zertifikatsspeicher aufnehmen, ergibt sich aus den Regelungen des CA/Browser Forums. Die Zertifizierungsstelle muss hierbei durch einen externen Audit nachweisen, mit den Sicherheitsvorgaben konform zu sein. Da dies mit Kosten verbunden ist, stellt es eine Aufnahmehürde dar. Das in der Open-Source-Community verbreitete CAcert, ein früher Anbieter kostenloser Zertifikate, ist eine prominente Zertifizierungsstelle, das nicht in den Browsern mitgeliefert wird. Anwender, die eine Seite mit CAcert-Zertifikat besuchen, müssen das Wurzelzertifikat h?ndisch installieren.

Um die Verbreitung von HTTPS zu f?rdern, ging Ende 2015 die gemeinnützige Zertifizierungsstelle Let’s Encrypt in Betrieb. Let’s Encrypt stellt für jeden kostenlose Zertifikate aus, die von den g?ngigen Browsern als vertrauenswürdig akzeptiert werden. Für die Installation und laufende Aktualisierung der Zertifikate ist eine Software auf dem Server notwendig.

Server-Betrieb

Als Software zum Betrieb eines HTTPS-f?higen Webservers wird eine SSL-Bibliothek wie OpenSSL ben?tigt. Diese wird h?ufig bereits mitgeliefert oder kann als Modul installiert werden. Der HTTPS-Service wird üblicherweise auf Port 443 bereitgestellt.

Zertifikat

Das digitale Zertifikat für SSL, das die Authentifizierung erm?glicht, ist vom Server bereitzustellen: Ein Bin?rdokument, das im Allgemeinen von einer – selbst wiederum zertifizierten – Zertifizierungsstelle (CA von englisch certificate authority) ausgestellt wird, das den Server und die Domain eindeutig identifiziert. Bei der Beantragung werden dazu etwa die Adressdaten und der Firmenname des Antragstellers geprüft.

In g?ngigen Browsern eingetragene Zertifikate werden typischerweise zu Preisen zwischen 15 und 600 € pro Jahr angeboten, wobei fallweise weitere Dienste, Siegel oder Versicherungen enthalten sind. Eine Reihe von Zertifizierungsstellen gibt kostenlos Zertifikate aus. Die etwa von Let’s Encrypt ausgestellten Zertifikate werden dabei von fast allen modernen Browsern ohne Fehlermeldung akzeptiert. Ebenfalls kostenlose Zertifikate erstellt CAcert, wo es bisher jedoch nicht gelang, in die Liste der vom Browser automatisch akzeptierten Zertifikate aufgenommen zu werden; siehe oben. Ein solches Zertifikat muss daher bei der Client-Verarbeitung vom Anwender manuell importiert werden; dieses Verhalten kann aber auch erwünscht sein.

Um veraltete oder unsicher gewordene Zertifikate für ungültig zu erkl?ren, sind Zertifikatsperrlisten (englisch certificate revocation list, CRL) vorgesehen. Das Verfahren sieht vor, dass diese Listen regelm??ig von Browsern geprüft und darin gesperrte Zertifikate ab sofort abgewiesen werden.

Mit dem OCSP (Online Certificate Status Protocol) kann, erg?nzt um SCVP (Server-based Certificate Validation Protocol), serverseitig die Unterstützung für Zertifikats-Prüfungen umgesetzt werden.

Zu Angriffen auf das Zertifikatsystem, siehe unten.

Selbst-signiert

Ein Server-Betreiber kann auch selbst-signierte Zertifikate (englisch self-signed certificate) kostenlos erstellen, ohne Beteiligung einer dritten Instanz. Diese müssen vom Browser-Anwender manuell best?tigt werden ('Ausnahme hinzufügen'). In diesem Fall garantiert kein Dritter die Authentizit?t des Anbieters. Ein solches Zertifikat kann wiederum dem Anwender vorab auf einem sicheren Weg zugestellt und in seine Client-Anwendung importiert werden, um Authentizit?t auf anderem Wege abzubilden.

Extended-Validation-Zertifikat

→ Hauptartikel: Extended-Validation-Zertifikat

Vor dem Hintergrund zunehmender Phishing-Angriffe auf HTTPS-gesicherte Webanwendungen hat sich 2007 in den USA das CA/Browser Forum gebildet, das aus Vertretern von Zertifizierungsorganisationen und den Browser-Herstellern besteht. Zum Gründungszeitpunkt waren die Browser-Hersteller KDE, Microsoft, Mozilla und Opera beteiligt. Im Juni 2007 wurde daraufhin eine erste gemeinsame Richtlinie verabschiedet, das Extended-Validation-Zertifikat, kurz EV-SSL in Version 1.0, im April 2008 dann Version 1.1.

Ein Domain-Betreiber muss für dieses Zertifikat weitere Prüfungen akzeptieren: W?hrend bisher nur die Erreichbarkeit des Administrators (per Telefon und E-Mail) zu prüfen war, wird nun die Postadresse des Antragstellers überprüft und bei Firmen die Prüfung auf zeichnungsberechtigte Personen vorgenommen. Damit sind auch deutlich h?here Kosten verbunden.

IP-Adressen bei mehreren Domains

Zum Betrieb eines HTTPS-Webservers war lange Zeit eine eigene IP-Adresse pro Hostname notwendig.

Bei unverschlüsseltem HTTP ist das nicht erforderlich: Seitdem Browser den Hostnamen im HTTP-Header mitsenden, k?nnen mehrere virtuelle Webserver mit je eigenem Hostnamen auf einer IP-Adresse bedient werden, zum Beispiel bei Apache über den NameVirtualHost-Mechanismus. Dieses Verfahren wird inzwischen bei der weit überwiegenden Zahl der Domains benutzt, da hier der Domain-Eigner selbst keinen Server betreibt.

Da bei HTTPS jedoch der Webserver für jeden Hostnamen ein eigenes Zertifikat ausliefern muss, der Hostname aber erst nach erfolgtem SSL-Handshake in der h?heren HTTP-Schicht übertragen wird, ist das Deklarieren des Hostnamens im HTTP-Header hier nicht anwendbar. Dadurch war eine Unterscheidung nur anhand der IP/Port-Kombination m?glich; ein anderer Port als 443 wird wiederum von vielen Proxys nicht akzeptiert.

Vor diesem Hintergrund nutzten einige Provider einen Workaround, um ihren Kunden auch HTTPS ohne eigene IP-Adresse zu erm?glichen, etwa ?shared SSL“. Sie nutzten Wildcard-Zertifikate, die für alle Subdomains einer Domain gültig sind, in Verbindung mit kundenspezifischen Subdomains. Andere Provider nutzten einen ?SSL Proxy“, der die Anfragen über eine von mehreren Kunden genutzte Domain leitete.

Die L?sung dieses Problems kam durch Server Name Indication (SNI), auf Basis von Transport Layer Security 1.2, da hier der vom Browser gewünschte Hostname bereits beim SSL-Handshake übermittelt werden kann. Damit sind die oben genannten anderen Techniken bedeutungslos geworden. Das Verfahren bedarf entsprechend aktueller Software auf Seiten des Servers und des Browsers und wurde von diesen ab 2006 unterstützt.

Im Falle des Apache-Servers wird die SNI-Verarbeitung z. B. durch eine nur leicht modifizierte Konfigurations-Anweisung gesteuert:
<VirtualHost _default_:443>

Einbindung

Die Einbindung von HTTPS in eine Website oder -anwendung erfolgt analog zu den oben genannten Varianten der HTTPS-Anwahl:

• Wenn ausschlie?lich HTTPS zul?ssig ist, kann das umgesetzt werden durch:
  • Weiterleitung (HTML-refresh) oder auch ein rewrite der URL
  • Konfiguration von HTML-Seiten oder Skripten als Muss-SSL, bei Apache etwa durch die Anweisung SSLRequireSSL in der .htaccess. Wird eine solche Seite per HTTP aufgerufen, erzeugt der Server einen '403 – Forbidden' HTTP-Fehlercode.
• Der Anwender wird auf die M?glichkeit der SSL-Nutzung durch einen entsprechenden Link hingewiesen.
  • Teilweise wird, vor allem w?hrend der Einführung von HTTPS, auf eine Bewerbung durch einen Link verzichtet. Der Anwender kann nur manuell auf HTTPS umschalten, indem er in der URL selbstst?ndig das ?s“ hinter ?http“ hinzufügt.
• Skriptgesteuerte Erzeugung von HTTPS-Links, um den Anwender bei bestimmten Arbeitsschritten oder Ausgaben auf eine HTTPS-Seite zu lenken. Anschlie?end kann im Skript geprüft werden, ob dieses per HTTPS aufgerufen wurde, bei PHP etwa durch die Bedingung: $_SERVER['HTTPS']=='on'

Umstellung

Mit zunehmender CPU-Leistung sowie Sicherheitsbewusstsein tritt regelm??ig die Anforderung auf, eine bisher auf HTTP basierende Website auf HTTPS umzustellen. Im Falle der Website Stack Overflow mit einer Vielzahl von Usern und Services zieht sich dieser Prozess über einige Jahre hin und ist Stand M?rz 2017 nicht abgeschlossen. Dabei wurden u. a. folgende Themen bearbeitet:

• Vermeidung von Einbindungen von unverschlüsselten Daten (Mediadaten, Stylesheets etc.) in eine verschlüsselte Seite (sogenannter Mixed Content). Andernfalls werden Browserwarnungen wie 'Part of this page is not secure' ausgegeben oder Daten nicht geladen.
• Gesamte Infrastruktur ist auf SSL umzustellen, darunter Loadbalancer und Proxies
• Organisation der Zertifikate, ggf. für eine Vielzahl von Subdomains
• Umstellung von Code der eigenen Webanwendung, worin HTTP hart codiert ist
• Umstellung von altem und Prüfung von neuem User-Code, der ggf. HTTP verwendet
• Qualit?tsprüfung
• Umsetzung laufender Sessions, ohne deren Inhalte zu verlieren (24/7 Betrieb)

Leistung

Beim Verbindungsaufbau handeln Client und Server im TLS-Handshake einen Verschlüsselungsalgorithmus aus. Hierbei besteht ein Zielkonflikt zwischen m?glichst sicheren und performanten Algorithmen. Dies gilt insbesondere für den Server, da dieser für gew?hnlich mehrere Clients gleichzeitig bedient und somit einen h?heren Datenverkehr als der Client verarbeitet. Früher übliche Verfahren wie die Blockchiffre DES und die Stromchiffre RC4 bieten eine gute Leistung, gelten heute jedoch nicht mehr als hinreichend sicher. RC4 wird seit 2016 von den gro?en Webbrowsern nicht mehr unterstützt.

Zur Erh?hung der Server-Performance wird auch Hardware-Beschleunigung eingesetzt. Eine M?glichkeit ist der Einsatz von PCI-Steckkarten mit speziellen, optimierten Prozessoren, die aus der TLS-Bibliothek angesprochen werden. Daneben gibt es auch eigenst?ndige Ger?te, meist in Rack-Bauweise, die Teile des HTTP-Datenstroms automatisch verschlüsseln. Weiterhin werden Server mit programmierbaren Recheneinheiten angeboten, die mit entsprechenden SSL-Bibliotheken h?here Leistung als vergleichbar aufwendige Universal-CPUs erreichen, so die MAU (Modular Arithmetic Unit) von Sun. Diese spezielle Hardware steht aber im engen Wettbewerb mit der stetigen Entwicklung der Multiprozessor- und Multi-Core-Systeme der gro?en CPU-Hersteller Intel und AMD. Moderne Prozessoren enthalten mit AES-NI eine Hardware-Beschleunigung für den AES-Verschlüsselungsalgorithmus, der einen Teil der für HTTPS notwendigen Rechenoperationen ausmacht.

2010 verursachte die Verschlüsselung beispielsweise bei Gmail weniger als 1 % der Prozessor-Last, weniger als 10 KB Arbeitsspeicherbedarf pro Verbindung und weniger als 2 % des Netzwerk-Datenverkehrs. 10 Jahre vorher belastete der Rechenaufwand der Verschlüsselung die Server noch stark.

Angriffe und Schwachstellen

Mit den allgemein zunehmenden Kenntnissen über die HTTPS-Technik haben sich auch die Angriffe auf SSL-gesicherte Verbindungen geh?uft. Daneben sind durch Recherche und Forschungen Lücken in der Umsetzung bekannt geworden. Dabei ist grunds?tzlich zu unterscheiden zwischen Schwachstellen bei der Verschlüsselung selbst und im Zertifikatsystem. 2013 wurde im Zusammenhang mit der globalen überwachungs- und Spionageaff?re bekannt, dass die NSA beide Angriffskan?le nutzte, um Zugang zu verschlüsselten Verbindungen zu erlangen.

Verschlüsselung

Die bei SSL eingesetzten Verschlüsselungsverfahren werden unabh?ngig von ihrem Einsatzzweck regelm??ig überprüft und gelten als mathematisch sicher, d. h., sie lassen sich theoretisch mit den heute bekannten Techniken nicht brechen. Die Zuverl?ssigkeit der Algorithmen wird regelm??ig etwa durch Wettbewerbe unter Kryptologen überprüft. Regelm??ig werden in den Spezifikationen und den Implementierungen die Unterstützung veralteter Verschlüsselungsverfahren, die nach dem aktuellen Stand der Technik als nicht mehr sicher gelten, gestrichen und neue Verfahren aufgenommen.

Probleme entstanden in der Vergangenheit mehrfach durch fehlerhafte Implementierung der Kryptologie. Insbesondere Schwachstellen in der weit verbreiten OpenSSL-Bibliothek wie Heartbleed haben dabei gro?e ?ffentliche Aufmerksamkeit erfahren.

Da in der Regel Benutzer nicht explizit eine verschlüsselte Verbindung durch Spezifizierung des HTTPS-Protokolls (http://) beim Aufruf einer Webseite anfordern, kann ein Angreifer eine Verschlüsselung der Verbindung bereits vor Initialisierung unterbinden und einen Man-in-the-Middle-Angriff ausführen.

Speziell zur Abwehr von Downgrade-Angriffen gegen die Verschlüsselung sowie von Session Hijacking wurde 2012 das Verfahren HTTP Strict Transport Security oder HSTS vorgestellt. Es wird durch einen HSTS-Header seitens des Servers aktiviert, worauf im Browser u. a. http- in http-URLs umgewandelt werden.

Zertifikatsystem

SSL-Verbindungen sind grunds?tzlich gef?hrdet durch Man-in-the-Middle-Angriffe, bei denen der Angreifer den Datenverkehr zwischen Client und Server abf?ngt, indem dieser sich beispielsweise als Zwischenstelle ausgibt. Eine Reihe von Angriffsverfahren setzen voraus, dass sich der Angreifer im Netzwerk des Opfers befindet. Beim DNS-Spoofing wiederum bestehen diese Voraussetzungen nicht.

Um sich als (anderer) Server auszugeben, muss der Angreifer auch ein Zertifikat vorweisen. Das ist ihm beispielsweise dann m?glich, wenn es ihm gelingt, in das System einer Zertifizierungsstelle einzudringen, oder er anderweitig in den Besitz eines Zertifikats kommt, mit dem sich beliebige andere Zertifikate ausstellen lassen. Insbesondere bei einflussreichen Angreifern, wie etwa Regierungsbeh?rden, k?nnen solche M?glichkeiten bestehen, da mitunter auch staatliche Zertifizierungsstellen existieren. HTTP Public Key Pinning und Certificate Transparency sollen solche Angriffe erschweren.

Phishing und HTTPS

Ein Nachteil der automatischen Best?tigung der Zertifikate besteht darin, dass der Anwender eine HTTPS-Verbindung nicht mehr bewusst wahrnimmt. Das wurde in jüngerer Zeit bei Phishing-Angriffen ausgenutzt, die etwa Online-Banking-Anwendungen simulieren und dem Anwender eine sichere Verbindung vort?uschen, um eingegebene PIN/TAN-Codes ?abzufischen“. Als Reaktion wiesen betroffene Unternehmen ihre Kunden darauf hin, keine Links aus E-Mails anzuklicken und http-URLs nur manuell oder per Lesezeichen einzugeben.

Wegen der teils oberfl?chlichen Prüfungen bei der Vergabe von Zertifikaten wurde von den Browserherstellern das extended-validation-Cert eingeführt, siehe oben.

Gemischte Inhalte

Das Nachladen unverschlüsselter Ressourcen erm?glicht einem Angreifer, mittels eines Man-in-the-Middle-Angriffs Schadcode in die ursprünglich verschlüsselt übertragene Webseite einzuschleusen. Daher blockieren aktuelle Versionen g?ngiger Webbrowser das Nachladen unverschlüsselter Ressourcen standardm??ig. Ebenso besteht bei einem sowohl für verschlüsselte als auch unverschlüsselte Verbindungen genutzten HTTP-Cookie das Risiko eines Session Hijacking, auch wenn die Authentifizierung über eine verschlüsselte Verbindung erfolgte.

Schwachstelle MD5

Auf dem 25. Chaos Communication Congress in Berlin wurde im Dezember 2008 ein erfolgreicher Angriff auf das SSL-Zertifikatsystem ver?ffentlicht. In internationaler Zusammenarbeit von Kryptologen und mit Einsatz speziell programmierter Hardware – einem Cluster aus 200 Playstation-3-Spielkonsolen – war es gelungen, im MD5-Algorithmus eine Kollision zu erzeugen, auf deren Basis ein Angreifer sich selbst beliebige Zertifikate ausstellen k?nnte. Von der Verwendung des MD5-Algorithmus wurde in Fachkreisen vorher schon abgeraten; bei EV-Zertifikaten kann er ohnehin nicht verwendet werden. Die meisten Webbrowser akzeptieren schon seit 2011 keine MD5-Zertifikate mehr. Um ?hnliche Probleme zu vermeiden, kündigten die Browser-Hersteller darauf an, auch SHA1-Zertifikate nur noch eine beschr?nkte Zeit zu unterstützen.

Spezifikationen

• RFC: 2818 – HTTP Over TLS. 2000 (englisch).
• RFC: 9110 – HTTP Semantics. 2022 (englisch).

Weblinks

• SSL intro. Apache.org