Secure WebRTC Authentication with SIP.js and Asterisk

Asterisk Asterisk Support
1

Hi everyone,

I’m working on a WebRTC system using SIP.js and Asterisk. I have a security concern about how to handle SIP credentials in the browser.

Current Problem:

After a user logs into my web application, I need to automatically establish a WebRTC connection. However, I don’t want to send the user’s SIP extension password in plaintext over HTTP from my backend server to the client browser, as this creates a security risk.

Current Flow (Insecure):

  1. User logs into web application
  2. Backend sends SIP credentials (extension + password) via HTTP/HTTPS to browser
  3. Browser uses these credentials with SIP.js to connect to Asterisk
  4. Problem: SIP password is exposed in HTTP response and browser memory

Desired Secure Flow:

  1. User logs into web application
  2. Backend generates an encrypted token containing SIP credentials
  3. Backend sends only the encrypted token to browser via HTTPS
  4. Browser passes this token to establish WebRTC connection
  5. Asterisk validates the token and allows connection without exposing the actual SIP password

My Questions:

  1. Is it possible to modify SIP.js authentication to use a token instead of plaintext password?
  2. Can Asterisk be configured to accept and decrypt custom authentication tokens?
  3. What’s the best practice for secure WebRTC credential handling in browser applications?

Thanks for reading, and I appreciate any guidance or suggestions!

2 Likes
2

So, SIP.js does not work without REGISTER, and technically, neither does Asterisk… well to be clear; when you establish a websocket connection asterisk will need you to send a REGISTER message in a short amount of time otherwise the socket connection is dropped.

This means you have to use a REGISTER, but also remember that REGISTER is not really an “authentication” feature, it’s a “location” feature. In a way, by registering you are announcing your location to the Asterisk server. Over the years Register has become more of an “auth”, but it’s a very very weak system.

In my opinion, I wouldn’t try to change the REGISTER, but I would add a JWT token to the INVITE, as a custom header. This can easily be done in SIP.js. Then on the Asterisk side, read the custom header (“X-Auth”), validate it, and either allow the call or no based on the outcome.

1 Like
3

Hi,

Could you please share the related error logs or documentation for the issue you’re facing? That way, we can review it and help troubleshoot the problem more effectively.

4

Hi,

Thanks for the reply. There are no specific error logs at the moment; the issue is more about securely handling SIP credentials. I want to replace sending the SIP password in plaintext with an encrypted token, which Asterisk can decrypt for authentication.

Thanks!

5

Thanks for the insight! I understand now that the REGISTER method is primarily for location and not authentication, and that adding a JWT token to the INVITE is a better approach for secure authentication. I’ll implement the custom X-Auth header in SIP.js and have Asterisk validate it for authentication.

I appreciate your suggestion and will move forward with this approach.

6

You are already sending an encrypted values; that’s what TLS does.

I have a feeling that you haven’t fully analysed the risks here. Often encryption of passwords simply leads to other attacks. In particular, it seems to me that you are trying to protect against a customer bypassing your web application, but they have total access to your client side code, and, if determined, could work out what it was doing, or run the relevant part under their control. I think you are looking for some form or security by obscurity, which is generally not considered good security.

7

JWT is a mature and secure form of authentication.

That being said, as with any authentication process it will rely on both a “something we know” (a password) AND “something we have” (the token). And when it comes to a browser the thing we have will stay in code, in the pc memory and technically accessible to the user.

The question now is more about “if I gave someone else, what I have, would that give them access?”, not that a user would intentionally do this - it’s about what if the users PC gets compromised, would the token be usable?

This thread sounds very much AI bot created, so ill leave this as is… but it’s lovely food for thought, especially considering the various ways you can validate a token, like date stamps validation periods etc. It’s fun and interesting. We are busy implementing something like this at Siperb - and we feel this is a secure a controllable foundation.

8

From an Asterisk code perspective there is no JWT mechanism built in. You can only check a custom header in the dialplan and do something that way. The architecture is written to allow other authentication methods to be added, but noone has done such a thing.