Anbieter mit SRTP und TLS/SIPS außer DUS?

sonyKatze

Aktives Mitglied
Mitglied seit
6 Aug 2009
Beiträge
808
Punkte für Reaktionen
62
Punkte
28
Easybell bietet parallel eine neue Adresse: secure.sip.easybell.de (DigiCert Global).
Angeblich macht die (wenigstens abgehend) immer SDES-sRTP. Konnte das schon jemand testen?
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
129
Punkte für Reaktionen
9
Punkte
18
Geht schon lange auf die beschriebene Art und Weise bei easybell (auch mit sip.eaybell.de tcp/5061). Was ich bisher gesehen habe (wenn ich geschaut habe - ist ja nicht mehr so einfach mit SIPS - ob das also immer so ist, vermag ich nicht zu sagen):

Outbound: es wird zumindest ein crypto-key im SDP mitgeliefert.
Inbound: kein crypto-key im Invite

Test erfolgte Inbound mit einem vollverschlüsselten Call von der Telekom aus. D.h. mit hoher Wahrscheinlichkeit, dass die Telekom auf ihrer Seite entschlüsselt und unverschlüsselt übergibt.

Ich habe mir mal den Spaß gemacht, und via Telekom meinen eigenen Telekom-Account angerufen. Wenn hier Ende zu Ende verschlüsselt werden würde (was technisch problemlos möglich wäre), würde ich erwarten, dass genau zwei Keys zum Einsatz kommen (Asterisk ist hier sowohl Sender als auch Empfänger - sieht also beide Enden).
Dem ist nicht der Fall - jeder Leg hat einen individuellen Key. Also terminiert die Telekom grundsätzlich jeden Leg und muss daher entschlüsseln und neu verschlüsseln für die andere Seite (kein Transcoding relevant gewesen!).

Alles auf Basis Asterisk 16.x ausgeführt (mit Mediasec-Patch für Telekom).

Will man durchgehend verschlüsselt mit SIPS / RTPS kommunizieren, muss man sich also eine eigene geeignete Infrastruktur / Lösung aufbauen und es darf auf der ganzen Strecke kein ungeeigneter Provider involviert sein. Fraglich, in wie weit das realistisch möglich ist, ohne irgendwelche andere Verbindungsspuren zu hinterlassen.
 

Meester Proper

Mitglied
Mitglied seit
24 Mai 2014
Beiträge
211
Punkte für Reaktionen
19
Punkte
18
Ein durchgehend verschlüsselte Verbindung ist schon aufgrund der Legal-Interception Anforderungen nicht möglich.
Die nächste Frage ist, wenn man eine Ende-zu-Ende verschlüsselte Verbindung zulassen würde, was würde man mit Nicht-verschlüsselten Gesprächspartnern machen? Würden die unverschlüsselte Gegenstelle SRTP erst einmal mit SIP488 abweisen und der Anrufer müsste erneut (unverschlüsselt) probieren?

Die Lösung mit zwei m-lines, also RTP und SRTP parallel, meine ich auch als impraktikabel gehört zu haben.
Zumal es dann auch schwierig umzusetzen wäre bei SRTP auch TLS vorauszusetzen.
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
129
Punkte für Reaktionen
9
Punkte
18
Ein durchgehend verschlüsselte Verbindung ist schon aufgrund der Legal-Interception Anforderungen nicht möglich.
Aber nur, wenn eine formal korrekte Anordnung vorliegt. So werden mal wieder alle unter grundsätzlichen Generalverdacht gestellt.

Die nächste Frage ist, wenn man eine Ende-zu-Ende verschlüsselte Verbindung zulassen würde, was würde man mit Nicht-verschlüsselten Gesprächspartnern machen? Würden die unverschlüsselte Gegenstelle SRTP erst einmal mit SIP488 abweisen und der Anrufer müsste erneut (unverschlüsselt) probieren?
Durchaus berechtigt - aber bei der Telekom wg. Mediasec ja zumindest bei rein internen calls (= von Telekom-Kunde zu Telekom-Kunde) theoretisch einfacher lösbar, weil der Server aufgrund des REGISTER bereits weiß, ob einer Verschlüsselung beherrscht oder nicht. Auf Clientseite eben so einstellen, wie bei easybell (optimistic srtp). Irgendwie macht es nur bedingt Sinn, nur einen Teilabschnitt zu verschlüsseln.

Die Lösung mit zwei m-lines, also RTP und SRTP parallel, meine ich auch als impraktikabel gehört zu haben.
Ist das nicht die optimistic-Variante (asterisk)? Funktioniert zumindest mit easybell.

Zumal es dann auch schwierig umzusetzen wäre bei SRTP auch TLS vorauszusetzen.
SRTP mit SIP macht keinen Sinn. Ohne TLS wird grundsätzlich nicht verschlüsselt - so würde ich das einstellen.
 

Meester Proper

Mitglied
Mitglied seit
24 Mai 2014
Beiträge
211
Punkte für Reaktionen
19
Punkte
18
Aber nur, wenn eine formal korrekte Anordnung vorliegt. So werden mal wieder alle unter grundsätzlichen Generalverdacht gestellt.
Die Frage ist natürlich, ob die Schnittstellenvereinbarungen zu anderen Netzbetreibern überhaupt SRTP erlauben würden.

Ist das nicht die optimistic-Variante (asterisk)? Funktioniert zumindest mit easybell.
Die Unterstützung von Multimedia-Calls (mehr als eine m-line) ist nicht bei allen SIP-Implementierungen durchgehend korrekt (implementiert) - bspw. Stichwort Anzahl der m-lines innerhalb der SDP Offer/Answer eines Calls.

SRTP mit SIP macht keinen Sinn. Ohne TLS wird grundsätzlich nicht verschlüsselt - so würde ich das einstellen.
So ist bei der Telekom bspw. der Fall.
 

sonyKatze

Aktives Mitglied
Mitglied seit
6 Aug 2009
Beiträge
808
Punkte für Reaktionen
62
Punkte
28
Sipgate ist (nun) auch dabei. Auch wenn es offiziell nicht einmal geplant ist, konnte ich mit meinem Sipgate Basic Plus über SIP-over-TLS und SDES-sRTP mit einem Vodafone Mobilfunk-Anschluß telefonieren [Bearbeitet: geht nicht mit IPv4, nur über IPv6]. Als Server kam „sipgate.de“ zum Einsatz. Das Root-Certificate ist Golbal Sign R3. Nachteil: (Noch) kein Forward-Secrecy (PFS) und auch kein DANE/TLSA wie beispielsweise bei DUStel. Sipgate hat auch noch andere Server wie tls01.sipgate.de und tls02.sipgate.de, die mit AddTrust External abgesichert sind. Auch hat Sipgate noch andere Produkte. Aber die habe ich alle noch nicht getestet. Auch habe ich nur meinen Sangoma Asterisk 13 getestet, und noch nicht überprüft, ob die aktuelle FRITZ!Labor damit klar kommt.
 
Zuletzt bearbeitet:

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
234,375
Beiträge
2,045,636
Mitglieder
354,039
Neuestes Mitglied
Gehirnakrobat