MIT-Kurs "Computer Systems Security". Vorlesung 14: „SSL und HTTPS“, Teil 3

Massachusetts Institute of Technology. Vorlesung # 6.858. "Sicherheit von Computersystemen." Nikolai Zeldovich, James Mickens. 2014 Jahr

Computer Systems Security ist ein Kurs zur Entwicklung und Implementierung sicherer Computersysteme. Die Vorträge behandeln Bedrohungsmodelle, Angriffe, die die Sicherheit gefährden, und Sicherheitstechniken, die auf jüngsten wissenschaftlichen Arbeiten basieren. Zu den Themen gehören Betriebssystemsicherheit, Funktionen, Informationsflussmanagement, Sprachsicherheit, Netzwerkprotokolle, Hardwaresicherheit und Sicherheit von Webanwendungen.

Vorlesung 1: „Einführung: Bedrohungsmodelle“ Teil 1 / Teil 2 / Teil 3
Vorlesung 2: „Kontrolle von Hackerangriffen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 3: „Pufferüberläufe: Exploits und Schutz“ Teil 1 / Teil 2 / Teil 3
Vorlesung 4: „Trennung von Privilegien“ Teil 1 / Teil 2 / Teil 3
Vorlesung 5: „Woher kommen Sicherheitssysteme?“ Teil 1 / Teil 2
Vorlesung 6: „Chancen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 7: „Native Client Sandbox“ Teil 1 / Teil 2 / Teil 3
Vorlesung 8: „Netzwerksicherheitsmodell“ Teil 1 / Teil 2 / Teil 3
Vorlesung 9: „Sicherheit von Webanwendungen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 10: „Symbolische Ausführung“ Teil 1 / Teil 2 / Teil 3
Vorlesung 11: „Ur / Web-Programmiersprache“ Teil 1 / Teil 2 / Teil 3
Vorlesung 12: Netzwerksicherheit Teil 1 / Teil 2 / Teil 3
Vorlesung 13: „Netzwerkprotokolle“ Teil 1 / Teil 2 / Teil 3
Vorlesung 14: „SSL und HTTPS“ Teil 1 / Teil 2 / Teil 3

Ich denke, die Durchsetzung von HTTPS ist auf Bedenken von Benutzern zurückzuführen, die bei der Entscheidung über die Verwendung von Zertifikaten zu viel Ermessensspielraum haben.

Ein weiteres Problem, das sich in der Praxis manifestiert und auch die Verwendung von HTTPS erzwingt, ist ein unsicherer Anhang oder gemischter Inhalt auf einer Webseite. Der Punkt dieses Problems besteht darin, dass eine sichere Website oder eine beliebige Website andere Inhalte in eine Webseite einbetten kann.

Wenn Sie also eine Website haben, z. B. foo.com/index.html, kann diese mithilfe des HTTPS-Protokolls bereitgestellt werden. Auf der HTML-Seite können jedoch viele Tags vorhanden sein, die den Browser dazu zwingen, irgendwohin zu gehen und sie zu trennen Diese Seite enthält fremde Inhalte.



Das Tag für dieses Szenario sieht folgendermaßen aus:

<script scr = «http://jquery.com/…”> 

Und verweist auf die Quelle von jquery.com. Somit erleichtert die beliebte JavaScript-Bibliothek die Interaktion vieler Dinge in Ihrem Browser. Viele Webentwickler verlinken jedoch einfach auf die URL einer anderen Website. Das macht die Sache einfacher, aber was könnte der Haken sein? Angenommen, Sie haben eine sichere Site und laden einfach jQuery von dort herunter.

Student: Es könnte eine gefälschte jQuery sein.

Professor: Ja, das ist es. Es gibt zwei Möglichkeiten, um das Falsche zu bekommen, das Sie nicht erwarten. Eine Möglichkeit besteht darin, dass jQuery selbst kompromittiert wird. Sie haben etwas Ähnliches wie das, was Sie angefordert haben. Wenn jQuery kompromittiert ist, ist dies sehr schlecht. Eine andere Möglichkeit besteht darin, dass diese Anforderung ohne Verschlüsselung oder Authentifizierung über das Netzwerk gesendet wird. Wenn der Gegner Ihre Netzwerkverbindung kontrolliert, kann er diese Anforderung abfangen und Ihnen als Antwort einen weiteren JavaScript-Code senden. Dieser JavaScript-Code funktioniert nun als Teil Ihrer Seite. Und da er in dieser HTTPS-Domain foo.com arbeitet, hat er Zugriff auf Ihre geschützten Cookies foo.com und alles andere auf dieser Seite. Das scheint eine wirklich schlechte Sache zu sein, also sei vorsichtig. Und der Webentwickler muss auch darauf achten, solche Fehler nicht zu machen.

Eine der Lösungen besteht daher darin, die Sicherheit aller in eine sichere Seite eingebetteten Inhalte zu gewährleisten. Dies ist eine gute Richtlinie für viele Webentwickler. Vielleicht sollten Sie in dieser Zeile einfach jquery.com anstelle von jquery.com verwenden . Wenn die URLs die Ursprungsrichtlinie unterstützen, bedeutet dies, dass Sie einen Teil von HTTPS weglassen und einfach sagen können, dass der Ursprung dieses Skripts //jquery.com/ ist, dh scr = "//jquery.com / ..."



Dies bedeutet, dass dieses Tag Sie an jquery.com sendet, wenn es sich auf der HTTPS-Seite befindet, und an jquery.com, wenn es sich nicht auf HTTPS befindet, sondern auf einer regulären HTTP-URL. Dies ist eine Möglichkeit, ein solches Problem zu vermeiden.

Die Leute versuchen jedoch ständig, alles zu verbessern. Eine der alternativen Möglichkeiten, dieses Problem zu lösen, besteht darin, einen Hash oder so etwas wie einen Indikator hier in das Tag aufzunehmen:

 <script scr = «http://jquery.com/…”> 

Wenn Sie wissen, welche Art von Inhalten Sie herunterladen möchten, müssen Sie diese wahrscheinlich nicht vollständig über das HTTPS-Protokoll herunterladen. Tatsächlich ist es Ihnen egal, wer Ihnen diesen Inhalt zur Verfügung stellt, solange er einem bestimmten Hash entspricht.

Daher gibt es eine neue Spezifikation, mit der Sie Hashes für Tags dieser Art konfigurieren können. Anstatt mit einer HTTPS-URL auf jquery.com zu verlinken, können Sie einfach sagen, dass die Quelle des Skripts jquery.com oder sogar HTTP ist. Am Ende des Skripts fügen Sie jedoch eine Art Tag-Attribut hinzu, z. B. ist Hash gleich dem, was Sie tun hoffe, vom Server zu bekommen.



Student: Wie heißt diese Spezifikation?

Professor: Es hat einen komplexen Namen, es steht in den Anmerkungen zu den Vorlesungsskripten, so etwas wie "Subressourcenintegrität", Subressourcenintegrität. Es wird ziemlich langsam implementiert, aber ich hoffe, dass es in naher Zukunft in verschiedenen Browsern angewendet wird. Dies ähnelt einer anderen Methode zur Authentifizierung von Inhalten, ohne auf Datenverschlüsselung auf Netzwerkebene angewiesen zu sein.

Daher haben wir diesen sehr allgemeinen Plan, der SSL und TLS verwendet, um Verbindungen zu einem bestimmten Server zu authentifizieren. Dies ist eine alternative Möglichkeit, Ihre Netzwerkverbindung zu schützen. Wenn Sie sich für Integrität interessieren, benötigen Sie möglicherweise keinen sicheren, verschlüsselten Netzwerkkanal. Sie müssen lediglich angeben, was genau Sie am Ende erhalten möchten.

Student: Kommt dieser SRC-Code nicht vom Client?

Professor: Er arbeitet auf der Client-Seite, aber der Client erhält diesen Code von einem Server.

Student: Kann niemand einfach seinen JavaScript-Code in eine Seite eingeben?

Professor: Ich denke es kann. Daher bedeutet der Hash, den Inhalt der Seite vor Eindringlingen zu schützen, die versuchen, anderen JavaScript-Code einzugeben. Für jQuery ist dies sehr wichtig, da jQuery bekannt ist, da Sie nicht versuchen, den jQuery-Quellcode auszublenden. Daher möchten Sie sicherstellen, dass ein Netzwerkangreifer Ihre Verbindung nicht abfangen und eine schädliche Version von jQuery einfügen kann, die zum Verlust von Cookies führt. Es ist wahr, dass jeder den Hash dieser Dinge für sich selbst herausfinden kann. Somit ist es eine Lösung für Integritätsprobleme, nicht für die Privatsphäre.

Ich denke, Entwickler sollten dies im Auge behalten, wenn sie Seiten schreiben oder den Inhalt ihrer HTML-Seiten in HTTPS-URLs aufnehmen. Ein weiteres Problem, das wir haben, sind Cookies. Hier kommt der Unterschied zwischen Cookies mit Sicherheitsflags und nur Cookies mit Ursprungsursprung ins Spiel. Das einzige, was der Entwickler hier verderben kann, ist einfach zu vergessen, das Flag auf Cookies zu setzen. Dies geschieht. Vielleicht denkt er nur an Benutzer, die nur zur HTTPS-URL gehen, und hält das Setzen von Flags für unnötig. Ist das ein Problem? Wenn Ihre Benutzer sehr vorsichtig sind und immer HTTPS-URLs besuchen, gibt es kein Problem. Halten Sie es in diesem Fall für sinnvoll, eine Sicherheitsflagge auf Ihren Cookies zu hinterlassen?

Student: Ist es wahrscheinlich, dass ein Angreifer eine Verbindung zu Ihrer URL herstellen und Sie auf eine schädliche Website umleiten kann?

Professor: Ja. Auch wenn der Benutzer nicht explizit manuell zu einer URL in Form von Klartext wechselt, kann der Angreifer ihm dennoch einen Link zu einer unsicheren Site geben oder ihn auffordern, ein Bild mit einer anderen URL als HTTPS herunterzuladen. Und dann werden unsichere Cookies zusammen mit der Netzwerkanforderung gesendet. Das ist also ein Problem, und Sie brauchen wirklich ein Flag, auch wenn Ihre Benutzer und Ihre Anwendungen sehr vorsichtig sind.

Student: Ich gehe davon aus, dass es sichere HTTP-URLs gibt.
Professor: Ja, das stimmt. Angenommen, ich habe eine Website, die nicht einmal Port 80 abhört, und es gibt keine Möglichkeit, über Port 80 eine Verbindung zu mir herzustellen. Warum kann es also ein Problem geben, wenn ich unsichere Cookies verwende?

Student: weil der Browser Ihre Cookies nicht an eine andere Domain senden kann.

Professor: Richtig, der Browser sendet keine Cookies an eine andere Domain, aber es besteht immer noch die Gefahr, dass ein Angreifer seine URL herunterlädt. Angenommen, amazon.com verwendet nur SSL und überwacht nicht einmal Port 80. Infolgedessen setzen sie ihr sicheres Flag nicht auf Cookies. Wie kann ein Hacker seine Cookies stehlen, wenn Amazon nicht einmal Port 80 abhört?

Student: Kann der Browser immer noch denken, dass dies eine HTTP-Verbindung ist?

Professor: Nun, wenn Sie eine Verbindung zu Port 443 herstellen und SSL oder TLS verwenden, wird die Verbindung immer verschlüsselt, sodass dies kein Problem darstellt.

Student: Ein Angreifer könnte die Verbindung abfangen.

Professor: Ja, ein Angreifer kann Ihre Pakete abfangen, die versuchen, über Port 80 eine Verbindung zu Amazon herzustellen, und so tun, als hätten Sie erfolgreich eine Verbindung zur Site hergestellt. Wenn ein Angreifer die Kontrolle über Ihr Netzwerk hat, kann er Ihre an Amazon gerichteten Pakete an Port 80 seines eigenen Computers umleiten, und der Client kann den Unterschied nicht erkennen. Es sieht so aus, als hätte Amazon Port 80 abgehört, aber in Wirklichkeit werden Ihre Cookies an den Webserver dieses Hackers gesendet.

Student: weil der Kunde unbekannt ist.

Professor: Das ist richtig, da HTTP keine Möglichkeit hat, die Authentizität des Hosts zu überprüfen, mit dem Sie verbunden sind. Genau das passiert. HTTP hat keine Authentifizierung. Wenn Sie also davon ausgehen, dass es einen Netzwerkgegner gibt, müssen Sie zunächst verhindern, dass Ihre Cookies über HTTP gesendet werden, da Sie keine Ahnung haben, an wen diese HTTP-Verbindung gehen wird.

Student: Dazu müssen Sie das Netzwerk steuern.

Professor: Ja natürlich. Wenn Sie die volle Kontrolle über Ihr Netzwerk haben, wissen Sie, dass Gegner Ihre Pakete nicht abfangen können. Selbst wenn Sie die volle Kontrolle über das Netzwerk haben, können Probleme auftreten. Schauen Sie sich die Materialien für die Vorlesung über TCP an. Dort wurden verschiedene Arten von Netzwerkangriffen in Betracht gezogen.

Teilnehmerin: Aber ist es in diesem Fall nicht möglich, einen Umleitungsangriff zu verhindern?

Professor: Der Hacker wird wahrscheinlich die http-Anfrage des Kunden auf amazon.com abfangen. Diese Anfrage enthält alle Ihre Cookies für amazon.com oder Cookies für jede andere Domain, an die Sie die Anfrage senden. Wenn Sie diese Cookies nicht als sicher markieren, können sie daher sowohl über eine verschlüsselte als auch über eine unverschlüsselte Verbindung gesendet werden.

Student: Wie wird diese Anfrage initiiert?

Professor: Vielleicht können Sie den Benutzer dazu bringen, newyorktimes.com zu besuchen, wo Sie für eine Anzeige bezahlt haben, in der ein Bild von amazon.com hochgeladen wurde. Und nichts schützt den Benutzer vor der Frage: "Bitte laden Sie das Bild von dieser URL herunter." Wenn der Browser jedoch versucht, eine Verbindung zur Website herzustellen, werden Cookies gesendet, wenn die Verbindung erfolgreich hergestellt wurde.

Es gibt eine HTTPS Everywhere-Erweiterung, die Force HTTPS oder Forced HTTPS sehr ähnlich ist und versucht, diese Art von Fehler zu verhindern. Wenn Sie eine Site im erzwungenen HTTPS-Modus auswählen, verhindert der Browser in erster Linie HTTP-Verbindungen zu diesem Host.



Daher gibt es keine Möglichkeit, Ihre Cookies nicht als sicher zu markieren oder einen ähnlichen Fehler zu machen. Wenn der Entwickler vergessen hat, ein Sicherheitsflag für Cookies zu setzen, liegt die Lösung in diesem Fall auf der Hand - er muss nur seinen Fehler beheben. Es gibt jedoch ein heikleres Problem: Wenn ein sicherer Webserver das Cookie des Clients zurückerhält, hat er keine Ahnung, ob dieses Cookie über eine verschlüsselte oder eine reine Textverbindung gesendet wurde. Tatsächlich erhält der Server nur einige Schlüsselwerte für das Cookie.

Aus dem oben diskutierten Aktionsplan folgt, dass der Browser beim Senden einer Anfrage an einen sicheren Server sowohl sichere als auch unsichere Cookies enthält, da er seinerseits um deren Vertraulichkeit besorgt ist. Auf der Serverseite gibt es jedoch keine Vertraulichkeitsgarantien. Wenn der Server Benutzercookies empfängt, können diese sowohl über eine verschlüsselte als auch über eine Textverbindung gesendet werden. Dies führt zu möglichen Angriffen wie der Sitzungsfixierung.

Dies bedeutet, dass ein Angreifer beispielsweise sehen möchte, welche E-Mails Sie senden. Zu diesem Zweck setzt er Ihnen seine eigenen Cookies, die eine Kopie der Cookies seines Google Mail-Kontos sind. Wenn Sie Ihren Brief senden, wird er im Ordner "Gesendete Objekte" und nicht in Ihrem Ordner angezeigt. Es ist, als würden Sie ein Angreifer-Konto verwenden, damit er Ihre Korrespondenz aus seiner Mailbox extrahieren kann. Wenn ein Hacker also zwangsweise Sitzungscookies in Ihren Browser einfügt, zwingt er Sie, sein Konto zu verwenden. Dies ist also ein weiteres Problem, das aufgrund von Missverständnissen bei unvollständiger Trennung von HTTP- und HTTPS-Cookies auftritt.

Student: Um Ihre Cookies in den Browser eines anderen Benutzers einzufügen, müssen Sie dort eine Sicherheitslücke haben.

Professor: Nein, um Ihr Cookie zu setzen, wird die Sicherheitsanfälligkeit nicht benötigt. Sie bringen den Browser einfach dazu, eine Verbindung zur normalen HTTP-Host-URL herzustellen. Und wenn der Browser keine Erweiterung hat, z. B. HTTPS erzwingen oder HTTPS Everywhere erzwingen, können Sie als Angreifer den Schlüssel im Browser des Benutzers festlegen. Dies ist ein unsicheres Cookie, das jedoch auch für sichere Anfragen zurückgesendet wird.

Student: Wie können Sie den Browser glauben lassen, dass diese Domain dieselbe Domain ist?
Professor: Dazu müssen Sie die Netzwerkverbindung abfangen und eine der Arten von Angriffen ausführen, über die wir vor einigen Minuten gesprochen haben.

Was macht erzwungenes HTTPS eigentlich? Er versucht, einige der vielen Probleme zu verhindern. Studien zum Force HTTPS-Protokoll wurden vor 5 oder 6 Jahren veröffentlicht. Seitdem wurde es standardisiert und tatsächlich übernommen. Es sieht aus wie ein skizzenhaftes Plugin, das einige Dinge und einige Cookies speichert. Heutzutage glauben die meisten Browserentwickler, dass das Erstellen eine gute Idee war. Es ist am besten, es direkt in den Browser zu integrieren. Es gibt so etwas wie HTTP Strict Transport Security (HSTS), einen Mechanismus, um eine sichere Verbindung über das HTTPS-Protokoll zu erzwingen. Dies ist ein gutes Beispiel dafür, wie sich wissenschaftliche Forschung auf die Sicherheit von Webanwendungen und Browsern auswirkt.

Mal sehen, was Force HTTPS für eine Website macht. Mit Forced HTTPS kann eine Website dieses Bit für einen bestimmten Hostnamen setzen, und es gibt drei Faktoren, die HTTPS dazu zwingen, das Browserverhalten zu beeinflussen.

Das erste ist, dass alle Zertifikatfehler immer schwerwiegend sind. Somit hat der Benutzer keine Chance, das falsche Zertifikat mit dem falschen Hostnamen zu akzeptieren oder abgelaufen zu sein, und so weiter. Dies ist eine Sache, die den Browser ändert.

Die zweite Sache ist, dass Force HTTPS alle HTTP-Anforderungen an HTTPS umleitet. Das ist eine ziemlich gute Idee. Wenn Sie wissen, dass die Site HTTPS immer rechtmäßig verwendet, sollten Sie wahrscheinlich reguläre HTTP-Anforderungen verbieten, da dies ein Zeichen für einen Fehler oder ein Beweis dafür sein kann, dass ein Angreifer versucht, Sie dazu zu verleiten, eine Verbindung zur Site ohne Verschlüsselung anzubieten . Sie möchten sicherstellen, dass dies tatsächlich geschieht, bevor die HTTP-Anforderung ausgeführt wird. Andernfalls wird jede HTTP-Anforderung bereits an das Netzwerk gesendet.

Und das Letzte, wozu Force Force HTTPS den Browser zwingt, ist, dass es den unsicheren Einbettungsplan verbietet, den wir uns zuvor angesehen haben - wenn Sie eine HTTP-URL in eine HTTPS-Site einbetten.



Dies ist also, was die Force HTTPS-Erweiterung tut. Basierend auf der heute verwendeten Terminologie macht das HSTS-Protokoll dasselbe. Jetzt verbieten die meisten Browser standardmäßig das unsichere Einbetten. Dies war umstritten, da viele Entwickler aufgrund von Force HTTPS Probleme hatten, aber ich denke, dass Firefox, Chrome und IE es standardmäßig ablehnen, unsichere Komponenten oder zumindest unsicheres JavaScript und CSS in Ihre Seite zu laden, wenn Sie dies tun dann mach es falsch.

Student: Sie fragen den Benutzer nicht nach der Ausführung einer Aktion?

Professor: Sie sind daran gewöhnt, dass der Benutzer normalerweise zustimmt. Der IE verwendet beispielsweise ein Popup-Dialogfeld, in dem Sie gefragt werden, ob Sie zusätzlichen Inhalt oder ähnliches herunterladen möchten. Ich denke, wenn Sie es versuchen, können Sie all diese Sicherheitsmaßnahmen umgehen, aber ich rate Ihnen nicht, dies zu tun. Daher versuchen moderne Browser, einige der Probleme mit Force HTTPS und HSTS zu lösen.

Student: Was passiert, wenn eine Site HTTPS nicht unterstützt?

Professor: Was meinen Sie?

Student: Der Browser stellt keine Verbindung zur Website über HTTPS her.

Professor: Was passiert, wenn Sie eine Website haben, die HTTPS nicht unterstützt, aber diese Cookies setzt? Tatsache ist, dass Sie mit dieser Option in Ihrem Browser nicht mit dem größten Teil des Internets kommunizieren können, da sie kein HTTPS verwenden. Daher sollte der Browser in der Lage sein, über HTTPS mit den Websites zu kommunizieren, die einen solchen Schutz wirklich wünschen.

Student: Wenn ich mich richtig erinnere, können Sie kein Cookie setzen, bis die Site dies zulässt.

Professor: Ja, das stimmt. Diese Leute sind besorgt über DoS-Angriffe, bei denen dieses Plugin verwendet werden kann, um anderen Websites Probleme zu bereiten. Wenn Sie beispielsweise das Force HTTPS-Bit für einige ahnungslose Websites setzen, funktionieren diese plötzlich nicht mehr, da jetzt jeder versucht, über HTTPS eine Verbindung zu ihnen herzustellen, die er nicht unterstützt. Dies ist also ein Beispiel, das sich Sorgen über die Möglichkeit macht, einen DoS-Angriff durch erzwungenes HTTPS für Sites zu verwenden, die nicht damit rechnen.

Eine andere Sache ist, dass dieses Protokoll die Verwendung von Force HTTPS nicht für die gesamte Domäne unterstützt. Ich bin beispielsweise ein Benutzer mit.edu, der in allen Browsern HTTPS-Cookies erzwingen gesetzt hat, und jetzt funktionieren nur noch HTTPS-Verbindungen im MIT. Dies scheint ein wenig katastrophal zu sein, daher möchten Sie wahrscheinlich eine ähnliche Situation vermeiden.

Auf der anderen Seite kam das HSTS-Protokoll darauf zurück und sagte, dass Sie Force HTTPS für die gesamte Subdomain festlegen können, da es sich als nützlich für unsichere Cookies herausstellt, die zusammen mit der Anfrage gesendet werden, wenn Sie nicht wissen, woher sie ursprünglich gesendet wurden. Es gibt eine ganze Reihe von Einstellungen für diese Dinge auf der untersten Ebene, aber es ist immer noch nicht klar, was die richtige Wahl in diesem Fall bedeutet.

Es gibt eine interessante Frage, die Sie stellen könnten: Sind diese Verbesserungen grundlegend oder sollen sie nur Entwicklern helfen, Fehler zu vermeiden? Angenommen, Sie haben einen sehr verantwortungsbewussten Entwickler, der keine gefährlichen Maßnahmen ergreift, Zertifikate rechtzeitig aktualisiert und neue erstellt. Muss er Force HTTPS verwenden?

Student: Natürlich, weil nichts den Hacker aufhalten wird, der den Benutzer zwingt, etwas über HTTP herunterzuladen und dann die Verbindung abzufangen.

Professor: Es ist wahr. Wenn Sie jedoch der Meinung sind, dass er sehr fleißig ist und alle seine Cookies als sicher gekennzeichnet sind, sollte dies keine Probleme verursachen, wenn jemand die HTTP-Version Ihrer Website besucht.



Sie müssen sich jedoch wahrscheinlich noch gegen das Überschreiben von Cookies oder Injektionsangriffen verteidigen. Das ist anstrengend, aber Sie können wahrscheinlich etwas dagegen tun.

Student: Ich denke, der Entwickler kann die Authentizität des Zertifikats auf keinen Fall überprüfen, oder?

: , : « ». , , , , , . : «, !», , , - - . , .

: , , HTTP HTTPS, , , .

: , UI, - , . URL-. amazon.com, , , . HTTPS amazon.com, HTTP URL . , URL-, , amazonn.com amazon.com. . , Force HTTPS.



– Force HTTPS ? ?

: , .

: . , , Force HTTPS HTTPS . , . , Force HTTPS, , , HTTP, HTTPS. , HTTPS. , , HTTPS.

: Force HTTPS?

: , , , . , , , , , , , Force HTTPS .

, amazon.com Force HTTPS, , , , amazon.com, .



. DNSSEC. DNSSEC, , , , HTTPS Force HTTPS, DNS-. , DNSSEC, , , .

Google , . , Chrome , Force HTTPS. Chrome, , CRL Force HTTPS, . , , , . , Google, , , .

, Google , , , , , Google . , Chrome , URL- Force HTTPS.


.

Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden empfehlen, einen Rabatt von 30% für Habr-Benutzer auf ein einzigartiges Analogon von Einstiegsservern, das wir für Sie erfunden haben: Die ganze Wahrheit über VPS (KVM) E5-2650 v4 (6 Kerne) 10 GB DDR4 240 GB SSD 1 Gbit / s von $ 20 oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

VPS (KVM) E5-2650 v4 (6 Kerne) 10 GB DDR4 240 GB SSD 1 Gbit / s bis Dezember kostenlos, wenn Sie für einen Zeitraum von sechs Monaten bezahlen, können Sie hier bestellen.

Dell R730xd 2 mal günstiger? Nur wir haben 2 x Intel Dodeca-Core Xeon E5-2650v4 128 GB DDR4 6 x 480 GB SSD 1 Gbit / s 100 TV von 249 US-Dollar in den Niederlanden und den USA! Lesen Sie mehr über den Aufbau eines Infrastrukturgebäudes. Klasse mit Dell R730xd E5-2650 v4 Servern für 9.000 Euro für einen Cent?