Eine SIP-Anmeldung zu "sniffen" ist wenig hilfreich (die kann man auch im Klartext mitlesen), da dort die Anmeldedaten nur in Form eines "salted hash"s übertragen werden (die "nonce" dient als "salt").
Wenn so etwas irgendwie funktionieren könnte, dann nur bei der Fernkonfiguration über TR-069. Selbst wenn die "Control-Verbindung" zum ACS in der Regel mit TLS gesichert ist (und damit da auch kein Lauschen möglich ist), ist oftmals das Belauschen der Übertragung einer konkreten Konfigurationsdatei trotzdem noch machbar (zumindest denkbar).
Im Rahmen des CWMP werden die Dateien ja nicht direkt zum CPE übertragen, der ACS sendet eine Aufforderung zum Download einer solchen Datei an das CPE und übermittelt dabei die URL der zu ladenden Datei (und deren Typ).
Wenn also der ACS die Übertragung der Daten nicht mit einer verschlüsselten URL ausführen läßt (eine FRITZ!Box kann das z.B. nur mit HTTPS, denn das ansonsten eingesetzte wget kennt keine Verschlüsselung und daher wird dort ein AVM-Eigengewächs namens "httpsdl" verwendet), dann sieht man diese Übertragung sehr wohl wieder in so einem Mitschnitt und das ist offenbar einigen Providern noch nicht in vollem Umfang klar bzw. einige haben wohl auch Probleme bei der Konfiguration eines HTTPS-Servers mit SNI (oder benutzen dafür gleich eine URL mit IP-Adresse und ohne Verschlüsselung) und verzichten daher beim Download von Konfigurationsdaten (genauso wie beim Download von Firmware-Images) auf eine Verschlüsselung ... zumindest war das in der Vergangenheit bei einigen so, O2 kenne ich jetzt (in den verschiedenen Spielarten der - auch historischen - Anschlußvarianten) nicht genug, um da zum aktuellen Zustand etwas zu wissen.
Wenn das aber jemand mit einer FRITZ!Box an einem O2-Anschluß vorher mal testet, kann man zumindest anhand der TR-069-Protokolldatei auch ermitteln, ob da TLS auch beim Konfigurationsdownload verwendet wird. Wenn das der Fall ist, dann reicht das simple Mitschneiden des Netzwerkverkehrs nicht aus, dann bräuchte man einen HTTPS-Proxy (z.B. mitmproxy) mit einem gültigen Zertifikat für die Adresse des ACS und/oder des Download-Servers. Da wird es dann schon wieder kritischer ... ob man auf einem O2-IAD überhaupt an das Verzeichnis mit den CA-Root-Zertifikaten kommt, weiß ich auch nicht ... bei einer FRITZ!Box (mit "normaler" Firmware) kann man da etwas machen.
Die Frage, ob die O2-IADs da überhaupt auf ein gültiges Zertifikat testen, wäre ggf. auch noch zu klären ... das wäre ja auch nicht das erste Mal, daß eine TLS-Verschlüsselung nur für die Sicherung der Übertragung und nicht zur Absicherung der Identität eines Servers genutzt würde. Wenn die O2-IADs da schlampig sind, dann ist natürlich ein MITM-Angriff auch wieder mit einem "self-signed certificate" möglich.
Fazit:
Erst einmal abklären, mit welchem Protokoll da überhaupt die Daten übertragen werden (da muß man den Mitschnitt ja noch nicht "verstehen") ... ist das TLS mit ordentlicher Zertifikat-Prüfung und ohne die Möglichkeit, dem IAD eine eigene CA unterzujubeln, ist das Projekt eine Totgeburt (zumindest für den anvisierten Zweck).
Auch macht das an einer DSL-Leitung natürlich nur dann Sinn, wenn man ein Modem zwischen der TAL und dem ersten Ethernet-Gerät (ob da nun ein Hub, Switch, Router, usw. ist) hat ... selbst wenn da kein ATM auf der Leitung mehr "gesprochen" wird, sind die Daten schon noch auf mehrere Träger aufmoduliert und die Aufgabe der Demodulation und des Zusammensetzens von Paketen muß schon noch jemand übernehmen.
Woher kommt eigentlich die Aussage, daß man eine FRITZ!Box nicht als reines Modem verwenden kann? Es gibt hier ja auch Erfahrungsberichte, daß das machbar sei (bei einigen Modellen ja sogar in der Firmware noch machbar per GUI) ... jedenfalls ist das wesentlich wahrscheinlicher (s.o. zum "Modem"), als daß sich ein RasPi da einspannen läßt. Ob die FRITZ!Box als Modem dann auch noch den Mitschnitt liefern kann, wüsste ich aus dem Stand jetzt auch nicht ... wenn ich raten sollte, würde ich eher auf "nein" tippen, da dann der PA wohl gar nicht aktiv ist.
