Perché cifrare le chiamate B2B

In uno scenario business-to-business (B2B) due organizzazioni interconnettono i propri Expressway-E attraverso una traversal zone di tipo B2B (SIP) o un semplice neighbor zone su Internet. Il traffico attraversa reti non fidate, quindi vanno protetti due piani distinti e indipendenti:

  • il signaling (setup, offer/answer SDP, REGISTER/INVITE) → SIP TLS
  • il media (RTP audio/video) → SRTP

Cifrare uno solo dei due non basta: se il signaling viaggia in chiaro, le chiavi SRTP contenute nell’attributo a=crypto dell’SDP sono leggibili e la protezione del media diventa inutile.

Signaling con SIP TLS

Sull’Expressway il transport SIP si imposta a livello di zona. Per il B2B si usa TLS su porta 5061 (contro TCP/5060 o UDP/5060 in chiaro). TLS fornisce riservatezza, integrità e autenticazione mutua dei peer tramite certificati X.509: ciascun Expressway-E presenta il proprio certificato server e, con TLS verify mode = On, valida quello del peer confrontando il subject/SAN con il TLS verify subject name e verificando la catena tramite le CA fidate nel trust store. È l’errore più comune: certificati non fidati o SAN mancante fanno fallire l’handshake TLS e la chiamata non parte affatto.

Media con SRTP

SRTP cifra il payload RTP (tipicamente AES-128 in modalità counter) e ne garantisce l’integrità con HMAC-SHA1. Le chiavi di sessione sono negoziate in-band nell’SDP (a=crypto: con suite tipo AES_CM_128_HMAC_SHA1_80) trasportato dentro l’INVITE/200 OK. Da qui la dipendenza logica: SRTP presuppone un canale di signaling sicuro, cioè SIP TLS. L’Expressway può agire da punto di terminazione della cifratura del media (encrypt-on-behalf-of): decifra su un lato e ricifra sull’altro, così può far parlare un lato SRTP con un lato RTP, a patto che la policy lo consenta.

Media encryption policy sulle zone

Ogni zona ha un parametro Media encryption mode che governa cosa fa l’Expressway al media che l’attraversa:

Policy Comportamento Chiamata in chiaro Chiamata SRTP
Auto Nessun intervento: passa così com’è Ammessa Ammessa
Best effort Cifra se il peer lo supporta, altrimenti fallback in chiaro Ammessa (fallback) Ammessa
Force encrypted Il media deve essere SRTP; l’Expressway cifra o rifiuta Rifiutata Ammessa
Force unencrypted Il media deve essere in chiaro; SRTP rifiutato/rimosso Ammessa Rifiutata

La policy si applica per zona, quindi una chiamata che attraversa più zone deve soddisfare la policy di ogni hop. L’Expressway media le differenze (es. best effort su un lato e force encrypted sull’altro convivono, perché “best effort” accetta anche SRTP). Ma le policy possono anche entrare in conflitto insanabile.

Interworking SIP/H.323 e impatto sulla cifratura

L’Expressway effettua l’interworking tra SIP e H.323 quando i due lati parlano protocolli diversi. La negoziazione delle chiavi SRTP vista sopra (a=crypto in SDP) è specifica del SIP: sul lato H.323 quel meccanismo non esiste. Di conseguenza, per una chiamata interworkata, l’Expressway tratta il media come non cifrabile end-to-end e applica comunque le policy di zona. In pratica il lato H.323 tende a essere in chiaro; se la zona verso l’H.323 è impostata a Force encrypted, la chiamata fallisce perché quel lato non può garantire SRTP. Con best effort invece la chiamata prosegue in chiaro. Va inoltre ricordato che l’interworking SIP↔H.323 consuma Rich Media Session (RMS) license sull’Expressway.

Trappole tipiche d’esame

  • Force encrypted su un lato, force unencrypted sull’altro → il setup fallisce per incompatibilità: un lato pretende SRTP, l’altro lo vieta, e nessun fallback è possibile. È lo scenario chiave: la soluzione corretta è allineare le policy (es. best effort su entrambi) o rimuovere il vincolo su una delle due zone.
  • Force encrypted su una chiamata interworkata SIP↔H.323 → la chiamata cade, perché il lato H.323 non supporta la negoziazione SRTP via SDP. Risposta giusta: usare best effort o mantenere il percorso SIP end-to-end.
  • SRTP senza SIP TLS → configurazione incoerente: le chiavi a=crypto viaggerebbero in chiaro. La scelta corretta è abilitare SIP TLS (5061) prima/insieme a SRTP.
  • Handshake TLS fallito (nessun media, chiamata mai instaurata) → causa quasi sempre certificato non fidato o TLS verify subject name errato, non un problema di SRTP. Correggere trust store/SAN, non la policy media.
  • Best effort scambiato per “sempre cifrato” → best effort ammette il fallback in chiaro; se il requisito è “media sempre protetto”, la risposta corretta è force encrypted, non best effort.