WebRTC: sipML5, Asterisk and Chrome

I got a quick WebRTC setup working. I used the sipML5 demo setup, so I was not required to do any Javascript coding. Mostly it was simple config of Asterisk, Apache, and a soft phone.

I followed these two guides:
https://wiki.asterisk.org/wiki/display/AST/Asterisk+WebRTC+Support
http://highsecurity.blogspot.com/2012/12/webrtc-and-asterisk-11-using-sipml5.html

I got audio calls working between Chrome (using a webpage with sipML5) and a soft-phone, and between two Chromes (Windows and Mac).
But there were some problems: one way audio, or no audio after been put on hold, etc.

There are some limitations to this setup:

• Chrome only supports G711
• sipML5 does seem to do some transcoding, but I am not sure in which scenarios
• Asterisk does not support the VP8 video codec
• I think some of the no-audio calls was caused by some SRTP issues (errors thrown on Asterisk CLI)

I think this is how it works:

• The browser talks to the sipML5 media stack
• simML5 talks SIP over Websocket to the built-in Asterisk HTTP server
• Asterisk then talks normal SIP to any soft-phones

This is how an INVITE looks from simML5 towards Asterisk:

INVITE sip:8000@10.1.43.131 SIP/2.0

Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bKp6HJtQdMMTDMPbySBk9LTU3eskrWXPu4;rport

From: "Yusuf"<sip:8001@10.1.43.131>;tag=0hwykfSs3NexZBU8tdJW

To: <sip:8000@10.1.43.131>

Contact: "Yusuf"<sip:8001@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;+sip.ice;language="en,fr"

Call-ID: 1fd37734-e224-993d-0e39-4a9d0a29249d

CSeq: 64283 INVITE

Content-Type: application/sdp

Content-Length: 2055

Max-Forwards: 70

User-Agent: IM-client/OMA1.0 sipML5-v1.2013.07.17

Organization: Doubango Telecom

v=0

o=- 5377262258022282000 2 IN IP4 127.0.0.1

s=Doubango Telecom - chrome

t=0 0

a=group:BUNDLE audio

a=msid-semantic: WMS akLep2Ro5PJZMHZbFqARiPlU485AHVNwnnUK

m=audio 35291 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126

c=IN IP4 196.14.169.11

a=rtcp:35291 IN IP4 196.14.169.11

a=candidate:221728540 1 udp 2113937151 10.1.43.131 55639 typ host generation 0

a=candidate:221728540 2 udp 2113937151 10.1.43.131 55639 typ host generation 0

a=candidate:2999745851 1 udp 2113937151 192.168.56.1 55640 typ host generation 0

a=candidate:2999745851 2 udp 2113937151 192.168.56.1 55640 typ host generation 0

a=candidate:2758328521 1 udp 1845501695 196.14.169.11 35291 typ srflx raddr 10.1.43.131 rport 55639 generation 0

a=candidate:2758328521 2 udp 1845501695 196.14.169.11 35291 typ srflx raddr 10.1.43.131 rport 55639 generation 0

a=candidate:1135916012 1 tcp 1509957375 10.1.43.131 0 typ host generation 0

a=candidate:1135916012 2 tcp 1509957375 10.1.43.131 0 typ host generation 0

a=candidate:4233069003 1 tcp 1509957375 192.168.56.1 0 typ host generation 0

a=candidate:4233069003 2 tcp 1509957375 192.168.56.1 0 typ host generation 0

a=ice-ufrag:ENpcn07bboX2FSNu

a=ice-pwd:R+IH3MlQbkh8eW5RO2Mux7GM

a=ice-options:google-ice

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level

a=sendrecv

a=mid:audio

a=rtcp-mux

a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:KAECDDgcHP+us1cLDMQnMU7r7tPUGp20csN2YXpx

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ZcVN+IBStqIqojpkJ9yHcw7lsz/w0zniMfyqg8LH

a=rtpmap:111 opus/48000/2

a=fmtp:111 minptime=10

a=rtpmap:103 ISAC/16000

a=rtpmap:104 ISAC/32000

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:107 CN/48000

a=rtpmap:106 CN/32000

a=rtpmap:105 CN/16000

a=rtpmap:13 CN/8000

a=rtpmap:126 telephone-event/8000

a=maxptime:60

a=ssrc:2411427001 cname:0uphoIzFFc4tBBDf

a=ssrc:2411427001 msid:akLep2Ro5PJZMHZbFqARiPlU485AHVNwnnUK akLep2Ro5PJZMHZbFqARiPlU485AHVNwnnUKa0

a=ssrc:2411427001 mslabel:akLep2Ro5PJZMHZbFqARiPlU485AHVNwnnUK

a=ssrc:2411427001 label:akLep2Ro5PJZMHZbFqARiPlU485AHVNwnnUKa0

Whats interesting is that you wont see this on the wire. Because websockets serves as a transport for SIP, you only seen an initial HTTP Upgrade request.

GET /ws HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: 10.1.43.133:8088
Origin: http://10.1.43.133
Sec-WebSocket-Protocol: sip
Pragma: no-cache
Cache-Control: no-cache
Sec-WebSocket-Key: JMjC0QBuN4z9XHAR4JWfHA==
Sec-WebSocket-Version: 13
Sec-WebSocket-Extensions: x-webkit-deflate-frame
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36
Cookie: __utma=96741151.1671289293.1374742717.1374742717.1374745812.2; __utmc=96741151; __utmz=96741151.1374742717.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)

SSL, Keys, Encryption: know just enough to make it work

I've been using the web for a while, but I've never really understood how encryption works. And after all these years, I don't really care. I don't want to know how it works - I just want to know little enough to get things to work. This is really just a note to myself, that I can read whenever I need to deal with encryption. Because every few years I have to figure it out all over again just to get something to work.

NOTE: this is not meant to be 100% technically correct. I'm going to confuse some terms, and mix some stuff up. But its OK, because I don't care. I just want it to be sufficiently correct so that I can get the thing to work next time.

I have used (or only realised I was using) encryption in these three main cases:

1. HTTPS sites
2. SSH  keys
3. SIP over TLS

The most important part of how SSL ensures that the traffic is safe is by authentication. By authenticating that the server is valid, it can use that fact to encrypt the traffic between the two.

Small excerpt: 

Authentication and encryption are two intertwined technologies that help to insure that your data remains secure. Authentication is the process of insuring that both ends of the connection are in fact who they say they are. This applies not only to the entity trying to access a service (such as an end user) but to the entity providing the service, as well (such as a file server or Web site). Encryption helps to insure that the information within a session is not compromised. This includes not only reading the information within a data stream, but altering it, as well.

While authentication and encryption each has its own responsibilities in securing a communication session, maximum protection can only be achieved when the two are combined. For this reason, many security protocols contain both authentication and encryption specifications.

These are few terms that we need to introduce first (again, not 100% correct, its just my version)

• SSL/TLS: I will be using these interchangeably. SSL is the predecessor of TLS. Both are used in browsers today. SSL and TLS run on top of TCP, and ensure the safety of the traffic.
• Key:  this is the signature of something. Used to verify its identity. For this discussion, we are talking about asymmetric keys, which consists of the public and private keys.
• Public Key: Used for verifying signatures and encryption  The public key of a site is distributed publicly. Clients use this to verify who the server is.
• Private Key: Used for signing and decrypting  Private keys are never distributed, and are guarded very seriously.
• PKI: This involves CAs, and how clients can verify certificates
• Public Key Cryptography: Messages encrypted with the public key can only be decrypted with the associated private key. Conversely, messages signed with the private key and be verified with the public key.
• RSA, DSA: a Key Exchange Algorithm
• X.509: the standard for certificates.
• Certificates contain public keys, and are signed by a CA.

SSL runs on top of TCP. This is how the protocol messages look like:

Ok, now lets see how these things come together in the different use cases:

HTTPS - Browser

Basically, the browser (client) sends a request to a website (server). The website responds with its certificate, which contains its public key. The browser can now verify that the website is really the server, and not someone else: The client is certain that the identity of the server is authentic. They agree on a key to encrypt the data, which itself is encrypted with the servers public key.

There is an element of trust. The browser trusts the CAs. So if a site says its certificate was signed by a particular CA, then once the browser verifies that fact (by checking the sites certificate was signed by the CA), it now trusts that the website is who it says it is. And that really is how SSL ensures safety: that the bank website that you are visiting is in fact the bank, and not an imposter trying to steal your credentials.

To get a publicly/CA signed certificate for a new website you want to host, you can go to Thawte or Verisign, and paste your CSR on the order form. Your CSR is generated on the server you want the certificate for. It will also generate an associated private key.
Once the CA verifies that you own the domain, they will sign the CSR with their private key, and issue you the signed certificate. You can now import this into your web server.
You can also use self-signed certificates, but browsers won't be able to verify the servers authenticity.

Mutual authentication can be used as well: where the server asks for the browsers certificate. This can be used e.g. to verify the person for access to a private site.

SSH

I needed access to an SSH server at work. The admins don't allow the use of username/passwords - only SSH keys are allowed. I generated a key pair on my local box, and sent them the public key. The public was put in the allowed-keys on the SSH server. When I SSH into that box, my SSH agent presents the private key. Thus only I can gain access to that box, but only my private key can decrypt messages sent with the public key.

SIP TLS

TLS can be used to encrypt SIP messages. You can encounter SIP over TLS in two ways:

• softphone to a SIP server: on your softphone, you can enable TLS, usually to a different port on the SIP server. The server will need a cert (self-signed will work) and private key. The softphone and server will then negotiate and encrypt the traffic.
• SIP trunk: In this case, you are setting up a SIP over TLS trunk between two SIP servers (perhaps MS Lync and an SBC). In this case, mutual authentication is required. For this to work, Lync and SBC need a certificates. We did not use a public CA, so we used self-signed certs. Each device generates a CSR, which gets signed by a CA. Then each device loads the cert, and the root/domain cert. During TLS negotiation, they exchange certificates, and because they are both signed by the same root, they are now authenticated. 

Here are some of the funnies I have come across:

• There are different types of certificates. From Thawte, you can buy SS123, WebServer, or code signing certs.
• Different formats of certificate files: .pem, .csr, p7b, pfx. Some are text based, and some are binary.
• Certificates have different usages: Server, Client, signing, etc
• you can use openssl to debug SSL issues. openSSL can act as a server or client, and can be used to negotiate and debug SSL
• wireshark can be used to debug SSL issues. Capture some traffic, and use Decode As if it does not automatically see the SSL (if different ports are used)

One common misunderstanding I had was that to enable authentication between two parties, they both needed the same certificate. One needs a certificate, and the other needs the associated root/private certificate

I found these links very usefull:

• http://security.stackexchange.com/questions/20803/how-does-ssl-work
• http://stackoverflow.com/questions/470523/how-does-ssl-really-work/7381711#7381711
• http://www.albertx.mx/blog/https-handshake/
• http://security.stackexchange.com/questions/12103/explanation-of-ssl-handshake-with-certificate