Warum nicht HTTPS für alles verwenden?


126

Wenn ich einen Server einrichten würde und über die SSL-Zertifikate verfügen würde, warum würde ich HTTPS nicht für die gesamte Site verwenden, anstatt nur für Käufe / Anmeldungen? Ich würde denken, es wäre sinnvoller, nur die gesamte Site zu verschlüsseln und den Benutzer vollständig zu schützen. Dies würde Probleme wie die Entscheidung, was gesichert werden muss, verhindern, da alles gesichert wäre, und es ist nicht wirklich eine Unannehmlichkeit für den Benutzer.

Wenn ich bereits ein HTTPS für einen Teil der Site verwendet habe, warum möchte ich es dann 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 Site anwenden konnten.


2
Es wundert mich, dass Finanzdienstleistungsunternehmen immer noch http verwenden.
Tom Hawtin - Tackline

15
@ Tom Ich wünschte, einige der Websites, die mir Phishing-Nachrichten senden, würden https für ihre gefälschten Websites verwenden, sodass ich weiß, dass ich meine Daten an den richtigen Phisher weitergebe.
WhirlWind

Vielen Dank, dass Sie diese Frage gestellt haben. Ich ging davon aus, dass Leistung der Grund war und es viel schlimmer sein würde als http. Wenn ich die Antworten sehe, scheint die Leistung nicht besonders schlecht zu sein, was mich zu wundern lässt.
Sundar - Wiedereinsetzung Monica

4
Ich denke, Sie haben die schlechteste Antwort auf der Seite ausgewählt, mit derzeit 11 Abstimmungen. Bei der von Ihnen gewählten Antwort werden Sicherheit und Best Practices völlig außer Acht gelassen.
Turm

5
Diese Frage verdient wirklich eine gebildete moderne Antwort.
Old Badman Grey

Antworten:


17

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 es zu einer Systembelastung kommen, diese jedes Mal zu verschlüsseln.

137
Welche Browser unterstützen SSL nicht?
Malfist

6
Einige Luchs-Kompilierungen unterstützen dies nicht. Wenn Sie nur neuere Browser unterstützen, sollte es Ihnen gut gehen.
WhirlWind

5
Ich habe Folgendes durchgesehen: iweb.tntech.edu/hexb/publications/https-STAR-03122003.pdf "Sobald der Server gesättigt ist, erreicht die Systemleistung von HTTPS rund 67% des HTTP-Durchsatzes."
WhirlWind

16
Ich t buy this explanation. 1) Donverwende 2013 keinen Browser, der SSL nicht unterstützt. 2) Selbst Google verwendet derzeit SSL. 3) Richtig eingerichtet. Sie können den HTTP-Verkehr auf den richtigen https-Link umleiten.
Jfyelle

4
Schlechte Antwort, warum so manu upvotes? Welcher Browser auf der Erde SSL nicht unterstützt und Benutzer sich nicht daran erinnern müssen, https eingegeben zu haben, kann mit Weiterleitungen behandelt werden
Sanne

25

Zusätzlich zu den anderen Gründen (insbesondere in Bezug auf die Leistung) können Sie bei Verwendung von HTTPS nur eine einzelne Domain 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, sodass der Server nicht wissen kann, welche Domain angefordert wird und mit welchem ​​Zertifikat (www.foo.com oder www.bar.com) er antworten soll.


* 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. Beispielsweise können Sie sowohl foo.example.com als auch bar.example.com mit dem Zertifikat * .example.com hosten


5
Würde ein Wildcard-SSL-Zertifikat dieses Problem nicht lösen?
Rob

Die Fußnote widerspricht der Antwort: / Sie können Platzhalterzertifikate verwenden und beliebige Domains hosten. en.wikipedia.org/wiki/Wildcard_certificate
lucascaro

23
Dieses Problem wurde seit langem durch die Servernamenanzeige behoben, die heutzutage von allen gängigen Browsern unterstützt wird. en.wikipedia.org/wiki/Server_Name_Indication
tia

@tia außer nicht alle Webserver unterstützen es
meffect

2
@meffect ... Aber es gibt viele, einschließlich apache2, nginx, lighttpd und nodejs. Außerdem kann der Entwickler auswählen, welchen Reverse-Proxy er für das HTTPS-Tunneling verwendet. Die Aussage "Keine Clients unterstützen dies" wäre ein gültiger Punkt, wenn dies der Fall wäre, da der Entwickler keine Kontrolle darüber hat und dies berücksichtigen muss. Die Aussage "Einige Server unterstützen dies nicht" ist jedoch weitgehend irrelevant, gerade weil es nicht berücksichtigt werden muss. Vor allem , wenn alle der Mainstream - Servern haben tatsächlich Unterstützung.
Parthian Shot

13

SSL / TLS wird fast 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 nur https zum Anmelden verwenden, verstoßen Sie eindeutig gegen die OWASP Top 10 für 2010 "A3: Broken Authentication and Session Management".


Dies kann eine zu weit gefasste Annahme sein. Es gibt keinen Grund, warum der Sitzungsstatus für http und https nicht separat über einen einzelnen https-Anmeldevorgang verwaltet werden kann. Es ist wahrscheinlich mehr Arbeit als es wert ist und lädt sicherheitsrelevante Fehler ein, scheint aber nicht automatisch einen eindeutigen Verstoß darzustellen.
Einstein

@Einstein bitte lesen Sie die OWASP A3, es ist sehr klar formuliert. Beachten Sie, dass der Angreifer den Benutzernamen / das Kennwort nicht benötigt, wenn er das Cookie aus einer authentifizierten Sitzung hat.
Turm

Die Site bietet gemischte https / http. Die https-Anmeldung bietet separate Sitzungstoken für niedrige und hohe Sicherheit. Token mit geringer Sicherheit, die nur der http-Sitzung zugewiesen sind, funktionieren nicht für Vorgänge, die eine hohe Sicherheit erfordern. Aus meiner Lektüre geht hervor, dass OWASP A3 das Grundproblem der Möglichkeit eines Hochsicherheitszugangs über Niedrigsicherheitstransporte nur wenig beleuchtet.
Einstein

@Einstein Sie sind sich also nicht einig, dass Sitzungs-IDs zur Authentifizierung von Webbrowsern verwendet werden? Berücksichtigen Sie dieses Angriffsmuster. Bei xss-Angriffen versuchen Sie, den Wert von zu ermitteln, document.cookiedamit der Angreifer diesen zur Authentifizierung verwenden kann. Dieser Wert kann auch durch Abhören des Datenverkehrs ermittelt werden, den https stoppt. Ich bin mir nicht ganz sicher, worum es dir geht.
Turm

In Ihrem Szenario wäre die Sitzungs-ID für http für https-geschützte Ressourcen wertlos, wenn ein System zwei separate Sitzungen für eine einzelne Authentifizierungsaktion erstellen würde, damit beide Protokolle ohne https-Sitzung und zugehörige Ressourcen verwendet werden können, die durch das http-Sitzungscookie verfügbar gemacht werden. Beispielsweise könnte die http-Sitzung zur Identifizierung des Zugriffs auf öffentliche Ressourcen für Berichtszwecke oder des Zugriffs auf öffentliche Message Boards verwendet werden, sie wären jedoch für sichere Ressourcen nicht gültig.
Einstein

12

Warum senden Sie nicht jeden Postversand per Einschreiben in einem manipulationssicheren undurchsichtigen Umschlag? Jemand von der Post hat immer das persönliche Sorgerecht dafür, so dass Sie ziemlich sicher sein können, dass niemand Ihre Post beschnüffelt. Offensichtlich ist die Antwort, dass einige E-Mails zwar die Kosten wert sind, die meisten E-Mails 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 beendet wird, gibt es keinen guten Grund, die gesamte Sitzung nicht so früh wie möglich zu HTTPS zu machen.

Meiner Meinung nach sollte HTTPS nur verwendet werden, wenn dies unvermeidlich erforderlich ist, entweder weil die Anforderung oder die Antwort vor Zwischen-Snooping geschützt werden muss. Schauen Sie sich als Beispiel die Yahoo! Startseite. Obwohl Sie angemeldet sind, erfolgt der größte Teil Ihrer Interaktion über HTTP. Sie authentifizieren sich über HTTPS und erhalten Cookies, die Ihre Identität belegen. Sie benötigen also kein HTTPS, um Nachrichten zu lesen.


LOL !!! Toll! Ich wette, der schurkische Postbote, der den Umschlag mit "Ich bin froh, dass du aus dem Gefängnis gekommen bist" öffnet, wird seine Hose ein wenig ausflippen und sie perfekt wieder verschließen.
Andrei Rînea

19
Wenn Einschreiben 1% mehr kostet als 300% mehr, würde ich es für alles verwenden.
löslicher Fisch

3
You authenticate over HTTPS and get cookies that prove your identity, so you don't need HTTPS to read news stories.Dies ist nicht der richtige Weg, um mit der Sitzungsauthentifizierung umzugehen. Cookies sollten mit dem SECURE-Flag gesetzt werden. Aber ignorieren Sie diesen schrecklichen Sicherheitshinweis für eine Sekunde ... Ihre Mail-Analogie ist aus einigen Gründen nicht wirklich korrekt. Eine davon ist, dass Sie normalerweise keine Exploits in Rücksendungen einfügen oder sich ungestraft als jemand anderes ausgeben oder eine "Ihre Sitzung abgelaufen" -Nachricht in die Rücksendung einfügen können, damit diese die für Yahoo! und ihre Bank.
Parthian Shot

Die Wiederverwendung von Passwörtern und die Fixierung von Sitzungen sind unter anderem keine Probleme bei der Post.
Parthian Shot

Das sind gute Punkte, aber Sie wenden die Analyse 2016 auf eine Diskussion im Jahr 2010 an.
David M

12

Der Hauptgrund, der über die Systemlast hinausgeht, ist, 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.


+1 Dies ist der Grund, warum Google App Engine https für benutzerdefinierte Domains nicht unterstützt. Warten auf die breitere Unterstützung von TLS-SNI.
Sripathi Krishnan

1
Sie könnten dies mit SSL-terminierender Hardware zurückbekommen. Und wenn die Systemlast ein Problem ist (es ist für viele Leute!), Ist Hardware-SSL möglicherweise trotzdem der richtige Weg.
Jason

außer Sie können mehrere Domänen in demselben Zertifikat haben.
Lucascaro

10
Überhaupt nicht wahr. (Jedenfalls nicht mehr.)
Parthian Shot

7
Downvoting, da die Informationen im Beitrag veraltet sind. SNI wird jetzt von allen gängigen Browsern unterstützt.
Martin Törnwall

5

Für Verbindungen mit hoher Latenz erfordert der anfängliche TLS-Handshake zusätzliche Roundtrips, um die Zertifikatkette zu validieren (einschließlich des Sendens von Zwischenzertifikaten), sich auf Cipher Suites zu einigen und eine Sitzung einzurichten. Sobald eine Sitzung eingerichtet ist, können nachfolgende Anforderungen das Zwischenspeichern von Sitzungen verwenden, um die Anzahl der Roundtrips zu verringern. Selbst in diesem besten Fall gibt es jedoch immer noch mehr Roundtrips, als eine normale HTTP-Verbindung erfordert. Selbst wenn Verschlüsselungsvorgänge kostenlos waren, sind Roundtrips nicht möglich und können über langsamere Netzwerkverbindungen deutlich wahrgenommen werden, insbesondere wenn die Site kein http-Pipelining nutzt. Für Breitbandbenutzer in einem gut vernetzten Segment des Netzwerks ist dies kein Problem. Wenn Sie international geschäftlich tätig sind und https benötigen, kann dies leicht zu spürbaren Verzögerungen führen.

Es gibt zusätzliche Überlegungen wie die Serverwartung des Sitzungsstatus, die möglicherweise erheblich mehr Speicher erfordert, und natürlich Datenverschlüsselungsvorgänge. Kleine Websites müssen sich praktisch keine Gedanken über die Serverfähigkeit oder die Kosten der heutigen Hardware machen. Jeder große Standort kann sich problemlos CPU / w-AES-Offload- oder Add-On-Karten leisten, um ähnliche Funktionen bereitzustellen.

All diese Probleme werden im Laufe der Zeit immer weniger zum Thema, und die Fähigkeiten von Hardware und Netzwerk verbessern sich. In den meisten Fällen bezweifle ich, dass es heute einen spürbaren Unterschied gibt.

Möglicherweise gibt es betriebliche Überlegungen wie administrative Einschränkungen für den https-Verkehr (z. B. Filter für Zwischeninhalte usw.), möglicherweise einige Unternehmens- oder behördliche Vorschriften. In einigen Unternehmensumgebungen ist eine Datenentschlüsselung am Umfang erforderlich, um Informationslecks zu vermeiden. Interferenzen mit Hotspots und ähnlichen webbasierten Zugriffssystemen, die keine Nachrichten in https-Transaktionen einfügen können. Letztendlich sind aus meiner Sicht die Gründe dafür, dass https nicht standardmäßig verwendet werden, wahrscheinlich recht gering.


4

https ist ressourcenhungriger als das normale http.

Es fordert mehr von den Servern und den Clients.


3

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


Nun, außer für SSL-terminierende Proxys oder wenn Sie ein HTTPS-fähiges CDN verwenden.
Parthian Shot

3

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

  1. Aufgrund von BREACH- und CRIME-Angriffen sollten Sie auf keinen Fall SSL-Komprimierung oder HTTP-Komprimierung über SSL verwenden. Also keine Komprimierung, wenn Ihre Antwort Sitzungs- oder CSRF-Kennungen enthält. Sie können dies abmildern, indem Sie Ihre statischen Ressourcen (Bilder, JS, CSS) in eine Domain ohne Cookies stellen und dort die Komprimierung verwenden. Sie können auch die HTML-Minimierung verwenden.

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

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

  4. Sie verlieren den ausgehenden HTTP-Referer-Header, wenn der Browser eine HTTP-Seite aufruft, was für Sie möglicherweise ein Problem darstellt oder nicht.


0

Der offensichtliche Grund ist die Leistung: 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 vorhanden sind. Dies kann sich auch darauf auswirken, wie viel von Ihrer Site zwischengespeichert wird.

Für Endbenutzer ist es möglicherweise auch verwirrend, wenn alle Adressen verwendet werden https://und nicht die vertrauten http://. Siehe auch diese Antwort:

Warum nicht immer https verwenden, wenn Sie eine js-Datei einfügen?


9
warum sollte es die Benutzer verwirren? Wie viele schauen sich tatsächlich das Protokoll des Uri an?
Malfist

Heute, 10 Jahre später, ist https häufiger und http wäre verwirrend
madprops

0

https erfordert, dass der Server Clientanforderungen und -antworten verschlüsselt und entschlüsselt. Die Auswirkungen auf die Leistung summieren sich, wenn der Server viele Clients bedient. Aus diesem Grund beschränken sich die meisten aktuellen Implementierungen von https nur auf die Kennwortauthentifizierung. Mit zunehmender Rechenleistung kann sich dies jedoch ändern, da Google Mail SSL für die gesamte Site verwendet.


0

Zusätzlich zur Antwort von WhirlWind sollten Sie die Kosten und die Anwendbarkeit von SSL-Zertifikaten, Zugriffsprobleme (es ist möglich, aber unwahrscheinlich, dass ein Client möglicherweise nicht über den SSL-Port kommunizieren kann) usw. berücksichtigen.

Die Verwendung von SSL ist keine garantierte Sicherheitsmaßnahme. Diese Art von Schutz muss in die Architektur der Anwendung integriert werden, anstatt sich auf ein Wundermittel zu verlassen.


2
Da der Benutzer bereits einen Teil der Website schützt, sind die Kosten für das Zertifikat mehr oder weniger hoch.
futureelite7

2
@ futureelite7 guter Punkt, aber wahrscheinlich relevant für andere, die dieses Thema in Zukunft erforschen könnten.
3Dave

Der Featurismus ist der Feind der Sicherheit. Die meisten Schwächen in meinen eigenen Sachen haben ihre Wurzeln in einer schlecht beratenen Funktion, die ich selbst oder ein Vorgänger in den Produktplan aufgenommen haben. Ich finde, dass das Starten einer Funktion, weil sie eine Sicherheitslücke verursacht, Sie nicht beliebter macht, als sie überhaupt abzulehnen. Popularität sollte keine Rolle spielen, aber leider kann und tut es. In Ihren Schuhen würde ich mich fragen, wie sehr ich wirklich mit ungesicherten Benutzern umgehen möchte oder ob die App überhaupt für Benutzer geeignet ist, die keine Verschlüsselung verwenden können (denken Sie an Bankgeschäfte, Politik, Aktivismus).
Jason

0

Mir wurde gesagt, dass bei einem Projekt in unserem Unternehmen festgestellt wurde, dass die von SSL-Nachrichten belegte Bandbreite erheblich höher war als bei einfachen Nachrichten. Ich glaube, jemand hat mir gesagt, dass es erstaunliche 12-mal so viele Daten sind. Ich habe dies selbst nicht überprüft und es klingt sehr hoch, aber wenn jeder Seite eine Art Kopfzeile hinzugefügt wird und die meisten Seiten eine geringe Menge an Inhalten enthalten, ist dies möglicherweise nicht so weit entfernt.

Trotzdem scheint mir der Aufwand, zwischen http und https hin und her zu gehen und zu verfolgen, welche Seiten vorhanden sind, zu aufwendig. Ich habe nur einmal versucht, eine Site zu erstellen, die sie vermischt, und wir haben den Plan schließlich aufgegeben, als wir von komplexen Dingen wie Popup-Fenstern, die von Javascript erstellt wurden und auf die das falsche Protokoll angehängt wurde, und dergleichen gestolpert sind. Am Ende haben wir nur die gesamte Website https als weniger problematisch eingestuft. Ich denke, in einfachen Fällen, in denen Sie nur einen Anmeldebildschirm und einen Zahlungsbildschirm haben, die geschützt werden müssen, und es sich um einfache Seiten handelt, wäre es keine große Sache, sie zu kombinieren.

Ich würde mir keine großen Sorgen über die Belastung des Clients beim Entschlüsseln machen. Normalerweise verbringt der Client viel mehr Zeit damit, darauf zu warten, dass Daten über das Kabel übertragen werden, als für die Verarbeitung erforderlich ist. Bis Benutzer routinemäßig ü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 möglich ist, mit Hunderten oder Tausenden von Benutzern Schritt zu halten.


1
Die zusätzliche Bandbreite ist auch im schlimmsten Fall gering.
Präsident James K. Polk

0

Ein weiterer kleiner Punkt (möglicherweise kann jemand dies überprüfen): Wenn ein Benutzer Daten in ein Formularelement wie ein Textfeld eingibt und dann aus irgendeinem Grund die Seite aktualisiert oder der Server für eine Sekunde ausfällt, gehen die vom Benutzer eingegebenen Daten verloren HTTPS wird jedoch über HTTP beibehalten.

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


0

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


1
Was hat das mit der Frage zu tun? Es ist eine interessante Funktion, aber ich sehe die Relevanz nicht.
user1618143
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.