Secure VoIP SRTP/ZRTP as per the RFC
Recently today i installed few new SRTP/ZRTP VoIP apps for testing. Until now was sure only about HW encryptions on routers, mainly Cisco.
Had some issues to get everything running properly.
There were a small changes to my laptop configs lately, but normal VoIP traffic and clients are running the whole time. So I wasn’t convinced it
effected anything since all my clients continued to work properly, except ZRTP Jitsi.
Obviously
something had changed but no one around
knew what it was :D
After some testing I discovered the problem!
It was
related to insecure port connections from Jitsi, on port UDP 5060 to ostel .co servers. Secured connections runs on port TCP 5061 - and these were working as expected.
To make matters more confusing, I could register and make calls with
two different softphones (CSipSimple and Linphone) on the same network, using the same ports for insecure connection to ostel.co on UDP
port 5060.
WTF?
Probably the Jitsi is buggy ... but something just wasn't seem right -- do you know that feeling?
So, I went back to my configs and pulled the SWARM backups.
(Thanks to Notepad++ for Compare Plugin)
What
could the "server" be doing to this poor bastard?
With a WireShark running, tracerouting and pinging with crafted packets to OSTN servers, Jitsi running as well with extra tcpdump filtered packets only for UDP port 5060.
When I opened Jitsi and (i) nfo -- things got much more interesting.
For the
curious, here’s the utility and options I used.
In case you are new to
operating a SIP network, ngrep is an excellent tool for debugging ;)
[code]ngrep -d eth0 -t -p -W byline foo port 5060[/code]
I’ll include just an excerpts (only relevant headers) of the initial request from Jitsi.
So, on Jitsi app i can see below:
[code]
Audio info :
Media stream transport protocol : UDP / SRTP
(Key exchange protocol: ZRTP TWO-CM-256/EC25)
Codec / Frequency : SILK / 24000 Hz
Local IP / Port : 10.168.10.35 / 5020 <<<<
Remote IP / Port : 66.151.32.200 / 38944
Bandwidth : ↓ 14 Kbps ↑ 30 Kbps
Loss rate : ↓0% ↑ 0%
Packets decoded with FEC : 0
Packets currently being discarded : 51%
Number of discarded packets : 1392
(0 late, 1384 full, 8 shrink, 0 reset)
Adaptive jitter buffer : enabled
Jitter buffer : ~160ms; currently in queue: 8/16 packets
Jitter : ↓ 5 ms ↑ 2 ms
[/code]
** IP addresses and
usernames have been changed to protect the innocent **
[code]
U 2017/03/09 13:17:34.920749 0.0.0.0:5060 -> 66.151.32.200:5060
REGISTER sip:ostel.co SIP/2.0.
CSeq: 1 REGISTER.
From: "foo" ;tag=1eb3467e.
To: "foo" .
Via: SIP/2.0/UDP 0.0.0.0:49152;branch=z9hG4bK-393535-2269e43afef0b312554eb419a8d0540e.
User-Agent: Jitsi2.3.4752Linux.
Contact: "foo" ;expires=600.
[/code]
#
[code]
U 2017/03/09 12:17:34.921155 66.151.32.200:5060 -> 0.0.0.0:5060
SIP/2.0 401 Unauthorized.
CSeq: 1 REGISTER.
From: “foo” ;tag=1eb3467e.
To: “foo” ;tag=e01f0de2cdfebbeefc5ff0c8eabbb8b3.2f1f.
Via: SIP/2.0/UDP 0.0.0.0:49152;branch=z9hG4bK-393535-2269e43afef0b312554eb419a8d0540e;rport=5060.
WWW-Authenticate: Digest realm=”ostel.co”, nonce=”Uen0alHp8z4d6ePDl83RtMwARltAxzQu”, qop=”auth”.
Server: kamailio (4.0.2 (x86_64/linux)).[/code]
If you read the response, you’ll see Kamailio sent 401 Unauthorized.
This is normal for SIP authentication. A second client request should
follow it, which should contain an Authorization header with an md5 and a
nonce. When Kamailio receives this request, checks the auth database
and sends a 200 OK response, the client is authenticated.
The SIP dialog looks good but Jitsi continues not to register. The
dialog flow is cut off after the 408 Unauthorized response. It’s almost
like something has blocked the response to the client.
Since I could register Linphone using the same account, I did the same trace for that client.
Here’s the excerpt.
[code]
U 2017/03/09 12:33:18.372770 0.0.0.0:42680 -> 66.151.32.200:5060
REGISTER sip:ostel.co SIP/2.0.
Via: SIP/2.0/UDP 0.0.0.0:49153;rport;branch=z9hG4bK359459505.
From: ;tag=142131416.
To: .
CSeq: 3 REGISTER.
Contact: .
User-Agent: LinphoneAndroid/2.1.2-1-g23b7fc0 (eXosip2/3.6.0).
.
[/code]
#
[code]
U 2017/03/09 12:33:18.373112 66.151.32.200:5060 -> 0.0.0.0:42680
SIP/2.0 401 Unauthorized.
Via: SIP/2.0/UDP 0.0.0.0:49153;rport=42680;branch=z9hG4bK359459505.
From: ;tag=142131416.
To: ;tag=e01f0de2cdfebbeefc5ff0c8eabbb8b3.4065.
CSeq: 3 REGISTER.
WWW-Authenticate: Digest realm=”ostel.co”, nonce=”Uen4GlHp9u4FwHNY/uE1iQQNCfGHJiob”, qop=”auth”.
Server: kamailio (4.0.2 (x86_64/linux)).
[/code]
This 408 Unauthorized response was received by the client and the
follow up request with the Authorization header was sent with the
correct digest. Linphone registered. I made a call. Everything worked
fine. So WTF is happening?
I stared at these traces for a while to get a clue.
Look again at the
first line of the request from Jitsi.
You’ll see a timestamp followed
by two IP:port pairs.
Notice the port on the first IP is 5060 and the
port on the second IP is also 5060. This means that the
source port
used by Jitsi on my home network is UDP port 5060. In order for a
response to come back to Jitsi, it must enter my network on the same
port it exited. Now read the top line of the response from Kamailio.
Indeed, the server sent the response to UDP port 5060.
Now look at the same flow for Linphone. There is a very different
source port in that dialog. In this case, Kamailio sent the response to
UDP port 42680 and Linphone received it. Also notice the IP address used
by Kamailio as the destination of the response is the same one in the
dialog from Jitsi.
The question remained, why can’t Jitsi get the same kind of SIP
response on UDP port 5060? Why is Jitsi using a single source port for
outgoing traffic anyway? That value can be dynamic. I configured Jitsi
to use a different port for insecure SIP. It has an advanced
configuration for SIP with the key “SIP client port”. I set this to 5062
(5061 is conventionally used for secure SIP traffic so I incremented by
2) and tried to register again.
SUCCESSSSSSSSSSSS!
To be thorough, I changed Jitsi’s SIP port again to a 5 digit number I randomly typed on my keyboard without looking.
SUCCESSSSSSSSSSSS!
So if Jitsi can register to Kamailio on any port other than UDP port
5060, WTF is going on? I had a suspicion. I tried one more test before I
called it. I configured Jitsi to connect on TCP port 5060. It
registered successfully. Now I know what’s going on. I had a sad
CONCLUSION
My ISP, has a firewall running somewhere upstream that blocks
incoming UDP traffic to port 5060. This probably falls under their TOS
section which forbids “running servers” since Verizon provides voice
services for an additional fee on top of data service, despite both
running over the same fiber connection to my house. It seems like
Verizon doesn’t want their data-only customers to get in the way of that
sweet cheddar delivery each month in exchange for “phone service”.
This sucks on two levels.
LEVEL 1
Why is my ISP censoring my incoming traffic when I have 5 mbps of
incoming bandwidth? I assume the answer is “because they can.” *desolate
frowny face*
LEVEL 2
Why doesn’t Jitsi use a dynamic source port for SIP requests? I
assume the answer is “Jitsi is open source, why don’t I change this and
send a patch upstream?”
Both levels are formidable challenges to overcome. Convincing Verizon
to play nice on the Internet feels like a vanity project. I’m writing
that off. To make a change to the SIP stack in Jitsi is well within the
area of the GP team’s expertise, myself included but it’s not a trivial
undertaking. Since this is a default configuration change there is
probably a reason upstream devs made this choice so in addition to the
programming work there’s the work to convince the developers this would
be a change worth a new release.
Since this is specific to Jitsi, I’m going to follow up with the
developers and see if I missed anything. Stay tuned for part two.
Thanks for listening. Stay safe!
