FreePBX | Register | Issues | Wiki | Portal | Support

Encrypt sip traffic on local network

Tags: #<Tag:0x00007fcd224d72d0>

(Jared Busch) #21


All of it.

That said, I 100% care about TLS for the SIP registration. Because most of my systems are publicly hosted and I don’t want the clear text extension credentials flying around when the users pop their SIP based smart phone app open on random_wifi_01.

(Tom Ray) #22

And that is 100% acceptable because 1) The provisioning server doesn’t have to be the PBX. 2) It doesn’t add load to Asterisk or the actual SIP system by doing real-time decryption/encryption on 100’s of packets at a time.

That said, having a locked down provisioning system is what I consider part of standard security for a voice provider or a hosted system for a company with dynamic sources.

(Jared Busch) #23

I said SIP registration. Not provisioning.

Because as you noted provisioning is a totally separate thing.

(Tom Ray) #24

Ahh, yeah you did. In that case there are no plain text details “flying around” because that’s not how SIP auth works. REGISTER, SUBSCRIBE, INVITE, etc all those use the same auth process.

You’re going to see something like this in the 401 Unauthorized being sent to your device to force it to auth.

WWW-Authenticate: Digest realm=“authrealm”, nonce=“XAcNxVwHDJl1Nj3MEoY+hn4yaIUFrgHJ”

Then you’re device will send back a new request with the auth headers:

Authorization: Digest username=“authuser”, realm=“authrealm”, algorithm=MD5, uri=“sip:uridomain”, nonce=“XAcNxVwHDJl1Nj3MEoY+hn4yaIUFrgHJ”, response=“a5ef09de1e4d9b240210f0b36a7e

So based on the realm and the nonce provided by the REGISTRAR the device will build the response based on that information which generates the MD5 hash response in the Authorization header. That hash should match the hash the REGISTRAR has. At no time is your SIP password ever passed in an auth attempt.

The only time they could easily gleam your password like that is if they spoof your MAC and pull your config which is 100% plain-text unless you have TLS for it.

(Jared Busch) #25

It was my understanding that the register was clear text and contains my id. Was my understanding wrong?

I know the password was sent nonced.

Just a little more security by wrapping that register in TLS.

(Tom Ray) #26

No, it’s in clear text and it does contain your user id but that’s it. The noonce is a one time thing for that transaction. Regardless if it really is the password it is an encrypted version of it and it dies after the transaction is finished or expired. So if I was to snoop an auth request made by you device and I got the nonce, great. When I go to use that noonce again it won’t be valid. It was either already used and deleted or it is expired and a new on is generated.

After your first registration with the REGISTRAR your next re-register will attempt to re-use the noonce and then REGISTRAR will go “Oh this is expired, here’s a new one. Try again” (ala 401) and the process is repeated. Your password is not exposed, the noonce exists per transaction and then it goes away.

You also cannot just do REGISTER over TLS and then not do everything else over TLS. Most devices won’t let you use insecure RTP when a TLS transport is being used and you just can pick a transport with each type of request.

Auth is auth and the three basic common methods that use it are REGISTER, SUBSCRIBE and INVITE. There is no difference in the process between the three. Again the only time your password is exposed is during the provisioning process if you are pulling configs with a non-TLS method.

And I’m not try to take a dig or flame you with this next comment but this goes right to my previous point of security becoming just things that are there. You wanted X for Y because of Z reason except Z reason actually isn’t a thing that exists so it makes the need of X for Y pretty moot. Doing X at that point is just for the sake of saying “Security!” and adds more load/overhead that really isn’t needed.

(Jared Busch) #27

I know how a nonce works. I know the password is never clear text. Having a valid auth id is half the puzzle though. When you connect to a pineapple and don’t know it you are giving a lot away.

Setting up TLS is trivial. Security that is significant work is important to cost analize, but TLS registration should not one of them. Your instance will have a LE (or some other) cert already if you are hosting on public clouds as I do. So to enable it for registration is a simple matter of selecting the cert in the Advanced Asterisk SIP settings and changing your phone to use TLS on port 5061.

Yealink, Snom, and Sangoma phones can all do it just fine. Some easier to setup than others depending on your provisioning method. I would assume Grandstream can to, but I don’t have any.

(Tom Ray) #28

Nor is the password, alone, in any form. The nonce is used with the password to create the the MD5 response it expects from the client. It’s why the nonce is provided in the WWW-Authenticate or other forms. There is also the qop option that depending on qop setting the responses and hashes are generated differently.

You understand that PBXes and SIP platforms can have the same user/auth id’s across them. How many have extensions 100, 101 or 1000 or 200, 201, etc, etc, etc. I watch SIP attacks happen every day and they are attempting with those standard types of auth ids. So they are either guessing at the passwords and/or they are hoping for insecurity on the network like not authing INVITEs from users. They don’t need to “snoop” you to get your auth id, they just use something a long the lines of a “dictionary attack” to try all the standard combinations of usernames.

No one needs to be “registered” to make calls as a SIP user, REGISTER just tells the system where you are located and unless they have certain measures in place they’ll auth INVITEs (or not) regardless if there is an “active” registered location.

I run three different ITSP’s networks for their end users and clients. All of them are “hosted” in the regards everything is in the cloud. Making everything TLS as a core security measure has never been a priority or an actual need. Hasn’t been now or in the past decade+.

Basically relying on TLS as your security method for your voice network is like relying on IPv6 so that you don’t have “NAT Issues”.