Da sich die meisten anderen Antworten hier mit den Nachteilen von standortweitem SSL befassen (hauptsächlich Leistungsprobleme - übrigens können diese leicht durch Auslagern der SSL-Terminierung auf eine SSL-Proxy-Box oder eine SSL-Karte gemindert werden) Ich werde auf einige Probleme hinweisen, wenn nur die Anmeldeseite über SSL angezeigt wird und dann zu Nicht-SSL gewechselt wird:

• Der Rest der Site ist nicht gesichert (obwohl dies offensichtlich ist, liegt manchmal auch der Fokus darauf viel nur über das Passwort des Benutzers).
• Die Sitzungs-ID des Benutzers muss im Klartext übertragen werden, damit sie abgefangen und verwendet werden kann und die bösen Jungs sich als Ihre Benutzer ausgeben können. (Darum ging es hauptsächlich im Trubel von Firesheep).
• Aufgrund des vorherigen Punkts können Ihre Sitzungscookies nicht mit dem Attribut safe gekennzeichnet werden. Dies bedeutet, dass sie auf zusätzliche Weise abgerufen werden können.
• I. Ich habe Websites mit Nur-Login-SSL gesehen und natürlich die Seite "Passwort vergessen", "Passwort ändern" und sogar die Seite "Registrierung" nicht berücksichtigt.
• Der Wechsel von SSL zu Nicht-SSL ist oft kompliziert, kann eine komplexe Konfiguration auf Ihrem Webserver erfordern und in vielen Fällen wird eine beängstigende Nachricht für Ihre Benutzer angezeigt.
• Wenn es NUR die Anmeldeseite ist, und z Auf der Homepage Ihrer Website befindet sich ein Link zur Anmeldeseite. Was soll sicherstellen, dass jemand Ihre Homepage nicht fälscht, ändert oder abfängt und auf eine andere Anmeldeseite verweist?
• Dann dort Ist dies der Fall, wenn die Anmeldeseite selbst nicht SSL ist, sondern nur SUBMIT - da dies das einzige Mal ist, dass das Passwort gesendet wird, sollte dies sicher sein, oder? In Wahrheit wird dem Benutzer jedoch die Möglichkeit genommen, im Voraus sicherzustellen, dass das Kennwort an die richtige Site gesendet wird, bis es zu spät ist. (Zum Beispiel Bank of America und viele andere).

Der "Server-Overhead", der als signifikanter "Nachteil" zunimmt, ist ein verbreiteter Mythos. Die Google-Ingenieure stellten fest, dass beim Umschalten von Google Mail auf 100% SSL keine zusätzliche Hardware bereitgestellt wurde und dass SSL weniger als 1% mehr CPU-Auslastung und 2% mehr Netzwerkverkehr verursachte. Der Stapelüberlauf hat auch einige Fragen, die sich damit befassen: Wie viel Overhead verursacht SSL? und HTTP vs. HTTPS-Leistung.

Aus dem zscaler-Blogeintrag Warum wurde das Web noch nicht auf Nur-SSL umgestellt?

"Mit dem von Firesheep noch einmal hervorgehobenen Problem mit dem Session-Sidejacking Viele Leute haben mich gefragt, warum mehr Websites oder zumindest die Hauptakteure (Google, Facebook, Amazon usw.) SSL nicht standardmäßig für die gesamte Kommunikation aktiviert haben. In der Tat ist Verschlüsselung der einzige Weg, um sicherzustellen, dass Benutzersitzungen nicht möglich sind in einem offenen drahtlosen Netzwerk leicht zu schnüffeln.

Das klingt einfach - fügen Sie einfach ein s nach http in die URL ein! Es ist eigentlich nicht so einfach. Hier sind einige der Herausforderungen. "

Zusammenfassung der Herausforderungen (Nachteile):

• "Server-Overhead"
• "erhöhte Latenz"
• "Herausforderung für CDNs "
• " Wildcard-Zertifikate reichen nicht aus "
• " gemischtes HTTP / HTTPS: das Huhn & das Eiproblem "
• " Warnungen sind beängstigend! "

Ars Technica hat einen ausgezeichneten Artikel, in dem einige der Herausforderungen bei der Bereitstellung von SSL-Sitewide erläutert werden.

Ein großer Punkt: Die meisten Werbenetzwerke bieten keine Möglichkeit, Anzeigen über SSL zu schalten . Wenn Sie Anzeigen (über HTTP geliefert) in eine Hauptseite einbetten, die über HTTPS geliefert wird, geben Browser außerdem beängstigende Warnungen mit gemischten Inhalten aus, denen Sie Ihre Benutzer nicht aussetzen möchten. Daher wird es für werbefinanzierte Websites wahrscheinlich sehr schwierig sein, auf SSL-Sitewide umzusteigen.

In diesem Artikel werden auch einige andere Herausforderungen beschrieben, z. B. Widgets von Drittanbietern, Analysen, eingebettete Videos usw. P. >

OK, dies ist eine uralte Frage, daher wird meine Antwort wahrscheinlich hier unten nachlassen. Ich muss jedoch noch etwas hinzufügen.

HTTPS-Latenz:

Eine geringe HTTP-Latenz von Client zu Server ist von entscheidender Bedeutung zum Erstellen von schnell ladenden, reaktionsschnellen Websites. Und schnelle Ladezeiten von Seiten erhöhen die Zufriedenheit der Endbenutzer.

TCP / IP allein verfügt über den berühmten TCP-3-Wege-Handshake, dh der anfängliche Verbindungsaufbau für einfaches HTTP über TCP erfordert 3 Pakete . Wenn SSL / TLS verwendet wird, ist der Verbindungsaufbau aufwendiger, was bedeutet, dass die Latenz für neue HTTPS-Verbindungen unvermeidlich höher ist als für Klartext-HTTP.

Beachten Sie, dass dies Auswirkungen haben kann Reduziert (aber nicht beseitigt) durch mehrmaliges Wiederverwenden der HTTPS-Verbindung, dh durch Verwenden dauerhafter Verbindungen und anderer Leistungsoptimierungen wie SSL-Fehlstart.

Modellieren genau, wie viel HTTPS Das Verlangsamen des Seitenladens ist kompliziert, da alle modernen Browser HTTP-Objekte parallel herunterladen, wann immer dies möglich ist. Trotzdem ist die höhere anfängliche Verbindungsaufbauzeit mit der aktuellen Technologie sowohl signifikant als auch unvermeidbar. Daher ist die erhöhte Latenzzeit für neue Verbindungen ein wichtiger Gesichtspunkt.

Ein Nachteil, der in den anderen Antworten oben übersehen wird, ist die massive Abhängigkeit von Content-Distributionsnetzwerken (z. B. Akamai). Viele Webseiten, die derzeit verwendet werden, greifen auf Inhalte aus einer Vielzahl von Domänen zu, sodass der Browser Zertifikate benötigen würde Jede dieser oder Warnungen würde auftauchen. Und wenn der Angreifer eine CDN-Plattform verwendet, für die der Browser bereits Zertifikate hatte, erhält er möglicherweise keine Warnung, wann er sollte.

Schwieriges Problem mit der Art und Weise, wie Anwendungen und Inhalte derzeit bereitgestellt werden.

Vorteile sind definitiv erhöhte Sicherheit. Nachteile können relativ langsamere Verbindungen, eine intensivere CPU-Auslastung, eine genaue Zertifikatsverwaltung und einige Kosten für Zertifikate sein (wenn Sie keine selbstsignierten Zertifikate verwenden). In jüngster Zeit gibt es jedoch eine verbreitete Praxis für die Verwendung von https, und diese Nachteile treten aufgrund des Nutzens für Endbenutzer und des gestiegenen Vertrauens in ein Unternehmen, das Dienste anbietet, in den Hintergrund.

Andere Antworten haben ein "Henne / Ei-Problem" aufgrund von Warnungen mit gemischtem Inhalt bestätigt, die die HTTP-> HTTPS-Migration schwierig machen. Es ist ein Problem, aber ich denke nicht, dass es so schwierig ist, wie sie es sich vorstellen.

Gemischte Inhalte können mit protokollbezogenen URLs und denselben behandelt werden Scanner, mit denen Sie XSS-Probleme finden sollten.

RFC 3986 Abschnitt 4.2 verwendet den Begriff Netzwerkpfadreferenz:

Eine relative Referenz Dies beginnt mit zwei Schrägstrichen und wird als Netzwerkpfadreferenz bezeichnet.

Scannen Sie zuerst Ihre Seiten, bis Sie alle Verwendungszwecke von http://example.com/ in finden Links, Bilder und andere Site-Assets gleichen Ursprungs und ersetzen Sie sie durch protokollbezogene URLs ( //example.com / ... ). Auf diese Weise können Sie denselben HTML-Code bereitstellen, unabhängig davon, ob Sie eine Seite über HTTP oder HTTPS bereitstellen, und Sie können das Rollback viel besser durchführen, wenn später bei der Migration ein Fehler auftritt.

Richten Sie dann permanent ein HTTP-> HTTPS leitet um, sodass vorhandene URLs auf Websites außerhalb Ihrer Kontrolle weiterhin funktionieren und über HTTPS bereitgestellt werden. Die Verwendung einer permanenten Weiterleitung mit aggressiven Cache-Headern hilft Suchmaschinen dabei, den Seitenrang zu übertragen und die Website für wiederkehrende Besucher zu beschleunigen.

Sie sollten Ihre Scanner natürlich auf der Suche nach gemischten Inhalten halten, damit Sie Regressionen abfangen.

Ich weiß, dass dies eine alte Frage / ein alter Thread ist, aber ich wollte nur auf einen großen PRO für das seitliche SSL hinweisen.

SPDY

Die Verwendung von mod_spdy unter Apache erfordert SSL.

Wenn Sie SPDY noch nicht bereitgestellt haben, erledigen Sie es! Sowohl Chrome als auch Firefox unterstützen das Protokoll sowie Opera.

Das ist ungefähr die Hälfte Ihrer Benutzer, die SPDY nutzen können.

Andere Nachteile (die von anderen berührt werden) sind fehlende Zwischenspeicherung, die sich offensichtlich auf die Geschwindigkeit auswirkt. Außerdem sind einige Servervariablen nicht verfügbar - wie z. B. HTTP_FORWARDED_FOR.

Alles Gute hier erwähnt, aber ich vermisse die Kosten! Und mit Kosten meine ich nicht nur den Kauf des Zertifikats, sondern die richtige Infrastruktur zum Verwalten von Zertifikaten, Widerrufen, dedizierten Kryptomodulen, um die CPU-Auslastung des Webservers zu verringern usw.

Vorteile der Verschlüsselung der gesamten Website:

• Sie werden Ihre datenschutzbedürftigen Besucher nicht verärgern, indem Sie ihnen nach der Anmeldung Klartext senden.
• geringeres Fehlerrisiko Wenn Sie zwischen http- und https-Teilen der Website umleiten / verknüpfen.

Der Nachteil :?

Lesen Sie die Testimonials von Google und anderen. Es muss nicht teuer sein, 100% https zu erreichen.

Wenn eine Website von einem CMS verwaltet wird, mit dem ein nicht technischer Benutzer Seiten bearbeiten kann, kann er den HTML-Code so bearbeiten, dass er Verweise auf externe Ressourcen wie Bilder über HTTP enthält. Ich habe eine Einkaufsseite erstellt, die nur bei Bedarf SSL verwendet und andere Seiten zurück zu HTTP umleitet, da sonst aufgrund aller Bilder außerhalb des Standorts, die der Eigentümer auf der Website festgehalten hat, Warnungen zu gemischten Inhalten angezeigt werden. P. >