From reSIProcate
Revision as of 15:28, 2 May 2012 by Dpocock (talk | contribs)
Jump to navigation Jump to search


reSIProcate aims to provide a solid basis for inter-domain routing of SIP messages with a high degree of trust to ensure that caller ID is authentic. It achieves this using TLS, especially what is documented in RFC 5922.

This page discusses all aspects of TLS in reSIProcate and repro:

  • Acting as a TLS server
  • Optionally accepting (or demanding) client certificates from TLS clients (new from v1.8)
  • Acting as a TLS client: inspecting the remote cert, and sending a `client' cert for mutual authentication if requested by the server

The transport layer TLS

  • Much of the work is done by OpenSSL
  • TLS v1 is the default for repro

reSIProcate, DUM and repro as a TLS server

  • the traditional behavior of the stack involves loading all certs from a single directory. CA root certs are in files matching the pattern root_cert_*.pem, our server certs must be in files matching the pattern domain_cert_<DOMAIN>.pem
  • from 1.8, the CA root certs can be loaded from a separate directory (e.g. /etc/ssl/certs/* on Debian)

Accepting connections from TLS clients with certificates

  • client certificates can be ignored, optional, or mandatory
  • if `optional', and if the client sends a cert, the cert must pass all the tests or their request will be rejected

checking the peer certificate

  • we make no distinction whether the peer is a TLS client or TLS server
  • at connection setup, transport layer checking of a peer's client or server cert is done (e.g. checking the expiry date, checking the CA is trusted)
  • for each SIP message received, and regardless of whether the connection is client or server mode, the stack can check each message that it receives against the cert (e.g. to validate the From: header)
  • in practice, the resip::TlsPeerAuthManager (in dum) and repro::CertificateAuthenticator (in repro) are checking the From: header of every SIP message from the peer, these classes can be subclasses to implement other checks
  • furthermore, they support two types of checks on the From: header/certificate, (a) for a domain cert, any user is permitted and (b) for a peer using a URI in their cert (e.g., only the exact URI will be permitted in the From: header

The gotchas

  • if the peer is a trusted proxy, a reSIProcate instance may NOT want to apply From: header filtering. For example, if reSIProcate is used to create a softphone, the trusted proxy may be receiving SIP messages from the outside world (from any arbitrary domain), verifying the source is good, and then relaying them to the softphone. In this case, reSIProcate should not match the From: header against the proxy's TLS certificate.
  • not all devices send their domain or username. E.g. a Polycom phone sends it's MAC address in the common name of the client certificate. In this case, a subclass of resip::TlsPeerAuthManager would need to know how to map the MAC addresses to authorized identities (perhaps an async database lookup)
  • an email certificate is not automatically trusted, as the email address in the subjectAltName is ONLY officially valid for email. A hack is available (useEmailAsSIP) that allows these certificates to be treated as if they contained SIP URIs.

Future work in this area

  • support Extended Key Usage (EKU)
  • async framework for authorization checks (authorizedForThisIdentity method)
  • repro database to support mapping values (e.g. mapping Polycom MAC addresses to SIP usernames)
  • separate specification of CA roots trusted for each TLS connection and/or for client or server mode
  • more sophisticated rules for giving different rights to different users based on the CA who signed their cert

Likely TLS peers

  • Other instances of repro connecting to each other
  • Kamailio is a SIP proxy with good TLS support
  • OpenSIPS and Asterisk have basic TLS support (not full RFC 5922)
  • Polycom phones all have built in client certificates, and they will automatically send the cert if asked for it
  • Jitsi supports client certificates
  • Lumicall

Testing manually

Various command line utilities exist for simulating TLS connections and feeding in SIP messages with cut and paste:

  • openssl s_client
  • openssl s_server
  • gnutls-cli
  • gnutls-serv