wake-up-neo.com

Warum nicht HTTPS für alles verwenden?

Wenn ich einen Server einrichten und die SSL-Zertifikate hätte, warum sollte ich HTTPS nicht für die gesamte Site verwenden, statt nur für Einkäufe/Anmeldungen? Ich denke, es wäre sinnvoller, nur die gesamte Site zu verschlüsseln und den Benutzer vollständig zu schützen. Dies würde Probleme verhindern, beispielsweise die Entscheidung, was gesichert werden muss, weil alles wäre, und es ist für den Benutzer keine Unbequemlichkeit.

Wenn ich bereits für einen Teil der Site ein HTTPS verwendet habe, warum sollte ich es nicht für die gesamte Site verwenden?

Dies ist eine verwandte Frage: Warum wird https nur für die Anmeldung verwendet? , aber die Antworten sind nicht zufriedenstellend. Bei den Antworten wird davon ausgegangen, dass Sie https nicht auf die gesamte Website anwenden konnten.

123
Malfist

Ich kann mir ein paar Gründe vorstellen.

  • Einige Browser unterstützen möglicherweise kein SSL. 
  • SSL kann die Leistung etwas beeinträchtigen. Wenn Benutzer große, öffentliche Dateien herunterladen, kann die Verschlüsselung dieser Dateien mit einem Systemaufwand verbunden sein. 
16
WhirlWind

Zusätzlich zu den anderen Gründen (insbesondere in Bezug auf die Leistung) können Sie bei Verwendung von HTTPS nur eine einzige Domäne pro IP-Adresse * hosten.

Ein einzelner Server kann mehrere Domänen in HTTP unterstützen, da der Server HTTP-Header dem Server mitteilt, mit welcher Domäne er antworten soll.

Bei HTTPS muss der Server dem Client sein Zertifikat während des ersten TLS-Handshakes (vor dem Start von HTTP) anbieten. Dies bedeutet, dass der Server -Header noch nicht gesendet wurde. Der Server kann also nicht wissen, welche Domäne angefordert wird und welches Zertifikat (www.foo.com oder www.bar.com) antworten soll mit.


* Fußnote: Technisch gesehen können Sie mehrere Domänen hosten, wenn Sie sie an verschiedenen Ports hosten. Dies ist jedoch im Allgemeinen keine Option. Sie können auch mehrere Domänen hosten, wenn Ihr SSL-Zertifikat über einen Platzhalter verfügt. Sie können beispielsweise foo.example.com und bar.example.com mit dem Zertifikat * .example.com hosten

25
Eadwacer

SSL/TLS wird nicht oft genug verwendet. HTTPS muss für die gesamte Sitzung verwendet werden, zu keinem Zeitpunkt kann eine Sitzungs-ID über HTTP gesendet werden. Wenn Sie für die Anmeldung nur https verwenden, liegt ein eindeutiger Verstoß gegen The OWASP top 10 for 2010 "A3: Broken Authentication and Session Management" vor.

13
rook

Warum verschicken Sie nicht jede Post mit einem manipulationssicheren, undurchsichtigen Umschlag per Einschreiben? Jemand vom Postamt hatte immer ein persönliches Sorgerecht, so dass Sie sich ziemlich sicher sein könnten, dass niemand auf Ihre Post schaut. Natürlich lautet die Antwort, dass einige Mails zwar die Kosten wert sind, die meisten jedoch nicht. Es ist mir egal, ob jemand mein "Ich bin froh, dass du aus dem Gefängnis gekommen bist!" Postkarte an Onkel Joe.

Die Verschlüsselung ist nicht kostenlos und hilft nicht immer.

Wenn eine Sitzung (z. B. Einkaufen, Bankgeschäfte usw.) mit HTTPS abgewickelt wird, gibt es keinen Grund, die gesamte Sitzung nicht so früh wie möglich zu HTTPS zu machen.

Meiner Meinung nach sollte HTTPS nur dann verwendet werden, wenn es unvermeidlich notwendig ist, entweder weil die Anfrage oder die Antwort vor einem Zwischen-Snooping geschützt werden muss. Sehen Sie sich als Beispiel die Yahoo! Startseite. Obwohl Sie angemeldet sind, werden die meisten Interaktionen über HTTP ausgeführt. Sie authentifizieren sich über HTTPS und erhalten Cookies, die Ihre Identität belegen, sodass Sie zum Lesen von Nachrichten kein HTTPS benötigen.

12
David M

Neben der Systemlast ist der Hauptgrund, dass das namenbasierte virtuelle Hosting unterbrochen wird. Bei SSL handelt es sich um eine Site - eine IP-Adresse. Dies ist ziemlich teuer und schwieriger zu verwalten.

12
Adam Wright

Für Links mit hoher Latenz erfordert der anfängliche TLS-Handshake zusätzliche Roundtrips, um die Zertifikatskette zu validieren (einschließlich Senden von Zwischenzertifikaten), Chipher-Suites zu vereinbaren und eine Sitzung einzurichten. Sobald eine Sitzung eingerichtet ist, können nachfolgende Anforderungen Sitzungs-Caching verwenden, um die Anzahl der Roundtrips zu reduzieren, aber selbst in diesem besten Fall gibt es noch mehr Roundtrips, als eine normale HTTP-Verbindung erfordert. Selbst wenn bei Verschlüsselungsvorgängen kostenlose Roundtrips nicht durchgeführt wurden, kann dies bei langsameren Netzwerkverbindungen durchaus auffällig sein, insbesondere wenn die Site das HTTP-Pipelining nicht nutzt. Für Breitbandbenutzer in einem gut verbundenen Netzwerksegment ist dies kein Problem. Wenn Sie international tätig sind, kann https leicht zu erheblichen Verzögerungen führen.

Es gibt weitere Überlegungen, z. B. die Serverwartung des Sitzungszustands, die möglicherweise erheblich mehr Arbeitsspeicher erfordern, und natürlich Datenverschlüsselungsvorgänge. Kleine Standorte brauchen sich praktisch keine Sorgen zu machen, wenn man die Server-Fähigkeit im Vergleich zu den Kosten der heutigen Hardware bedenkt. Jede große Site kann sich problemlos CPU/w-AES-Auslagerungs- oder Zusatzkarten leisten, um ähnliche Funktionen bereitzustellen.

All diese Probleme werden mit zunehmender Zeit immer schwieriger und die Fähigkeiten von Hardware und Netzwerk verbessern sich immer mehr. In den meisten Fällen bezweifle ich, dass es heute einen spürbaren Unterschied gibt.

Möglicherweise gibt es betriebliche Erwägungen wie etwa administrative Einschränkungen für den https-Verkehr (etwa Filter für Zwischeninhalte usw.), möglicherweise einige Unternehmens- oder Regierungsvorschriften. In einigen Unternehmensumgebungen ist eine Datenentschlüsselung am Rand erforderlich, um das Durchsickern von Informationen zu verhindern. Interferenzen mit Hotspot- und ähnlichen webbasierten Zugriffssystemen, die keine Nachrichten in https-Transaktionen einfügen können. Am Ende des Tages sind meiner Meinung nach die Gründe dafür, dass https standardmäßig nicht ganz normal ist, recht klein.

5
Einstein

https ist ressourcenhungriger als das normale http.

Es fordert mehr von den Servern als auch von den Clients.

4
Johan

Sie sollten HTTPS überall verwenden, aber Sie verlieren Folgendes:

  1. Sie sollten SSL-Komprimierung oder HTTP-Komprimierung aufgrund von BREACH- und CRIME-Angriffen auf keinen Fall über SSL verwenden. Also keine Komprimierung, wenn Ihre Antwort Sitzungs- oder CSRF-Bezeichner enthält. Sie können dies verhindern, indem Sie Ihre statischen Ressourcen (images, js, css) in eine Domäne ohne Cookies setzen und dort die Komprimierung verwenden. Sie können auch die HTML-Minifizierung verwenden. 

  2. Ein SSL-Zertifikat, eine IP-Adresse, sofern nicht SNI verwendet wird. Dies funktioniert nicht bei allen Browsern (altes Android, Blackberry 6 usw.).

  3. Sie sollten keine externen Inhalte auf Ihren Seiten hosten, die nicht über SSL gesendet werden.

  4. Sie verlieren den ausgehenden HTTP-Referer-Header, wenn der Browser auf eine HTTP-Seite wechselt, was für Sie möglicherweise ein Problem ist. 

3
Neil McGuigan

Wenn die gesamte Sitzung verschlüsselt ist, können Sie das Caching für statische Ressourcen wie Images und js auf Proxy-Ebene (z. B. ISP) nicht verwenden.

3
Alexei Tenitski

DasHTTPSist HTTP, das mitSSLgesichert ist. Möglicherweise müssen Sie ein kostenpflichtiges Zertifikat registrieren, damit Ihre Site verwaltet und vertrauenswürdig ist.

HTTPS ist erforderlich, wenn Ihre Site Informationen mit dem Benutzer austauschen muss und Sie die Informationen durch Verschlüsselung geschützt halten möchten.

Andernfalls ist HTTPS nicht erforderlich. Sie können es jedoch weiterhin verwenden, wenn Sie möchten.

0
K. Sopheak

Ein weiterer kleiner Punkt (vielleicht kann jemand das überprüfen): Wenn ein Benutzer Daten in ein Formularelement wie z. B. ein Textfeld eingibt und aus irgendeinem Grund die Seite aktualisiert oder der Server für einen Moment abstürzt, gehen die vom Benutzer eingegebenen Daten verloren HTTPS wird aber unter Verwendung von HTTP beibehalten.

Hinweis: Ich bin mir nicht sicher, ob dies browserspezifisch ist, aber es passiert sicherlich mit meinem Firefox-Browser. 

0
toc777

windows Server 2012 mit IIS 8.0 bietet jetzt SNI (Server Name Indication), wodurch mehrere SSL-Webanwendungen in IIS auf einer IP-Adresse gehostet werden können.

0
Webmaister

Zusätzlich zu WhirlWinds Antwort sollten Sie die Kosten und die Anwendbarkeit von SSL-Zertifikaten sowie Zugriffsprobleme berücksichtigen. 

Die Verwendung von SSL ist keine garantierte Sicherheitsdecke. Diese Art von Schutz muss in die Architektur der Anwendung integriert werden, anstatt sich auf ein magisches Geschoss zu verlassen.

0
3Dave

Der offensichtliche Grund liegt in der Performance: Alle Daten müssen vor der Übertragung vom Server verschlüsselt und nach Erhalt vom Client entschlüsselt werden. Dies ist Zeitverschwendung, wenn keine sensiblen Daten vorliegen. Es kann auch Auswirkungen darauf haben, wie viel von Ihrer Website zwischengespeichert wird.

Es kann auch für Endbenutzer verwirrend sein, wenn alle Adressen https:// anstelle des bekannten http:// verwenden. Siehe auch diese Antwort:

Warum nicht immer https verwenden, wenn eine js-Datei eingefügt wird?

0
Will Vousden

für https muss der Server Clientanforderungen und -antworten ver- und entschlüsseln. Die Auswirkungen auf die Leistung summieren sich, wenn der Server viele Clients bedient. Daher sind die meisten aktuellen Implementierungen von https auf die Kennwortauthentifizierung beschränkt. Mit zunehmender Rechenleistung kann sich dies jedoch ändern, nachdem Google Mail SSL für die gesamte Site verwendet.

0
futureelite7

Mir wurde gesagt, dass bei einem Projekt in unserem Unternehmen die Bandbreite der SSL-Nachrichten deutlich größer war als bei einfachen Nachrichten. Ich glaube, jemand sagte mir, dass es erstaunliche 12-mal so viele Daten waren. Ich habe das nicht selbst überprüft und es klingt sehr hoch, aber wenn zu jeder Seite eine Art Header hinzugefügt wird und die meisten Seiten etwas Inhalt haben, ist dies möglicherweise nicht so weit herausgekommen.

Das heißt, der Aufwand, zwischen http und https hin und her zu wechseln und zu verfolgen, welche Seiten sind, scheint mir zu viel Aufwand zu sein. Ich habe nur einmal versucht, eine Website zu erstellen, die sie vermischt hat, und wir haben den Plan aufgegeben, als wir von komplexen Dingen wie Pop-Up-Fenstern, die von Javascript erstellt wurden, in die Knie gezwungen wurden. Am Ende haben wir nur die gesamte Website als weniger Probleme gemacht. Ich schätze, in einfachen Fällen, in denen es nur einen Anmeldebildschirm und einen Zahlungsbildschirm gibt, die geschützt werden müssen, und deren einfache Seiten, ist das Mischen und Abgleichen keine große Sache.

Ich mache mir keine großen Sorgen um die Entschlüsselung des Clients. Normalerweise verbringt der Client viel mehr Zeit damit, auf Daten zu warten, als für die Verarbeitung erforderlich ist. Bis Benutzer normalerweise über Gigabit/Sek. Internetverbindungen verfügen, ist die Verarbeitungsleistung des Clients wahrscheinlich ziemlich irrelevant. Die CPU-Leistung, die der Server zum Verschlüsseln von Seiten benötigt, ist ein anderes Problem. Es kann durchaus Probleme geben, dass es nicht in der Lage ist, mit Hunderten oder Tausenden von Benutzern mitzuhalten.

0
Jay