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

srynoname

Neuer User
Mitglied seit
15 Okt 2009
Beiträge
27
Punkte für Reaktionen
0
Punkte
0
Hallo,

ich suche einen Anbieter, der SRTP und SIP über TLS / SIPS anbietet. Bisher ist mir nur DUS bekannt, persönlich scheint mir deren Zuverlässigkeit leider nicht die beste zu sein. Daher suche ich nun eien alternative zu DUS / weitere Anbieter mit SRTP und SIPS.
Danke für jeden Tipp :)
 
Deine Frage ist schon etwas älter, aber weil die Tage (April?) ein neuer Anbieter dazugekommen ist:

IPv4:
  • DUStel: secure.dus.net
  • Easybell: sip.easybell.de
  • Easybell: secure.sip.easybell.de [nachträglich ergänzt, siehe unten]
  • Easybell: secure.pbx.easybell.de [nachträglich ergänzt, siehe unten]
  • PeopleFone: sips.peoplefone.ch [nachträglich ergänzt]
  • Plusnet (EnBW, ehemals QSC): secure-sipconnect.ipfonie.de [nachträglich ergänzt, siehe unten]
  • Sipgate Basic: sip.sipgate.de [nachträglich ergänzt, siehe unten]
  • Telekom Deutschland: hpbxsec.deutschland-lan.de
  • Telekom Deutschland: reg.sip-trunk.telekom.de [nachträglich ergänzt, siehe unten]
  • Telekom Deutschland: tel.t-online.de
  • VoIP.ms: paris1.voip.ms (welcher Server?)
IPv6:
  • DUStel: securev6.dus.net
Dual:
  • 1&1: tls-sip.1und1.de
  • Easybell: sip.easybell.de
  • Easybell: secure.sip.easybell.de
  • Easybell: secure.pbx.easybell.de
  • PeopleFone: sips.peoplefone.ch
Zertifikate:
Telekom Deutschland und Plusnet verlangen, dass Dein VoIP/SIP-Telefon den Server über DNS-SRV bzw. DNS-NAPTR auflöst. Für Telekom Deutschland muss Dein VoIP/SIP-Telefon bereits TLS in Version 1.2 beherrschen. Im Gegensatz zu DUStel, muss bei Easybell die Gegenstelle (bzw. der Übergabepunkt) auch sRTP können, denn Easybell leitet Deine Anfrage (SDP) direkt durch und schiebt sich nicht als sRTP-Gateway (Media-Gateway) dazwischen. Bei DUStel wird die Sprache immer verschlüsselt – zwischen Dir und DUStel. Was danach passiert, kann SIP-over-TLS bzw. SDES-sRTP nicht sicherstellen. Die Telekom konnte ich mangels Account noch nicht testen, aber früher verhielt sich das so wie bei Easybell: sRTP wird durchgereicht, also muss die Gegenstelle ebenfalls sRTP beherrschen.

DUStel bietet über IPv6 nur TLS Version 1.0 und keine Cipher-Suite mit Forward-Secrecy (PFS) an. Die Telekom und QVC bieten wenigstens DHE aber nur mit 1024 bit. Den aktuellen Stand kannst Du selbst über die Kommandozeile abfragen, beispielsweise über:
Code:
dig _sips._tcp.tel.t-online.de SRV
openssl s_client -connect s-eps-608.edns.t-ipnet.de:5061
Gefunden habe ich das durch das Change-Log von LANCOM Systems. Deren Firmware-Update letzte Woche enthielt Änderungen wegen SIP-over-TLS mit Telekom Deutschland.
 
Zuletzt bearbeitet:
Moins


Verschlüsselung sollte direkt von Endgerät zu Endgerät gehen.
Da vertraue ich keinen Anbieter.
Leider scheuen sich zu Viele dies in die eigene Hand zu nehmen.

Übrigens: Auch die beliebte Fritz!Box kennt keine SIP-Verschlüsselung.
...weder SIPS noch SRTP und schon gar kein: ZRTP
 
Auch QSC bietet SRTP. Kommt aber wohl nur für Geschäftskunden in Frage.

Grüße.
 
Zentronix, Danke für den Hinweis!
  • QSC: secure-sipconnect.qsc.de
DNS-A(AAA) löst nicht direkt auf, sondern das VoIP/SIP-Telefon muss DNS-SRV können. QSC unterstützt sowohl TLS 1.0 als auch TLS 1.2. Wenn Du QSC auch authentifizieren willst (also sichergehen willst, dass Du wirklich mit QSC verbunden bist), muss das Telefon auch noch den Server-Alternative-Name (SAN) in SSL/TLS-Zertifikaten auswerten können. Viele Telefone können immer noch nur den Common-Name (CN) auswerten. Als Trust-Anchor (CA Zertifikate) kommt aktuell zum Einsatz:
Code:
dig _sips._tcp.secure-sipconnect.qsc.de SRV
openssl s_client -connect secure-duro01.sipconnect.qsc.de:5061
 
Auch die beliebte Fritz!Box kennt keine SIP-Verschlüsselung.
...weder SIPS noch SRTP und schon gar kein: ZRTP
Vor mehreren Jahren gab es mal Firmwares, da war das als Haken vorhanden und wurde bei Anbietern, die dies unterstützen, sichtbar. Aber dann wurde es wieder entfernt. Vielleicht hat der BND sich bei AVM beschwert...

https://www.ip-phone-forum.de/threads/7170-srtp-welche-firmware.154203/

Oder eine noch ältere Antwort vom AVM-Service auf entsprechende Nachfrage:
Antwort von AVM vom 22. Nov. 2005 ist:
SRTP ist im Hause AVM bekannt und auch problemlos per Software in eine bereits heute gekaufte FBF implementierbar.
Voraussetzung hierfür ist jedoch, dass sich SRTP als Verschlüsselungsstandart durchgesetzt hat!

Der jetzige Sicherheitsstand der FBF wurde damit begründet , "dass durch den Verzicht auf Soft- und IP-Phones (es werden
herkömmliche Telefone genutzt) sowie durch die Trennung von LAN und VoIP die FRITZ!Box den aktuellen Empfehlungen
des BSI für eine sichere VoIP-Lösung entspricht. Desweiteren würde Gartner VoIP-Security als eines der fünf am meisten überbewerteten Sicherheitsthemen einstufen".

https://www.ip-phone-forum.de/threads/srtp-verschlüsselung-auf-avm-fon-boxen.73394/

Nachtrag: 13.07.: Grundsätzlich ist bei Verschlüsselung, die Ende zu Ende verlaufen sollte, eine Station in der Mitte (in-the-middle) wie bei dus.net schlecht. Da kann man sich die Verschlüsselung eigentlich auch sparen, obwohl ich dus.net ja erstmal vertraue...

Noch ein Nachtrag zu easybell: Im Gegensatz zu dem, was weiter oben steht, finde ich in deren FAQ diesen Text:
easybell unterstützt SRTP nach RFC 3711.

Bitte beachten Sie, dass derzeit eine Verschlüsselung der RTP-Daten nur von Ihrem Endgerät zu unserer Plattform möglich ist. Bitte konfigurieren Sie SRTP so, dass eine Verschlüsselung mit SRTP optional stattfindet, da eingehende Verbindungen ohne SRTP übermittelt werden. Wenn Sie die Verschlüsselung erzwingen, können eingehende Gespräche nicht entgegen genommen werden.

https://www.easybell.de/hilfe/frage...-bei-voip-die-datenverschluesselung-srtp.html

Also genauso wie bei dus.net. Vielleicht ist etwas anderes auch nicht mehr erlaubt bei uns.
 
Zuletzt bearbeitet:
  • Wow
Reaktionen: FunkReich
Hallo zusammen,

nach meinem Kenntnisstand muss doch der RTP Stream in D stets über den Provider gehen. Der muss doch, gesetzlich vorgegeben, für Polizei, Geimdienste usw. natürlich nach richterlichem Erlass, jederzeit eine Sprachaufzeichnung gewährleisten können. Wenn der Stream zwischen Tln A und B laufen würde, wäre diese Möglichkeit nicht mehr gegeben. Also wird das technisch umgesetzt, was gesetzlich vorgegeben ist.

Mir persönlich ist kein Provider bekannt, der den RTP Stream direkt zwischen den Teilnehmern "vermittelt".

Gruß
Michael
 
Zuletzt bearbeitet:
Mir persönlich ist kein Provider bekannt, der den RTP Stream direkt zwischen den Teilnehmern "vermittelt".

Geht auch nicht bei vermittlung ins PSTN. Oder gibts inzwischen nur noch VoIP carrier interconnects?
 
Hallo @woprr,

mit PSTN meist Du das "alte ISDN Netz"?

Spielt doch keine Rolle ob ich mich im VoIP Netz befinde, VoIP => PSTN, PSTN => VoIP oder was weiß ich welche Kombination noch möglich ist. Fakt ist doch, dass der SIP Provider festlegt über welchen Weg der (s)RTP Stream läuft. Und wenn der Staat eine "Abhörmöglichkeit" gesetztlich vorgibt, wird der (s)RTP Stream mit Sicherheit über die Mediengateways des Providers laufen. (Mit fällt im Moment nicht der Name der NGN Komponente ein, die das macht).

Gruß
Michael
 
Zuletzt bearbeitet:
  • Like
Reaktionen: FunkReich
Zur Info:

Der Provider Easybell bietet neuerdings sowohl
  • Punkt-zu-Punkt-Verschlüsselung (Anrufer bis zu Provider, falls die Gegenstelle kein SRTP unterstützt)
  • falsche Ende-zu-Ende-Verschlüsselung (Anrufer zu Provider, dort Entschlüsselung, anschließend wieder verschlüsselt von Provider zu Angerufenem)

Hierzu ein interessanter Blogeintrag auf einem Blog von easybell:

Easybell-Blog schrieb:
Die SIPS/SRTP-Verfahren dienen also dazu, Sprache zwischen einem Provider und einem VoIP-fähigen Endgerät zu verschlüsseln. Die Verschlüsselung der Sprachdaten erfolgt durch SRTP und die der Signaldaten durch SIPS. Hier handelt es sich nicht um eine End-to-End-Verschlüsselung, da im Session Border Controller (SBC) des Anbieters die Daten unverschlüsselt verarbeitet werden. „Der Grund: Unverschlüsselte Schnittstellen müssen für Bedarfsträger wie Zoll oder Polizei bereitgehalten werden. Dazu sind die Provider gesetzlich verpflichtet“, so Johannes.

Was kann ich denn nun tun, wenn ich eine "echte" Ende-zu-Ende-Verschlüsselung erreichen möchte? Wie sieht es mit ZRTP aus, da hier ja durch den Diffie-Hellmann-Schlüsselaustausch theoretisch eine echte Absicherung ermöglicht werden könnte?
 
  • Wow
Reaktionen: FunkReich
Habe gerade interessante ZRTP-Unsicherheitsthreads in diversen Foren gelesen.
Es wird alternativ browserbasierendes verschlüsseltes PeerToPeer WebRTC vorgeschlagen ...
 
Seit kurzem unterstützt easybell auch die lange ersehnte Punkt-zu-Punkt-Verschlüsselung. Früher konnte eine Verschlüsselung nur dann stattfinden, wenn beide Gesprächspartner ein SRTP-fähiges Telefon besaßen (= Ende-zu-Ende-Verschlüsselung). Mittlerweile wird aber auch die Verbindung vom Anrufer hin zu den easybell-Servern verschlüsselt, sofern der Gesprächspartner kein kompatibles Telefon nutzt (= Punkt-zu-Punkt-Verschlüsselung).
Wo hast Du das gelesen bzw. davon erfahren? Bei mir will das nicht zu allen Zielen klappen.
ich bin immer noch nicht sicher, wie sicher eigentlich [SIP-over-TLS mit SDES-sRTP] wirklich [ist]
Dabei kommt AES-128 zum Einsatz, für das ich bisher keine (erfolgreichen) Angriffe kenne. Aber wie Du schreibst, eine VPN-Verbindung ist auch eine Alternative.
Habe gerade interessante ZRTP-Unsicherheitsthreads in diversen Foren gelesen …
Kannst Du diese Threads mal verlinken? Ich kenne bisher nur Implementierungsfehler der Hersteller, nicht im Vorgehen selbst. Aber jene Hersteller waren bemüht ihre Fehler zu beheben (Quelle mit Video).
… alternativ browserbasierendes verschlüsseltes PeerToPeer WebRTC
Meinst Du DTLS-sRTP? Dabei bist Du leider nicht viel weiter, weil die aktuellen Implementierungen nicht die Gegenstellen authentifizieren. Dadurch kann sich immer noch irgendwer dazwischen einklinken.
Mir persönlich ist kein Provider bekannt, der den RTP Stream direkt zwischen den Teilnehmern "vermittelt".
Aber dank All-IP ist das die Zukunft (3GPP IMS). Auch scheuen immer mehr Festnetz-Provider die teuren Umkonvertierungen. Mit 1&1 hatte ich bereits einmal eine direkte Verbindung zwischen meinem Mobiltelefon im O₂-Netz (eingebucht über die WLAN-Telefonie).
[Mit] eine[r] Station in der Mitte ([Man-]in-the-middle) […] kann man sich die Verschlüsselung eigentlich auch sparen
Die Frage ist, gegen wen man sich schützen will. SIP-over-TLS mit SDES-sRTP oder DTLS-sRTP schützen Dich davor, dass Dich auf dem Weg von Dir bis zu Deinem Provider jemand abhört. Wenn Du in einem freien WLAN bist, nicht weißt wie das Internet-Routing läuft oder Du daheim einen Informatiker als Lebenspartner sitzen hast, dann schauen die erstmal in die Röhre bzw. hören nur Zahlensalat.
Vielleicht hat der BND sich bei AVM [über SDES-sRTP] beschwert.
Die Konkurrenz bietet weiterhin SIP-over-TLS, SDES-sRTP und vereinzelt auch DTLS-SRTP bzw. ZRTP an. Selbst Unternehmen mit Sitz in Deutschland wie Auerswald, LANCOM Systems, Gigaset (ehemals Siemens Consumer), Unify (ehemals Siemens Enterprise) und Snom bieten das.
Vielleicht ist etwas anderes auch nicht mehr erlaubt bei uns.
Das Problem ist die Technologie. Außer ZRTP gibt es bisher nichts am Markt, was durch die Provider hindurch funktionieren würde. koyaanisqatsi hat es bereits beschrieben: Die Alternative ist ohne Provider sein Gegenüber direkt anzurufen, beispielsweise über dessen SIP-URI. Dann hat man auch mittels dem „einfachen“ SIP-over-TLS mit SDES-sRTP faktisch eine Ende-zu-Ende-Verschlüsselung. ZRTP bietet dann zusätzlich den Vorteil, dass man nicht nur das Endgerät des Gegenübers sondern auch seinen Gesprächspartner selbst – also den Menschen – authentifiziert.
keine einzige sichere Kommunikationsmethode per Telefon?
Wenn Du die Gegenstelle sicher authentifizieren kannst, dann schon. ZRTP, DTLS-sRTP und auch SDES-sRTP bieten das, wenn richtig eingesetzt:
  • ZRTP: richtig implementiert
  • DTLS-sRTP: mit Signaturen ala S/MIME (Zukunftsmusik)
  • SDES-sRTP: wenn Du alle Proxys dazwischen kontrollierst bzw. kein Proxy hast
Außerdem hast Du noch die Alternative über VPN. Aber wie geschildert, es geht darum Gegenüber wem Du Dich absichern willst/musst. Soll jeder im Heimnetz bzw. im WLAN Dein Telefon mitlauschen können? Dann reicht SIP-over-TLS mit SDES-sRTP.
 
Zuletzt bearbeitet:
Wo hast Du das gelesen bzw. davon erfahren?

Hier und hier.

"Bitte beachten Sie, dass derzeit eine Verschlüsselung der RTP-Daten nur von Ihrem Endgerät zu unserer Plattform möglich ist. Bitte konfigurieren Sie SRTP so, dass eine Verschlüsselung mit SRTP optional stattfindet, da eingehende Verbindungen ohne SRTP übermittelt werden. Wenn Sie die Verschlüsselung erzwingen, können eingehende Gespräche nicht entgegen genommen werden."

=> Warum kann ich dann bei einer Snom M700 mit explizit "optional" eingestellter SRTP-Verschlüsselung trotzdem keine Anrufe tätigen oder annehmen?

Und:

"Durch SIPS/SRTP ist die Strecke von einem Gesprächspartner bis easybell sicher. Für Sie als Geschäftskunde bedeutet das: Wenn Sie Ihre Firmentelefonie über easybell führen, so sind Ihre Gesprächsdaten sicher.

Leider gilt das nur innerhalb der Netzgrenze des jeweiligen SIP Trunk-Providers. Das heißt, dass beispielsweise Telefonate ins Mobilnetz bei der Netzgrenze entschlüsselt werden, da im Mobilfunk (wie auch bei ISDN oder Primärmultiplex) die Kommunikation unverschlüsselt stattfindet, die Metadaten also von jedem, der firm genug ist, „gelesen“ werden können."
 
@sonyKatze Und wie stellst Du Dir vor, wie ein Telefonieanbieter in Deutschland die gesetztlich geforderte "Abhörmögllichkeit" (natürlich stets nach richterlichem Beschluss) durchsetzen soll wenn der RTP Stream zwischen Teilnehmer A und B fließt?
 
Niemand verbietet einem Provider die Verschlüsselung vom Kunden bis zu seinem System und niemand verbietet (bisher) einem Kunden, sich direkt mit der Gegenstelle "ins Benehmen zu setzen" und dabei SRTP auszuhandeln.

Was der Provider bei einer Überwachungsmaßnahme zu übermitteln hat, ist klar geregelt und z.B. hier: https://www.bundesnetzagentur.de/Sh....0 pdf deutsch.pdf?__blob=publicationFile&v=1 nachzulesen. Der Punkt 5.5 im Anlage H (S. 117) ist da ziemlich eindeutig - und der Kommentar in der rechten Spalte zeigt auch auf, daß ein Provider nur den Session-Key bereitstellen muß, wenn der über seine Infrastruktur ausgetauscht wurde (ansonsten hat er ihn ohnehin nicht).

Das heißt, es gibt derzeit faktisch keine einzige sichere Kommunikationsmethode per Telefon?
Das ist ja eine vollkommen neue Erkenntnis: https://www.youtube.com/watch?v=4zUZwih19R0&feature=youtu.be&t=7

Inwieweit hat sich die Situation denn jetzt für die Kunden eines Providers dadurch verschlechtert, daß dieser auf VoIP setzt anstelle der "klassischen" Telefonie? Genau ... gar nicht. Die Ausleitung des Verkehrs hat (im Rahmen einer TKÜ-Maßnahme) bei leitungs- oder paketvermittelten Verbindungen genauso zu erfolgen, wie bei SIP/RTP - nur ist da schon mal gar keine Verschlüsselung möglich. Außer ggf. ein "scrambler" auf beiden Seiten, der als Zusatzgerät die Audio-Daten verschlüsselt - was bei RTP immer noch (bei verlustloser Kompression) machbar wäre.

Eine Verschlüsselung kann trotzdem noch sinnvoll sein ... denn im Gegensatz zu einer vollkommen unverschlüsselten Verbindung (wo dann sogar an beiden Endpunkten und bei jedem am Transport beteiligten Router ein einfacher Paketmitschnitt ausreicht, um ein Gespräch zu extrahieren), kann dann das Risiko des "eavesdropping" auf die beiden Endpunkte beschränkt werden. Das ist ja auch der Grund, warum die Schlapphüte immer wieder von "Quellen-TKÜ" träumen (aka Bundestrojaner), weil sie dann die noch unverschlüsselte Kommunikation abfangen können und auch in Ende-zu-Ende-verschlüsselte Verbindungen "hineinhorchen" könnten.

Deshalb ist auch die "These" im anderen Thread:
zwischenzeitlich sollte dem geneigten Leser hinreichend bekannt sein, dass deutschen Providern eine echte Ende-zu-Ende-Verschlüsselung aufgrund der gesetzlich vorgeschriebenen Möglichkeit auf Bestandsdatenabfrage grundsätzlich verwehrt wird.
eigentlich Quatsch ... die "deutschen Provider" können auch nicht verhindern, wenn die Kunden Ende-zu-Ende-verschlüsselt telefonieren. Das Einzige, was tatsächlich stimmt, ist das fehlende (bzw. nicht wirklich erkennbare) Bemühen der Provider, auch über Interconnects hinweg eine Verschlüsselung zu realisieren.

Außerdem liegen die "Bestandsdaten" (§111 Abs. 1 TKG) ohnehin immer vor, was soll das also mit der "gesetzlich vorgeschriebenen Möglichkeit auf Bestandsdatenabfrage" zu tun haben, ob ein Provider Verschlüsselung anbietet oder nicht?

Das kann dann aber tatsächlich auch noch damit zusammenhängen, daß bei "lawful interception" kein anderes Routing erfolgen darf, wenn der Belauschte (aus Sicherheitsperspektive kann man auch schreiben: der Angegriffene) nicht mißtrauisch werden soll und das soll auch nach der TR TKÜV verhindert werden:
Soll die Überwachung der Nutzinformation durch ein spezielles Routing, z.B. zu einem zentralen Netzknoten erfolgen, muss besonders darauf geachtet werden, dass dies gemäß § 5 Abs. 4 TKÜV nicht durch die VoIP-Teilnehmer festgestellt werden kann.
Wenn zuvor bei Telefonaten per "direct media" eine Ende-zu-Ende-Verbindung mit Verschlüsselung ausgehandelt wurde und plötzlich endet die verschlüsselte Verbindung irgendwo beim Provider, ist das natürlich zumindest mal ein Fingerzeig.

Aber das ist bei RTP ohnehin alles nicht ganz so einfach, wie es manchmal den Eindruck macht ... man braucht nur mal an die unterschiedlichen Paketgrößen bei RTP denken, die von den Gateways unterschiedlicher Provider "aufgerufen" werden und es gibt auch so schon genug Gründe, warum eine SIP/RTP-Verbindung zwischen zwei Teilnehmern bei unterschiedlichen Providern in die Hose gehen kann.

Da braucht es die zusätzliche Verschlüsselung gar nicht mehr und insofern kann man die Provider auch irgendwo verstehen, wenn sie nur da tatsächlich auf Verschlüsselung setzen (so wie easybell im eigenen Netz), wo sie auch alle Stationen auf dem Weg "unter Kontrolle" haben. Solange der Provider gar nicht der Peer bei einer Verbindung ist, die im Rahmen einer Überwachungsmaßnahme komplett "ausgeleitet" (bzw. "kopiert") wird, kann er auch die Informationen gemäß Anlage H, Punkt 5.5 nicht bereitstellen.

Wer tatsächlich vertraulich kommunizieren will, greift dann eben zu anderen Methoden (z.B. einem Whatsapp-Call, wenn man daran glaubt, daß dabei die Ende-zu-Ende-Verschlüsselung greift und bis das Gegenteil bewiesen wurde - https://www.whatsapp.com/security) oder direkter Kommunikation (ob per SRTP oder VPN, ist dabei egal). Telefonie ist (und war schon immer) abhörbar, SMS genauso (Stichwort SS7 und was man damit alles anstellen kann, um selbst mTANs abzufangen) und auch bei E-Mail ist der Vergleich mit der Postkarte ja offensichtlich.

Wer auf die Idee kommt, mit einem dieser Medien wirklich vertrauliche Informationen zu übermitteln, dem ist nicht mehr zu helfen ... nicht ganz umsonst machen diverse Firmen (z.B. secunet AG, die m.W. auch für die VPN-Boxen nach TR TKÜV zuständig sind) auf diesem Gebiet ihr Geschäft und von den "Krypto-Handys" hat sicherlich auch schon jeder mal etwas gelesen.

Wie weit diese Kenntnis jetzt tatsächlich die TKÜ "ausbremst", kann sich jeder selbst ausrechnen ... am Ende werden bei solchen Maßnahmen nur die "Ahnungslosen" oder die "Unvorsichtigen" tatsächlich in einer Weise kommunizieren, die sich "belastend" auswirken kann.

Die sogenannten "Meta-Daten" (also wer, wann, mit wem, wie lange kommuniziert hat - IRI im Jargon der TR und in §7 TKÜV aufgeführt) sind auch bei SRTP weiterhin zugänglich (weil sie im SIP-Protokoll vorliegen) und können auch nur max. zwischen Provider und Kunde verschlüsselt werden, wenn man SIPS verwendet (wobei der Provider sie dann bei einer TKÜ-Maßnahme wieder ausleiten muß - und kann), weil irgendjemand das ja mal "entziffern" muß, wohin das VoIP-Telefonat nun eigentlich gehen soll.

-------------------------------------------------------------------------------------------------

Und um noch mal zu den "Bestandsdaten" zurückzukommen ... schaut man sich Dienste wie posteo.de an, wundert man sich aufgrund der ziemlich weitreichenden "Schnüffelbefugnisse" in D vielleicht, wie man dort ein Postfach anbieten kann, für das mit
Anmeldung ohne Angabe persönlicher Daten
geworben wird, aber auch das steht eigentlich im §111 TKG:
(2) Die Verpflichtung zur unverzüglichen Speicherung nach Absatz 1 Satz 1 gilt hinsichtlich der Daten nach Absatz 1 Satz 1 Nummer 1 und 2 entsprechend für denjenigen, der geschäftsmäßig einen öffentlich zugänglichen Dienst der elektronischen Post erbringt und dabei Daten nach Absatz 1 Satz 1 Nummer 1 und 2 erhebt, wobei an die Stelle der Daten nach Absatz 1 Satz 1 Nummer 1 die Kennungen der elektronischen Postfächer und an die Stelle des Anschlussinhabers nach Absatz 1 Satz 1 Nummer 2 der Inhaber des elektronischen Postfachs tritt.
Entscheidend sollte hier das "und dabei Daten [...] erhebt" sein ... was der Provider (bei E-Mail geht das, bei Telefonie seit einiger Zeit nicht mehr, seitdem die Authentifizierungspflicht auch bei Prepaid-SIMs eingeführt wurde) nicht an Daten erhebt bzw. erhoben hat, kann er auch nicht weitergeben, wenn er darüber Auskunft erteilen soll.

Und das ist eben bei posteo.de dann "Firmenphilosophie" (https://posteo.de/site/datenschutz/) ... es werden einfach keine Bestandsdaten erhoben und gespeichert. Es geht also (zumindest bei E-Mail) auch anders ... wenn sich eine Firma das "traut".

Die immer wieder gerne genommene "Ausrede", die deutschen Gesetze ließen einem gar keine andere Wahl, ist auch immer "leicht gelogen" - die meisten dieser Anbieter nehmen halt nur den Schutz der Daten ihrer Kunden lange nicht so wichtig, wie die diversen "Schweinereien", die sie selbst gerne mit solchen Daten machen ... und dafür müssen sie diese Daten eben erst mal erheben und geraten damit automatisch in die Speicher- und Auskunftspflicht. Das (also die "bequeme Ausrede", man könne ja gar nicht anders) dürfte am Ende auch für die Frage der Verschlüsselung von RTP-Verbindungen gelten ...
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.