[Frage] Telekom SIP Trunk mit TLS

[ubsyathEe]

Hallo,

weiß jemand wie man den Telekom SIP Trunk mit TLS zum Laufen bekommen (Asterisk 16.3, chan_pjsip)?

Ich habe keine Probleme ohne Verschlüsselung. Wenn ich die Transport Sektion mit transport=tls, Port 5061 und cert_file=<path>/globalroot_class_2.cer definiere und ansonsten überall wo SIP URIs stehen sip durch sips ersetze, sollte zumindest eine Reaktion des Telekom Servers zu erwarten sein.

Es gibt aber keine Reaktion.

Kann es sein, dass TLS nicht überall verwendet werden kann, obwohl die Serviceanfrage dig reg.sip-trunk.telekom.de NAPTR SIPS anbietet?

; ANSWER SECTION:
reg.sip-trunk.telekom.de. 84600 IN NAPTR 20 0 "s" "SIP+D2T" "" _sip._tcp.reg.sip-trunk.telekom.de.
reg.sip-trunk.telekom.de. 84600 IN NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.reg.sip-trunk.telekom.de.

 

[sonyKatze]

Hilft dies… oder direkt gefragt: Macht Dein Asterisk bereits DNS-SRV? SIPS-URIs brauchst Du nicht.
Wenn Du nicht nur den Signalisierung sondern auch die Medien verschlüsseln willst, würde ich jenen Thread weiterverfolgen…

 

[ubsyathEe]

Ich verwende den pjsip Stack und der macht implizit vollständige NAPTR und SRV Lookups (chan_sip nur einen einfachen SRV Lookup). Ich habe das hier nur händisch gemacht, um zu zeigen, dass sips über tcp auch angeboten wird.

Die anderen Threads muss ich mir in Ruhe durchlesen. Sobald die Registrierung funktioniert, kommen die Medien dran.

-- Aktualisiert --

Ich habe jetzt in den Threads nichts gelesen, was von meinen Fehlschlägen abweicht. Ich könnte noch den Port in der Transport Sektion wegnehmen, aber sonst ist das alles ziemlich identisch, wobei ich aber das vorgesehen Zertifikat der Telekom verwende. Hierzu gibt es folgende Seite:
https://geschaeftskunden.telekom.de/461850?wt_mc=alias_1599_gk/neues-zertifikat

 

[sonyKatze]

Mhm. Ich habe hier als SIP-Stack nur chan_sip am Laufen, daher kann ich gerade nicht nachschauen. Siehst Du in einem Paket-Mitschnitt mittels Tools ala Wireshark, ob die TLS-Verbindung aufgebaut wird und es an SIP hapert? In Wireshark filterst Du dazu auf "tcp.port == 5061 && ssl". bzw. seit Wireshark 3 auf "tcp.port == 5061 && tls".

Oder klappt schon die TLS-Verbindung nicht? Ich meine, ich musste in der Konfigurationsdatei pjsip.conf method=sslv23 angeben, weil das PJSIP-Team (Teluu) die TLS-Version nicht automatisch aushandelt, sondern in der Standard-Einstellung nur TLS 1.0-only macht. Teluu hat schlicht die OpenSSL-API falsch verstanden. Die Telekom bietet aber kein TLS 1.0 mehr an. Daher musst Du diese schlechte Voreinstellung selbst korrigieren.

 

[ubsyathEe]

Guter Hinweis. Ich werde gleich einen Telekom SIP Trunk für die Tests wieder vorbereiten und mit tcpdump mitschneiden. Ich habe hier auch noch eine konfigurierte Digibox rumliegen, die ich auch mal mitschneiden könnte. Ich hoffe, dass es da bei Telefonie eine Option gibt TLS zu erzwingen...

-- Aktualisiert --

PS chan_sip: Hast Du Probleme mit chan_sip an ALL-IP Anschlüssen?

Mit pjsip habe ich deutlich weniger Nichterreichbarkeitszustände als vorher, wobei unter pjsip auch Session Timer und Qualifies funktionieren. chan_sip autentifiziert OPTIONS nicht, wofür es bei pjsip eine Einstellung in der conf-Datei gibt. Die Telekom schickt wohl auch (neuerdings und ungefragt) nach einer halben Stunde UPDATE Requests mit timer Feld.

Mittlerweile getestet: "method=sslv23" lässt SIP mit Transport TCP/TLS laufen (REGISTER, OPTIONS, ...). Derzeit habe ich Medienprobleme, aber das dürfte jetzt nicht sonderlich schwer sein. Danke.

 

[sonyKatze]

Hast Du Probleme mit chan_sip an ALL-IP Anschlüssen?

Aktuell habe ich keinen Anschluss bei der Deutschen Telekom. Ich bezog mich auf das DNS-Verhalten (NAPTR, SRV, A) – das wusste ich nicht mehr auswendig. Über was ich mal gestolpert war, ist dieses method=sslv23. Schön dass das auch bei Dir geholfen hat.

chan_sip autentifiziert OPTIONS nicht

Wäre eigentlich ein eigener Thread wert. Wozu brauchst Du in Deinem Szenario qualify=yes bzw. die SIP-Methode OPTIONS genau?

UPDATE

In chan_sip? Dann hätte die Deutsche Telekom einen riesigen Software-Bug, weil chan_sip im Header Supported klar beschreibt, dass es mit der SIP-Methode UPDATE nicht umgehen kann.

timer

Während einem Telefonat oder während eine (ruhenden) Verbindung? Die Gegenstelle darf (während einem Telefonat) wann immer sie will, die Sitzung erneuern. Aber im Fall von chan_sip muss das über re-INVITE passieren und darf nicht mittels der SIP-Methode UPDATE erfolgen. Oder meinst Du eine ruhende Verbindung? Das Szenario müsste ich nochmals nachschauen.

 

[ubsyathEe]

Wozu brauchst Du in Deinem Szenario qualify=yes bzw. die SIP-Methode OPTIONS genau?

Wenn ich OPTIONS verwenden kann, brauche ich keine Firewallregeln für reinkommende Verbindungen. Ich müsste mir die Details noch mal ansehen, aber so reichen die eigenen Kontaktdaten mit rport für alles was von der Telekom kommt aus. Im Einzelfall hängt das aber wohl auch von den Eigenschaften des Routers ab.

Bei chan_sip hat bei mir immer session-timers=refuse, oder so, funktioniert. Bei den neueren Telekomprodukten kommen von der Telekom automatisch UPDATE requests nach einer halben Stunde bei langen Gesprächen, egal was man selbst bezüglich "timer" selbst konfiguriert hat.

 

[gehtdoch]

Guter Hinweis. Ich werde gleich einen Telekom SIP Trunk für die Tests wieder vorbereiten und mit tcpdump mitschneiden. Ich habe hier auch noch eine konfigurierte Digibox rumliegen, die ich auch mal mitschneiden könnte. Ich hoffe, dass es da bei Telefonie eine Option gibt TLS zu erzwingen...

Du kannst den kompletten SIP-Verkehr auch bei Verschlüsselung mitlesen, indem Du auf der asterisk-Büchse folgendes machst (als root):

asterisk -r

dann in der CLI folgendes eingibst:

pjsip set logger on

-> Dann bekommst Du sämtliche SIP-Pakete im Terminal präsentiert.

Mit

pjsip set logger off

schaltest Du das Ganze wieder aus.

PS chan_sip: Hast Du Probleme mit chan_sip an ALL-IP Anschlüssen?

Mit pjsip habe ich deutlich weniger Nichterreichbarkeitszustände als vorher, wobei unter pjsip auch Session Timer und Qualifies funktionieren. chan_sip autentifiziert OPTIONS nicht, wofür es bei pjsip eine Einstellung in der conf-Datei gibt. Die Telekom schickt wohl auch (neuerdings und ungefragt) nach einer halben Stunde UPDATE Requests mit timer Feld.

Die "Totmannschaltung" kommt alle 15 Minuten und funktioniert entweder über ReInvites (bei chan_sip, weil chan_sip kein UPDATE beherrscht) oder bei pjsip via UPDATE. Letzteres funktioniert dann auch, während die ReInvites abhängig vom Provider des TN B den Bach runtergehen und es dadurch zu Gesprächsabbrüchen kommt. Daher ist pjsip mit der Telekom Pflicht.

Mittlerweile getestet: "method=sslv23" lässt SIP mit Transport TCP/TLS laufen (REGISTER, OPTIONS, ...). Derzeit habe ich Medienprobleme, aber das dürfte jetzt nicht sonderlich schwer sein. Danke.

Bitte nicht die Option sslv23 verwenden, weil die deprecated ist. Verwende

method=tlsv1_2

Ansonsten unterstützt asterisk 16.x / pjsip alle relevanten HA-Features der Telekom (NAPTR, SRV) und kann auch mit den mehrfachen Einträgen in den SRV-Ergebnissen umgehen. Habe selbst eine solche Installation hier mittlerweile problemlos laufen (bin von 13.x / pjsip gewechselt, die auch schon ganz ordentlich lief - aber eben ohne die HA-Fähigkeiten und v.a. hat der immer wieder mal die falsche IP aus der Liste verwendet (konnte damit nicht umgehen) für die OPTIONS-Pakete - was bei TLS aber irrelevant ist, weil der Paketfilter den Inhalt des Paketes eh nicht mitbekommt und selbst im anderen Fall hatte ich damit kein Problem, weil der Paketfilter den Error einfach ignoriert hat und den Paketfluss an sich schon als ok angenommen hat).

Verschlüsselung RTP-Stream: ist derzeit mit asterisk nicht möglich, weil die relevanten Mediasec-Erweiterungen in asterisk / pjsip nicht unterstützt werden.

Meine Aussagen beziehen sich übrigens auf ALLIP der Telekom - aber ich gehe davon aus, dass der Business-Trunk hiervon nicht substantiell abweicht.

 

[sonyKatze]

Bitte nicht die Option sslv23 verwenden, weil die deprecated ist. Verwende method=tlsv1_2

Geht auch (im Moment).

Aber ganz so einfach ist das nicht. In OpenSSL ist ein Teil der Programmierschnittstelle (API) deprecated. Den Teil den Du anspricht ist deprecated, weil jetzt nach über zwei Jahrzehnten irgendwem auf einmal die Bezeichnung nicht gefallen hat – also der Name der Methode. Folglich besteht noch nicht einmal ein technischer Unterschied; die alte und die neue Schnittstelle macht das selbe. sslv23 ist ein Wert für einen Parameter in PJSIP. Asterisk reicht den durch. Wie dann genau PJSIP die SSL/TLS-Bibliothek angesteuert (und ob das überhaupt OpenSSL ist), muss man im Quellcode von PJSIP schauen. Aktuell: Mit tlsv1_2 wählst Du genau eine Version und schaltest damit TLS 1.3 (und neuer) aus.

OpenSSL bietet weiterhin die „Option“ die TLS-Version automatisch auszuhandeln und das ist auch nicht deprecated sondern der Normalfall. Lediglich wünscht sich das OpenSSL-Team, dass man dazu jetzt TLS_method() zusammen mit SSL_CTX_set_min_proto_version() nutzt und beispielsweise TLS1_2_VERSION setzt.

Lange Rede kurzer Sinn: Wenn man immer weiß, was die Gegenstelle macht, dann kann man statt der Automatik method=sslv23 die explizite Version nehmen. Aktuell kann die Telekom nur TLS 1.2 und nicht mehr. Daher ist method=tlsv1_2 optimal. Wenn die Telekom irgendwann mal TLS 1.2 ausschaltet (oder vorher bekannt wird, dass TLS 1.2 eine Schwäche hat), dann fliegt man (wieder) auf die Nase. Daher geht das auch im Moment.

 

[gehtdoch]

Lange Rede kurzer Sinn: Wenn man immer weiß, was die Gegenstelle macht, dann kann man statt der Automatik method=sslv23 die explizite Version nehmen. Aktuell kann die Telekom nur TLS 1.2 und nicht mehr. Daher ist method=tlsv1_2 optimal. Wenn die Telekom irgendwann mal TLS 1.2 ausschaltet (oder vorher bekannt wird, dass TLS 1.2 eine Schwäche hat), dann fliegt man (wieder) auf die Nase. Daher geht das auch im Moment.

Das ist korrekt. Aus Sicherheitsgesichtspunkten ist es allerdings vorteilhafter, nur TLS 1.2 zu erlauben und nichts anderes (sslv23 ist daher auch in FreePBX 14 explizit als unsicher eingestuft, weil es eben auch noch ältere, unsichere Protokollvarianten erlaubt). Falls sich da in der Zukunft Änderungen ergeben sollten, muss man natürlich nachziehen / neu bewerten. Das ist der Nachteil - aber das ist leider meistens so - entweder sicher oder - ich nenne es mal komfortabel. Auf die eingeschränkte Weise bin ich mir wenigstens sicher, was konkret genutzt wird (hoffentlich) und bekomme es mit, wenn die Telekom davon plötzlich abweichen sollte - mit dem Nachteil, dass es dann eben mal klemmt.

TLS 1.3 wird wahrscheinlich sowieso mit einer neuen OpenSSL-Version einhergehen (zumindest gehe ich davon aus, dass in der hier eingesetzten 1.0.x-Version TLS 1.3 nicht unterstützt werden wird). Für den, der OpenSSL 1.1.x einsetzt, könnte die Bewertung anders aussehen. Allerdings fehlt hierzu derzeit noch der Support sowohl in Asterisk als auch in pjsip (zumindest in den Produktionsversionen). In diesem Fall würde ich dann nämlich gerne auf 1.3 einschränken können oder 1.2 und 1.3 - den Rest will ich nicht mehr haben.

Muss aber letztendlich jeder für sich selbst bewerten / abwägen. Rein funktional betrachtet ist beides möglich und es gibt je nach Anforderung gute Gründe für beide Varianten.

 

[sonyKatze]

Zitat aus der Man-Page von OpenSSL: „Applications should use [the version-flexible SSL/TLS methods], and avoid the version-specific methods [which] were deprecated in OpenSSL 1.1.0.“

… das ist der Nachteil …

Nein.
Die API von OpenSSL wird durch Asterisk bzw. das PJProject falsch angesteuert. Das hat nichts mit Komfort oder Sicherheit zu tun, sondern ist einfach deren Inkompetenz. Du willst nicht genau Version X sondern mindestens Version X. Deswegen sind die versionsspezifischen Methoden deprecated – weil Du so nicht in den Genuss einer höheren Versionen kommst. Wenn man ältere Versionen nicht will, bleibt man bei der Auto-Negotiation, schaltet aber die ungewünschten Versionen über Optionen ab.

Positiv-Beispiel chan_sip: Dort ist von Haus aus SSL 2.0 und SSL 3.0 abgeschaltet. Alles Neuere ist an. Wenn Du TLS 1.0 und TLS 1.1 abschalten willst, dann machst Du das über die Konfigurationsdatei sip.conf und tlsdisablev1=yes bzw. tlsdisablev11=yes. So kannst Du zum Testen/Spielen sogar TLS 1.2 ausschalten und nur TLS 1.3 verlangen: tlsdisablev12=yes.

Willst Du dasselbe in chan_pjsip erreichen, geht das (bisher) nicht über die Konfigurationsdatei pjsip.conf. Aber es gibt Wege…

[Für OpenSSL 1.1.1] fehlt derzeit noch der Support sowohl in Asterisk als auch in pjsip.

Wie kommst Du darauf?
Ich habe hier Asterisk 13 und OpenSSL 1.1.1 mit TLS 1.3 am Start, sowohl unter chan_sip als auch chan_pjsip.

In diesem Fall würde ich dann nämlich gerne auf 1.3 einschränken können.

Die Telekom bietet aktuell ausschließlich TLS 1.2.

oder 1.2 und 1.3 - den Rest will ich nicht mehr haben.

Warum auch immer.

Was Du (auch) willst, ist eine durchgehende Mindest-Bitstärke auf allen Ebenen. OpenSSL hat dazu SECLEVEL eingeführt (Diskussion über dessen Zukunft). Dies hängst Du an die Liste der Cipher-Suites an: DEFAULT@SECLEVEL=4. Mit der Deutschen Telekom kommst Du nicht über SECLEVEL=1 hinaus, weil deren DH-Key aktuell nur 1024 bit stark ist. Wenn Du DHE ausschaltest – und damit auf Forward-Secrecy (PFS) verzichtest –, kannst Du maximal SECLEVEL=2 erreichen, weil der Public-Key der Telekom aktuell nur 2048 bit stark ist.

Lange Rede kurzer Sinn: Komfort und Sicherheit stehen hier nicht im Widerspruch. Problem ist lediglich, dass die Firma Teluu die API von OpenSSL und die Firma Digium die API von PJSIP nicht verstanden haben.

Auf die eingeschränkte Weise bin ich mir wenigstens sicher, was konkret genutzt wird (hoffentlich) …

Auch dafür: Nein.
So etwas kann man mit Tools wie testssl (Server) oder Wireshark (Client) schnell nachprüfen. Wenn man dann eine unerwartet zu niedrige Version bekommt, meldet man das an den Hersteller. Ich hatte schon so viele Closed-Source-Produkte bei denen die TLS-Version falsch festgezurrt war und dass dann wahnsinnig viel Aufwand war. Die versionsspezifischen Methoden sind gut wie möglich zu vermeiden.

 

[gehtdoch]

Zitat aus der Man-Page von OpenSSL: „Applications should use [the version-flexible SSL/TLS methods], and avoid the version-specific methods [which] were deprecated in OpenSSL 1.1.0.“Nein.
Die API von OpenSSL wird durch Asterisk bzw. das PJProject falsch angesteuert.

Eben!

Du willst nicht genau Version X sondern mindestens Version X. Deswegen sind die versionsspezifischen Methoden deprecated – weil Du so nicht in den Genuss einer höheren Versionen kommst. Wenn man ältere Versionen nicht will, bleibt man bei der Auto-Negotiation, schaltet aber die ungewünschten Versionen über Optionen ab.

Alles schön und gut und korrekt und kein Widerspruch. Ist aber bei pjsip 2.8 leider nicht so implementiert. Da ist TLS 1 default (deshalb geht ohne zusätzliche Option zur Telekom auch nichts). Mit sslv23 holst Du Dir mehr ins Haus als nötig. Mit tls1.2 eben nur noch TLS 1.2. (mehr kann openSSL <= 1.0.x eh nicht derzeit). In Bezug auf die gegebene Umsetzung halte ich das daher für die bessere Variante.
Anders sieht es aus, wenn man openSSL >= 1.1.x verwendet. Hier wird dann TLS_method verwendet. Wie man dann aber einzelne SSL-Versionen ausschalten soll über die gegebenen Möglichkeiten (ohne zu patchen) ist mir nicht klar.

Positiv-Beispiel chan_sip:

Tja - hilft hier nicht weiter. In Sachen pjsip ist Asterisk nur Durchlauferhitzer.

Willst Du dasselbe in chan_pjsip erreichen, geht das (bisher) nicht über die Konfigurationsdatei pjsip.conf. Aber es gibt Wege…

Natürlich kriegt man durch eigenes Patchen alles hin. Habe ich nicht explizit geschrieben, weil das bei OSS klar sein sollte! Danke für Deinen Link!

Wie kommst Du darauf?
Ich habe hier Asterisk 13 und OpenSSL 1.1.1 mit TLS 1.3 am Start, sowohl unter chan_sip als auch chan_pjsip.

Weil ich in den derzeitigen Produktionsversionen von Asterisk und pjsip z.B. noch die ganz banale Möglichkeit vermisse, TLS 1.3 explizit zu deaktivieren, falls es da zu Problemen kommen sollte. Ein anderes Beispiel hast Du ja schon selbst geliefert.

Was Du (auch) willst, ist eine durchgehende Mindest-Bitstärke auf allen Ebenen. OpenSSL hat dazu SECLEVEL eingeführt (Diskussion über dessen Zukunft). Dies hängst Du an die Liste der Cipher-Suites an: DEFAULT@SECLEVEL=4. Mit der Deutschen Telekom kommst Du nicht über SECLEVEL=1 hinaus, weil deren DH-Key aktuell nur 1024 bit stark ist. Wenn Du DHE ausschaltest – und damit auf Forward-Secrecy (PFS) verzichtest –, kannst Du maximal SECLEVEL=2 erreichen, weil der Public-Key der Telekom aktuell nur 2048 bit stark ist.

Interessante Info! Wo stelle ich das bei den gegeben Produktionsversionen von Asterisk / pjsip ein?

 

[sonyKatze]

In Bezug auf die gegebene Umsetzung halte ich das daher für die bessere Variante.

Nein. Nochmal: „Applications should use [the version-flexible SSL/TLS methods], and avoid the version-specific methods [which] were deprecated in OpenSSL 1.1.0.“ Du behauptest meine Variante sei deprecated dabei ist es deine – aus gutem Grund. Wenn Du eine Mindest-Version haben willst, dann beteilige Dich an dem Open-Source Project und gebe das als Patch oder wenigstens als Anregung weiter.

Weil ich in den derzeitigen Produktionsversionen von Asterisk und pjsip z.B. noch die ganz banale Möglichkeit vermisse, TLS 1.3 explizit zu deaktivieren, falls es da zu Problemen kommen sollte.

Das kannst Du hinzufügen, wenn Du es willst. Ist nur Copy-and-Paste-Arbeit. Brauche ich nicht, daher mache ich das nicht.

Ein anderes Beispiel hast Du ja schon selbst geliefert.

Welches Beispiel meinst Du?

Wo stelle ich [den SECLEVEL] bei den gegeben Produktionsversionen von Asterisk / pjsip ein?

Steht in dem verlinkten Thread.