[SR-Users] Obscuring SIP traffic and using with NoSIP
Daniel-Constantin Mierla
miconda at gmail.com
Wed Jul 30 12:40:40 CEST 2014
On 30/07/14 11:52, Muhammad Shahzad wrote:
> 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.
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
>
> Thank you.
>
>
>
>
> On Wed, Jul 30, 2014 at 12:22 PM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto: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 <mailto: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.com
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140730/2bdb6890/attachment.html>
More information about the sr-users
mailing list