Telekom All IP Privat endlich erfolgreiche Registierung SSL/TLS möglich

[mipo]

Hallo zusammen,

bisher war die VoIP Telefonie Verschlüsselung über SSL/TLS ja nur den Geschäftskunden vorbehalten. Am WE
habe ich ein wenig mit meiner Auerswald COMmander 6000 herumgespielt und habe erfreulicherweise festge-
gestellt, dass eine erfolgreiche Registrierung mit SSL/TLS möglich war. Also die Verschlüsselung auch an meinem
BNG All IP Anschluss möglich ist.

Frage: Ist das ein regionaler Zufall oder ist die Verschlüsselung jezt generell (endlich) möglich?

Viele Grüße
Michael

 

[ta99]

Das ist schon seit vielen Monaten generell möglich.

 

[mipo]

Jo, mit Sicherheit in unserer Region vor 4-8 Wochen noch nicht. Für Geschäftskundenanschlüsse mag sein, aber
nicht für Privatanschlüsse!

Gruß
Michael

 

[rollo]

Bei mir klappt es nicht. Welches Template verwendest Du? Welche Einstellungen wurden geändert?
Ist SIP und RTP verschlüsselt?

jo

 

[ta99]

Jo, mit Sicherheit in unserer Region vor 4-8 Wochen noch nicht. Für Geschäftskundenanschlüsse mag sein, aber nicht für Privatanschlüsse!

Ich habe auch nur einen Magenta M und habe TLS schon seit Herbst letzten Jahres aktiv.

 

[mipo]

Hallo Rollo,
hab im Moment nur SIPS aktiviert. Also "Telekom MagentaZuhause IPv4 V201" genommen und SIPS SSL/TLS und das Häkchen "Prüfung des Hostnamen aktiviert"
Stimmt, SRTP habe ich natürlich übersehen. Habs gerade getestet, wenn ich es auf "vorgeschrieben" setze, klingelt es aber nach abheben ist das Gespräch weg.

Hm ... nicht so prickelnd .. Denn gerade RTP sollte ja verschlüsselt sein. Oder mache ich einen Denkfehler?

Gruß
Michael

 

[rollo]

Hallo Michael,

habe es inzwischen auch mit SIPS hinbekommen aber SRTP läuft nicht. Das in der Tat der wichtigere Teil, wobei ich bei Telekom-DSL die Abhörgefahr gering einschätze. So richtig gut wäre eine Ende zu Ende Verschlüsselung aber das ist in öffentlichen Netzen nicht gewollt.

jo

 

[Auerswald Fan]

Hallo Rollo.

Bei der COMpact 4000 sollte sich unter Administration -> Zertifikate ein Zertifikat finden, dem man noch vertrauen muss...ist das evtl. Die Lösung?

 

[sonyKatze]

RTP sollte ja verschlüsselt sein. Oder mache ich einen Denkfehler?

Mit SIP-over-TLS wird die Verbindung zwischen Deinem Telefon (-anlage) und der Deutschen Telekom abgesichert. Was danach passiert, kann SIP-over-TLS bzw. sRTP nicht sicherstellen.

Die Deutsche Telekom unterstützt sRTP selbst nicht, sondern leitet Deine Anfrage (SDP) lediglich durch. Alles andere wäre mir neu. Dadurch muss Dein Gesprächspartner ebenfalls sRTP können. Das ist wie beim VoIP/SIP-Provider Easybell. Mehr dazu in diesem Thread… Wenn Du in Deinem Telefon (-anlage) sRTP auf „optional“ stellen kannst, müsste alles automatisch funktionieren:
a) Das Gespräch baut sich auf, falls Dein Gegenüber kein sRTP kann. Oder
b) Das Gespräch ist verschlüsselt, falls Dein Gegenüber ebenfalls SDES-SRTP kann (und die Verbindung durchgehend IP-basiert war).

Der VoIP/SIP-Provider Dus.net verfolgt einen anderen Ansatz:
Dus.net schaltet sich auch auf der Medien-Ebene (RTP) dazwischen, daher machst Du sRTP direkt mit Dus.net. Dadurch kann bei Dus.net jedes Gespräch mit sRTP verschlüsselt werden und Du brauchst kein „optionales sRTP“.

 

[wuesten.fuchs]

Welche Einstellungen braucht man bei der Telekom für SIPS?

Habe unter Asterisk 13 folgenden Transport in meiner pjsip.conf:

[transport-tls-generic]
type = transport
protocol = tls
bind = 0.0.0.0
ca_list_path = /etc/ssl/certs/
method = tlsv1

Doch damit funktionierts nicht. Fehlermeldung:

res_pjsip_outbound_registration.c:797 schedule_retry: No response received from 'sip:tel.t-online.de' on registration attempt to 'sip:[email protected]', retrying in '60'
pjproject:0 <?>:                        SSL STATUS_FROM_SSL_ERR (connecting): Level: 0 err: <336151598> <SSL routines-SSL3_READ_BYTES-tlsv1 alert protocol version> len: 0

SIP-Einstellungen:

 <Registration/ServerURI..............................>  <Auth..........>  <Status.......>
==========================================================================================

 telekom_0123451234567/sip:tel.t-online.de                telekom_0123451234567_auth  Rejected       

 ParameterName            : ParameterValue
 =============================================================
 auth_rejection_permanent : false
 client_uri               : sip:[email protected]
 contact_user             : +49123451234567
 endpoint                 :
 expiration               : 480
 fatal_retry_interval     : 0
 forbidden_retry_interval : 300
 line                     : false
 max_retries              : 10
 outbound_auth            : telekom_0123451234567_auth
 outbound_proxy           :
 retry_interval           : 60
 server_uri               : sip:tel.t-online.de
 support_path             : false
 transport                : transport-tls-generic

 

[Meester Proper]

Die Deutsche Telekom unterstützt sRTP selbst nicht, sondern leitet Deine Anfrage (SDP) lediglich durch. Alles andere wäre mir neu. Dadurch muss Dein Gesprächspartner ebenfalls sRTP können.

Das ist falsch, die SBCs der Telekom können SRTP, also End-to-Access Edge Security ("media plane security" laut 3GPP), dort wird das Gespräch wieder zu RTP gewandelt. Der B-Teilnehmer muss kein SRTP unterstützen. Ansonsten ist es jedoch korrekt, dass keine SDP-Filterung eingesetzt wird.

Bei der Telekom muss bei den "Nicht-SIP-Trunk"-Telefondiensten momentan jedoch noch die komplexe, zusätzliche Signalisierung für 3GPP end-to-access edge security / media plane security bei der Registrierung und beim Call-Aufbau (INVITE, MediaSec-Header) verwendet werden, um SRTP verwenden zu können. Das soll sich erst in 2019 ändern.

Momentan haben diese Erweiterungen bintec-elmeg ("MediaSec": https://www.bintec-elmeg.com/fileadmin/user_upload/Downloads/48/release_notes_10.2.4.101_de.pdf) und Lancom ("MediaSec": https://www.lancom-systems.de//download/documentation/Release_Notes/RN_LCOS-1012-RU10_DE.pdf) implementiert.

 

[sonyKatze]

Ja, als ich letzt meine Digitialisierungsbox aktualisierte, fand ich das ebenfalls. LANCOM-Systems kann das seit Mai. Bintec-Elmeg seit Oktober. Durch deren genauere Beschreibung fand ich dann im Forum Telekom-Hilft einen weitergehenden Post. Dort wird auf die zugrundeliegende Definition dieser Sec-Agree- bzw. MediaSec-Header verwiesen. Mit Sec-Agree habe ich ein wenig Erfahrung, aber MediaSec war mir komplett neu. Daher wollte ich warten, bis ich das an einem Telekom-Anschluss testen konnte. Was ich nämlich noch nicht verstehe: Du schreibst vom Session-Border-Controller (SBC) bzw. MediaSec erwähnt „edge of the core network“ – was passiert, wenn ich keinen Übergang habe, also wenn meine Gegenstelle
a) im Mobilfunk Voice-over-LTE (VoLTE),
b) im Mobilfunk WLAN-Telefonie (VoWiFi) oder
c) im Festnetz einen IP-basierten Anschluss
nutzt. Ich dachte, in diesen Fällen gäbe es keine Session-Border mehr. Oder erkennt die Telekom – weil die Zusatz-Header im SIP-REGISTER fehlten –, dass sie sich für dieses Ende auf der Media-Ebene einklinken muss?

Randbemerkung: Die komplett neue und erst in diesem Jahr eingeführte Digitalisierungsbox BASIC von ZyXEL kann diese Erweiterung bis heute noch nicht. Jedenfalls finde ich in meiner die Option nicht.

 

[Meester Proper]

Was ich nämlich noch nicht verstehe: Du schreibst vom Session-Border-Controller (SBC) bzw. MediaSec erwähnt „edge of the core network“ – was passiert, wenn ich keinen Übergang habe, also wenn meine Gegenstelle
a) im Mobilfunk Voice-over-LTE (VoLTE),
b) im Mobilfunk WLAN-Telefonie (VoWiFi) oder
c) im Festnetz einen IP-basierten Anschluss
nutzt. Ich dachte, in diesen Fällen gäbe es keine Session-Border mehr. Oder erkennt die Telekom – weil die Zusatz-Header im SIP-REGISTER fehlten –, dass sie sich für dieses Ende auf der Media-Ebene einklinken muss?

Du verwechselst hier SBC mit Media Gateway. Ein SBC separiert verschiedene SIP-Domänen, trennt öffentliche von privaten Netzen ab. In der 3GPP IMS-Architektur heißen die SBCs gewöhnlich *-CSCF, in der funktionalen Architektur der Hersteller gibt es dann noch getrennte Netzelemente für die Signalisierung (SIP) und die eigentlichen Medien-Pakete (RTP, UDPTL für T.38). In den meisten Netzbetreiber-Implementierungen wird der Medienstrom zwischen zwei IP-Teilnehmern über zwei SBCs geführt: Ingress- und Egress-SBCs. Der Medienstrom fließt dann vom Teilnehmer zum Ingress-SBC, dort dann zum Egress-SBC und dort zum Teilnehmer.

Ein Mediagateway (MGW) stellt dagegen den Übergang zwischen verschiedenen Medien her: IP-basiert bspw. in TDM-Netze, wie ISDN. Gewöhnlich steuert ein Mediagateway Controller mehrere Mediagateways, ersterer ist für die Signalisierung zuständig, zweiterer für den Medienübergang. Das meintest du eigentlich, wenn du von SBCs gesprochen hast. Bei zwei IP-Teilnehmern kommen natürlich keine MGWs zum Einsatz.

Randbemerkung: Die komplett neue und erst in diesem Jahr eingeführte Digitalisierungsbox BASIC von ZyXEL kann diese Erweiterung bis heute noch nicht. Jedenfalls finde ich in meiner die Option nicht.

ZyXEL hat diese Erweiterungen bisher nicht implementiert.

 

[sonyKatze]

Ehrlich, ich verstehe kein Wort. Ich dachte, dass RTP und sRTP bereits verschiedene Medien sind. Danach folgend klinkt sich die Telekom sowohl in die Signalisierung als auch den Medienstrom. Das macht sie auch tatsächlich, aber auf lange Sicht soll das doch alles weg. Beispiel: Wenn ich heute von O₂ VoWiFi meinen Festnetz-Anschluss bei 1&1 anrufe, dann sehe ich bereits alle entfernten Audio-Codecs im SDP (G.711 aber auch AMR-WB und bei entsprechendem Mobiltelefon sogar EVS). Wie will ich dann noch von/zu SDES-sRTP aushandeln/umwandeln? Hat die 3GPP irgendwo ein Übersichtsdokument, wo der Ablauf (mit Sec-Agree/MediaSec) schematisch veranschaulicht wird?

 

[Meester Proper]

SRTP ist im Grunde nur RTP mit verschlüsseltem Payload. Die Schlüsselaushandlung geschieht per Crypto-Line in den SDP-Attributen. dabei sprichst du dann aber nicht direkt mit deinem entfernten Endgerät (wie du dir das vorstellst), sondern handelst es mit dem SBC des Providers aus. Dieser schickt dann auf der dem Kunden abgewandten Seite wieder ohne Crypto-Attribute und als gewöhnliches RTP den Medienstrom weiter. Bis auf die Crypto-spezifischen Anpassungen, wird die Session Description (SDP) jedoch nicht modifiziert.

Auf der Seite von Sonus Networks gibt es dort auch eine Illustration, wie es aussieht, wenn beide Endgeräte SRTP nutzen: https://support.sonus.net/display/SBXDOC62/IMS+end-to-access+edge+(e2ae)+Media+Security+Support (Bild 1)

Bei der 3GPP ist dies hier ab 7.2 beschrieben: http://www.qtc.jp/3GPP/Specs/33328-920.pdf

Theoretisch wäre auch eine End to End Verschlüsselung möglich, hier lassen sich aber meines Wissens die Vorgaben des TKG bzgl. "Lawful Interception" (Abhören durch Polizeibehörden usw.) nicht bzw. schwierig umsetzen, daher ist das bei der Telekom m.W. nicht möglich.

 

[sonyKatze]

Suppi Erklärung! Folglich grätscht die Deutsche Telekom im SDP sogar bis in die Media Descriptions (m=). Ich fasse nochmal zusammen, was ich verstanden habe: Egal wohin ich anrufe (oder von wem ich angerufen werde), die Verbindung zwischen mir und tel.t-online.de ist nicht nur durch SIP-over-TLS sondern immer auch über SDES-sRTP abgesichert. Richtig? Klar, ich muss es in meinem Router von LANCOM-Systems bzw. bintec-elmeg auch aktivieren.

Das wäre ein Vorteil gegenüber Easybell, bei denen sRTP bisher nur fallweise je nach Quelle/Ziel geht.

Welche Einstellungen braucht man bei der Telekom für [Digium Asterisk 13 über den Channel chan_pjsip]?

Die Deutsche Telekom verlangt mindestens TLS in Version 1.2. Daher musst Du „method = tlsv1“ entfernen, weil sonst Dein Asterisk nicht mehr TLS 1.0 bis 1.2 sondern nur noch TLS 1.0 macht.

 

[Meester Proper]

Richtig, es wird immer SRTP genutzt.

 

[gehtdoch]

Bei der Telekom muss bei den "Nicht-SIP-Trunk"-Telefondiensten momentan jedoch noch die komplexe, zusätzliche Signalisierung für 3GPP end-to-access edge security / media plane security bei der Registrierung und beim Call-Aufbau (INVITE, MediaSec-Header) verwendet werden, um SRTP verwenden zu können. Das soll sich erst in 2019 ändern.

Ich habe mit asterisk 13.24.x / pjsip und freepbx 13 und der Telekom kein Problem mit SIP / RTP bzw. SIPS / RTP (allerdings ist manuelle Konfig in pjsip.registration_custom.conf, pjsip.transports_custom_post.conf und pjsip.endpoint_custom_post.conf nötig - es wird also vieles quasi direkt gemacht). Neuerdings sind auch noch zwei Patches bei outbound calls nötig, weil das ring back zu bestimmten Providern fehlt.

Ich überlege gerade, ob ich die mediasec-Erweiterungen implementieren soll. Wenn das allerdings ab diesem Jahr auch normal via RFC 3329 funktionieren soll, wäre der Aufwand unnötig. Daher die Frage: gibt es eine Einschätzung darüber, wie wahrscheinlich es ist, dass SRTP bei der Telekom zukünftig auch via RFC 3329 funktionieren soll?

 

[Meester Proper]

SRTP wird voraussichtlich im ersten Halbjahr auch ohne RFC3329 und mediasec-Erweiterungen gemäß draft-dawes-sipcore-mediasec-parameter-09.txt funktionieren.

Neuerdings sind auch noch zwei Patches bei outbound calls nötig, weil das ring back zu bestimmten Providern fehlt.

Das Problem ist vermutlich, dass Asterisk, so wie ich es gelesen habe, P-Early-Media gemäß RFC5009 nicht unterstützt. Wenn Early Media „gated“ wird, d.h. zwar eine SDP Offer/Answer Prozedur stattgefunden hat, aber kein Media übermittelt, wird dies per PEM-Header mitgeteilt, damit ein lokales Klingeln generiert werden kann.

 

[gehtdoch]

Danke für Deine Info Meester Proper!

Das Problem ist vermutlich, dass Asterisk, so wie ich es gelesen habe, P-Early-Media gemäß RFC5009 nicht unterstützt. ... Vollzitat von darüber gekürtzt by stoney

Leider hat keine SDP Offer/Answer Prozedur stattgefunden! Kann ja auch nicht, wenn im 183 kein SDP enthalten ist.

Welches Problem löst RFC5009, was nicht mit 180 Ringing bzw. 183 EarlyMedia schon gelöst ist? Wenn ein 180 Ringing kommt, heißt das doch, dass das ring back lokal erzeugt werden muss. Bei 183 mit SDP weiß man, dass das ring back remote erzeugt wird (oder was auch sonst immer als Ansage kommt). Wieso muss man da dann mit 183 ohne SDP daherkommen (was dann de facto einem 180 entspricht) oder auf der anderen Seite 180 mit SDP (was dann einem gewöhnlichen 183 entspricht)? Das erschließt sich mir absolut noch nicht und scheint auch irgendwie Telekom-spezifisch zu sein, weil ich das so noch nirgendwo gesehen habe (ok, das heißt jetzt nicht allzu viel).