Frage:
Warum kann Windows 98 / IE5 2015 keine Verbindung zu HTTPS-Sites herstellen?
smitelli
2015-08-04 19:30:31 UTC
view on stackexchange narkive permalink

Vor kurzem habe ich eine alte Installations-CD für Windows 98 Second Edition gefunden und auf der Suche nach einem kleinen Nostalgie-Kick in VirtualBox installiert. Win98SE wurde mit IE 5.0 ausgeliefert, und das Surfen im Internet mit diesem Browser war eine ebenso kaputte Erfahrung, wie Sie sich vorstellen können. jede HTTPS-Site. Und ich habe mich gefragt, warum das so ist. Sind alle vertrauenswürdigen CA-Zertifikate, mit denen es geliefert wurde, abgelaufen? Wurden alle Standard-TLS / SSL-Algorithmen in den letzten 16 Jahren eingestellt? Benötigte es das IE High Encryption Pack (wow, es ist für immer her, seit ich darüber nachgedacht habe).

Ich bin gespannt, ob dies Auswirkungen auf andere Betriebssysteme dieser Zeit (Mandrake 6!) Oder wenn das Kernproblem irgendwie Windows-spezifisch ist.

Es ist höchstwahrscheinlich der gleiche Grund, warum GitHub unter Windows XP, veralteten SSL-Chiffren, nicht mehr unter IE funktioniert: https://github.com/blog/1937-improving-github-s-ssl-setup
Wenn Sie diesen Browser aus einem bestimmten Grund unbedingt verwenden möchten, können Sie einen lokalen Proxy ausführen. (Vorsichtsmaßnahmen gelten)
Viele der frühen CA-Wurzeln hatten Gültigkeitszeiträume von 30 Jahren oder mehr und sind nicht * abgelaufen *. Sie sind ** veraltet **, da praktisch alle heute gültigen (und in den letzten Jahren ausgestellten) Zertifikate unter neueren Wurzeln stehen. Einige können jedoch immer noch zu alten Wurzeln * verketten *; Als Verisign beispielsweise 2006 zu "Generation 5" wechselte und dies anfangs bei den meisten Clients nicht der Fall war, stellten sie einen Bridge-Root zurück zu ihrem ursprünglichen Root von 1996, und ich habe gesehen, dass Server im letzten Jahr oder so immer noch die veraltete Bridge bereitstellten . Sie können sehen, wie viel http://www.ssllabs.com/ssltest/viewMyClient.html schreit.
Sie können einen transparenten (oder nicht so transparenten) Proxy verwenden, der von Ihnen konfiguriert wurde, um die https-Sites nutzbar zu machen.Sie müssen auch Ihre eigene Zertifizierungsstelle werden.Es ist viel Arbeit, aber es könnte funktionieren (auch große Unternehmensnetzwerke belauschen auf diese Weise den https-Verkehr).
Fünf antworten:
Thomas Pornin
2015-08-04 20:47:28 UTC
view on stackexchange narkive permalink

Das Hauptproblem besteht wahrscheinlich darin, dass ein IE aus dieser Zeit SSL 2.0 unterstützen möchte und daher seine ursprüngliche Nachricht ( ClientHello ) im SSL 2.0-Format sendet, das ungefähr nichts gemeinsam hat mit dem ClientHello späterer Protokollversionen (SSL 3.0 und alle TLS-Versionen). Dadurch konnte der Browser eine Verbindung zu einem Server herstellen, der SSL 2.0 kannte, aber nichts anderes, während der ClientHello weiterhin dokumentiert, dass der Client bereit ist, etwas Moderneres zu verwenden.

Allerdings modern Server unterstützen das SSL-2.0 ClientHello -Format nicht mehr. Es gab eine Übergangszeit, in der sie dieses Format noch akzeptierten (obwohl sie nicht zuließen, dass die Verbindung tatsächlich SSL 2.0 verwendet), aber jetzt haben sie die Unterstützung insgesamt eingestellt. Insbesondere das SSL-2.0 ClientHello -Format bietet keinen Platz für Erweiterungen wie SNI, was den Drang erklärt, diese Unterstützung einzustellen.

Weitere Probleme sind:

  • IE 6.0 unterstützt TLS 1.0, ist jedoch standardmäßig deaktiviert. Ich weiß nicht, ob IE 5 TLS 1.0 unterstützt hätte, aber auf jeden Fall wäre es nicht standardmäßig aktiviert worden. Viele moderne Server lehnen jedoch auch SSL 3.0 ab (aufgrund von POODLE, wie von @etherealflux festgestellt).

  • Der Client-Code kennt AES nicht, da er von stammt vor der Standardisierung dieses Algorithmus. Es wird versucht, Cipher Suites zu verwenden, die auf RC2, 3DES und möglicherweise RC4 basieren (dies würde eine gewisse Überprüfung erfordern, da RC4 die Eigenschaft von IE-Nemesis Netscape war, sodass IE 5 es möglicherweise nicht verwenden würde). Diese Algorithmen sind heutzutage bei Serveradministratoren nicht sehr beliebt ...

  • Moderne Websites verwenden ziemlich große kryptografische Schlüssel. Typischerweise RSA mit Schlüsseln von mindestens 2048 Bit. Ein alter Windows + IE ist möglicherweise in der Größe der RSA-Schlüssel, die er verarbeiten kann, eingeschränkter. Insbesondere ein Windows + IE, der den US-Exportregeln für Kryptographie der Zeit vor 2000 entspricht, könnte auf eine maximale Größe von 1024 Bit für RSA-Schlüssel beschränkt werden. Dieselbe Kombination würde sich auch weigern, 3DES oder etwas mit einem symmetrischen Schlüssel größer als 56 Bit zu verwenden, während kein anständiger Server von 2015 weniger als 128 Bit akzeptieren würde.

Für Auf Linux-basierten Systemen gibt es keine zentrale SSL-Implementierung (häufig gibt es eine OpenSSL-Bibliothek, die jedoch nicht so allgegenwärtig ist wie Microsoft SChannel und CryptoAPI). Jeder Browser hat also seine eigenen Regeln. Vor 2000 hätte dies Nestcape Navigator bedeutet (derjenige, der fehlerhaft ist, wenn in UTF-8 etwas angezeigt wird ...). Vielleicht könnte ein früher KDE-basierter Browser etwas SSL? In diesem Fall würde wahrscheinlich OpenSSL und verwendet, damit weiterhin eine Verbindung zu einigen Servern mit der richtigen Konfiguration herstellen kann (insbesondere, wenn das SSL-2.0-Format für den ClientHello code vermieden wird >).

`Moderne Server unterstützen das SSL-2.0 ClientHello-Format nicht mehr` [Zitieren erforderlich] https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=74.125.239.142&hideResults=on - SSL 2-Handshake-Kompatibilität Ja
@Cthulhu Google ist wahrscheinlich das einzige große Unternehmen, das es noch akzeptiert, da es als Gateway zum Internet verwendet wird.
Interessanter Leckerbissen: Von den jüngsten großen Browsern verwenden nur IE, Safari und (vermutlich) Edge SChannel. Firefox verwendet NSS. Chrome verwendete SChannel bei den ersten Veröffentlichungen, wechselte dann zu NSS und dann zu BoringSSL (Googles eigene Bibliothek basierend auf OpenSSL / LibreSSL).
Minor: RC4 wurde von der damaligen RSA Data Security (jetzt eine Abteilung von EMC) als Geschäftsgeheimnis beansprucht, die versuchte, alle AFAIK einschließlich Microsoft zu belasten. Es gab keine US-Exportbeschränkung für die Stärke der * Authentifizierung *, nur * der Vertraulichkeit *, und die "EXPORT" -Suiten handhabten dies unter Verwendung eines zweiten RSA-Schlüssels von ** bis zu 512 **, nicht 1024, und symmetrischen Chiffren, die auf ** 40 beschränkt waren ** nicht 56; Wie Sie sagen, lehnt jeder anständige Server heute sowohl den Export 40 als auch den Single-DES 56 ab. Auch SSL2-Hello wird besser als "Übergang" als "Übergang" bezeichnet. es dauerte mehr als 10 Jahre (obwohl es nicht hätte sein sollen).
Ich gehe davon aus, dass es auch ein Problem mit dem Auslaufen von SHA-1 gibt. Laut Wikipedia wurde [SHA-2] (https://en.wikipedia.org/wiki/SHA-2) erst 2001 veröffentlicht, daher konnte es nicht von etwas so Altem unterstützt werden.
@NateKerkhofs Die meisten Websites, einschließlich CloudFlare RSA, akzeptieren dies weiterhin, da OpenSSL und andere TLS-Implementierungen dies in den neueren Versionen weiterhin unterstützen. Ja, das ist schlecht und sie sollten sich schlecht fühlen. Ich finde das Deaktivieren der SSL 2-Handshake-Kompatibilität nicht trivial. Das einzige große Unternehmen, das ich bisher gesehen habe, ist "Network Solutions": https://www.ssllabs.com/ssltest/analyze.html?d=networksolutions.com - SSL 2-Handshake-Kompatibilität Nr
bayo
2015-08-04 19:36:30 UTC
view on stackexchange narkive permalink

Es kann weitere Gründe geben, ich werde nur einige auflisten, die mir in den Sinn gekommen sind:

  1. Beim Herstellen der SSL / TLS-Verbindung (Handshake) sendet der Client eine Liste mit Verschlüsselungen Suiten zum Server. Der Server ist dann dafür verantwortlich, denjenigen auszuwählen, der verwendet werden soll. Falls keine geeignete Verschlüsselung vorhanden ist, wird die Verbindung beendet.
  2. SNI - Server Name Indication-Erweiterung. AFAIK Dies wird für IE6 und frühere Versionen unter XP nicht unterstützt.
  3. ol>

    Um ehrlich zu sein, bin ich mir nicht einmal sicher, ob IE5 TLS unterstützt.

Jede IE-Version unter XP unterstützt SNI nicht, es kommt auf die Windows-Version an, nicht auf den IE. Außerdem unterstützt SSL SNI nicht, nur TLS.
etherealflux
2015-08-04 19:38:13 UTC
view on stackexchange narkive permalink

Sie haben höchstwahrscheinlich Recht. Die meisten Websites verbieten jetzt die Verwendung veralteter SSL-Protokolle - erinnern Sie sich, dass SSL v3.0 unter anderem Teil des POODLE -Angriffs war! Wenn Ihr Browser nur die deaktivierten Protokolle unterstützt, werden Sie nicht weit kommen.

Wikipedia hat auf seiner Seite ein großartiges Diagramm über SSL / TLS, das zeigt, was Protokolle sind Wird standardmäßig in verschiedenen Browserversionen unterstützt. Am wichtigsten ist, dass Internet Exploder 6 nur bis zu TLS 1.0 unterstützt und standardmäßig deaktiviert ist. Dies bedeutet, dass Ihr Browser wahrscheinlich versucht, SSL v3.0 zu verwenden.

Sie sollten in der Lage sein, den Status Ihrer vertrauenswürdigen Zertifikate zu überprüfen - nach so vielen Jahren hoffe ich, dass sie es sind bin abgelaufen. Das Betriebssystem ist so alt, dass die Google-Suche jedoch nicht viele Ratschläge dazu liefert!

Bacon Brad
2015-08-04 21:14:18 UTC
view on stackexchange narkive permalink

Die wahrscheinliche Ursache könnte sein, dass nicht viele Server die Verschlüsselungsbedingungen unterstützen, die IE5 verwenden kann. Zum Zeitpunkt der Veröffentlichung Ihres IE gab es nur SSL-Unterstützung und keine TLS-Unterstützung.

SSL 1.0 wurde nie öffentlich veröffentlicht. SSL 2.0 und 3.0 sind inzwischen veraltet. Obwohl Server in freier Wildbahn sie unterstützen könnten, werden sie wahrscheinlich nicht auf Servern für die meisten gängigen Websites gefunden.

Der TLS 1.0-Standard wurde erst 1999 definiert. Und Microsoft ist seit langem dafür berüchtigt, dass er nicht mitgenommen hat Standards rechtzeitig. In Ihrem Betriebssystem ist wahrscheinlich IE 5.0 oder 5.01 (Bugfix Edition) enthalten, für das keine Verschlüsselung vorhanden ist. Die Version mit Verschlüsselung war 5.5. Es ist nicht mit Ihrer Version des Betriebssystems verpackt, aber kompatibel. Sie werden jedoch noch nicht frei und klar sein. Es werden nur 128-Bit-TLS 1.0 unterstützt, das der IE standardmäßig deaktiviert.

Zusätzlich werden EV-Zertifikat, SHA-2-Zertifikat und ECDSA-Zertifikate ebenfalls nicht unterstützt. Es wird äußerst selten sein, einen Server in freier Wildbahn zu finden, der über ein 128-Bit-Zertifikat mit TLS 1.0- und IE5-Cypher-Anzug verfügt.

Selten wäre das. Ich frage mich, ob 3DES sicher ist. Wahrscheinlich.
EV ist kein Problem, ein alter Browser ignoriert die Erweiterung einfach. SHA2 ist es mit ziemlicher Sicherheit; XP hat RSA / SHA2 bis SP3 nicht unterstützt, also würde ich wetten, dass 98 und sogar NT das überhaupt nicht können. ECDSA könnte ein Problem sein, aber ich bezweifle, dass Sie öffentliche Websites finden, die ECDSA * erfordern *; nicht so viele * erlauben * es sogar.
@dave_thompson_085-Sites, die CloudFlare-Dienste verwenden und auf HTTPS mit Comodo SHA2-Zertifikaten (nicht GlobalSign SHA1) ausgeführt werden, benötigen ECDSA-Unterstützung, sodass Internet Explorer- und Chromium-basierte Browser unter Windows XP fehlschlagen. Sehen Sie nur, wie viele Leute sich beschweren: https://code.google.com/p/chromium/issues/list?can=1&q=CloudFlare+ECDSA Ich verwende CloudFlare nicht, habe aber derzeit 3 ​​Websites, für die ECDSA erforderlich ist, und weitere . Ihr Kommentar lässt mich denken, dass Sie im Jahr 2001 oder so leben :(.
Leslie
2015-08-16 14:42:30 UTC
view on stackexchange narkive permalink

Installieren Sie Opera, das mit Windows 98 kompatibel ist. Ich verwende 10.10.

Rufen Sie die Menüleiste auf.

Extras-> Einstellungen => Registerkarte Erweitert

Wählen Sie Sicherheit und dann die Schaltfläche Sicherheitsprotokolle ... Das Popup-Fenster

enthält das Kontrollkästchen SSL 3 aktivieren.

Erfolgreich! Die Google-Website mit HTTPS funktioniert wieder!



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...