Humm, no reply so far, may be because my email was very long and no body bothered to read it all. Anyways, here is the shorter more direct version of it. (including kamailio dev list, since question is rather technical).
Is it possible to implement a custom SIP transport in Kamailio script file i.e. kamailio.cfg. The purpose is to allow experimentation with custom encryption algorithms such as this,
What we need is a couple of functions, one to receive incoming raw / encrypted data received on SIP socket, which then can be parsed / decrypted in kamailio.cfg (using e.g. LUA or PERL language modules etc.) and afterwords feed to kamailio for usual processing (as if it was normal / plain-text sip data received on sip socket). The second function to do the opposite, it receives the normal / plain-text sip data that is ready to be sent out from kamailio's core, encrypts it and then send it out to actual destination.
In case above is not possible. Can i do it in kamailio's native code? Any hooks / example code for reference?
Many thanks and kind regards for your help.
On Mon, Jul 28, 2014 at 2:38 AM, Muhammad Shahzad shaheryarkh@gmail.com wrote:
On 30/07/14 06:37, Muhammad Shahzad wrote:
If you look at encrypting sip messages, look at topoh module. You can write a replacement for its hooks. Topoh is practically decoding the headers and then lets the pure SIP message go through config file execution. Before sending, it encodes the headers and then let it go to the network.
This is something that should be rather straightforward to do if you are familiar with C code.
You mentioned that using TLS can still reveal patters of being sip. You have to think here of ways to obfuscate even in your case of a new encryption method. What can be matched here: - periodical registrations - you can have the client (or even the server) to use different expires times for each registration - size of packages, specially if user IDs are the same or similar length (e.g., say everyone uses a 10 digit id), practically no matter who is calling who, the size will be pretty much the same because most of the phones I have seen so far use same set of headers. Here you can add random custom headers for each packet. I haven't checked the proposed encryption algorithm (some use random blocks implicitly to pad the data), but eventually you can add random data before and after the packet that you strip (and re-add) in topoh-replacement module
The other option of having a totally different protocol than SIP should be possible as well. But you need to re-implement a lot (like location, authentication, ...). Look at msrp module for an example. This may need to touch core code a bit.
Of course, in both cases, the client application has to be developed as well. Perhaps still easier if going for first option, by reusing some open source sip client and adding the encapsulation/decapsulation layer when receiving/sending to network.
Cheers, Daniel
Thank you so much for this very useful information. I am working on first approach for the moment since its much simpler and easier to implement with only difference being that instead of per header or per sdp line, i plan to do it in one go, i.e. get entire sip message in $mb (sip message buffer), encrypt it and put it back in $mb.
- i guess randomizing registration time is already provided by kamailio. - yes packet sizes are a concern, so i already have planned for random padding as you mentioned.
For client app, i have a developed a basic prototype based on doubango framework. I am hopping to release a free and open source implementation using idoubs within next couple of months on Apple app store.
Thank you.
On Wed, Jul 30, 2014 at 12:22 PM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
On 30/07/14 11:52, Muhammad Shahzad wrote:
For a mobile device, an app is needed. But for a linux computer, it might works running a kamailio proxy there. Say you have many locations for a company, then within local network on each site can be sip and between sites, the encrypted signaling.
If kamailio uses a socket for clients and a socket for communicating with the other sides, then it is easy to tell to the new module for which socket should do encryption/decryption. Alternative is to provide either local network address or remote site address and match on src ip/dst ip.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Muhammad Shahzad