Chapter 4. Certificates for Endpoint Security
We only need to be lucky once. You need to be lucky every time.
The IRA to Margaret Thatcher, after a failed assassination attempt
If you really want to do something, you’ll find a way. If you don’t, you’ll find an excuse.
Jim Rohn
The Inconvenience of Security
VoIP security can be regarded as two separate (but interconnected) challenges:
Securing a system against toll fraud (which is generally the goal of SIP-based intrusion attempts)
Securing a system against call interception (which relates to privacy, as well as improving toll fraud defenses)
There are of course many other aspects to the security of your system, but most of those are general security concepts, not specific to VoIP.
In this chapter we will focus on an area of security that is too often overlooked, namely the generation and application of certificates and keys in order to secure communication between endpoints and your system. In SIP communications, encryption is optional (and, unfortunately, not used most of the time). In WebRTC, it is required.
This chapter should by no means be considered the final word on securing your Asterisk system; there will be more covered in Chapter 22. We do hope, however, that it will provide you with a solid foundation on which to build a secure solution.
Securing SIP
If you build any sort of server that is exposed to the internet, and wait for a few short hours after powering it up, you will notice that the system will have already attracted probes attempting to determine if it has any vulnerable SIP services. You will then notice, a short while later, an increasing amount of attacks on the server attempting to compromise account security. Congratulations, your server has automatically been added to lists of SIP servers shared by criminals for the purpose of fraud. If one of these intrusions succeeds, the compromised platform will likely become part of an organized crime network, with you paying the bill for untraceable calls to various expensive destinations.
Warning
We’re not playing around here; do not take your SIP security lightly or you are likely to find yourself the victim of a very expensive fraud attack.
Subscriber Names
The subscriber portion of the SIP credentials (the userinfo part of the URI) is far too often set
to an extension number. This practice is fine for the purposes of
addressing calls, but is not at all recommended for the purposes of
authenticating an endpoint. The subscriber name of your endpoints should
have no meaning outside of your organization. A MAC address is perfect
for this. Without an actual address to probe, an attacker’s job just got
a lot more difficult.
You will see many SIP-type PBXs (including many based on Asterisk, unfortunately) that assign the extension number to the credentials of the phone. In this book, you will see that the extension number is not part of the phone credentials. There are several benefits to this, but from the perspective of security, the benefit is that if an attacker knows an extension, it does not provide any knowledge about how to authenticate a call through the system.
So, you might have a user with the SIP address [email protected], which your Asterisk system
will associate with the device at [email protected]. When a call is
directed to 100, it will ring
0000f3101010, but the caller never
knows anything about that endpoint.
You will see throughout this book that we will establish a relationship between an extension (which we believe is something that should be associated with a user or service) with a device identifier (which could be a SIP device or a phone number), and that a simple table can be used to tie them together (and subsequently increase both security and flexibility).
Secure SIP Signaling
By default, SIP messaging is passed in the clear, with no effective security. A man-in-the-middle attack is capable of obtaining all sorts of information about your calls. Transport layer security (TLS) is used to minimize this risk.
We’ll talk more about how to configure devices to use TLS in the next chapter. All we need to do here is create the certificates.
There are three common ways to generate certificates. We’ll provide examples for two of them (self-signed and LetsEncrypt), but will leave the exercise of obtaining formally issued certificates to the reader.
Self-signed certificates
The primary advantage of a self-signed certificate is that you don’t have to validate it with any external entity. The disadvantage is that because of this, external entities will not trust it.
If you are securing SIP devices only for use within your controlled network environment, a self-signed certificate may be all you need. This is not considered the best approach, but in some cases it may be good enough, and it’s generally better than nothing.
In this world full of automated crime, there is much to learn about privacy and security, and the cryptography necessary to both. However, this is a book about Asterisk, so what we are going to do is provide a template for generating the required components, and it’ll be up to you to research further.
The openssl toolkit provides a tool that’ll
get the job done for us. We’ll run it as follows:
$ sudo su asterisk - $ mkdir /home/asterisk/certs $ openssl req -x509 -nodes -newkey rsa:2048 -days 3650 -keyout /home/asterisk/certs/self-signed.key -out /home/asterisk/certs/self-signed.crt
You will be asked to provide some information, and then your key and cert will be written to the /home/asterisk/certs folder.
You can add the following to the command to bypass the questions (change the information as appropriate to your situation):
-subj "/C=CA/ST=Ontario/L=Toronto/O=ShiftEight/CN=shifteight.org"
The full command should then look something like this:
$ openssl req -x509 -nodes -newkey rsa:2048 -days 3650 > -keyout /home/asterisk/certs/self-signed.key > -out /home/asterisk/certs/self-signed.crt > -subj "/C=CA/ST=Ontario/L=Toronto/O=ShiftEight/CN=shifteight.org"
This will generate a self-signed certificate and a private key, and save them both to /home/asterisk/certs/. We can use them later when we are configuring our SIP endpoints.
It’s probably a good idea to chmod your certs
so only the relevant user/group can access them:
$ chmod 640 /home/asterisk/certs/*
Exit the asterisk user account.
$ exit $ who am i # You should be astmin again.
There is an alternative to using self-signed certificates: if you have a domain name assigned to your server that can be reached from the public internet, you can generate a validated certificate using LetsEncrypt. Read on.
LetsEncrypt certificates
If you are interested in secure communications across the public internet (which you are, trust us), then having domain certificates provided by a certificate authority (CA) is useful.
The LetsEncrypt project provides free domain validation (DV) digital
certificates. The free tool provided by the Let’s Encrypt Foundation
called certbot allows you to
automate the obtaining and maintenance of trusted certificates.
At a minimum, your server will need a fully qualified domain name (FQDN) that maps to an external IP address that arrives at the machine. Any firewall in between will need to pass traffic for that hostname to the system you are obtaining the certificate for. If you cannot do this for whatever reason, the obtaining of a trusted certificate becomes more complex (and beyond the scope of this book).
certbot can be installed with yum as
follows:
$ sudo yum -y install certbot
Once it’s installed, you simply need to run the following:
$ sudo certbot certonly How would you like to authenticate with the ACME CA? ------------------------------------------------------------------------------- 1: Spin up a temporary webserver (standalone) 2: Place files in webroot directory (webroot) ------------------------------------------------------------------------------- Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
If you’ve got a web
server running, or are confident with option 2, that is OK, but these
steps assume you don’t have a web server running, and thus will
need/want to use the built-in temporary web server that
certbot will use to authenticate. This server is
used to prove that you control the domain you’re requesting a
certificate for.
Answer the next questions as appropriate, and then at this point you will insert the hostname that you assigned to the IP address of your server:
Please enter in your domain name(s) (comma and/or space separated) (Enter 'c'
to cancel): asteriskbook.shifteight.org(replace
asteriskbook.shifteight.org with the domain
name you assigned).
certbot will perform its magic, and if all
went well you should get some sort of message similar to the
following:
IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/asteriskbook.shifteight.org/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/asteriskbook.shifteight.org/privkey.pem Your cert will expire on 2018-07-23. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
You now have the certificates you’ll need for enabling various TLS services on your system. We’ll put them to use in the next chapter.
Not too difficult, eh?
Note
Bear in mind that most certificates you get from an outside source will have an expiration date. In the case of LetsEncrypt, the current validity is three months. If you are going to put certificates into production, it is up to you to understand how to manage them (for example, automating renewal, which the LetsEncrypt folks have done a good job of simplifying).
Purchasing certificates from a formal certificate authority
If LetsEncrypt certificates do not provide the level of validation you require—for example, if you need organization validation (OV) or extended validation (EV)—you will need to obtain the services of a certificate authority that provides such things. These matters are beyond the scope of this book.
If you have worked through the examples for the self-signed and LetsEncrypt sections, you’ll have at least a basic understanding of some of the process of obtaining certificates from a certificate authority, as many of the steps will be similar.
Securing Media
The certificates we’ve obtained can be used to secure both our signaling, and the payload itself (i.e., what’s being spoken, or the video being transmitted). Note that the mechanisms to secure signaling are an SIP protocol thing, and the mechanisms to secure the media are an RTP protocol thing. Keep in mind that encrypting your SIP signaling does not mean you’re automatically also encrypting your media (RTP) traffic.
Encrypted RTP
Encrypting the Real Time Protocol will achieve the effect of securing our media streams.
There are two mechanisms commonly used to provide media encryption: SDES and DTLS-SRTP. SDES is a media encryption mechanism that trusts that the signaling is secure. In other words, if you are using TLS to secure your SIP signaling, then SDES is likely how your media encryption is being handled.
DTLS-SRTP, on the other hand, does not trust the signaling. It is important because the WebRTC standard requires that media be encrypted this way.
The certificates we’ve generated here should work in both scenarios. In upcoming chapters, when we are configuring SIP or WebRTC endpoints, we will cover in more detail how to use the certificates. For now, it’s enough that we’ve generated the certificates and have them available for use.
Conclusion
Make no mistake: security makes everything more complicated. In the good old days, you could fire up a SIP connection with a half-dozen lines of config and call it a day. That doesn’t fly anymore, and while that type of configuration will still work (simply use UDP instead of TLS, and all you need is a password), we decided that starting with this edition, all configuration examples will choose more secure options wherever possible. We’re not claiming to present the final word on VoIP security, but we are going to deliver examples that pay more than lip service to the concept.
Next up, we’ll discuss how to configure endpoints on your Asterisk system (using the keys and certificates we’ve just generated).