读书笔记 - Building Telephony Systems with OpenSIPS (2nd Edition)

这是一本介绍OpenSIPS的书，有14章，感觉全部读完，就可以用OpenSIPS搞一个PBX出来了，但现实架构设计中，我们不仅仅用OpenSIPS, 还会考虑用SBC和Freeswitch来搭建一个PBX系统。基于这个想法，我就只看前2章了，后面的章节如下
Chapter 3: Installing OpenSIPS
Chapter 4: OpenSIPS Language and Routing Concepts
Chapter 5: Subscriber Management
Chapter 6: OpenSIPS Control Panel
Chapter 7: Dialplan and Routing
Chapter 8: Managing Dialogs
Chapter 9: Accounting
Chapter 10: SIP NAT Traversal
Chapter 11: Implementing SIP Services
Chapter 12: Monitoring Tools
Chapter 13: OpenSIPS Security
Chapter 14: Advanced Topics with OpenSIPS 2.1

这里主要记录前2章的要点

Chapter 1: Introduction to SIP

RFC 3261 describes SIP version 2. SIP is an application layer protocol used to establish, modify, and terminate sessions or multimedia calls. These sessions can be audio, video, chatting or screen sharing sessions. It is similar to HTTP.

RFC 3665 defines best practices to implement a minimum set of functionalities for a SIP IP communications network. SIP registrar server accepts REGISTER requests and saves the information received in these packets on the location server for their managed domains.

Types of SIP Servers

• The proxy server: all SIP signaling goes through the SIP proxy, but the RTP packets will go directly from one endpoint to another even if the server is working as a SIP proxy.
• The redirect server: In this mode, the SIP server is very scalable because it doesn't keep the state of the transactions. Just after the initial INVITE, it replies to UAC with a 302 and is removed from the SIP dialog. Use this mode if you don't need to bill the calls.
• The B2BUA server: Back-to-Back User Agent server is normally applied to hide the topology of the network and support buggy clients unable to route SIP requests correctly based on record routing. Freeswitch, Asterisk, Yate and otehrs work as B2BUAs. (two legs)

SIP request messages (methods)

Message	Description	RFC
REGISTER	Registers the user and updates the location table	RFC 3261
INVITE	Session establishment	RFC 3261
ACK	Acknowledges an INVITE	RFC 3261
BYE	Terminates an existing session	RFC 3261
CANCEL	Cancels a pending registration	RFC 3261
PRACK	Acknowledges a provisional response	RFC 3262
INFO	Provides mid-call signaling info	RFC 2976
MESSAGE	Instant message transport	RFC 3428
NOTIFY	Sends information after subscribing	RFC 3265
SUBSCRIBE	Establishes a session to receive future updates	RFC 3265
PUBLISH	Uploads the status info to the server	RFC 3903
REFER	Asks another UA to act on URI	RFC 3515
UPDATE	Updates a session state info	RFC 3311

Most of the time, we will use REGISTER, INVITE, ACK, BYE, and CANCEL.
INFO is used for DTMF relay and mid-call signaling information.
PUBLISH, NOTIFY, and SUBSCRIBE give support to the presence systems.
REFER is used for call transfer.
MESSAGE is used for chat application.

SIP dialog flow
INVITE, 100 Trying, 180 Ringing, 200 OK, ACK, BYE

A call made using sips: (secure SIP) will use a secure transport, TLS (Transport Layer Security), between the caller and callee. Session details such as the media type and codec are not described in SIP. Instead, it uses the SDP (Session Description Protocol). This SDP message is carried by the SIP message, similar to email attachment.

A combination of the To, From, and Call-ID tags fully defines an end-to-end SIP relation known as a SIP dialog.

While the Via header field tells the other elements where to send a response, the Contact header tells the other elements where to send future requests.

SIP three-way handshake is: INVITE/200 OK/ACK
During the session, the parties can change session characteristics issuing a new INVITE request. This is called reinvite.

SIP transactions and dialogs
According to RFC 3261, a dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. A dialog is a succession of transactions that control the creation, existence, and termination of the dialog. All dialogs do have a transaction (INVITE) to create them, and may (or may not) have a transaction to change them. And the end-dialog transaction may be missing.

The configuration of the SRV records is often used to provide failovers and load sharing between the SIP servers. It is one of the easiest ways to get geographical redundancy in a SIP project.

SIP services
RFC 5359 defines a standard way to accomplish SIP services, including

• Call Hold
• Consulation Hold
• Music on Hold
• Transfer - Unattended (blind)
• Transfer - Attended (warm) 
• Call Forwarding
• 3-way conference
• Find-me
• Incoming Call Screening
• Outgoing Call Screening 
• Call Park
• Call Pickup
• Automatic Redial
• Click to Dial

The RTP Protocol
The Real-time Protocol (RTP) is defined in RFC 3550 for the real-time audio and video etc data transporting. It uses UDP as the transport protocol. To be transported, the audio or video data has to be packetized using a codec.

Codec	Bandwidth	MOS	Env.	When to use
G.711	64 kbps	4.45	LAN/WAN	Use it for toll quality and broad support from gateways
G.729	8 kbps	4.04	WAN	Use it to save bandwidth and keep toll quality
G.722	64 kbps	4.5	LAN	Use it for HD voice
OPUS	6-501 kbps	-	INTERNET	OPUS is the most sophisticated codec ever created. It spans from a narrow band audio to HD voice.

The µ-law and A-law algorithms encode 14-bit and 13-bit signed linear PCM samples (respectively) to logarithmic 8-bit samples. Thus, the G.711 encoder will create a 64 kbit/s bitstream for a signal sampled at 8 kHz.

DTMF-relay
There are 3 ways to carry DTMF in VoIP networks:

1. inband as audio tones
2. named events on RTP (RFC 2833)
3. signaling using SIP INFO messages 

The SIP and OSI model

Application	OpenSIPS
Presentation	G711/G729/GSM/Speex
Session	SIP/SIPS
Transport	UDP/TCP/TLS/RTP/SRTP/RTCP/SCTP (Stream control transmission protocol)
Network	IP
Datalink	Frame-Relay/ATM/PPP/Ethernet
Physical	Ethernet/V.35/RS-232/xDSL

To communicate to the PSTN, a PSTN gateway is usually required, except when you have a SIP trunk. The SIP proxy never handles the media. Services such as IVR, voicemail, conference, or anything related to media should be implemented in a media sever. There are many SIP servers fitting this purpose like Asterisk, FreeSwitch, Yate, SEMS from IPTEL, and SilkServer for AG projects.

Chrome browser always redirects http to https

When I access some website, it always redirects the URL from http to https even I manually enter http://mysite.com. I wonder how it happens so dig it a bit further and find out Chrome always does a 307 Internal Redirect

How to stop an automatic redirect from “http://” to “https://” in Chrome?
To answer this question, we need understand why Chrome behaves in this way.

https://tools.ietf.org/html/rfc6797 specifies HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header (Strict-Transport-Security). Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS.

For example:

Strict-Transport-Security: max-age=31536000; includeSubDomain

The main benefits HSTS can bring in terms of security:

1. HSTS automatically redirects HTTP requests to HTTPS for the target domain
2. HSTS does not allow a user to override the invalid certificate message

Here are solutions to stop HSTS:
1) Server side: Disable on web server side, for instance, on Nginx, set max-age to zero
add_header Strict-Transport-Security "max-age=0;";

2) Client side: Delete domain security policies from browser side, for instance, go to chrome://net-internals/#hsts and delete the target domain. However, you cannot delete browser preloaded entries

References:
https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
https://superuser.com/questions/565409/how-to-stop-an-automatic-redirect-from-http-to-https-in-chrome
https://stackoverflow.com/questions/27945501/307-redirect-when-loading-analytics-js-in-chrome

UCaaS security framework

Cloud UCaaS (Unified Communications as a Service) needs a security framework to make it secure and reliable in the cloud for Meetings, Phone and Chat.

1) Secure data center
UCaaS provider (vendor) needs facilities with strong physical protections, redundant power, and tested disaster recovery procedures.

2) Robust network security
UCaaS vendor must add unique protections designed to prevent attacks on the infrastructure, preventing service disruption, data breaches, fraud, and service high-jacking. Also needs to resolve firewall traversal problems in VoIP systems with network address translation (NAT) support for static IP configuration and “Keep-Alive” SIP signaling.

3) Secure voice
All voice traffic within cloud phone system should be encrypted to prevent eavesdropping on voice calls.  Provide additional security for IP phone calls using SIP over TLS and SRTP encryption.

4) Data encryption
All data should be encrypted in transit and at rest, with audit-able record-keeping and reporting. It includes everything from physical protections at data centers to encrypted storage to comprehensive digital tracking with clear audit trails.

5) Fraud prevention
The service provider should have protections built in to the service layer and should conduct continuous monitoring for dangerous anomalies or other indicators of toll fraud and service abuse.

6) User access controls
To ensure only authorized users access cloud communications accounts and services, the vendor should implement at a minimum strong password policies and ideally two-factor authentication as well as single sign-on (SSO).

7) Account management and administration
Administrators can instantly revoke the remote user’s access to the cloud network—and thereby to customer contacts, CRM info, and other corporate information—and almost no data resides on the device itself.

RingCentral Phone provisioning is unsecure

Recently I provisioned a Cisco SPA-525G2 Desk Phone to my RingCentral Free Trial account, and found their provisioning process is totally not secure.

When I added an existing phone on account admin portal, it prompted me to input the IP address of my IP Desk Phone. I am curious how the flow works underneath, then I dig it out and find RingCentral uses http instead of https. It doesn't provide either server side certificate or client side certificate for mutual TLS authentication. This means the provisioning data packets are exposed to hackers, and also any device can get provisioned through their provisioning portal. I am very surprised of their design from security perspective.

Phone resync URL
http://10.100.61.87/admin/resync?http://service.ringcentral.com/op/?u=1953899020&ai=803497337020&sn=$SN&pn=$PN

Proxy to their provisioning portal using HTTP
http://service.ringcentral.com/op/?u=1953899020&ai=803497337020&sn=$SN&pn=$PN

Variables in the URL will be replaced by desk Phone with serial number and product model
http://service.ringcentral.com/op/?u=1953899020&ai=803497337020&sn=CCQ214808CZ&pn=SPA525G2

If you sniff the network, you can clearly see the request and response in clear text (including user ID, password, auth ID etc info in plain XML file), and you can use any User agent to do the provisioning acting as a Cisco IP Phone.

This design worries me about their security design. I am not sure if they design by purpose or design by mistake.

Mutual TLS Authentication

Mutual authentication or two-way authentication refers to two parties authenticating each other at the same time. By default the TLS protocol only proves the identity of the server to the client using X.509 certificate and the authentication of the client to the server is left to the application layer. TLS also offers client-to-server authentication using client-side X.509 authentication.

When Mutual TLS authentication is in place, both client and server authenticate each other through the digital certificate so that both parties are assured of the others' identity. In this aspect, both client and server use 12 handshake messages to establish the encrypted channel prior to message exchanging.

Refer to https://www.codeproject.com/articles/326574/an-introduction-to-mutual-ssl-authentication

When set up Mutual TLS authentication, it involves creating your own Certification Authority, self-signing the server certificate and client certificate, then installs self-signed certificate on server and client. The detailed steps are as followings:

1. Generate CA certificate:
1.1. Generate CA key:
openssl genrsa -out ca.key 2048
1.2. Generate CA certificate request:
openssl req -new -key ca.key -out ca.csr -subj /C=US/ST=ABC/L=XYZ/O=Example/OU=Test/CN=Root/emailAddress=john.doe@example.com
1.3. Generate CA certificate:
openssl x509 -req -days 3650 -in ca.csr -signkey ca.key -out ca.pem

2. Generate server certificate:
2.1. Generate server key:
openssl genrsa -out server.key 2048
2.2. Generate certificate request:
openssl req -new -key server.key -out server.csr -subj /C=US/ST=ABC/L=XYZ/O=Example/OU=Test/CN=test.cert.example.com/emailAddress=john.doe@exampl
e.com
2.3. Generate certificate:
openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out test.cert.example.com.pem -days
365

3. Generate client certificate:
3.1. Generate client key:
openssl genrsa -out client.key 2048
3.2. Generate certificate request:
openssl req -new -key client.key -out client.csr -subj /C=CN/ST=FJ/L=City/O="Company"/OU=Dept/CN=ClientID/emailAddress=support@company.com
3.3. Generate certificate:
openssl x509 -req -in client.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out client.pem -days 365

4. Combine cert and key:
cat client.pem client.key > client2.pem

Some client like Firefox, to install the client certificate, we’ll need a PKCS#12 file which stores both the certificate and the client’s private key.
openssl pkcs12 -export -clcerts -in client.pem -inkey client.key -out client2.p12

5. Configure server:
Apache:
TLSCACertificateFile ca.pem
TLSCertificateKeyFile server.key
TLSCertificateFile test.cert.example.com.pem
TLSVerifyClient demand

Nginx:
ssl_certificate test.cert.example.com.pem;
ssl_certificate_key server.key;
ssl_client_certificate ca.pem;
ssl_verify_client on;

6. Configure client (device or browser):
6.1 Add ca.pem as a trusted CA certificate on client side
6.2 Add client2.pem or client2.p12 as a client certificate and use it

https://blog.codeship.com/how-to-set-up-mutual-tls-authentication/ also gives step-by-step instructions to set up mutual authentication using openssl commands.

CA certificate
openssl genrsa -aes256 -out ca/ca.key 4096 chmod 400 ca/ca.key
openssl req -new -x509 -sha256 -days 730 -key ca/ca.key -out ca/ca.crt
chmod 444 ca/ca.crt
openssl x509 -noout -text -in ca/ca.crt

Server certificate
openssl genrsa -out server/client-ssl.bauland42.com.key 2048
chmod 400 server/client-ssl.bauland42.com.key
openssl req -new -key server/client-ssl.bauland42.com.key -sha256 -out server/client-ssl.bauland42.com.csr
openssl x509 -req -days 365 -sha256 -in server/client-ssl.bauland42.com.csr -CA ca/ca.crt -CAkey ca/ca.key -set_serial 1 -out server/client-ssl.bauland42.com.crt
chmod 444 server/client-ssl.bauland42.com.crt
openssl x509 -noout -text -in server/client-ssl.bauland42.com.crt
openssl verify -CAfile ca/ca.crt server/client-ssl.bauland42.com.crt

Client certificate
openssl genrsa -out client/heiko.key 2048
openssl req -new -key client/heiko.key -out client/heiko.csr
openssl x509 -req -days 365 -sha256 -in client/heiko.csr -CA ca/ca.crt -CAkey ca/ca.key -set_serial 2 -out client/heiko.crt
openssl pkcs12 -export -clcerts -in client/heiko.crt -inkey client/heiko.key -out client/heiko.p12

Nginx server config
ssl_certificate /etc/nginx/certs/server/client-ssl.bauland42.com.crt;
ssl_certificate_key /etc/nginx/certs/server/client-ssl.bauland42.com.key;
ssl_client_certificate /etc/nginx/certs/ca/ca.crt;
ssl_verify_client on;