Am vergangengen Freitag, dem 23. Juli, wurde die erste Beta der Asterisk Version 1.8 veröffentlicht. Die Featureliste liest sich ganz gut: Secure RTP, IPv6 Support, Connected Party Identification Support und noch einiges mehr. Die Secure RTP (SRTP) Funktionalität lag jetzt einige Jahre im Issue-Tracker von Digium herum und die Patches wurden ab und wann mal aktualisiert, jetzt hat es die Funktion aber endlich in den gepflegten Codezweig gebracht. Die 1.8 Funktionen waren jetzt schon einige Wochen angekündigt, und ich hatte mir den Trunk bzw. die Version 1.8 in den letzten Tagen etwas genauer angeschaut.
Leider mangelt es noch etwas an Dokumentation, wie man die Zertifikate für den TLS Support erzeugen muss. Funktional muss mindestens ein Zertifikat mit unverschlüsseltem Private Key in der bereitgestellten Datei vorhanden sein. Alle Checks auf Certificate-Chain und von Clients gezeigten Zertifikaten können deaktiviert werden, was für einen ersten Test die Sache zunächst erleichert. Mit einem solchen Setup ist es dann möglich TLS Verbindungen zum Asterisk aufbauen zu lassen. Hierzu muss in der SIP-Konfiguration, sip.conf, generell oder in der Peer-Konfiguration der Transport-Modus auf transport=tls eingestellt werden.
Je nach SIP-Client benötigt dieser auch ein explizit vorgegebenes Zertifikat, z. B. beim SFLphone für Linux ist dies so. Andere Clients sind auch ohne vorgegebenes Client-Zertifikat zufrieden, z. B. das Snom 370, oder wollen zumindest noch das Root-CA-Zertifikat zum Prüfen des Server-Zertifikate, so beim Counterpath Bria Softphone.
Soweit die Verschlüsselung der Signalisierung, die auch schon in Asterisk 1.6 verfügbar war. Den Zwang zur Nutzung von SRTP kann man über den sip.conf Parameter encryption=yes in der Peer-Konfiguration aktivieren. Die Softphones Bria und SFLphone arbeiten sofort mit verschlüsseltem Medienstrom, eine Auswahl von weiteren Parameter gibt es in beiden Programmen nicht.
sip.conf:
[user1]
...
transport=tls
encryption=yes
Das Snom 370 hat leider nicht direkt mit gearbeitet, wie ich es mir gewünscht hatte. Die Signalisierung fand zwar statt, aber es wurde sofort die Verbindung beendet. Die Lösung brachte die Modifikation eines Patch, auf den im Digium-Bugtracker schon vor einigen Tagen hingewiesen wurde.
--- asterisk-1.8.0-beta1-orig/res/res_srtp.c 2010-07-20 21:35:02.000000000 +0200
+++ asterisk-1.8.0-beta1/res/res_srtp.c 2010-07-25 15:02:50.353081700 +0200
@@ -304,6 +304,7 @@
if (res != err_status_ok && res != err_status_replay_fail ) {
ast_debug(1, "SRTP unprotect: %sn", srtp_errstr(res));
+ errno = EAGAIN;
return -1;
}
Danach war die Verbindung bei ankommenden Gesprächen möglich, das Schloss im Display war zu und somit waren TLS und SRTP aktiv. Die abgehende Verbindung blieb allerdings stumm und die Debug-Nachrichten in der Asterisk-Konsole zeigen auch einige Fehler. Die Lösung brachte eine Änderung der RTP-Konfigration im Snom 370. Das SRTP Auth-tag musste von AES-32 auf AES-80 gestellt werden. Mit diesem Parameter wird die verwendete Crypto-Suite ausgewählt. Ein Blick in verschiedene SIP-Dialoge im Asterisk zeigte auch, dass alle anderen Clients ebenfalls die Suite verwenden, welche Snom mit AES-80 bezeichnet.
Leider habe ich keine Stelle in der Asterisk-Konsole gefunden, wo ich sehen konnte, ob die Verschlüsselung des Medienstrom tatsächlich aktiv ist. Hier war jeweils ein Blick auf das Snom Telefon oder in die Softclients notwendig. Ob eine TLS-Signalisierung aktiv ist, kann dagegen leicht nachgeschaut werden.
Kurzes Fazit an dieser Stelle, es funktioniert. Die Asterisk Version 1.8 deutet sich als sehr interessant ab. In der nächsten Zeit werde ich mal ein paar tiefere Tests fahren, ob die Verschlüsselung auch verschiedene komplexe Szenarien verträgt. Bisher waren die Testcalls etwas einfach (Voiceprompt vorlesen, Anruf zwischen zwei Clients) und entsprechen noch nicht den Szenarien bei einer TK-Anlage im echten Einsatz.
Kommentar hinterlassen