Frage Ist es schlecht, http zu https umzuleiten?


Ich habe gerade ein SSL-Zertifikat auf meinem Server installiert.

Dann richtete es eine Umleitung für den gesamten Datenverkehr in meiner Domain auf Port 80 ein, um es auf Port 443 umzuleiten.

Mit anderen Worten, alle meine http://example.com Der Verkehr wird jetzt zu den entsprechenden weitergeleitet https://example.com Version der Seite.

Die Weiterleitung erfolgt in meiner Apache Virtual Hosts Datei mit so etwas ...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

Meine Frage ist, gibt es irgendwelche Nachteile bei der Verwendung von SSL?

Da dies keine 301 Redirect ist, verliere ich Link Juice / Ranking in Suchmaschinen durch Umschalten auf https?

Ich schätze die Hilfe. Ich wollte schon immer SSL auf einem Server einrichten, nur um das zu tun, und ich beschloss, es heute Abend zu tun. Es scheint bisher gut zu funktionieren, aber ich bin mir nicht sicher, ob es eine gute Idee ist, dies auf jeder Seite zu verwenden. Meine Website ist kein eCommerce und behandelt keine sensiblen Daten. es ist hauptsächlich für Aussehen und den Nervenkitzel, es für das Lernen zu installieren.


AKTUALISIERTE AUSGABE

Seltsamerweise erstellt Bing diesen Screenshot von meiner Seite jetzt, wo er HTTPS überall benutzt ...

enter image description here 


245
2018-01-28 00:12


Ursprung


[WTF - Ich kann keine Antwort hinzufügen (obwohl es so aussieht, als hätte ich genug Rep).] Meine Antwort wäre (teilweise) das Manchmal ist es schlecht. Erwägen Sie, einen COOKIE- oder API-Schlüssel in einem GET über HTTP zu übergeben. Wenn Ihre Site HTTP - Anfragen an HTTPS - Anfragen umleitet, würden diese Aufrufe funktionieren, aber der COOKIE - oder API - Schlüssel würde in der Clear - Exposed - Datei übertragen werden. Einige APIs schalten HTTP aus, ein robusterer Ansatz - überhaupt kein HTTP, so dass Sie es nicht einmal funktionieren, wenn Sie HTTPS verwenden. Beispiel: "Alle API-Anforderungen müssen über HTTPS gestellt werden. Aufrufe, die über einfaches HTTP ausgeführt werden, werden fehlschlagen" stripe.com/docs/api?lang=php#Authentifizierung - codingoutloud
@codingoutloud - die Alternative ist, dass die das ganze Ding passiert über HTTP ohne HTTPS überhaupt. Wie ist das besser? - Mark Henderson♦
@ BenCrowell, das ist weil a Gefangenschaftsportal sieht sehr ähnlich aus wie ein sslstripStil Redirect-Angriff (sie sind beide Man-in-the-Middle Anfrage Hijacks) so HSTS- Browser ignorieren sie beide. - Jeffrey Hantin
Seien Sie sich bewusst, dass die Verwendung von https bedeutet, dass alles, was Sie einschließen, auch https sein sollte oder dass es nicht geladen wird - zB laden Sie jquery mit src="://example.com/jquery.js" - Beachten Sie den Mangel an http oder https also lädt der Browser den passenden. Ich hatte einen Alptraum, der versuchte, eingebettete Amazon-Sachen richtig zu laden, da die API (geladen über https) erzeugte http-Links - was bedeutet, dass sie nicht richtig funktionierten, bis ich den undokumentierten Parameter gefunden hatte, um https-Links umzuschalten - Basic
Jason; Dein Update sollte eine neue Frage sein, wahrscheinlich auf Webmaster weil es zu Ihrer ursprünglichen Frage (technisch) nicht verwandt ist. Wahrscheinlich stammen Ihre Stylesheets jedoch aus einer unsicheren Domain. - Mark Henderson♦


Antworten:


Das [R] Flagge allein ist a 302 Umleitung (Moved Temporarily). Wenn Sie wirklich wollen, dass Menschen die HTTPS-Version Ihrer Website verwenden (Hinweis: Sie tun), dann sollten Sie verwenden [R=301] für eine permanente Weiterleitung:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

EIN 301 Behält alle Ihre google-fu und hart verdienten Seitenrängen intakt. Stelle sicher mod_rewrite aktiviert:

a2enmod rewrite

Um Ihre genaue Frage zu beantworten:

Ist es schlecht, http zu https umzuleiten?

Auf keinen Fall. Es ist sehr gut.


309
2018-01-28 00:27



Danke für die Informationen, mein Chef sagt mir den Grund, warum er nur https auf bestimmten Seiten seiner Website ausführt, ist, dass es viel mehr Server-Ressourcen verwendet, um es auf jeder Seite auszuführen. Weißt du etwas darüber oder wenn das wahr ist? - JasonDavis
@jasondavis Nur, wenn Sie nicht ein paar Minuten zu verbringen optimieren Sie es. - Michael Hampton♦
"Es verwendet viel mehr Serverressourcen, um es auf jeder Seite auszuführen." Moderne CPUs verfügen über Verschlüsselungsbeschleunigungsfunktionen, die SSL nahezu frei machen. Mach dir keine Sorgen über den Overhead. - Adam Davis
@AdamDavis Der Kryptoalgorithmus ist zwar leicht, aber der Handshake-Overhead ist immer noch vorhanden. Außerdem verhindert HTTPS, dass HTTP-Proxies Ihren Inhalt zwischenspeichern. Im die meisten In einigen Fällen ist der Overhead von HTTPS minimal und sinnvoll, aber seien Sie vorsichtig bei der Überallgenerierung. - 200_success
Es tötet geteiltes Caching, was für die Nutzungsmuster einiger Sites nützlich ist und schützt oft wenig (ist es wichtig, dass die Leute wissen, dass Sie die Site besucht haben, aber nicht die Details von dem, was Sie getan haben? Das ist die einzige Situation, in der SSL nützlich ist). Der Hauptvorteil von SSL auf jeder Ressource besteht nicht darin, dass Sie z. Leute, die "über uns" schauen, aber dass Sie nicht ausrutschen können und es nicht in einem Fall verwenden, in dem Sie es sollten. - Jon Hanna


Während ich die Idee von SSL nur Websites unterstütze, würde ich sagen, ein Nachteil ist Overhead je nach Website-Design. Ich meine zum Beispiel, wenn Sie viele einzelne Bilder in Img-Tags dienen, könnte dies dazu führen, dass Ihre Website viel langsamer läuft. Ich würde jedem empfehlen, der SSL nur Server verwendet, um sicherzustellen, dass sie auf dem folgenden arbeiten.

  1. Überprüfen Sie die gesamte Website auf interne Links und stellen Sie sicher, dass sie alle HTTPS verwenden, wenn Sie Ihren eigenen Domainnamen in Links angeben, sodass Sie keine eigenen Weiterleitungen verursachen.
  2. Aktualisieren Sie Ihre <meta property="og:url" um die https-Version Ihrer Domain zu verwenden.
  3. Wenn du benutzt <base href= Aktualisieren Sie erneut, um HTTPS zu verwenden.
  4. Installieren SPDY-Protokoll wenn möglich
  5. Verwenden Sie möglichst CSS-Bild-Sprites, um die Anzahl der Anfragen zu reduzieren.
  6. Aktualisieren Sie Ihre Sitemaps, um den https-Status anzugeben, damit Spider im Laufe der Zeit diese Änderung erfahren.
  7. Ändern Sie die Suchmaschineneinstellungen wie Google Webmaster-Tools, um HTTPS zu bevorzugen
  8. Wenn möglich, sollten Sie alle staktischen Medien auf HTTPS CDN-Server laden.

Wenn das oben angesprochen wird, dann bezweifle ich, dass Sie viele Probleme haben werden.


49
2018-01-28 02:08



SPDY ist ein guter Vorschlag; Es scheint sogar ein Modul zu sein Hinzufügen von SPDY-Unterstützung zu Apache 2.x. - Calrion
Verwenden von "//yourserver.com/some-uri" anstelle von "yourserver.com/some-uri"behebt das Problem (1), da der Browser abhängig vom Schema, mit dem die Seite geladen wurde, das entsprechende Schema (http oder https) auswählt. - MauganRa
@MauganRa Es sei denn, es handelt sich zum Beispiel um einen Link von der http-Artikelseite zur https-Anmeldeseite. - Mołot
Google sieht die URL, die jemand über das Internet besucht Referer Header. Zum Beispiel verwendet diese Website jQuery von Google's CDN und mein Browser sendet jedes Mal eine Anfrage an Google, wenn ich die Seite neu lade. Dabei a Referer Header wird auch an Google gesendet, das auf die URL dieser Site eingestellt ist. So kann Google die Websites, die ich besuche, während der Zeit verfolgen, in der sich meine IP-Adresse nicht ändert (und wenn ich während dieser Zeit einen Google-Dienst nutze, kann Google diese Informationen auch mit meinem Google-Konto verknüpfen). - Stephan Kulla
Für 1) Ich habe nur eine Suche und ersetzen in meiner MySQL-Datenbank http zu https ... Ich benutze WordPress, so dass es wirklich einfach gemacht, Hunderte von Links zu aktualisieren - JasonDavis


Wenn Sie https eingerichtet haben, sollten Sie es überall auf der Website verwenden. Sie vermeiden das Risiko von Problemen mit gemischten Inhalten und wenn Sie über die erforderlichen Tools verfügen, können Sie die gesamte Website sicher machen.

Bei der Umleitung von http zu https ist die Antwort nicht so einfach.

Redirecting wird es Ihren Benutzern sehr erleichtern, sie geben einfach whateversite.com ein und werden auf https umgeleitet.

Aber. Was ist, wenn sich der Benutzer manchmal in einem unsicheren Netzwerk befindet (oder sich in der Nähe befindet)? Troy Hunt und seine Ananas) Dann wird der Benutzer anfordern http://whateversite.com aus alter Gewohnheit. Das ist http. Das kann kompromittiert werden. Die Weiterleitung könnte auf zeigen https://whateversite.com.some.infrastructure.long.strange.url.hacker.org. Für einen gewöhnlichen Benutzer würde es ziemlich echt aussehen. Aber der Verkehr kann abgefangen werden.

Wir haben also zwei konkurrierende Anforderungen: Benutzerfreundlich und sicher sein. Glücklicherweise gibt es ein Heilmittel namens HSTS-Header. Damit können Sie die Weiterleitung aktivieren. Der Browser wird auf die sichere Seite wechseln, aber dank dem HSTS-Header auch daran erinnern. Wenn der Benutzer whateversite.com in das unsichere Netzwerk eingibt, geht der Browser sofort zu https, ohne durch die Weiterleitung über http zu springen. Wenn Sie nicht mit sehr sensiblen Daten umgehen, ist dies für die meisten Websites ein fairer Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit. (Als ich vor kurzem eine Anwendung eingerichtet habe, die mit Krankenakten arbeitet, habe ich alle https ohne Umleitung gemacht). Leider hat Internet Explorer keine Unterstützung für HSTS (Quelle) Wenn Ihre Zielgruppe hauptsächlich IE verwendet und die Daten sensibel sind, sollten Sie möglicherweise Weiterleitungen deaktivieren.

Wenn Sie also nicht auf IE-Benutzer abzielen, können Sie redirect verwenden, aber auch den HSTS-Header aktivieren.


38
2018-01-28 07:40



Mehr Menschen müssen darauf auch achten. Eine andere Sache ist, dass Leute davon ausgehen, dass sie sicher sind, da der Endpunkt HTTPS ist, wobei die Tatsache ignoriert wird, dass alle Informationen, die an die Seite in GETs oder POSTs gesendet werden, im Klartext sind. - Velox
@ Velox - Ich denke nicht, dass die Implikation von "Menschen davon ausgehen, dass sie sicher sind, weil der Endpunkt HTTPS ist, die Tatsache ignorierend, dass alle Informationen in GETs oder POSTs im Klartext gesendet werden" ist ziemlich genau. Während einige Fehler auftreten, werden die GET-Abfrageparameter während des Transports über HTTPS nicht transparent übertragen. Siehe zum Beispiel: stackoverflow.com/questions/323200/... POST-Payloads sind ebenfalls geschützt, während sie auch nicht anfällig für Logging und Referrer-Header sind. - codingoutloud
@codingoutloud Das ist mein Punkt. Über HTTPS sind sie verschlüsselt, aber in der ersten Anfrage an die HTTP-Seite waren sie nicht. - Velox
@Velox - Wenn die gesamte Site zu HTTPS umleitet, ist es unwahrscheinlich, dass irgendwelche GET-Parameter gesendet werden, bevor HTTPS gestartet wurde (und alles wird HTTPS nach diesem Punkt bleiben). Es gibt immer noch die erste Anfrage, bei der Cookies gesendet werden, die mit HSTS behoben werden können ... und ein kleines Angriffsfenster für SSLStrip, das möglicherweise von JavaScript besiegt werden könnte, aber das ist ein eigenes Wettrüsten. - Brilliand
@Brilliand Fairer Punkt, aber ein Schwachpunkt in Sicherheit macht die ganze Sache schwach. Immer eine Überlegung wert. - Velox


Es ist nichts falsch daran, und in der Tat ist es Best Practice (für Websites, die sollte über eine sichere Verbindung bedient werden). In der Tat ist das, was Sie tun, ziemlich ähnlich zu der Konfiguration, die ich verwende:

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

Das 301 Statuscode zeigt a an permanent Weiterleiten, wobei fähige Clients angewiesen werden, die sichere URL für zukünftige Verbindungen zu verwenden (z. B. Aktualisieren des Lesezeichens).

Wenn Sie die Site nur über TLS / SSL bedienen, würde ich eine weitere Direktive zur Aktivierung von HTTP empfehlen Strenge Transportsicherheit (HSTS) in Ihrem sichern virtueller Host:

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

Dieser Header weist fähige Clients an (die meisten von ihnen heutzutage, glaube ich), dass sie sollten Verwenden Sie nur HTTPS mit der zur Verfügung gestellten Domain (secure.example.comin diesem Fall) für die nächste 1234 Sekunden. Das ; includeSubdomains Teil ist wahlweise und zeigt an, dass die Richtlinie nicht nur für die aktuelle Domäne gilt, sondern für alle darunter (z. alpha.secure.example.com). Beachten Sie, dass der HSTS-Header ist nur akzeptiert von Browsern, wenn sie über eine SSL / TLS-Verbindung bedient werden!

Um Ihre Serverkonfiguration gegen aktuelle Best Practices zu testen, ist eine gute freie Ressource Qualys SSL Server Test Bedienung; Ich würde versuchen, mindestens ein A- zu erreichen (mehr kann man mit Apache 2.2 nicht bekommen, da die Elliptische-Kurven-Kryptographie nicht unterstützt wird).


22
2018-01-28 02:20



Ich sollte hinzufügen, die Überschrift senden Strict-Transport-Security: max-age=0 negiert jede vorherige Anweisung; wie immer, das Muss über HTTPS gesendet werden, um akzeptiert zu werden, aber es ist eine praktische Möglichkeit, Dinge zu stornieren, wenn Sie sich entschließen, auch HTTP in der Domäne zu verwenden. - Calrion


Beeindruckend ! HTTP auf HTTPS umleiten ist eine sehr gute Sache und ich kann keine Nachteile dafür sehen.

Stellen Sie nur sicher, dass Ihre Kunden über die richtige Zertifizierungsstelle verfügen, um nicht benutzerfreundliche Warnungen zu Zertifikaten im Browser zu vermeiden.

Darüber hinaus scheint die Art und Weise, wie Apache auf HTTPS umgeleitet wurde, in Ordnung zu sein.


5
2018-01-28 00:35





Ist es schlecht, http zu https umzuleiten?

Nein überhaupt nicht. Eigentlich ist es eine gute Sache zu tun!

Auf Weiterleitungen:

Es könnte effizienter sein, durch die Überschreibungen vollständig beseitigen. Hier ist meine Konfiguration in einer ähnlichen Situation ...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

5
2018-01-28 13:45





HTTPS ist nicht gerade kinderleicht. Natürlich ist das Erzwingen von HTTPS eine gute Sache. Es verhindert, dass normale Kriminelle etwas Schlechtes für Ihre Benutzer tun.

Aber denken Sie daran, Ihre SSL-Einstellungen wie die SSLCiphers-Einstellung zu überprüfen. Deaktivieren Sie Dinge wie RC4 Crypto, das SSLv2 und SSLv3 Protokoll. Außerdem sollten Sie herausfinden, ob die Krypto-System-Bibliotheken Ihres Systems TLS1.2 unterstützen (was Sie haben wollen;))

Aktivieren Sie SSL, es ist eine gute Sache.


4
2018-01-28 07:43



Entropie wird nicht aufgebraucht (Zumindest wenn du dich gegen Angreifer aus der Erde verteidigst eher, als Voodoo machen). Entweder beginnen Sie mit unzureichender Entropie, und Sie können nichts tun, was Zufälligkeit erfordert, oder Sie beginnen mit ausreichender Entropie und Sie haben immer genug Entropie, egal wie viel Zufall Sie erzeugen. - Gilles
Es tut uns leid, Was? Es gibt eine Reihe von Operationen unter Linux, die auf hardware-abgeleiteter starker Entropie statt auf PRNG-basierter wahrscheinlich guter Entropie bestehen, und diese können tatsächlich blockieren, wenn die Pool-Tiefe niedrig ist. Es ist sehr wahrscheinlich möglich, mit ausreichender Entropie auf einem Linux-System zu beginnen, aber durch übermäßige Nutzung des Pools auszulöschen, wodurch einige Operationen blockiert werden. - MadHatter


Persönlich bin ich für die Verwendung von SSL, um Verbindungen im Internet zu sichern, jedoch habe ich den Eindruck, dass alle anderen Antworten hier versäumt haben, dass nicht jedes Gerät und jede Software, die eine HTTP-Verbindung herstellen können, SSL verwenden kann. Daher würde ich in Erwägung ziehen, Benutzern einen Weg zu bieten, sie zu vermeiden, wenn sie nicht für sie unterstützt werden. Es ist auch möglich, dass Personen in einigen Ländern, in denen Verschlüsselungstechnologien illegal sind, nicht auf Ihre Website zugreifen dürfen. Ich würde es in Betracht ziehen, eine unverschlüsselte Zielseite mit einem Link hinzuzufügen, um die unsichere Version der Site zu erzwingen, es sei denn, ein Benutzer wählt eine solche Option ausdrücklich aus und leitet sie nur an die HTTPS-Version weiter.


3
2018-01-28 10:13



Ein Problem mit Lösungen wie einer einfachen HTTP-Zielseite, selbst wenn sie ordnungsgemäß getrennt sind, besteht darin, dass diese Seite manipuliert werden kann. Dh, es gibt keine Garantie, dass der Link für die HTTPS-Version der Site für die Besucher intakt ist. - Håkan Lindqvist


Hier sind einige der allgemeinen Probleme des Pinselstrichs:

  • MITM / SSLSTRIP: Das ist ein großer Vorbehalt. Wenn Sie Ihre Website über HTTPS bereitstellen möchten, Deaktivieren Sie dann HTTP auf der Site. Andernfalls lassen Sie Ihre Benutzer für verschiedene Man-in-the-Middle-Angriffe offen, einschließlich SSLSTRIP, die Anfragen abfangen und sie über HTTP ruhig bedienen und ihr eigenes Malware-Skript in den Stream einfügen. Wenn der Benutzer es nicht bemerkt, dann werden sie es tun denken Ihre Sitzung ist sicher, wenn sie es nicht ist.

    • Das Problem dabei ist jedoch, dass wenn Ihre Site eine öffentliche Site ist und Sie HTTP einfach deaktivieren, könnten Sie viele Besucher verlieren. Es wird wahrscheinlich nicht einmal auftreten zu ihnen, um HTTPS zu versuchen, wenn die Seite nicht mit HTTP lädt.
  • Wenn Ihre Site eine sichere Anmeldung erfordert, sollte die gesamte Benutzersitzung gesichert werden. Authentifizieren Sie sich nicht über HTTPS, und leiten Sie den Benutzer dann zurück an HTTP. Wenn Sie dies erneut tun, lassen Sie Ihre Benutzer anfällig für MITM-Angriffe. Der Standardansatz für die Authentifizierung besteht heutzutage darin, sich einmal zu authentifizieren und dann ein Authentifizierungs-Token (in einem Cookie) hin und her zu geben. Wenn Sie sich jedoch über HTTPS authentifizieren und dann zu HTTP umleiten, kann ein Man-in-the-Middle diesen Cookie abfangen und die Site so verwenden, als ob er Ihr authentifizierter Benutzer wäre, und Ihre Sicherheit umgehen.

  • Die "Leistung" Probleme mit HTTPS sind für alle praktischen Zwecke auf den Handshake beim Erstellen einer neuen Verbindung beschränkt. Tun Sie, was Sie können, um die Notwendigkeit mehrerer HTTPS-Verbindungen von einer URL zu minimieren, und Sie werden Meilen voraus sein. Und das ist ehrlich gesagt auch dann der Fall, wenn Sie Ihre Inhalte über HTTP bereitstellen. Wenn Sie SPDY lesen, werden Sie feststellen, dass alles, was es tut, darauf ausgerichtet ist, den gesamten Content von einer einzelnen URL über eine einzige Verbindung zu liefern. Ja, die Verwendung von HTTPS beeinflusst das Caching. Aber wie viele Websites sind heutzutage nur noch statischer, cachefähiger Inhalt? Mit dem Caching auf Ihrem Webserver werden Sie wahrscheinlich mehr Geld für Ihr Geld bekommen, um redundante Datenbankabfragen zu minimieren und immer wieder unveränderte Daten abzurufen und teure Codepfade daran zu hindern, öfter als nötig auszuführen.


3
2018-04-19 10:43



Die Sache, die Sie tun können, um tatsächlich zu adressieren sslstrip ist die Verwendung von HSTS (vorzugsweise Holen Sie sich Ihre HSTS-Einstellungen vor). Ob Sie Anfragen über einfaches HTTP akzeptieren oder nicht, spielt in dieser Hinsicht keine Rolle, ein MITM kann über einfaches HTTP (möglicherweise Proxying auf Ihre HTTPS-Site) antworten, selbst wenn Sie nur HTTPS-Anfragen akzeptieren. - Håkan Lindqvist
@ HåkanLindqvist Ich habe wirklich einen Downvote von dir verdient? Habe ich einen schlechten Ratschlag gegeben oder einen guten Ratschlag gegeben, um nicht über HTTPS zu authentifizieren und dann für den Rest der Sitzung auf HTTP umzusteigen? Habe ich schlechte Ratschläge bezüglich HTTPS-Performance-Mythen gegeben? Wenn der Client anfänglich versucht, eine Verbindung mithilfe von HTTPS herzustellen, kann das MITM nicht abfangen und reagieren, ohne eine Warnung im Browser auszulösen, da sein Zertifikat nur dann übereinstimmt, wenn es ein gestohlenes oder erfolgreich gefälschtes Zertifikat hat. Auf der anderen Seite, wenn die Site eine HTTP-Verbindung akzeptiert, ist das Abfangen einfacher. So oder so, HTTPS legt die Messlatte höher. - Craig
..und natürlich stimme ich voll und ganz mit der Verwendung von HSTS überein. - Craig
Mein Problem mit der Antwort ist der erste Punkt in der Liste, der angibt, sslstrip zu adressieren, während dies tatsächlich nicht der Fall ist (wenn man von Mythen spricht). Was ich in meinem ersten Kommentar versucht habe, ist, dass, wenn Sie ein aktives MITM haben (was Sie für sslstrip überhaupt benötigen), der Angreifer im Wesentlichen "die Seite" aus der Perspektive des Clients sein kann; Es ist der Angreifer, der entscheidet, ob er einfache HTTP-Verbindungen vom Client akzeptiert. Wie sich der tatsächliche Webserver in dieser Hinsicht verhält, hat keinen Einfluss darauf, was der Angreifer tun kann oder tun wird. - Håkan Lindqvist
@ HåkanLindqvist Nur wenn der Besucher absichtlich versucht, sich mit HTTPS zu verbinden, kann der Angreifer diese Anfrage nicht erfüllen, ohne Flags im Browser zu werfen, es sei denn, er hat ein Serverzertifikat gestohlen oder erfolgreich eines gefälscht tun, um die Verbindung zu HTTP zu wechseln. HTTPS immer noch setzt die Messlatte höher. Natürlich, wenn der Besucher den ersten Verbindungsversuch über HTTP macht, sind alle Wetten komplett deaktiviert. - Craig


Dies ist technisch keine Antwort auf Ihre ursprüngliche Frage, aber wenn Sie die Google Chrome-Erweiterung HTTPSEverywhere verwenden (ich bin mir sicher, dass es ähnliche Erweiterungen in anderen Browsern gibt), leitet die Erweiterung Websites mit HTTP automatisch an die gleiche Site mit HTTPS um. Ich benutze es seit einer Weile, und ich hatte keine Probleme (außer vielleicht Verlangsamung, aber ich habe das nicht getestet). HTTPSEverywhere kann durch bestimmte Regeln auf der Serverseite geändert werden, aber da ich in diesem Bereich nicht viel getan habe, bin ich mir über die genauen Details nicht sicher.

Gehen wir zurück zu Ihrer eigentlichen Frage, wenn Sie etwas wie HTTPSEverywhere verwenden, gibt es noch weniger Anreiz, nur HTTP zu verwenden, obwohl ich mir vorstelle, dass es schwierig ist, korrekte Regeln für den Fall einzurichten, dass Sie sie brauchen.


1
2018-01-28 04:27