In der aktuellen Beta-Version 1.15beta ist eine Unterstützung für SRTP eingebaut.
Bei den Konfigurationsdaten kann man über den Codec-Button auch SRTP ein- und ausschalten.
Mit dem VoIP-Provider dus.net konnte ich ein- und ausgehende Rufe verschlüsselt aufbauen.
Die verschlüsselte Form von RTCP ist derzeit noch nicht implementiert - aber das wird hoffentlich auch bald funktionieren.

Der Verbindungsaufbau (SIP) erfolgt weiterhin über UDP, eine Unterstützung für TLS wird es nicht so bald geben. Die Konsequenz daraus ist, dass der Schlüsselaustausch für SRTP mehr oder weniger im Klartext erfolgt - es ist also noch nichts wirklich sicher, aber schon mal ein Anfang.

Bitte probiert es mal mit diversen Providern aus. Mich würde interessieren, welche Provider derzeit SRTP unterstützen.

Der einzige mir bekannte Provider mit SRTP-Unterstützung ist dus.net. Es wird dann auch das entsprechendes Symbol angezeigt - derzeit etwas "unfertig"...

Ist denn das überhaupt wichtig, dass der Provider auch SRTP unterstützt? Das SIP Protokoll baut die verbindung doch weiterhin unverschlüsselt auf... und in die "nutzdaten" wird der Provider doch net reinschauen    ... das spielt doch dann erst eine Rolle, wenn ein Gateway genutzt wird, also über PSTN ...oder nicht??? 





JB wrote on 04. Sep 2006 at 19:29:


...das war nicht SIPgate, sondern SIPbase 

hmm... bin jetzt zurück vom Winterurlaub, aber ich raff das immer noch nicht! Wenn das Gespräch zwischen bspw. 2 Softphones (oder Hardwaregeräte) mit SRTP unterstützung stattfindet, dan wird per SIP vom Provider vermittelt wo der Sender den Empfänger erreicht, das SDP dient doch dann zur aushandliung zwischen den teilnehmern und die unterstützen beide SRTP???

Oder mischt das SDP schon während der Teilnehmervermittlung dazwischen? 

Quote:


Nicht das ich dir nicht glaube, aber hast du zufällig ein paar Quellen wo ich das nochmal nachlesen kann?

Wie kann ich dann rausfinden bei welchem Provider SRTP zwischen reinen Internetgesprächen einsetzbar ist? Ich weiss derweil nur von dus.net und SipBase das die SRTP unterstützen (sowi weitere die das noch dieses Jahr bringen wollen), weil die das auch auf ihrer Website bekannt machen (die bieten beide auch STUN-Server an).

Ich hab da noch nicht nachgeschaut, aber weisst du zufällig aus dem stehgreif, ob ich auch SRTP einsetzten kann wenn der Verbindungsaufbau über IAX/IAX2 erfolgt? Es gibt einige Provider die zusätzlich zu SIP auch IAX implementiert haben oder dies noch tun wollen, da mit diesem Protokoll die NATs einfacher umgangen werden können (bspw. Portunity die einen IAX-Clienten entwickeln oder blueSIP)!? Jetzt kommt mir natürlich der gedanke das sie dies auch gerade wegen eine mögliche Verschlüsselung tun könnten...

Wie Sipbase macht SIPS mit? Ich dachte bisher macht das keiner... in den FAQ habe ich auch "nur" folgendes gefunden:

ZITAT SIBASE FAQ:
"...
Sind die Gespräche abhörsicher?
Ja, wenn Sie dies wüschen. Sie haben die Möglichkeit eine gesicherte SRTP-Verbindung direkt zwischen den Telefonen aufzubauen. Unternehmen bieten wir zusätzlich die Möglichkeit Ihre Gespräche durch einen geschützten VPN-Tunnel abhörsicher zu übertragen. Diese Verbindungen sind somit sicherer als analoge oder ISDN Gesprächsverbindungen..."


EDIT:
ach jo, das erklärt auch das Zertifikat, das zum Download zur verfügung steht 

Zitat: "Immer mehr Provider gehen dazu über, die Audioströme ebenfalls über sich laufen zu lassen... "

Ich habs jetzt gefunden, das Codewort lautet: "SessionBorderControl"

Da gibts auch ein kurzes Skript von der BNA (quelle hab ich jetzt leider nicht mehr) ist aber prinzipiell das gleiche wie du oben beschrieben hattest, der RTP Strom läuft nicht mehr direkt von Nutzer zu Nutzer, sondern wird über ein SessionBorderControlGateway von dem eigenen Provider an den Ziel-Provider übergeben, der dann das Gespräch ans Ziel schickt, damit wird unter anderem verhindert, das der Caller die IP von seinem Gegenüber bekommt.

Sehr Interessant das ganze und hier nochmals meinen Dank an dich wegen der tollen anregung mal in die richtung zu schauen 

Gruß

hmm... du meinst also, das das SBCG direkt in der Antwort auf Invite eine zusätzliche Angabe für den Clienten mit sich trägt die ihm seine öffentliche Adresse mitteilt? Ich hab gerad mal bei Broadnet geschaut, von denen weiss ich das die SBCG einsetzten, die bieten auch gar kein STUN an ... also müsste das ja irgendwie so funktionieren.... 

Hauptgründe liegen für mich dennoch nicht darin die NAT zu umgehen, viel mehr kommen hier die Richtlinien der BNA ins Spiel, denn dadurch das der RTP Strom jetzt über den Provider läuft kann dieser in seinem IP-Netz auch sicherstellen das er sich im Bezug auf das Fernmeldegeheimnis richtig verhält, auch kann dieser jetzt Fangschaltungen durchführen etc. wie die Richtlinien bei VoIP genau aussehen weiss ich aber noch nicht, hatte bei der BNA aber mal grob reingeschaut und das aufgefangen...

Das mit der NAT ist wohl eher nur ein nebeneffekt, aber wenn wir schon mal bei dem Thema NAT/STUN sind, ich kenn mich da nicht so gut aus, was mir aber aufgefallen ist, einige Provider geben an, dass für VoIP auf jeden fall Ports auf dem Router duchgeschaltet werden müssen, aber ist das nicht unfug wenn die gleichzeitig einen STUN Server bereitstellen? Ich meine, der STUN Server ist doch dafür da, dass die NAT umgangnen wird und nicht das ich mir in meinem Heimnetz löcher bohre!?!? übrigens findet man zum Thema STUN auch nicht so viel im Netz wie ich gerne hätte