SIPS — verschlüsselte SIP-Signalisierung nach RFC 5630.
Der CodeB Souveräne SBC terminiert SIP über TLS auf eigenen Ports für Trunk- und öffentlichen Listener-Verkehr. Jeder TLS-Handshake wählt das mandanteneigene Zertifikat per SNI aus dem vorhandenen Windows-Zertifikatsspeicher — ein Let’s-Encrypt-Zertifikat pro Mandant, keine SAN-Liste zu pflegen. ACL, Auto-Blacklist und Observability werden mit dem restlichen Bridge-Stack geteilt.
Mandanten anlegenZwei TLS-Ports parallel zur UDP-Topologie
Die Aktivierung von SIPS auf einem CodeB-Mandanten strukturiert das Routing nicht um. Die zwei TLS-Listener liegen neben den vorhandenen UDP-Listenern, sodass Anrufabläufe, ACL-Regeln und Trunk-Konfiguration weiterhin wie konfiguriert funktionieren. Pro-Trunk-Aktivierung ermöglicht den schrittweisen SIPS-Rollout.
Carrier-ITSP mit SIPS-Endpunkt oder Enterprise-SBC
Hardphone oder SIP-Phone mit TLS-Pflicht beim REGISTER
Mandantenzertifikat per SNI
Jeder TLS-Handshake wählt das mandantenspezifische Zertifikat per SNI-Servername aus LocalMachine\My. Derselbe Zertifikatsspeicher, den auch der WSS-Listener und TURN-TLS verwenden; dasselbe per Mandant ausgerollte LE-Zertifikat via /acquire-cert.
Mandant N+1 hinzuzufügen bedeutet: ein weiteres Zertifikat installieren — keine SAN-Liste, keine betreiberseitige SIPS-Neukonfiguration.
Pro Trunk aktivierbar
In trunks-admin.html hat jeder Trunk eine TLS (SIPS)-Checkbox und einen optionalen TLS-Port (Standard 5061). Aktiviert registriert und wählt die Bridge via sips:user@host:5061;transport=tls nach RFC 5630.
Die meisten modernen Carrier bieten TLS auf 5061; klassische FRITZ!Box-/ATA-Boxen meist nicht — dort einfach deaktiviert lassen.
ACL-Tor (gemeinsam mit UDP)
Dieselben acl.html-Regeln, die SIP über UDP blockieren, blockieren auch SIPS. SIPS-Verkehr betritt denselben InboundDispatcher-Punkt; Regeln für IP, CIDR, Glob, sip-user, sip-from, sip-did und Mandant gelten ohne Sonderfall.
Hot-Reload, Selbst-Aussperr-Schutz für private IPs, Pro-Mandanten-Regelpools — alles an einer Stelle.
Per-IP TLS Auto-Blacklist
Sliding-Window-Detektor pro Quell-IP: mehr als 15 fehlgeschlagene TLS-Handshakes innerhalb von 5 Minuten sperrt die IP auf der SIPS-Annahmestufe für 1 Stunde. Fängt lärmenden SIP-Scanner-Traffic am kostengünstigsten Antwortpunkt ab.
Schwellenwert höher als TURN-Standard (5), um CGNAT-geteilte Mobilfunk-Quell-IPs zu schonen. Private, Loopback-, Link-local- und IPv4-mapped-IPv6-Adressen sind ausgenommen.
Slow-Loris-Verteidigung
15-Sekunden-Handshake-Timeout beendet Peers, die nach dem TLS-Record-Header nur tropfweise Bytes nachliefern. Per-Kanal-SemaphoreSlim(200) deckelt In-Flight-Handshakes pro Port, damit ein /16-Scanner den Thread-Pool nicht aushungert.
Über-Cap-Accepts erhalten ein sofortiges TCP-RST plus eine gedrosselte WRN-Logzeile.
Observability ohne REST-Exposure
Eine greppbare Logzeile pro eingehender SIPS-Anfrage: [sips-arrival] mit CallID, Methode, From, To, Remote, Local. Eine [sips-downgrade] WRN-Zeile pro Anruf, wenn eine SIPS-Strecke auf eine SIP-Klartextstrecke umsteigt — nie still, nie blockiert.
Periodische [SIPS-stats]-Zeile alle 30 s. Betreiberorientierter /sip-tls/health-Endpoint liefert dieselben Daten als JSON.
SRTP via SDES — Medien-Verschlüsselung auf der Trunk-Strecke
SIPS schützt die SIP-Steuerebene. SDES (Session Description Protocol Security Descriptions, RFC 4568) verschlüsselt SRTP auf der Medienebene derselben Trunk-Strecke. Zusammen ist die Strecke zwischen Bridge und Carrier auf beiden Ebenen verschlüsselt: SIPS für Signalisierung, SDES für Medien.
Pro-Trunk-SRTP-Schalter
In trunks-admin.html hat jeder Trunk eine SRTP-Checkbox neben der vorhandenen TLS (SIPS)-Checkbox. Aktiviert offeriert die Bridge SDES bei ausgehenden INVITEs und antwortet mit SDES bei eingehenden INVITEs dieses Trunks. Standardmäßig AUS pro Trunk — bestehende Routings bleiben unverändert, bis ein Betreiber aktiviert.
Crypto-Suite: AES_CM_128_HMAC_SHA1_80
Ausgehende INVITEs offerieren m=audio … RTP/SAVP mit a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:<base64-key> — die nach RFC 4568 verpflichtende Basis-Suite. Der 32-Byte-Schlüssel (128-Bit Master Key + 112-Bit Master Salt) wird pro Anruf frisch erzeugt.
Asymmetrische eingehende Antwort
Eine eingehende INVITE mit a=crypto: wird unabhängig vom ausgehenden Schalter des Trunks mit SDES beantwortet — safe-by-default. Peers, die SRTP bevorzugen, erhalten SRTP zurück; Peers ohne Crypto-Angebot funktionieren weiterhin wie zuvor.
Fail closed, nie still Klartext
Wenn der Pro-Trunk-SRTP-Schalter aktiv ist und der Peer das SDES-Angebot ablehnt (oder keine brauchbare crypto-Zeile zurückgibt), endet der Anruf. Es gibt keinen Fallback auf Klartext-RTP, den ein Betreiber nicht ausdrücklich freigegeben hat. Jede Ablehnung wird auf INF-Ebene mit Anruf-Korrelations-ID protokolliert.
Bridge-terminiert für KI & Aufzeichnung
Die Bridge terminiert die SDES-Sitzung und sendet die passende Form auf der Gegenstrecke. KI-Empfang, signierte Anrufaufzeichnung, Transkription und Lawful-Intercept-Hooks arbeiten weiter, weil die Bridge intern dekodiertes Audio sieht. Der Carrier sieht nie Klartext auf der Leitung.
Ergänzt DTLS-SRTP auf WebRTC
Browser-Strecken verhandeln DTLS-SRTP bereits automatisch. SDES auf der Trunk-Strecke schließt die symmetrische Lücke auf der Carrier-Seite. Gepaart mit dem Pro-Trunk-Schalter TLS (SIPS) ist die Trunk-Strecke gleichzeitig auf Signalisierungs- und Medienebene verschlüsselt.
Session-Timer für Mid-Call-Liveness (RFC 4028)
SIPS hält den TCP-Socket lebendig; Session-Timer (RFC 4028) hält den SIP-Dialog selbst rechenschaftspflichtig. Mit aktivem Pro-Trunk-Session-Timer-Schalter signalisieren ausgehende INVITEs Session-Expires + Min-SE + Supported: timer; bestätigt der Carrier, sendet die Bridge mid-call UPDATE-Refreshes auf der Hälfte des ausgehandelten Intervalls und beendet den Dialog per BYE, wenn eine Refresh-Round-Trip ausbleibt. Carrier ohne RFC 4028-Unterstützung ignorieren das Angebot schlicht und fallen auf den bereits vorhandenen RTP-Watchdog zurück — keine Day-One-Regression. Standardmäßig AUS pro Trunk; eingehende Anrufe beantworten die Anfrage des Peers unabhängig vom Schalter.
EU-CRA- und NIS2-Ausrichtung: Medien-Verschlüsselung zwischen einer regulierten Organisation und ihrer Telekom-Grenze ist zunehmend Basis-Erwartung, nicht Nice-to-have. SDES auf der Trunk-Strecke, gepaart mit SIPS auf der Signalisierungsebene, deckt beides ab — mit betreiberkontrollierter Pro-Trunk-Granularität, ohne All-or-Nothing-Rollout.
Das Risiko von unverschlüsseltem SIP
Ein SIP-Paket auf einer UDP- oder TCP-ohne-TLS-Strecke durchquert jeden Zwischen-Router, ISP, IXP und Transit-AS im Klartext. Drei konkrete Schadenskategorien folgen direkt daraus.
Header-Metadaten sind personenbezogene Daten
Die Header From, To, Contact, P-Asserted-Identity und Via tragen anrufende und gerufene Nummern, Nebenstellen und Host-Identitäten. Nach EU-Datenschutzrecht ist eine Telefonnummer, die eine natürliche Person identifiziert, ein personenbezogenes Datum (DSGVO Art. 4 Abs. 1). Ein passives Mitschneiden von Klartext-SIP ist eine Interception personenbezogener Daten — meldepflichtig nach DSGVO Art. 33, wenn es geschieht.
Authentifizierungs-Digests finanzieren Toll-Fraud
Ein Klartext-REGISTER oder INVITE trägt den Digest-Authorization-Header. Der HA1-Hash ist mit Realm und Nonce gesalzen, aber Benutzername und Realm sind sichtbar und jede Nonce ist bis zur Rotation durch den Registrar wiederverwendbar. Mitgeschnittene Digests werden routinemäßig offline gebrochen oder während des Nonce-Fensters wiedergespielt — die gekaperte SIP-Leitung wird dann automatisch zu Premium-Zielnummern gewählt und es entstehen vier- bis fünfstellige Rechnungen innerhalb eines Wochenendes. ENISA und CFCA listen Toll-Fraud jedes Jahr unter den Top-3-Telekom-Betrugskategorien.
Audio ist ohne SRTP aufzeichenbar
Klartext-RTP-Pakete tragen G.711- oder Opus-Nutzlast ohne Integritätssicherung und ohne Verschlüsselung. Eine Position auf dem Anrufpfad — ein fehlkonfigurierter Switch, ein kompromittiertes CPE, ein feindliches Transit-Netz — reicht, um jedes Gespräch wörtlich aufzuzeichnen und mit Standardwerkzeugen das Audio zu rekonstruieren. SRTP via SDES auf der Trunk-Strecke und DTLS-SRTP auf der Browser-Strecke beseitigt diese Exposition.
CodeB ist auf eine Haltung voreingestellt, in der TLS auf der Signalisierungs- und SRTP auf der Medien-Ebene auf jedem Trunk und jedem Endpunkt verfügbar sind. Die Schalter TLS (SIPS) und SRTP in trunks-admin.html sind pro Trunk, sodass ein Mandant sie Carrier für Carrier aktivieren kann, sobald Vertrauen aufgebaut ist — ohne Flag-Day-Rollout.
Verschlüsseltes SIP und das Recht
Keine geltende Verordnung schreibt “nutzt SIPS” in genau diesen Worten vor. Mehrere fordern jedoch die Verschlüsselung personenbezogener Daten bei der Übertragung, die Vertraulichkeit elektronischer Kommunikation und Kryptographie als Basis-Sicherheitsmaßnahme — und TLS auf SIP-Signalisierung plus SRTP auf RTP-Medien ist die anerkannte Art, wie ein SIP-/Telekom-Betreiber die Einhaltung dieser Klauseln nachweist.
DSGVO Art. 32 (EU 2016/679)
Verantwortliche und Auftragsverarbeiter setzen “geeignete technische und organisatorische Maßnahmen” um, einschließlich “der Pseudonymisierung und Verschlüsselung personenbezogener Daten”. SIP-Header identifizieren natürliche Personen; SIP-Audio trägt identifizierende biometrische Sprachdaten. TLS + SRTP ist die anerkannte Stand-der-Technik-Antwort für Verschlüsselung bei der Übertragung.
ePrivacy-Richtlinie Art. 5 (2002/58/EG)
Die Mitgliedstaaten sichern die Vertraulichkeit der Kommunikation und verbieten Abhören oder Überwachen von Kommunikation und zugehörigen Verkehrsdaten ohne Einwilligung. Klartext-SIP verfehlt den technischen Teil dieser Pflicht: jeder auf der Leitung kann es abfangen.
NIS2-Richtlinie Art. 21 Abs. 2 lit. h (EU 2022/2555)
Wesentliche und wichtige Einrichtungen — einschließlich digitaler Infrastruktur und einem breiten Spektrum von B2B-Anbietern — müssen Cyber-Risikomanagement-Maßnahmen ergreifen, einschließlich “Konzepte und Verfahren bezüglich der Verwendung von Kryptografie und gegebenenfalls Verschlüsselung.” In Kraft seit dem 18. Oktober 2024 in den EU-Mitgliedstaaten.
EU Cyber Resilience Act (EU 2024/2847)
Anhang I verpflichtet Produkte mit digitalen Elementen, “die Vertraulichkeit von gespeicherten, übertragenen oder anderweitig verarbeiteten Daten zu schützen … durch Verschlüsselung relevanter Daten ruhend oder bei der Übertragung mit Mechanismen nach dem Stand der Technik.” SBCs und Voice-Plattformen fallen klar in den Anwendungsbereich.
EECC Art. 40 (EU 2018/1972)
Anbieter elektronischer Kommunikation müssen geeignete und verhältnismäßige technische und organisatorische Maßnahmen ergreifen, um Risiken für die Sicherheit von Netzen und Diensten zu beherrschen. Nationale Regulierer lesen Transport-Verschlüsselung der Signalisierung als Basis des “Stands der Technik.”
Deutschland — TKG § 165 + BSI TR-02102
Das Telekommunikationsgesetz § 165 verlangt “angemessene technische Vorkehrungen” zur Vertraulichkeit der Kommunikation. Die BSI-Richtlinie TR-02102-2 zu kryptografischen Verfahren empfiehlt TLS 1.2 oder TLS 1.3 mit Forward-Secrecy-Cipher-Suites für Transport-Sicherheit. Beide werden durch SIPS auf TLS 1.2/1.3 mit den modernen Cipher-Suites erfüllt, die IIS / SCHANNEL standardmäßig aushandeln.
Sektorspezifische Aufschläge addieren ihre eigenen Anforderungen: HIPAA § 164.312(e) (US-Gesundheitswesen-Voice), PCI-DSS v4 wenn Anrufaufzeichnungen Karteninhaberdaten berühren, ETSI TS 133.203 für IMS-Interconnect. Der gemeinsame Nenner auf der SIP-Ebene ist derselbe: TLS auf Signalisierung, SRTP auf Medien.
Häufig gefragt
Ist SIPS für jeden Mandanten Pflicht?
Nein. SIPS ist pro Trunk aktivierbar. Die Bridge startet mit gebundenen SIPS-Listenern; ein Trunk verwendet aber nur dann sips:-URIs, wenn ein Betreiber die TLS-Checkbox im Trunk-Admin aktiviert. Mandanten ohne SIPS laufen unverändert auf UDP weiter.
Wie steht es um SRTP auf der Medienstrecke?
SIPS schützt die Signalisierungsebene. SRTP für Medien ist eine ergänzende, separate Aushandlung. WebRTC-Browser-Strecken nutzen automatisch DTLS-SRTP. Für die Carrier-Trunk-Strecke bietet die Bridge SDES nach RFC 4568 mit der Crypto-Suite AES_CM_128_HMAC_SHA1_80 an, wenn der pro-Trunk-Schalter SRTP aktiviert ist — ausgehende INVITEs offerieren RTP/SAVP mit a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:…, eingehende INVITEs antworten mit SDES, wenn der Peer es anbietet. Lehnt der Peer ab, endet der Anruf — kein stiller Klartext-Fallback. Die Bridge terminiert SRTP, sodass KI-Empfang, Aufzeichnung und Lawful-Intercept-Hooks weiterhin funktionieren. Wenn eine SIPS-INVITE auf eine Klartext-SIP-Strecke brückt (SRTP aus), wird pro Anruf eine strukturierte WRN-Zeile geschrieben, sodass der Betreiber jede Klartext-Strecke sieht.
Funktioniert SIPS mit TLS 1.3 und Post-Quantum-Hybrid-Schlüsselaustausch?
Ja für TLS 1.3. Die Bridge erzwingt TLS 1.2+TLS 1.3 explizit über SCHANNEL. Post-Quantum-Hybrid-Key-Shares (Chrome 124+ liefert X25519+Kyber768; später ML-KEM-768 nach NIST FIPS 203) werden von SCHANNEL auf Windows Server 2025+ verhandelt. Der SNI-Peek-Puffer ist auf 8 KB dimensioniert.
Wie verhindert die Auto-Blacklist die Aussperrung legitimer CGNAT-Clients?
SIPS-Schwelle: 15 Fehlschläge in 5 Minuten pro Quell-IP — bewusst höher als der TURN-Standard von 5. Begründung: viele Mobilfunkanbieter routen tausende Nutzer hinter einer IPv4-Quell-IP. Ein zu niedriger Schwellenwert würde beim ersten Fehlerschauer einen ganzen Carrier-Pool blockieren.
Wo sehe ich SIPS-Health und Verkehrszähler?
GET /sip-tls/health liefert JSON mit Port-Status, lebenslangem Handshake-Zähler, aktueller und kumulativer Blocklist-Größe und einer menschenlesbaren Policy-Beschreibung. Dieselben Daten erscheinen alle 30 Sekunden als [SIPS-stats] INF-Logzeile.
EU-Made?
Ja. CodeB wird von Aloaha Limited unter EU-Recht entwickelt und betrieben. SIPS-Deployments laufen auf betreibereigener Infrastruktur — keine CodeB-seitige Datenebene, kein Drittanbieter-Cloud-STUN/TURN, kein Metadaten-Export. Die Bridge läuft auf .NET Framework 4.8 unter Windows Server mit SCHANNEL als TLS-Provider.