Skip to content

Fixed tls->verify_server #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Fixed tls->verify_server #7

wants to merge 1 commit into from

Conversation

attilabogar
Copy link

Created this patch, after installing blink on Arch Linux from AUR.

Couldn't get my-sip-account->advanced->TLS-Verify-Server working.
Without the TLS Server Verification the communication is vulnerable to MITM attack vectors.

My SIP server for testing was Asterisk 16.5.0 w/ chan_pjsip + TLSv1.2 and the certificate from letsencrypt. For letsencrypt I enabled CA: /etc/ssl/certs/DST_Root_CA_X3.pem

I've tested two use cases:

  1. NAPTR + SRV records, take a look at $ dig bogar.io NAPTR - SSL CERT CN: bogar.io
  2. NO NAPTR, NO SRV record, just defining outbound proxy w/ TLS - SSL CERT CN: vox.bogar.io

Reference:

@danpascu
Copy link
Contributor

danpascu commented Oct 9, 2019

This breaks the case for platforms that use multiple proxies by mapping the proxy host name to multiple IP addresses in DNS.

The reason the DNS lookup is performed in python is because pjsip's DNS lookup is broken. pjsip will do a DNS lookup for every request within the dialog, which means that in-dialog requests and the BYE can end up on a different proxies than the original INVITE. It seems to work in your case because you only have one IP address mapped for the proxy.

In addition other things depend on routes being IP addresses, like for example generating the contact URI, which with your change will do a name resolution that will block the twisted thread, whenever that contact is requested by sipsimple during the dialog and may even result in different contact URIs within dialog (for example in a call transfer when a REFER is sent).

@traud
Copy link

traud commented May 27, 2020

Can we go two steps back and first create a full-blown issue report?

The issue reported here affects all products from AG Projects based on SIP SIMPLE Client SDK. That means, tools like the SIP Clients and Blink are not able to connect via SIP over TLS, except:
A) the server presents a certificate with its IP address, or
B) you do not enable verify_server.

In other words: Even if the remote SIP server offers a valid certificate, with a domain in its certificate as usual, Blink is not able to validate that certificate.

Steps to Reproduce

  1. install Blink, for example, on Ubuntu 18.04 LTS …
  2. Menu → Blink → Preferences → (tab) Advanced → (TLS settings) Certificate Authority: /etc/ssl/certs/ca-certificates.crt
  3. add an existing SIP account, for example, 00038799999@secure.dus.net
  4. Menu → Blink → Preferences → (tab) Accounts → Advanced → Verify server

Note
Menu → Blink → Preferences → (tab) Accounts → Advanced → Certificate File is not about the server but just about a client certificate. Its value does not matter; even empty is possible.

Actual Result
When I dial any number, I get ‘503 SSL certificate verification error (PJSIP_TLS_ECERTVERIF)’.

Root Cause
SIP SIMPLE Client SDK resolves the hostname via DNS itself. In the example above, the hostname is ‘secure.dus.net’. Not the hostname but the resulting IP address is passed to PJSIP. PJSIP is included in the SIP SIMPLE Client SDK as SIP stack. Consequently, because PJSIP only got an IP address, remote_name is not a hostname but an IP address. Therefore, the domain in the server certificate does not match. pjsip/src/pjsip/sip_transport_tls.c:on_connect_complete(.) returns PJSIP_TLS_ECERTVERIF. Furthermore, the PJSIP internal verify_status of its ssl_info is not PJ_SUCCESS but PJ_SSL_CERT_EDIDENTITY_NOT_MATCH.

Step Two
I was able to reproduce this with Blink and the command sip-audio-session --config-directory=~/.blink 00038799999. AG Projects team, are you able to reproduce and verify my analysis?

Approach A
Attila’s approach was to disable the DNS resolution, in case of SIP over TLS, and therefore provide the domain to PJSIP. PJSIP then does the DNS resolution. However, when the SIP provider does non-transparent load-balancing, the SIP provider offers several servers via DNS-SRV or DNS-A(AAA). In that case, PJSIP does not cache the very first chosen IP address but resolves the IP address again and again. That fails if:

  • the SIP provider uses Round-robin DNS and
  • the SIP provider does not sync the state between its servers.

How to apply Attila’s approach even for Blink?

sudo apt install build-essential debhelper dh-python python-all-dev python-all-dbg cython-dbg libasound2-dev libssl-dev libv4l-dev libavcodec-dev libavformat-dev libavutil-dev libswscale-dev libx264-dev libvpx-dev libsqlite3-dev pkg-config uuid-dev
darcs get --set-scripts-executable http://devel.ag-projects.com/repositories/python-sipsimple
cd ./python-sipsimple
wget github.com/AGProjects/python-sipsimple/pull/7.patch
patch -p1 <./7.patch
sudo python setup.py install

Approach B
If AG Projects does not like the DNS resolver of PJSIP, what about upgrading the struct pjsip_tls_setting with a field like verify_servername? That could be copied over to the PJSIP internal struct tls_transport and then used in on_connect_complete(.).

Approach C
Until this is fixed, AG Projects, please, change the user interface at least in Blink and that verify_server works only with IP addresses and not with domains. A similar test/warning could be added to the SIP SIMPLE Client SDK. Perhaps even a link to this issue here. Normally, a user thinks he did something wrong and tries around. Attila invested some time, I invested some time, even on your mailing list, several users asked.

pjsip's DNS lookup is broken. pjsip will do a DNS lookup for every request within the dialog

@danpascu, do you have an open issue with the PJProject?

@adigeo
Copy link
Member

adigeo commented May 27, 2020

Approach B sounds reasonable. If you can provide a patch for existing codebase we are willing to look at integrating it.

@adigeo
Copy link
Member

adigeo commented Feb 9, 2021

All new developments take place here

@adigeo adigeo closed this Feb 9, 2021
@adigeo
Copy link
Member

adigeo commented Apr 17, 2021

Implemented in AGProjects/python3-sipsimple@799a0b6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants