[sr-dev] Obscuring SIP traffic and using with NoSIP

[Muhammad Shahzad]

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 at gmail.com> wrote:

>
> On 30/07/14 06:37, Muhammad Shahzad wrote:
>
>  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,
>
> https://github.com/mshary/itv
>
>  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?
>
> 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
>
>
>
>  Many thanks and kind regards for your help.
>
>
> On Mon, Jul 28, 2014 at 2:38 AM, Muhammad Shahzad <shaheryarkh at gmail.com>
> wrote:
>
>>   Hi,
>>
>>  As the mobile voip is getting more and more popular these days, there
>> has been a strong opposition from GSM operators against mobile voip apps.
>> They often use tactics like blocking voip ports, or detect and block voip
>> traffic and in some cases restricting udp traffic altogether to very low
>> upload and download speeds. See below link for some details,
>>
>> http://www.linphone.org/eng/blog/linphone-over-3g.html
>>
>>  While not all the problems can be solved right now (especially the
>> limiting udp traffic, since RTP always uses udp transport) I was wondering
>> if we can at least handle the sip related problems. The most important of
>> them is SIP traffic detection. While some forks would suggest using TCP/TLS
>> to encrypt SIP traffic, it has a few problems, e.g.
>>
>>  1. It requires somewhat high resources on mobile devices, so many
>> low-end android phones simply can't use it.
>>
>>  2. There is possibility that encryption signature may identify it as SIP
>> traffic. There exists firewalls (often deployed in middle eastern
>> countries) which have huge database of encryption signatures and patterns
>> which although may not decrypt the sip packet but at least identify it as
>> sip packet and block it.
>>
>>  Also with rough agencies of evil empires spying over millions of users
>> worldwide makes the current encryption standards pretty much pointless, at
>> least in terms of user privacy and network security. So there is a strong
>> need to experiment with new ideas and concepts to regain internet freedom.
>> Some of such ideas are,
>>
>>  1. Convert sip traffic which is plain text to binary format just before
>> transmitting it and revert it to plain text upon reception.
>>
>>  2. XOR the sip traffic (pretty much same as binary sip).
>>
>>  3. Use some very lightweight but effective / non-standard encryption
>> algorithm, e.g.
>>
>> https://github.com/mshary/itv
>>
>>  All these ideas require that SIP server such as Kamailio is able to
>> adopt to these, preferably with minimal or no change in native code. The
>> NoSIP module seems an interesting module in this regard. It provides all
>> traffic it thinks is not the SIP traffic to configuration script, where we
>> can do our own parsing and do whatever we want with it. I have two
>> questions about this,
>>
>>  1. If parsed message is SIP, we can we send it back to kamailio core to
>> get it processed as if it is a normal SIP message received by kamailio?
>>
>>  2. Can this module or any other module available in kamailio, that can
>> provide us full sip packet that is about to be transmitted over sip socket,
>> so we can "encode" it just before it is sent to next hop?
>>
>>  I know this would be like writing a SIP transport in kamailio script
>> which would be very tough if not impossible to implement in native core.
>> But it will really help in winning the modern mobile voip challenges.
>>
>>  Thank you.
>>
>>
>>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140730/7fbb5d38/attachment.html>