frag mich gerade was mit SSL Sicherheit beim NAT ist

Was soll damit sein?
tcp kommt in der Regel über NAT und CGNAT rüber. SSL bzw. TLS liegt oben drauf.
Gleiches gilt auch für NAT64.

Aber können die da nicht ungestört ssl bei. Zugriff auf IPv4 Adressen aufbrechen?
Sie haben den DNS unter Kontrolle, liefern dem Client doch eine destination NAT IPv6adresse statt der originären IPv4 Adresse und Faken dann die Reverse Lookup Überprüfung der ipadresse auf Ihrem DNS .
Oder seh ich das falsch.

Du verwechselst SSL/TLS (z.B. https) mit dnssec. TLS ist es egal, was dazwischen passiert. Die Zertifikate werden vom Client überprüft und das war's.
Bei dnssec kann es in seltenen Fällen zu Problemen mit DNS64 kommen. Dort sollte der DNS64-server dnssec erkennen und keinen fake-AAAA-Record hinzufügen. Dann ist der Client entweder zu 464xlat gezwungen oder er kann keine Verbindung aufbauen.
Wenn dnssec und IPv6 gleichzeitig vorhanden sind, läuft hingegen alles ohne Probleme.

also beim SSL Verbidungsaufbau prüft der Client dass die IP Adresse die Ihm das Zertifikat präsentiert auch im DNS der Eigner der IP Adresse ist dachte ich.

das hat nix mit DNSSEC zu tun, das ist ganz normaler Standardaufbau

für mich hat das irgendwas von Man in the Middle auf Seiten der Telekom.

Bevor Du jemanden man in the middle vorwirfst, nimm bitte zu Kenntnis, das CGNAT und DS-lite bereits millionenfach angewendet werd. Bei SSL/TLS wird nur das Serverzertifikat überprüft, genauer der Name des Servers. Die IP des Servers ist egal, die des Client ist egal. Und ob die des Clients zwischendurch übersetzt wurde, ist auch egal, anderenfalls würde heute schon nichts funktionieren, schließlich macht auch jeder Homerouter "NAT".
Wie es bei DNSSEC aussieht, habe ich dir schon kurz erläutert.

Es gibt einen Unterschied zwischen Misstrauen und Paranoia.

Es geht mir nicht um die IP des Clients sondern die des Servers, und bei IPV6 Only Anschlüssen zu IPV4 ist ein Fake DNS Eintrag im IPV6, kurz davor..

Server/IP liefert Zertifikat
Zertifkat enthält DNS Namen des Servers
Client prüft ob der Reverse Lookup der IPV6 Adresse dessen der das Zertifkat liefert übereinstimmt mit dem DNS Namen im Zertifikat.

Fehlt quasi nur noch das Fake Zertiifkat einer Trusted CA

Benutzer Pitt_g schrieb:

Clients machen keinen Reverse Lookup der Serveradresse. Nur Mailserver machen Reverse lookups der clients/anderer Mailserver

Und wie schon gesagt am Namen des Servers wird nichts geändert.

Name und Zertifikat stimmen nach wie vor über ein. Auch bringt ein sauber konfigurierter (nicht gehackter) DNS64/NAT64-Server die Pakete zum richtigen Server - mit der im A-Record hinterlegten IPv4-Adresse.

Und was die mögliche Manipulation von DNS betrifft - dagegen hilft DNSSEC - oder auch nicht.

DNSSEC+(IPV4)+IPv6 --> DNS64 macht keinerlei Änderungen-- > alles gut

DNSSEC+IPV4 ohne IPv6 --> DNS64 sprengt ggf. die Signatur, aber das ist auffällig --> Ausweg: nicht trauen oder über 464xlat die vertrauenswürdige Signatur für "A" wählen

Auf SSL-Zertifikaten befindet sich keine IP-Adresse, daher sorgt die IPv6-Umstellung auch für keine Probleme mit SSL. Die Server von teltarif.de verwenden beispielsweise dasselbe Zertifikat sowohl für IPv4 als auch für IPv6. Hintergrund: Mit dem Zertifikat wird die Identität des Servers (bzw. genau genommen ein so gennanter "privater Schlüssel", den der Server-Betreiber - hoffentlich - zuverlässig geheim hält) bestätigt und nicht eine konkrete IP-Adresse. Denn ein böswilliger Provider kann ja immer Zugriffe auf eine bestimmte IP (zum Beispiel die einer Bank) auf eine andere IP (zum Beispiel die eines Phishing-Servers) umleiten. Würde im Zertifikat die IP-Adresse und nicht die Identität des Servers zertifiziert, dann könnte jeder Provider ganz einfach Phishing betreiben.

Die Schwächen von SSL liegen woanders, beispielsweise darin, dass die Identität desjenigen, der ein Zertifikat beantragt, zumindest bei Standardzertifikaten nur recht grob geprüft wird.