Ist es schlecht, http zu https umzuleiten?


247

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

Anschließend wurde eine Umleitung für den gesamten Verkehr auf meiner Domain auf Port 80 eingerichtet, um ihn auf Port 443 umzuleiten.

Mit anderen Worten, mein gesamter http://example.comDatenverkehr wird jetzt auf die entsprechende https://example.comVersion der Seite umgeleitet .

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 es sich nicht um eine 301-Weiterleitung handelt, verliere ich den Link-Status / das Ranking in Suchmaschinen, wenn ich auf umschalte https?

Ich schätze die Hilfe. Ich wollte schon immer SSL auf einem Server einrichten, nur um es zu üben, und ich habe mich schließlich dazu entschlossen, es heute Abend zu tun. Bisher scheint es gut zu funktionieren, aber ich bin nicht sicher, ob es eine gute Idee ist, dies auf jeder Seite zu verwenden. Meine Website ist kein E-Commerce und verarbeitet keine vertraulichen Daten. Es ist hauptsächlich für das Aussehen und den Nervenkitzel, es zum Lernen zu installieren.


AKTUALISIERTE AUSGABE

Seltsamerweise erstellt Bing diesen Screenshot von meiner Website, da er überall HTTPS verwendet ...

Bildbeschreibung hier eingeben


12
[WTF - Ich kann keine Antwort hinzufügen (obwohl ich anscheinend genug Repräsentanten habe).] Meine Antwort wäre (teilweise), dass ES SCHLECHT IST . Überlegen Sie, ob Sie ein COOKIE oder einen API-Schlüssel in einem GET über HTTP übergeben möchten. Wenn Ihre Site HTTP-Anforderungen an HTTPS-Anforderungen umleitet, funktionieren diese Aufrufe, der COOKIE- oder API-Schlüssel wird jedoch in der frei verfügbaren Form übertragen. Einige APIs deaktivieren HTTP, ein robusterer Ansatz - überhaupt kein HTTP, sodass Sie es erst dann zum Laufen bringen können, wenn Sie HTTPS verwenden. Beispiel: "Alle API-Anforderungen müssen über HTTPS erfolgen. Aufrufe über HTTP schlagen
codingoutloud

8
@codingoutloud - Die Alternative ist, dass das Ganze über HTTP ohne HTTPS geschieht. Wie ist das besser?
Mark Henderson

3
@BenCrowell, das liegt daran, dass ein unverlierbares Portal einem sslstripRedirect-Angriff im Stil einer Man-in-the-Middle-Anfrage ähnelt, sodass HSTS- fähige Browser beide blockieren.
Jeffrey Hantin

3
beachten Sie, dass https bedeutet alles , was Sie umfassen sollen auch https oder es könnte nicht geladen werden mit - zB Last jquery mit src="://example.com/jquery.js"- man beachte das Fehlen httpoder httpsso der Browser lädt die entsprechenden ein. Ich hatte einen Albtraum, als ich versuchte, eingebettetes Amazon-Material richtig zu laden, da die API (über https geladen) http-Links erzeugte - was bedeutete, dass sie nicht richtig funktionierten, bis ich den undokumentierten Parameter fand, um https-Links umzuschalten
Basic

3
Jason; Ihr Update sollte eine neue Frage sein, wahrscheinlich für Webmaster, da es (technisch) nichts mit Ihrer ursprünglichen Frage zu tun hat. Aber es ist wahrscheinlich, dass Ihre Stylesheets aus einer unsicheren Domäne stammen.
Mark Henderson

Antworten:


316

Die [R]Flagge für sich ist eine 302Umleitung ( Moved Temporarily). Wenn Sie wirklich möchten, dass Benutzer die HTTPS-Version Ihrer Website verwenden (Hinweis: Ja), sollten Sie Folgendes [R=301]für eine permanente Weiterleitung verwenden:

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

A 301hält alle Ihre Google-Fu und hart verdienten PageRanks intakt . Stellen Sie sicher, dass mod_rewriteaktiviert ist:

a2enmod rewrite

Um Ihre genaue Frage zu beantworten:

Ist es schlecht, http zu https umzuleiten?

Auf keinen Fall. Es ist sehr gut.


3
Vielen Dank für die Information, mein Chef sagt mir, dass er https nur auf bestimmten Seiten seiner Site ausführt, weil es viel mehr Serverressourcen verwendet, um es auf jeder Seite auszuführen. Weißt du etwas darüber oder ist das wahr?
JasonDavis

9
@jasondavis Nur wenn Sie nicht ein paar Minuten damit verbringen, es zu optimieren .
Michael Hampton

10
"Es verwendet viel mehr Serverressourcen, um es auf jeder Seite auszuführen." Moderne CPUs verfügen über Verschlüsselungsbeschleunigungsfunktionen, die SSL nahezu kostenlos machen. Mach dir keine Sorgen über Kopf.
Adam Davis

41
@AdamDavis Der Krypto-Algorithmus ist zwar leicht, der Handshake-Overhead bleibt jedoch bestehen. HTTPS verhindert außerdem, dass HTTP-Proxys Ihren Inhalt zwischenspeichern. In den meisten Fällen ist der Overhead von HTTPS minimal und lohnenswert, aber seien Sie vorsichtig, wenn Sie zu viele Elemente generalisieren.
200_success

6
Es unterbindet das gemeinsame Caching, das für die Nutzungsmuster einiger Websites nützlich ist, und schützt häufig nur wenig (ist es wichtig, dass die Benutzer wissen, dass Sie die Website besucht haben, nicht jedoch, was Sie getan haben? Dies ist die einzige Situation, in der SSL nützlich ist). Der Hauptvorteil von SSL für jede Ressource besteht nicht darin, dass Sie z. B. Personen, die sich "um uns" kümmern, "schützen" müssen, sondern dass Sie nicht ausrutschen und es nicht verwenden können, wenn Sie es sollten.
Jon Hanna

49

Ich unterstütze zwar die Idee, nur SSL-Sites zu verwenden, aber ich würde sagen, ein Nachteil ist der Overhead, der vom Design Ihrer Site abhängt. Ich meine zum Beispiel, wenn Sie viele einzelne Bilder in IMG-Tags bereitstellen, kann dies dazu führen, dass Ihre Website viel langsamer ausgeführt wird. Ich würde jedem empfehlen, nur SSL-Server zu verwenden, um sicherzustellen, dass diese auf den folgenden Servern funktionieren.

  1. Überprüfen Sie die gesamte Website auf interne Links und stellen Sie sicher, dass alle HTTPS verwenden, wenn Sie Ihren eigenen Domainnamen in Links angeben, damit Sie keine eigenen Weiterleitungen verursachen.
  2. Aktualisieren Sie <meta property="og:url"Ihre Domain auf die https-Version Ihrer Domain.
  3. Wenn Sie <base href=erneut update verwenden, um HTTPS zu verwenden.
  4. Installieren Sie nach Möglichkeit das SPDY-Protokoll
  5. Verwenden Sie nach Möglichkeit CSS-Image-Sprites, um die Anzahl der Anfragen zu verringern.
  6. Aktualisieren Sie Ihre Sitemaps, um den https-Status anzuzeigen, damit Spinnen mit der Zeit von dieser Änderung erfahren.
  7. Ändern Sie die Suchmaschineneinstellungen wie Google Webmaster Tools, um HTTPS zu bevorzugen
  8. Laden Sie nach Möglichkeit alle Stactic-Medien auf HTTPS-CDN-Server herunter.

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


SPDY ist ein guter Vorschlag. Es scheint sogar ein Modul zu geben, das Apache 2.x SPDY-Unterstützung hinzufügt .
Calrion

18
Die Verwendung 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

1
@MauganRa Es sei denn, es handelt sich zum Beispiel um einen Link von der http-Artikelseite zur https-Anmeldeseite.
Mołot

4
Google sieht die URL, die jemand besucht, über den RefererHeader. Diese Website verwendet zum Beispiel jQuery von Googles CDN und mein Browser sendet jedes Mal eine Anfrage an Google, wenn ich die Website neu lade. Dabei Refererwird auch ein Header an Google gesendet, der auf die URL dieser Site gesetzt ist. Google kann also nachverfolgen, welche Websites ich während der Zeit, in der sich meine IP-Adresse nicht ändert, besuche (und wenn ich während dieser Zeit einen Google-Dienst nutze, kann Google diese Informationen auch mit meinem Google-Konto verbinden).
Stephan Kulla

1
1) Ich habe gerade ein Suchen und Ersetzen in meiner MySQL-Datenbank durchgeführt, http zu https ... Ich verwende WordPress, damit es wirklich einfach ist, Hunderte von Links zu aktualisieren
JasonDavis

38

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

Bezüglich der Umleitung von http zu https ist die Antwort nicht so einfach.

Durch die Umleitung wird es für Ihre Benutzer viel einfacher. Sie geben lediglich whateversite.com ein und werden zu https umgeleitet.

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

Wir haben hier also zwei konkurrierende Anforderungen: Benutzerfreundlich und sicher zu sein. Zum Glück gibt es ein Mittel namens HSTS-Header . Damit können Sie die Umleitung aktivieren. Der Browser wechselt zur sicheren Seite, merkt sich dies aber dank des HSTS-Headers. Wenn der Benutzer whateversite.com in diesem unsicheren Netzwerk eingibt, wechselt der Browser sofort zu https, ohne über die Umleitung über http zu springen. Sofern Sie nicht mit sehr sensiblen Daten arbeiten, ist dies für die meisten Websites ein fairer Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit. (Als ich kürzlich eine Anwendung für die Bearbeitung von Krankenakten eingerichtet habe, habe ich alle https ohne Weiterleitung verwendet.) Leider unterstützt der Internet Explorer kein HSTS ( Quelle). Wenn Ihre Zielgruppe hauptsächlich IE verwendet und die Daten vertraulich sind, möchten Sie möglicherweise Weiterleitungen deaktivieren.

Wenn Sie sich also nicht an IE-Benutzer wenden, verwenden Sie die Umleitung, aber aktivieren Sie auch den HSTS-Header.


Auch hier müssen mehr Menschen aufpassen. Eine andere Sache ist, dass die Leute davon ausgehen, dass sie sicher sind, weil der Endpunkt HTTPS ist. Dabei wird die Tatsache ignoriert, dass alle Informationen, die in GETs oder POSTs an die Seite gesendet werden, im Klartext vorliegen.
Velox

3
@Velox - Ich glaube nicht, dass die Implikation von "Menschen gehen davon aus, dass sie sicher sind, weil der Endpunkt HTTPS ist, und ignoriere die Tatsache, dass alle Informationen, die in GETs oder POSTs an die Seite gesendet werden, im Klartext vorliegen" ziemlich korrekt ist. Während es einige Fallstricke gibt, bewegen sich GET-Abfrageparameter beim Transport über HTTPS nicht im Klartext. Siehe zum Beispiel: stackoverflow.com/questions/323200/… POST-Payloads sind ebenfalls geschützt, aber auch nicht anfällig für Protokollierung und Referrer-Header.
Codierung laut

@codingoutloud Das ist mein Punkt. Über HTTPS werden sie verschlüsselt, bei der ersten Anforderung an die HTTP-Seite jedoch nicht.
Velox

1
@Velox - Wenn die gesamte Site auf HTTPS umleitet, ist es unwahrscheinlich, dass GET-Parameter gesendet werden, bevor HTTPS aktiviert wurde (und alles bleibt nach diesem Zeitpunkt HTTPS). Es gibt noch eine erste Anfrage, wo 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 Wettrüsten für sich.
Brilliand

@Brilliand Fairer Punkt, aber ein schwacher Punkt in der Sicherheit macht das Ganze schwach. Immer eine Überlegung wert.
Velox

22

Es ist nichts falsch mit diesem, und es ist am beste Praxis (für Websites , die in der Tat sollen über eine sichere Verbindung bedient werden). In der Tat ist das, was Sie tun, der von mir verwendeten Konfiguration ziemlich ähnlich:

<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 :)

Der 301Statuscode weist auf eine permanente Weiterleitung hin und weist fähige Clients an, die sichere URL für zukünftige Verbindungen zu verwenden (z. B. das Lesezeichen zu aktualisieren).

Wenn Sie die Site nur über TLS / SSL bereitstellen, empfehle ich eine weitere Anweisung, um HTTP Strict Transport Security (HSTS) auf Ihrem sicheren virtuellen Host zu aktivieren :

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

Dieser Header weist fähige Clients (die meisten von ihnen heutzutage, glaube ich) an , in den nächsten Sekunden nur HTTPS mit der angegebenen Domäne ( secure.example.comin diesem Fall) zu verwenden 1234. Der ; includeSubdomainsTeil ist optional und zeigt an, dass die Direktive nicht nur für die aktuelle Domain gilt, sondern für jede unter ihr (zB alpha.secure.example.com). Beachten Sie, dass der HSTS-Header nur von Browsern akzeptiert wird, wenn er über eine SSL / TLS-Verbindung bereitgestellt wird!

Eine gute kostenlose Ressource zum Testen Ihrer Serverkonfiguration anhand der aktuellen Best Practice ist der SSL-Server-Testdienst von Qualys . Ich würde versuchen, mindestens ein A zu erzielen (mehr als das kann man mit Apache 2.2 nicht erreichen, da die Kryptographie mit elliptischen Kurven nicht unterstützt wird).


Ich sollte hinzufügen, dass das Senden des Headers Strict-Transport-Security: max-age=0alle vorherigen Anweisungen negiert. Wie immer muss dies über HTTPS gesendet werden, um akzeptiert zu werden. Dies ist jedoch eine praktische Möglichkeit, um Vorgänge abzubrechen, wenn Sie festlegen, dass in der Domäne auch HTTP verwendet werden soll.
Calrion

5

Wow ! HTTP zu HTTPS umzuleiten ist eine sehr gute Sache und ich kann keine Nachteile dafür sehen.

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

Außerdem scheint die Art und Weise, wie Sie Apache für die Weiterleitung zu HTTPS eingerichtet haben, in Ordnung zu sein.


5

Ist es schlecht, http zu https umzuleiten?

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

Bei Weiterleitungen:

Es könnte effizienter sein, indem die Neuschreibungen vollständig beseitigt werden . Hier ist meine Konfiguration in einer ähnlichen Situation ...

<VirtualHost *:80>
  ServerName domainname.com

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

4

HTTPS ist nicht genau narrensicher. Normalerweise ist es natürlich eine gute Sache, HTTPS zu erzwingen. Es verhindert, dass normale Kriminelle Ihren Benutzern etwas Böses antun.

Denken Sie jedoch daran, Ihre SSL-Einstellungen wie die SSLCiphers-Einstellung zu überprüfen. Deaktivieren Sie Dinge wie RC4-Krypto, das SSLv2- und das SSLv3-Protokoll. Außerdem sollten Sie herausfinden, ob die Krypto-Systembibliotheken Ihres Systems TLS1.2 unterstützen (welches ist das, was Sie haben möchten;))

Aktivieren Sie SSL, das ist eine gute Sache.


Die Entropie wird nicht aufgebraucht ( zumindest wenn Sie sich gegen Angreifer auf der Erde verteidigen, anstatt Voodoo zu betreiben ). Entweder Sie beginnen mit einer unzureichenden Entropie und können nichts tun, was Zufälligkeit erfordert, oder Sie beginnen mit einer ausreichenden Entropie und Sie haben immer eine ausreichende Entropie, unabhängig davon, wie viel Zufälligkeit Sie erzeugen.
Gilles

Entschuldigung, was ? Unter Linux gibt es eine Reihe von Operationen, die auf einer von der Hardware abgeleiteten starken Entropie und nicht auf einer PRNG-basierten Entropie bestehen. Diese Operationen können in der Tat blockieren, wenn die Pooltiefe niedrig ist. Es ist höchstwahrscheinlich möglich, mit einer ausreichenden Entropie auf einem Linux-System zu beginnen, jedoch durch übermäßige Nutzung, um den Pool zu entleeren, was dazu führt, dass einige Operationen blockiert werden.
MadHatter

3

Persönlich bin ich alle für die Verwendung von SSL zur Sicherung von Verbindungen im Web, aber ich bin der Meinung, dass alle anderen Antworten, die hier verpasst wurden, darin bestehen, dass nicht jedes Gerät und jede Software, die eine HTTP-Verbindung herstellen kann, SSL verwenden kann. Daher würde ich in Betracht ziehen, Benutzern eine Möglichkeit zu bieten, dies zu vermeiden, wenn dies für sie nicht unterstützt wird. Es ist auch möglich, dass Personen in einigen Ländern, in denen Verschlüsselungstechnologien illegal sind, keinen Zugriff auf Ihre Website erhalten. Ich würde in Betracht ziehen, eine unverschlüsselte Landingpage mit einem Link hinzuzufügen, um die unsichere Version der Site zu erzwingen, es sei denn, ein Benutzer wählt dies ausdrücklich aus und leitet sie einfach an die HTTPS-Version weiter.


Ein Problem bei Lösungen wie einer einfachen HTTP-Landingpage, selbst wenn diese ordnungsgemäß getrennt ist, besteht darin, dass diese Seite für Manipulationen offen bleibt. Das heißt, es gibt keine tatsächliche Garantie dafür, dass der Link für die HTTPS-Version der Website den Besuchern unversehrt zur Verfügung gestellt wird.
Håkan Lindqvist

3

Hier sind einige der allgemeinen Pinselstrichprobleme:

  • MITM / SSLSTRIP : Dies ist eine große Einschränkung. Wenn Sie Ihre Site über HTTPS bereitstellen möchten, deaktivieren Sie HTTP auf der Site . Andernfalls lassen Sie Ihre Benutzer für verschiedene Man-in-the-Middle-Angriffe offen, einschließlich SSLSTRIP, das Anforderungen abfängt und sie still über HTTP bedient und ihr eigenes Malware-Skript in den Stream einfügt. Wenn der Benutzer dies nicht bemerkt, wird er denken, dass seine Sitzung sicher ist, wenn dies tatsächlich nicht der Fall ist.

    • Das Problem dabei ist jedoch, dass Sie möglicherweise viele Besucher verlieren, wenn Ihre Website eine öffentliche Website ist und Sie HTTP nur kurzerhand deaktivieren. Wahrscheinlich fällt es ihnen nicht einmal ein , HTTPS zu testen, wenn die Site nicht mit HTTP geladen wird.
  • Wenn für Ihre Site eine sichere Anmeldung erforderlich ist, sollte die gesamte Benutzersitzung gesichert sein. Authentifizieren Sie sich nicht über HTTPS und leiten Sie den Benutzer dann zurück zu HTTP. Wenn Sie dies erneut tun, sind Ihre Benutzer für MITM-Angriffe anfällig. Die Standardmethode für die Authentifizierung besteht heutzutage darin, sich einmal zu authentifizieren und dann ein Authentifizierungstoken (in einem Cookie) hin und her zu übergeben. Wenn Sie sich jedoch über HTTPS authentifizieren und dann zu HTTP umleiten, kann ein Man-in-the-Middle-Benutzer dieses Cookie abfangen und die Site so verwenden, als ob es sich um Ihren authentifizierten Benutzer handelt, wodurch Ihre Sicherheit umgangen wird.

  • Die "Leistungs" -Probleme mit HTTPS beschränken sich für alle praktischen Zwecke auf den Handshake beim Herstellen einer neuen Verbindung. Tun Sie, was Sie können, um den Bedarf an mehreren HTTPS-Verbindungen von einer URL zu minimieren, und Sie sind meilenweit voraus. Und das ist ehrlich gesagt auch dann der Fall, wenn Sie Ihre Inhalte über HTTP bereitstellen. Wenn Sie sich über SPDY informieren, werden Sie feststellen, dass alles, was es tut, darauf ausgerichtet ist, den gesamten Inhalt von einer einzigen URL über eine einzige Verbindung bereitzustellen. Ja, die Verwendung von HTTPS wirkt sich auf das Caching aus. Aber wie viele Websites sind heutzutage überhaupt nur statische, cachefähige Inhalte? Sie werden wahrscheinlich mehr für Ihr Geld bekommen, wenn Sie das Caching auf Ihrem Webserver verwenden, um redundante Datenbankabfragen zu minimieren, bei denen immer wieder unveränderte Daten abgerufen werden, und um zu verhindern, dass teure Codepfade häufiger als nötig ausgeführt werden.


Das, was Sie tun können, um sslstrip tatsächlich zu adressieren, ist, HSTS zu verwenden (vorzugsweise lassen Sie Ihre HSTS-Einstellungen vorab laden ). Ob Sie Anfragen über normales HTTP annehmen oder nicht, spielt in dieser Hinsicht keine Rolle, ein MITM kann über normales HTTP (möglicherweise als Proxy für Ihre HTTPS-Site) antworten, selbst wenn Sie nur HTTPS-Anfragen annehmen.
Håkan Lindqvist

@ HåkanLindqvist Ich habe mir wirklich ein Downvote von dir verdient? Habe ich schlechte oder gute Ratschläge bezüglich der Nichtauthentifizierung über HTTPS gegeben und dann für den Rest der Sitzung auf HTTP umgestellt? Habe ich in Bezug auf HTTPS-Leistungsmythen schlechte Ratschläge gegeben? Wenn der Client anfänglich versucht, eine Verbindung über HTTPS herzustellen, kann das MITM nicht abfangen und reagieren, ohne eine Warnung im Browser auszulösen, da sein Zertifikat nur dann übereinstimmt, wenn ein gestohlenes oder erfolgreich gefälschtes Zertifikat vorliegt. Wenn die Site andererseits eine HTTP-Verbindung akzeptiert, ist das Abfangen einfacher. In jedem Fall legt HTTPS die Messlatte höher.
Craig

..und natürlich stimme ich der Verwendung von HSTS voll und ganz zu.
Craig

Mein Problem mit der Antwort ist das erste Element in der Liste, das behauptet, sslstrip anzusprechen, obwohl dies nicht der Fall ist (wenn man von Mythen spricht). Was ich in meinem ersten Kommentar versucht habe, ist, dass der Angreifer aus Sicht des Clients im Wesentlichen "die Site" sein kann, wenn Sie über eine aktive MITM verfügen (die Sie in erster Linie für sslstrip benötigen). Es ist der Angreifer, der entscheidet, ob er einfache HTTP-Verbindungen vom Client akzeptieren möchte, und wie sich Ihr tatsächlicher Webserver in dieser Hinsicht verhält, hat keinen Einfluss darauf, was der Angreifer tun kann oder wird.
Håkan Lindqvist

@ HåkanLindqvist Außer wenn der Besucher absichtlich versucht, eine Verbindung mit HTTPS herzustellen, kann der Angreifer diese Anforderung nicht erfüllen, ohne Flags im Browser zu werfen, es sei denn, er hat es geschafft, ein Serverzertifikat zu stehlen oder irgendwie erfolgreich ein Zertifikat zu fälschen, das er hätte erstellen müssen tun, um die Verbindung zu HTTP zu wechseln. HTTPS setzt immer noch neue Maßstäbe. Wenn der Besucher den ersten Verbindungsversuch über HTTP unternimmt, sind natürlich alle Wetten vollständig ungültig.
Craig

1

Dies ist technisch gesehen keine Antwort auf Ihre ursprüngliche Frage. Wenn Sie jedoch die Google Chrome-Erweiterung HTTPSEverywhere verwenden (ich bin sicher, dass es ähnliche Erweiterungen in anderen Browsern gibt), leitet die Erweiterung Websites mit HTTP automatisch auf dieselbe Website mit HTTPS um. Ich benutze es seit einer Weile und 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 nicht sicher, ob die genauen Details vorliegen.

Zurück zu Ihrer eigentlichen Frage: Wenn Sie HTTPSEverywhere verwenden, gibt es noch weniger Anreize, nur HTTP zu verwenden, obwohl es meines Erachtens schwierig ist, die richtigen Regeln für den Zeitpunkt festzulegen, an dem Sie sie benötigen.


1

Der einzige technische Nachteil von HTTPS über HTTP besteht darin, dass die Verarbeitung von HTTPS-Anforderungen rechenintensiver ist als die von einfachem HTTP

Angesichts der Tatsache, dass die meisten modernen Server über leistungsstarke CPUs verfügen, ist diese Auswirkung in der Regel vernachlässigbar, es sei denn, Sie sind mit extrem hohem Datenverkehr konfrontiert, und an diesem Punkt setzen Sie wahrscheinlich ohnehin Load Balancer ein

Mit dem Aufkommen von Protokollen wie SPDY, für die SSL / TLS erforderlich ist, wirkt dies dem oben genannten Rechenaufwand entgegen, indem signifikante Leistungsverbesserungen in Bezug auf mehrere Anforderungen erzielt werden und Assets insgesamt schneller an den Client gesendet werden.


Das Problem mit der HTTPS-Leistung besteht darin, dass das Herstellen einer neuen Verbindung teurer ist, da es sich um mehr Roundtrips handelt und asymmetrische Verschlüsselung / Entschlüsselung viel teurer ist als symmetrische Verschlüsselung / Entschlüsselung. Sobald der Verbindungs-Handshake einen gemeinsamen symmetrischen Verschlüsselungsschlüssel erstellt, ist der laufende Aufwand praktisch irrelevant (sehr gering). Wenn Sie sich über SPDY informieren, werden Sie feststellen, dass das Ziel aller ausgefallenen Aktivitäten darin besteht, den gesamten Inhalt einer URL über eine einzelne Verbindung bereitzustellen und so den Verbindungs-Handshake-Aufwand zu verringern.
Craig

1

Es ist sehr gut, zu https umzuleiten, aber ich habe gelesen, dass es auch davon abhängt, wie Sie die Umleitung organisieren.

Das Erstellen eines dedizierten virtuellen Servers zum Umleiten der eingehenden http-Anforderungen an Ihre https-Verbindung, wie in der Antwort auf security.stackexchange.com vorgeschlagen, klingt sehr intelligent und schließt einige zusätzliche Sicherheitsbedrohungen. Eine Konfiguration in Apache würde ungefähr so ​​aussehen:

# Virtual host for rerouting
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/
</VirtualHost>

# Virtual host for secure hosting on https
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"

    ...site settings...

</VirtualHost>
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.