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 < mico...@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 <shaherya...@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 > >
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
