Migrationsszenarien ISDN -> VoIP/SIP (was: 1. RfD: de.comm.geraete.isdn.* (Loeschung))

[Paul Muster]

On 03.04.22 11:03, Sebastian Suchanek wrote:

> Hmm - ob ich die bislang einwandfrei funktionierende Auerswald COMpact
> 4406(?) doch noch schnell gegen ein VoIP-Modell tauschen sollte, solange
> letztere noch mit internem S0-Bus kommen?

Könnte man tun, ja. Man kann auch auf unbestimmte Zeit eine derzeit
aktuelle Fritzbox (z.B. 7590) im internen Netz (d.h. hinter einem
vorgeschalteten Router/Gateway/...) betreiben, die sich beim Provider
per SIP registriert und nach innen ISDN-S0 bereitstellt.
Irgendwann bekommt die 7590 dann keine Updates mehr, aber sie steht ja
im internen Netz und hat lediglich per SIP Kontakt zum - hoffentlich
vertrauenswürdigen - Telefonprovider.


mfG Paul

[Rupert Haselbeck]

Paul Muster schrieb:

> Man kann auch auf unbestimmte Zeit eine derzeit
> aktuelle Fritzbox (z.B. 7590) im internen Netz (d.h. hinter einem
> vorgeschalteten Router/Gateway/...) betreiben, die sich beim Provider
> per SIP registriert und nach innen ISDN-S0 bereitstellt.

Nicht wirklich. Die "unbestimmte Zeit" des Weiterbetriebs ist begrenzt
durch den ersten irreparablen Defekt der Fritzbox. Freilich könnte man
eine Dehnung des Zeitraums erreichen durch Einlagern einer (oder gar
einiger?) Fritzboxen...

MfG
Rupert

[Marc Haber]

Paul Muster <exp-3...@news.muster.net> wrote:
>Irgendwann bekommt die 7590 dann keine Updates mehr, aber sie steht ja
>im internen Netz und hat lediglich per SIP Kontakt zum - hoffentlich
>vertrauenswürdigen - Telefonprovider.

RTP kann direkt mit einer (nicht notwendigerweise vertrauenswürdigen)
Gegenstelle geprochen werden, das halte ich für nicht ungefährlich.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Paul Muster]

Am 04.04.2022 um 07:55 schrieb Marc Haber:
> Paul Muster <exp-3...@news.muster.net> wrote:

>> Irgendwann bekommt die 7590 dann keine Updates mehr, aber sie steht ja
>> im internen Netz und hat lediglich per SIP Kontakt zum - hoffentlich
>> vertrauenswürdigen - Telefonprovider.
>
> RTP kann direkt mit einer (nicht notwendigerweise vertrauenswürdigen)
> Gegenstelle geprochen werden, das halte ich für nicht ungefährlich.

Das ist bei keinem großen deutschen Provider üblich, denn wäre es so,
könnte dieser die Anforderungen bzgl. Lawful Interception/G19
("Abhören") nicht erfüllen:
Eine der Anforderungen ist, dass der Betroffene die Maßnahme nicht
bemerken kann, somit leiten alle Provider immer RTP über ihre SBCs - und
erstellen dort ggf. die Kopie des Datenstroms für die Behörde. Würde der
Provider den RTP-Strom direkt von Kunde zu Kunde ermöglichen, könnte der
von einer Maßnahme Betroffene bemerken, wenn sich das plötzlich ändert
(d.h. der RTP-Strom über den Provider geführt wird), und daraus
ableiten, dass er eben gerade Betroffener einer Abhörmaßnahme ist.

(Obiges gilt und greift natürlich dann nicht, wenn Leute ohne Nutzung
von Providern direkt zwischen Fritzboxen telefonieren (also
1...@fritzbox1.dyndns.tld mit 2...@fritzbox2.dyn.tld, ggf. unterstützt
durch public ENUM e164.arpa). Aber das ist sehr sehr selten.)


mfG Paul

[Marc Haber]

Paul Muster <exp-3...@news.muster.net> wrote:
>Am 04.04.2022 um 07:55 schrieb Marc Haber:
>> Paul Muster <exp-3...@news.muster.net> wrote:
>
>>> Irgendwann bekommt die 7590 dann keine Updates mehr, aber sie steht ja
>>> im internen Netz und hat lediglich per SIP Kontakt zum - hoffentlich
>>> vertrauenswürdigen - Telefonprovider.
>>
>> RTP kann direkt mit einer (nicht notwendigerweise vertrauenswürdigen)
>> Gegenstelle geprochen werden, das halte ich für nicht ungefährlich.
>
>Das ist bei keinem großen deutschen Provider üblich, denn wäre es so,
>könnte dieser die Anforderungen bzgl. Lawful Interception/G19
>("Abhören") nicht erfüllen:
>Eine der Anforderungen ist, dass der Betroffene die Maßnahme nicht
>bemerken kann, somit leiten alle Provider immer RTP über ihre SBCs - und
>erstellen dort ggf. die Kopie des Datenstroms für die Behörde. Würde der
>Provider den RTP-Strom direkt von Kunde zu Kunde ermöglichen, könnte der
>von einer Maßnahme Betroffene bemerken, wenn sich das plötzlich ändert
>(d.h. der RTP-Strom über den Provider geführt wird), und daraus
>ableiten, dass er eben gerade Betroffener einer Abhörmaßnahme ist.

Aber größere VoIP-Plattformen haben durchaus mehrere (hunderte?) SBCs,
die müsste man alle einzeln berücksichtigen wenn man RTP nicht
generell freischalten möchte.

>(Obiges gilt und greift natürlich dann nicht, wenn Leute ohne Nutzung
>von Providern direkt zwischen Fritzboxen telefonieren (also
>1...@fritzbox1.dyndns.tld mit 2...@fritzbox2.dyn.tld, ggf. unterstützt
>durch public ENUM e164.arpa). Aber das ist sehr sehr selten.)

Das müsste man tatsächlich mal probieren ;-) Gibt es da Webseiten mit
Anleitung?

[Paul Muster]

Am 04.04.2022 um 15:57 schrieb Marc Haber:
> Paul Muster <exp-3...@news.muster.net> wrote:
>> Am 04.04.2022 um 07:55 schrieb Marc Haber:
>>> Paul Muster <exp-3...@news.muster.net> wrote:

>>>> Irgendwann bekommt die 7590 dann keine Updates mehr, aber sie steht ja
>>>> im internen Netz und hat lediglich per SIP Kontakt zum - hoffentlich
>>>> vertrauenswürdigen - Telefonprovider.
>>>
>>> RTP kann direkt mit einer (nicht notwendigerweise vertrauenswürdigen)
>>> Gegenstelle geprochen werden, das halte ich für nicht ungefährlich.
>>
>> Das ist bei keinem großen deutschen Provider üblich, denn wäre es so,
>> könnte dieser die Anforderungen bzgl. Lawful Interception/G19

G 10, sorry. https://de.wikipedia.org/wiki/Artikel_10-Gesetz

>> ("Abhören") nicht erfüllen:
>> Eine der Anforderungen ist, dass der Betroffene die Maßnahme nicht
>> bemerken kann, somit leiten alle Provider immer RTP über ihre SBCs - und
>> erstellen dort ggf. die Kopie des Datenstroms für die Behörde. Würde der
>> Provider den RTP-Strom direkt von Kunde zu Kunde ermöglichen, könnte der
>> von einer Maßnahme Betroffene bemerken, wenn sich das plötzlich ändert
>> (d.h. der RTP-Strom über den Provider geführt wird), und daraus
>> ableiten, dass er eben gerade Betroffener einer Abhörmaßnahme ist.
>
> Aber größere VoIP-Plattformen haben durchaus mehrere (hunderte?) SBCs,
> die müsste man alle einzeln berücksichtigen wenn man RTP nicht
> generell freischalten möchte.

"RTP nicht generell freischalten"? Wohin RTP gesendet bzw. von wo RTP
empfangen wird, wird per SDP mitgeteilt (c-line). Diese Info kommt von
den SBCs des Providers, die man - vgl. Nutzung von Google/Android- oder
Apple-Handys - definitiv als vertrauenswürdig ansehen muss, wenn man sie
nutzt.

Es gibt somit kein Szenario (oder ich sehe zumindest aktuell keines),
bei dem die fragliche, nicht mehr mit Updates versorgte Fritzbox mit
nicht vertrauenswürdigen Systemen per SIP und/oder RTP kommuniziert.

Gewisse Einbußen bei der Sicherheit könnten zum Tragen kommen, wenn
irgendwann seitens der Provider neue, sehr starke
Verschlüsselungsalgorithmen/Ciphers möglich werden, die die "alte"
Fritzbox nicht mehr kann, wodurch sie ältere, eher angreifbare Verfahren
nutzen muss.
Aber da stellt sich mMn sehr die Frage, wie realistisch ein Angriff auf
SIP/TLS und SRTP eines Endkundenanschlusses ist oder ob da nicht andere
Methoden (Wanze vor Ort) eingesetzt würden.

>> (Obiges gilt und greift natürlich dann nicht, wenn Leute ohne Nutzung
>> von Providern direkt zwischen Fritzboxen telefonieren (also
>> 1...@fritzbox1.dyndns.tld mit 2...@fritzbox2.dyn.tld, ggf. unterstützt
>> durch public ENUM e164.arpa). Aber das ist sehr sehr selten.)
>
> Das müsste man tatsächlich mal probieren ;-) Gibt es da Webseiten mit
> Anleitung?

<https://wiki.zebradem.com/wiki/index.php?title=Fritzbox:_Anonyme_SIP-Adresse>
Keine Ahnung, ob das heute noch so geht. Insbesondere die Manipulation
der voip.cfg über telnet - fraglich.


mfG Paul

[Ignatios Souvatzis]

Also, wenn du wirklich ISDN über das Ende der Erhätlichkeit
traditionell erhältlicher Chipsätze (etwa als Ersatzteil zur
Reparatur deines Gerätes) hinaus sprechen willst - moderne
Mikrocontroller sollten schnell genug sein, einen S0-Bus zu bitbangen.

Das Lowlevelformat war in den Nutzerdatenblaettern des Siemens-Chipsatzes
hinreichend beschreiben, um sich aus den Leitungen den D- und die beiden
B-Kanäle herauszufischen bzw. umgekehrt aus D+2xB einen S0 zu mischen.
Sind ja bloss 144 kbit/s netto (faktisch etwas mehr, da das Framing
dazukommt - mir spuken da 160 kbit/s im Kopf herum).

Dazu dann etwas HDLC (wenn ich mich recht entsinne) auf dem D-Kanal,
der Rest ist hoehere Ebene und sollte z.B. in Asterisk aufzufinden
sein.

-is

[Marc Haber]

Ignatios Souvatzis <u50...@bnhb484.de> wrote:
>Also, wenn du wirklich ISDN über das Ende der Erhätlichkeit
>traditionell erhältlicher Chipsätze (etwa als Ersatzteil zur
>Reparatur deines Gerätes) hinaus sprechen willst - moderne
>Mikrocontroller sollten schnell genug sein, einen S0-Bus zu bitbangen.

"Software defined Uk0". Sehr schön. Gefällt mir.

[Kay Martinen]

Am 04.04.22 um 16:49 schrieb Paul Muster:

> Am 04.04.2022 um 15:57 schrieb Marc Haber:
>> Paul Muster <exp-3...@news.muster.net> wrote:
>>> Am 04.04.2022 um 07:55 schrieb Marc Haber:
>>>> Paul Muster <exp-3...@news.muster.net> wrote:
>
>>>>> Irgendwann bekommt die 7590 dann keine Updates mehr, aber sie steht ja
>>>>> im internen Netz und hat lediglich per SIP Kontakt zum - hoffentlich
>>>>> vertrauenswürdigen - Telefonprovider.
>>>>
>>>> RTP kann direkt mit einer (nicht notwendigerweise vertrauenswürdigen)
>>>> Gegenstelle geprochen werden, das halte ich für nicht ungefährlich.
>>>
>>> Das ist bei keinem großen deutschen Provider üblich, denn wäre es so,
>>> könnte dieser die Anforderungen bzgl. Lawful Interception/G19
>
> G 10, sorry. https://de.wikipedia.org/wiki/Artikel_10-Gesetz

> Aber da stellt sich mMn sehr die Frage, wie realistisch ein Angriff auf
> SIP/TLS und SRTP eines Endkundenanschlusses ist oder ob da nicht andere
> Methoden (Wanze vor Ort) eingesetzt würden.

Optimist! Ich werde ja das Gefühl nicht los werden das die gesamte VoIP
Technik vor allem zu zwei Zwecken propagiert wird (und die Alte folglich
obsolet zu werden hat).

1. Zentralisierung durch Software.
2. Dadurch möglich werdende Einfache Massenüberwachung - durch Software.

Öffentlich wird da natürlich nur von den Vorzügen geredet die es bringen
soll und maximal eingestanden das man die Teure und Veraltende Hardware
in den Vermittlungen dadurch entfernen könnte. Was zugleich ja auch
wieder als Argument Pro Innovativer Techniken die dann möglich sind
kolportiert wird. Welche das wohl sein werden...

"Wanze vor Ort" ist der Klassische Ansatz aus Analog-Zeiten als
Leitungen noch knackten und Knirzten wenn da ein Lauscher mit dran hing. ;-)

Das will doch heute eh keiner mehr bezahlen und die Unfähigkeit solches
zu tun scheint mir auch an zu steigen.

Ich sehe da eher einen Globalen (nicht nur DE & EU) Trend hin zur
Konzentration von Kontrolle & Überwachung.

Und da die Geld-/Macht-gierigen und möchtegern-Diktatoren nicht
aussterben kann das leicht zu einem Big-Brother Staat führen wo Macht
durch Kontrolle und Geld durch Gier erzeugt wird.


Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Kay Martinen]

Am 11.04.22 um 18:35 schrieb Marc Haber:

> Ignatios Souvatzis <u50...@bnhb484.de> wrote:
>> Also, wenn du wirklich ISDN über das Ende der Erhätlichkeit
>> traditionell erhältlicher Chipsätze (etwa als Ersatzteil zur
>> Reparatur deines Gerätes) hinaus sprechen willst - moderne
>> Mikrocontroller sollten schnell genug sein, einen S0-Bus zu bitbangen.

Interessant. Noch interessanter wären konkrete durchgeführte Projekte
damit. Links? Wenn $Provider davon aber Rückwirkungen bemerkte
(Implementationsfehler?) könnte er sagen "Der Bus ist teil unseres
Netzes = Verbotene Manipulation" oder?

Die B-Kanäle übertragen ja nur je einen Datenstrom. Die ganze
Signalisierung dazu läuft über den D-Kanal. Wenn es da
Signalisierungs-Fehler gibt dürfte das $Techniker bei $Provider stutzig
machen.

> "Software defined Uk0". Sehr schön. Gefällt mir.

Fehlt nur noch eine 48 Volt Quelle um den "Bus" auch treiben zu können. :)

[Thomas Einzel]

Am 19.04.2022 um 19:05 schrieb Kay Martinen:
> Am 11.04.22 um 18:35 schrieb Marc Haber:

...

>> "Software defined Uk0". Sehr schön. Gefällt mir.
>
> Fehlt nur noch eine 48 Volt Quelle um den "Bus" auch treiben zu können. :)

PoE dafür nutzen?
--
Thomas

[Thomas Einzel]

Am 19.04.2022 um 18:57 schrieb Kay Martinen:
> Am 04.04.22 um 16:49 schrieb Paul Muster:

...

>> G 10, sorry. https://de.wikipedia.org/wiki/Artikel_10-Gesetz
>
>> Aber da stellt sich mMn sehr die Frage, wie realistisch ein Angriff auf
>> SIP/TLS und SRTP eines Endkundenanschlusses ist oder ob da nicht andere
>> Methoden (Wanze vor Ort) eingesetzt würden.

Die TLS Verbindung ist nicht bei jeweiligen Provider terminiert?

> Optimist! Ich werde ja das Gefühl nicht los werden das die gesamte VoIP
> Technik vor allem zu zwei Zwecken propagiert wird (und die Alte folglich
> obsolet zu werden hat).
>
> 1. Zentralisierung durch Software.
> 2. Dadurch möglich werdende Einfache Massenüberwachung - durch Software.

Seit spätestens 1998 (seit es Call by Call und Preselection gibt) ist
das prinzipiell Geschichte, es wird mit IP Telefonie über die Provider
nur einfacher.

Soweit ich gehört habe, sind allein die Wartungskosten der alten
digitalen Vermittlungsstellen *so* hoch, dass das mit dem kleiner
gewordenen Festnetz-Gesprächen nicht mehr bezahlbar wäre. Dazu kommt
dass rangieren an den Verteilern nur per Hand (mit Fahrtaufwand und
hohen Personalkosten) möglich war. Angeblich soll ja Big-T vor einigen
Jahren u.a. viele Fernmeldemonteure - ähm - Personal-umgebaut haben, man
VTS.
...

> Ich sehe da eher einen Globalen (nicht nur DE & EU) Trend hin zur
> Konzentration von Kontrolle & Überwachung.

In Israel z.B. soll wohl "nicht am Telefon!" schon immer üblich sein,
aber vielleicht habe ich das auch nur falsch verstanden.
--
Thomas

[Paul Muster]

On 19.04.22 18:57, Kay Martinen wrote:
> Am 04.04.22 um 16:49 schrieb Paul Muster:
>> Am 04.04.2022 um 15:57 schrieb Marc Haber:
>>> Paul Muster <exp-3...@news.muster.net> wrote:

>>>> Das ist bei keinem großen deutschen Provider üblich, denn wäre es so,
>>>> könnte dieser die Anforderungen bzgl. Lawful Interception/G19
>>
>> G 10, sorry. https://de.wikipedia.org/wiki/Artikel_10-Gesetz
>
>> Aber da stellt sich mMn sehr die Frage, wie realistisch ein Angriff auf
>> SIP/TLS und SRTP eines Endkundenanschlusses ist oder ob da nicht andere
>> Methoden (Wanze vor Ort) eingesetzt würden.
>
> Optimist! Ich werde ja das Gefühl nicht los werden das die gesamte VoIP
> Technik vor allem zu zwei Zwecken propagiert wird (und die Alte folglich
> obsolet zu werden hat).
>
> 1. Zentralisierung durch Software.

Ja, klar, definitiv. Es ist bei Weitem weniger Aufwand, 10 oder 20
regional verteilte (ca. eine pro Bundesland) Komponenten zu pflegen als
300 lokale (ca. eine pro mittelgroßer Stadt). Wenn die modernen
VoIP-Knoten dann noch jeweils aus ein paar VMs auf einer
Virtualisierungsplattform bestehen, die man remote, ggf. aus Rumänien,
upgraden, monitoren etc. kann, während die alten EWSDen vor Ort betreut
werden wollten, dann wird es *um Größenordnungen* günstiger, schneller
(Featureentwicklung/-rollout) und betrieblich einfacher.

> 2. Dadurch möglich werdende Einfache Massenüberwachung - durch Software.

LI war auch im ISDN gefordert und somit in den Systemen eingebaut.

> Öffentlich wird da natürlich nur von den Vorzügen geredet die es bringen
> soll

Welche Vorzüge von VoIP werden denn öffentlich kolportiert? Außer, dass
es billiger ist (s.o. zu den Gründen)?

> und maximal eingestanden das man die Teure und Veraltende Hardware
> in den Vermittlungen dadurch entfernen könnte.

Nuja, die lokalen VSt braucht ja tatsächlich keiner mehr, wenn alle
Dienste von den o.g. 10 oder 20 regionalen VoIP-Knoten erbracht werden.


mfG Paul

[Paul Muster]

On 19.04.22 19:05, Kay Martinen wrote:
> Am 11.04.22 um 18:35 schrieb Marc Haber:
>> Ignatios Souvatzis <u50...@bnhb484.de> wrote:

>>> Also, wenn du wirklich ISDN über das Ende der Erhätlichkeit
>>> traditionell erhältlicher Chipsätze (etwa als Ersatzteil zur
>>> Reparatur deines Gerätes) hinaus sprechen willst - moderne
>>> Mikrocontroller sollten schnell genug sein, einen S0-Bus zu bitbangen.
>
> Interessant. Noch interessanter wären konkrete durchgeführte Projekte
> damit. Links?

Hat noch keiner gemacht. Du darfst Vorreiter sein.

> Wenn $Provider davon aber Rückwirkungen bemerkte
> (Implementationsfehler?) könnte er sagen "Der Bus ist teil unseres
> Netzes = Verbotene Manipulation" oder?

Hä? Welcher Bus zu welchem Provider? Du hast doch gerade nebenan
nachgelesen, dass Provider nur noch VoIP (also SIP+RTP) anbieten. Es
geht also im Kontext ganz klar um die interne Telefonie, also den
Anschluss des guten alten ISDN-Telefons.

> Die B-Kanäle übertragen ja nur je einen Datenstrom. Die ganze
> Signalisierung dazu läuft über den D-Kanal. Wenn es da
> Signalisierungs-Fehler gibt dürfte das $Techniker bei $Provider stutzig
> machen.

Quatsch. Da ist kein Provider am ISDN-Bus.

>> "Software defined Uk0". Sehr schön. Gefällt mir.
>
> Fehlt nur noch eine 48 Volt Quelle um den "Bus" auch treiben zu können. :)

Was soll das Problem sein? Du bist doch Elektriker.


mfG Paul

[Paul Muster]

On 20.04.22 19:29, Thomas Einzel wrote:
> Am 19.04.2022 um 18:57 schrieb Kay Martinen:
>> Am 04.04.22 um 16:49 schrieb Paul Muster:

>>> G 10, sorry. https://de.wikipedia.org/wiki/Artikel_10-Gesetz
>>
>>> Aber da stellt sich mMn sehr die Frage, wie realistisch ein Angriff auf
>>> SIP/TLS und SRTP eines Endkundenanschlusses ist oder ob da nicht andere
>>> Methoden (Wanze vor Ort) eingesetzt würden.
>
> Die TLS Verbindung ist nicht bei jeweiligen Provider terminiert?

Doch, klar, sonst könnte der seinen Verpflichtungen bzgl. LI ja nicht
nachkommen.
Es ging darum, welches Szenario eines Angriffs durch Dritte(!) von einer
Fritzbox mit veralteter Firmware, die moderne Ciphers oder
Hashalgorithmen ggf. irgendwann nicht mehr kann, begünstigt wird.

>> Optimist! Ich werde ja das Gefühl nicht los werden das die gesamte VoIP
>> Technik vor allem zu zwei Zwecken propagiert wird (und die Alte folglich
>> obsolet zu werden hat).
>>
>> 1. Zentralisierung durch Software.
>> 2. Dadurch möglich werdende Einfache Massenüberwachung - durch Software.
>
> Seit spätestens 1998 (seit es Call by Call und Preselection gibt) ist
> das prinzipiell Geschichte, es wird mit IP Telefonie über die Provider
> nur einfacher.

Welches "das" ist seitdem Geschichte?

> Soweit ich gehört habe, sind allein die Wartungskosten der alten
> digitalen Vermittlungsstellen *so* hoch, dass das mit dem kleiner
> gewordenen Festnetz-Gesprächen nicht mehr bezahlbar wäre.

Gut möglich. Die Leute, die noch an EWSD-Baugruppen herumzulöten bereit
sind (um diese zu reparieren), wollen dafür richtig viel Schmerzensgeld.
Zu Recht mMn.
Und auf der anderen Seite vertickt der Vertrieb überall
Festnetzflatrates!!1111elf ;-)


mfG Paul

[Thomas Einzel]

Am 20.04.2022 um 20:43 schrieb Paul Muster:
> On 20.04.22 19:29, Thomas Einzel wrote:
>> Am 19.04.2022 um 18:57 schrieb Kay Martinen:
>>> Am 04.04.22 um 16:49 schrieb Paul Muster:
>
>>>> G 10, sorry. https://de.wikipedia.org/wiki/Artikel_10-Gesetz
>>>
>>>> Aber da stellt sich mMn sehr die Frage, wie realistisch ein Angriff auf
>>>> SIP/TLS und SRTP eines Endkundenanschlusses ist oder ob da nicht andere
>>>> Methoden (Wanze vor Ort) eingesetzt würden.
>>
>> Die TLS Verbindung ist nicht bei jeweiligen Provider terminiert?
>
> Doch, klar, sonst könnte der seinen Verpflichtungen bzgl. LI ja nicht
> nachkommen.

Und damit ist es bezüglich der end2end TLS Verbindungs-Integrität *)
äquivalent zum MITM. *)Es gibt keine.

> Es ging darum, welches Szenario eines Angriffs durch Dritte(!) von einer
> Fritzbox mit veralteter Firmware, die moderne Ciphers oder
> Hashalgorithmen ggf. irgendwann nicht mehr kann, begünstigt wird.

Achso, ja, IMO auch ein Thema, aber ein anderes.

>>> Optimist! Ich werde ja das Gefühl nicht los werden das die gesamte VoIP
>>> Technik vor allem zu zwei Zwecken propagiert wird (und die Alte folglich
>>> obsolet zu werden hat).
>>>
>>> 1. Zentralisierung durch Software.
>>> 2. Dadurch möglich werdende Einfache Massenüberwachung - durch Software.
>>
>> Seit spätestens 1998 (seit es Call by Call und Preselection gibt) ist
>> das prinzipiell Geschichte, es wird mit IP Telefonie über die Provider
>> nur einfacher.
>
> Welches "das" ist seitdem Geschichte?

die zentralisierte G10 Telefon-Überwachung ohne Kabel anklemmen u.ä.

"Geschichte" im Sinne von realisiert, dafür war IP Telefonie nicht nötig
--
Thomas

[Paul Muster]

On 21.04.22 20:53, Thomas Einzel wrote:
> Am 20.04.2022 um 20:43 schrieb Paul Muster:
>> On 20.04.22 19:29, Thomas Einzel wrote:

>>> Die TLS Verbindung ist nicht bei jeweiligen Provider terminiert?
>>
>> Doch, klar, sonst könnte der seinen Verpflichtungen bzgl. LI ja nicht
>> nachkommen.
>
> Und damit ist es bezüglich der end2end TLS Verbindungs-Integrität *)
> äquivalent zum MITM. *)Es gibt keine.

Ja, korrekt. Aber hatte denn irgendwer behauptet, SIP-Telefonie über dt.
Provider umfasse Ende-zu-Ende-Verschlüsselung, sodass du das widerlegen
zu müssen glaubst?

>> Es ging darum, welches Szenario eines Angriffs durch Dritte(!) von
>> einer Fritzbox mit veralteter Firmware, die moderne Ciphers oder
>> Hashalgorithmen ggf. irgendwann nicht mehr kann, begünstigt wird.
>
> Achso, ja, IMO auch ein Thema, aber ein anderes.

In der Tat ein anderes Thema, allerdings *das* Thema, um das es eben
ging: Die TLS-Verschlüsselung der SIP-Kommunikation mit dem Provider und
deren Schutz gegen Dritte.

>>> Seit spätestens 1998 (seit es Call by Call und Preselection gibt) ist
>>> das prinzipiell Geschichte, es wird mit IP Telefonie über die
>>> Provider nur einfacher.
>>
>> Welches "das" ist seitdem Geschichte?
>
> die zentralisierte G10 Telefon-Überwachung ohne Kabel anklemmen u.ä.

Ah, ok.

> "Geschichte" im Sinne von realisiert, dafür war IP Telefonie nicht nötig

Jap, sagte ich ja. War auch bei der EWSD schon umfassend möglich.


mfG Paul

[Kay Martinen]

Am 20.04.22 um 20:54 schrieb Paul Muster:

> On 19.04.22 19:05, Kay Martinen wrote:
>> Am 11.04.22 um 18:35 schrieb Marc Haber:
>>> Ignatios Souvatzis <u50...@bnhb484.de> wrote:
>
>>>> Also, wenn du wirklich ISDN über das Ende der Erhätlichkeit
>>>> traditionell erhältlicher Chipsätze (etwa als Ersatzteil zur
>>>> Reparatur deines Gerätes) hinaus sprechen willst - moderne
>>>> Mikrocontroller sollten schnell genug sein, einen S0-Bus zu bitbangen.

>> Wenn $Provider davon aber Rückwirkungen bemerkte
>> (Implementationsfehler?) könnte er sagen "Der Bus ist teil unseres
>> Netzes = Verbotene Manipulation" oder?
>
> Hä? Welcher Bus zu welchem Provider? Du hast doch gerade nebenan
> nachgelesen, dass Provider nur noch VoIP (also SIP+RTP) anbieten. Es
> geht also im Kontext ganz klar um die interne Telefonie, also den
> Anschluss des guten alten ISDN-Telefons.

Und den Internen S0 Bus willst du dann auch nur Intern benutzen? Weder
von "außen" angerufen werden können noch nach "draußen" telefonieren,
Faxen, Daten übertragen??? Ein Interner Bus für sich allein ist nix wert.

So wie heute Computer ohne Netzwerk als Defekt gelten könnten (Den
Spruch las ich kürzlich und fand ihn treffend). Und das Netzwerk KANN
intern sein. Aber bei den meisten dient es der WAN-Verbindung und die
ist "draußen".

>> Signalisierung dazu läuft über den D-Kanal. Wenn es da
>> Signalisierungs-Fehler gibt dürfte das $Techniker bei $Provider stutzig
>> machen.
>
> Quatsch. Da ist kein Provider am ISDN-Bus.

Der S0 Bus mag ja passiv sein, einen NTBA brauchte es früher dennoch.

Und wenn der nicht nur-lokal ist muß "etwas" von D-Kanal auf SIP
dolmetschen. Bei einer eigenbau-µC Lösung und nur einem Fehler darin
sehe ich hier das Potential das dem SIP-Provider eine ungültige, Falsche
oder Fehlende Signalisierung auffällt. Und dann? "der tut nix, der
wollte nur spielen" oder klemmen sie dich dann ab? SIP-Gegenstelle
antwortet nicht mehr...

[Paul Muster]

On 21.04.22 22:06, Kay Martinen wrote:
> Am 20.04.22 um 20:54 schrieb Paul Muster:
>> On 19.04.22 19:05, Kay Martinen wrote:

>>> Wenn $Provider davon aber Rückwirkungen bemerkte
>>> (Implementationsfehler?) könnte er sagen "Der Bus ist teil unseres
>>> Netzes = Verbotene Manipulation" oder?
>>
>> Hä? Welcher Bus zu welchem Provider? Du hast doch gerade nebenan
>> nachgelesen, dass Provider nur noch VoIP (also SIP+RTP) anbieten. Es
>> geht also im Kontext ganz klar um die interne Telefonie, also den
>> Anschluss des guten alten ISDN-Telefons.
>
> Und den Internen S0 Bus willst du dann auch nur Intern benutzen? Weder
> von "außen" angerufen werden können noch nach "draußen" telefonieren,
> Faxen, Daten übertragen??? Ein Interner Bus für sich allein ist nix wert.

Du befürchtest also Implementierungsfehler beim hypothetischen
*internen* 'software defined S0-Bus', die sich auf der
SIP-Schnittstelle, die zum Provider zeigt, Auswirkungen haben? Da müsste
jemand aber ganz arg Schrott verzapfen, nicht nur beim S0-Bus, sondern
auch bei der Signalling-/Media-Gateway-Funktionalität. Klar, ist
/theoretisch/ möglich. Wird beim Test im Rahmen der Entwicklung
hoffentlich auffallen.

>>> Signalisierung dazu läuft über den D-Kanal. Wenn es da
>>> Signalisierungs-Fehler gibt dürfte das $Techniker bei $Provider stutzig
>>> machen.
>>
>> Quatsch. Da ist kein Provider am ISDN-Bus.
>
> Der S0 Bus mag ja passiv sein, einen NTBA brauchte es früher dennoch.
>
> Und wenn der nicht nur-lokal ist muß "etwas" von D-Kanal auf SIP
> dolmetschen. Bei einer eigenbau-µC Lösung und nur einem Fehler darin
> sehe ich hier das Potential das dem SIP-Provider eine ungültige, Falsche
> oder Fehlende Signalisierung auffällt. Und dann? "der tut nix, der
> wollte nur spielen" oder klemmen sie dich dann ab? SIP-Gegenstelle
> antwortet nicht mehr...

Quatsch. Die Provider wollen, dass die Kunden telefonieren können und
ziehen fehlerhafte Signalisierung gerade. Die klemmen niemanden ab, wenn
der nicht entweder selbst missbraucht ("Fraud") oder missbraucht wird
(auch heutzutage werden TkA "gehackt" und Rufumleitungen z.B. nach
Nigeria geschaltet).


mfG Paul