[VFKD] Ständige Probleme mit falsch ausgelieferten Websites und SSL-Zertifikaten bei CDNs

[Froschflutscher]

Hallo zusammen,

ich habe inzwischen seit Monaten ein recht kurioses Problem, das häufig vorkommt und doch nicht zuverlässig reproduzierbar ist.

Es passiert täglich, dass ich versuche Websites aufzurufen und zunächst den Fehler NET::ERR_CERT_COMMON_NAME_INVALID erhalte, der darauf hinweist, dass das ausgelieferte SSL-Zertifikat nicht zu der angefragten Domain gehört.

Die zurück gelieferten Zertifikate weisen, wenn ich sie gegenprüfe stets folgende Eigenschaften auf:

• Es sind valide Zertifikate von vertrauenswürdigen Certificate Authorities (CAs)
• Die Domains zu denen die Zertifikate gehören sind legitime Domains
• Die aufgerufene Domain und Domain im Zertifikat teilen sich meist das selbe Content Delivery Network (CDN) wie beispielsweise Akamai oder AWS, häufig (aber nicht immer) erkennbar am Herausgeber des Zertifikats

Ich habe testweise und im vollen Bewusstsein der damit verbundenen Risiken auch schon mal versucht, was passiert, wenn ich den SSL-Fehler ignoriere und die Seite trotzdem aufrufe. Das Ergebnis ist, dass mir die zum Zertifikat zugehörige falsche Website ausgeliefert wird.

Das Problem tritt bei allen angeschlossenen Geräten (Windows PC, Linux PC, Android Smartphone, Android TV-Stick) auf.
Das Problem tritt unabhängig von der verwendeten Netzwerkhardware auf.
Das Problem tritt unabhängig von den verwendeten DNS-Servern auf.
Das Problem behebt sich im Normalfall innerhalb von 2-3 Minuten ohne mein weiteres Zutun, wenn ich die Seite neu lade.
Das Problem taucht täglich und ohne für mich erkennbares Muster auf. Eine Website kann für eine Woche am Stück problemlos funktionieren und die nächste Woche jeden Tag dieses Problem verursachen.
Die Nutzung eines VPNs entweder auf Gerätebasis als Software oder für die Endgeräte transparent durch einen VPN-Router behebt das Problem komplett. Gleiches gilt, wenn ich mein Netzwerk mit einem LTE-Router statt mit dem Kabelmodem verbinde.

Heute sind beispielsweise schon folgende Paarungen aufgetreten:

Aufgerufene Domain	Zurückgegebene Website	CDN
www.cdc.gov	www.aarpmedicareplans.com	Akami
www.medizinfuchs.de	checkout.flo.com.tr	AWS

Ich habe meinem Verständnis nach durch meine Tests prinzipiell alle Fehlerquellen außer dem Routing/Cache-Verhalten seitens Vodafone ausgeschlossen. Habt ihr noch Tipps zu dem Thema?

[Flole]

Du hast durch deine Tests gerade Fehler im Bereich von Vodafone ausgeschlossen. Vodafone hat keine gültigen SSL Zertifikate für die entsprechenden Gegenstellen, kann somit also überhaupt gar nicht das SNI ignorieren/beeinflussen/whatever. Der Punkt von SSL ist doch gerade, dass die Verbindung verschlüsselt und gegen Manipulationen geschützt ist. Das Routing ist dafür völlig irrelevant und caching kann es überhaupt nicht geben.

[Froschflutscher]

Danke für dein Feedback.

Du hast durch deine Tests gerade Fehler im Bereich von Vodafone ausgeschlossen. Vodafone hat keine gültigen SSL Zertifikate für die entsprechenden Gegenstellen, kann somit also überhaupt gar nicht das SNI ignorieren/beeinflussen/whatever. Der Punkt von SSL ist doch gerade, dass die Verbindung verschlüsselt und gegen Manipulationen geschützt ist. Das Routing ist dafür völlig irrelevant und caching kann es überhaupt nicht geben.

Danke für dein Feedback. Es hilft mir allerdings nur bedingt weiter, da es im direkten Konflikt mit meiner erlebten Realität steht.

Ich habe erfolglos unterschiedliche DNS-Server ausprobiert - falls mein DNS-Server falsche oder veraltete Records liefert

Ich habe erfolglos unterschiedliche Geräte, mit unterschiedlichen Betriebssystemen und unterschiedlichen Browsern ausprobiert - falls es sich um Malware auf meinem Rechner handelt.

Ich habe erfolglos die Vodafone Station ausprobiert - ohne guten Grund, einfach um den Fehler einzugrenzen

Die einzigen Maßnahmen, die zum Erfolg geführt haben, waren die Nutzung eines VPN-Tunnels und die Nutzung eines LTE-Routers als Zugang zum Internet. Diese Maßnahme haben beide gemeinsam, dass Vodafone-Kabel nichts mit dem tatsächlichen Traffic zu tun hat.

Ich habe mich aufgrund deines Beitrags nun nochmal im Detail zum SNI-Verfahren belesen und ich sehe zumindest theoretisch durchaus Potential, dieses Problem durch den Versuch eines "optimierten" Routings zu verursachen und zwar nach dem selben Prinzip, nach dem ein falscher DNS-Record das Problem verursachen könnte.

Vodafone könnte versuchen anhand des unverschlüsselt übermittelten server_name-Parameters ein Routing zu einer gecachten IP vorzunehmen. Wenn seitens des CDN die Domain nicht mehr unter dieser IP-Adresse bedient werden würde, dann würde der Server versuchen einfach die erstbeste Website inklusive des Zertifikats zurück zu geben. Genauso wie wenn man die IP des Servers direkt ohne Domain aufruft: https://3.65.71.216/.

Deine Aussage, dass es nicht am Routing liegen kann ist meines Erachtens also falsch.

[Flole]

Vodafone könnte versuchen anhand des unverschlüsselt übermittelten server_name-Parameters ein Routing zu einer gecachten IP vorzunehmen.

Nein, das funktioniert nicht. Das steht in direktem Widerspruch zu dem IP-Header, welcher ja schon eine IP Adresse beinhaltet, was man natürlich umschreiben könnte, aber Routing ist keineswegs symmetrisch, die Antwort würde also beim Client möglicherweise von der falschen IP ankommen und verworfen werden, wenn man dort keine verrückten NAT Spielchen macht klappt das nicht, aber all das macht die Performance nicht besser, eher im Gegenteil.

Bei cdc.gov landet man dann auch bei https://104.70.249.171/, und da ist das Default-Certificate sogar für cdc.gov gültig, das wäre also da gar kein Problem.

Kurzum: Routing hält sich strikt an die IP Header (alles andere wäre auch ein riesiges Chaos was auch nicht mehr vernünftig skaliert), Caching kann es dank SSL/TLS nicht geben.

[robert_s]

Ist das Problem inzwischen gelöst? Statt sinnlosen theoretischen Diskussionen würde ich mich lieber handfesten Fehleranalysen widmen. Denn es ist noch lange nicht heraus, bei wem der Fehler nun sitzt - es könnte prinzipiell auch ein "lokaler" CDN-Node sein.

Ich würde erst mal IPv6 deaktivieren. Tritt das Problem dann noch auf?

Wenn ja, dann mal schauen, worauf www.cdc.gov und www.aarpmedicareplans.com bei Dir aufgelöst werden.

Bei mir sind es beispielsweise aktuell:

www.cdc.gov:
Name: www.akam.cdc.gov
Address: 104.108.150.144

www.aarpmedicareplans.com
Name: e5739.a.akamaiedge.net
Address: 104.79.33.201

Das sind also schon mal unterschiedliche IP-Adressen. Die könntest Du auch mal testweise bei Dir in die hosts-Datei reinschreiben und so sehen, ob es mit diesen IP-Adressen bei Dir läuft.

Umgekehrt kannst Du auch mal schreiben, zu welchen IP-Adressen diese beiden DNS-Namen bei Dir aufgelöst werden, am besten mit mehreren DNS-Providern. Wenn da bei allen DNS-Providern IP-Adressen herauskommen, die z.B. auch über Deine VPN-Verbindung (wieder über die Hosts-Datei erzwingen) gar nicht die gewünschte Webseite hosten, dann läge der Fehler eindeutig beim CDN.