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

Muhammad Shahzad shaheryarkh at gmail.com
Sat Aug 2 03:33:01 CEST 2014


OK, i realize my mistake, SREV_NET_DATA_IN event is processed before
msg->rcv info is set. This is kind of nice since we get completely raw
message direct from receive socket. :)

Thank you.




On Fri, Aug 1, 2014 at 5:49 AM, Muhammad Shahzad <shaheryarkh at gmail.com>
wrote:

> OK, so writing kamailio module was fun and easy. All thanks to
> Daniel-Constantin for providing very useful hints, it took hardly 2-3 hours
> to write up a functional module that exposes data received on kamailio
> socket and data that is about to be sent out, in an event route, where it
> can be manipulated e.g. to encode and decode per custom encryption
> algorithms defined by script writer. Here is bleeding edge code,
>
> http://webrtc.voip-demos.com/obfuscate.c.txt
>
> Most of the code is borrowed from topoh, nosip and msrp modules and works
> fine. There is just one little problem, that is unlike nosip module, the
> event route for obfuscate module gives error when i try to print source
> address using $si and $sp variables.
>
> Here is an example kamailio.cfg
>
> ========================
> loadmodule "nosip.so"
> loadmodule "obfuscate.so"
>
> ...
>
> event_route[nosip:msg] {
>     xlog("L_INFO", "[$pr:$si:$sp]: Received nosip message '$mb' \n");
> }
>
> event_route[obfuscate:msg] {
>     if (is_msg_obfuscated()) {
>         xlog("L_INFO", "[$pr:$si:$sp]: Received obfuscated message '$mb'
> \n");
>         $avp(msg) = $mb;
>     } else {
>         xlog("L_INFO", "[$pr:$dd:$dp]: Sending obfuscated message '$mb'
> \n");
>         $avp(msg) = $mb;
>     };
> }
> ========================
>
>
> using telnet when i send some random junk i get following in kamailio logs,
>
> ========================
> webrtc[13284]: : pv [../../parser/../ip_addr.h:669]: ip_addr2sbuf(): BUG:
> ip_addr2sbuf: unknown address family 0
> webrtc[13284]: INFO: <script>: [NONE::0]: Received obfuscated message
> 'lkasndkasldnaklsndklaskndklasnkldnasklndklasndlkasndkasndlkasnkldanskldnaslkdnlkasndlkasnldnaskdnlasdn#015#012#015#012'
>
> webrtc[13284]: INFO: <script>: [tcp:192.168.100.11:55206]: Received nosip
> message
> 'lkasndkasldnaklsndklaskndklasnkldnasklndklasndlkasndkasndlkasnkldanskldnaslkdnlkasndlkasnldnaskdnlasdn#015#012#015#012'
> ========================
>
>
> Can you guys give any hint, what is wrong here? The "received msg" code is
> almost identical to nosip module yet, nosip module is able to show $si and
> $sp values while my module can not.
>
> Also is it possible to expose destination socket address (ip + port) for
> "sent msg" (i.e. the destination socket where kamailio is about to send
> some sip message).
>
> Thank you.
>
>
>
>
> On Thu, Jul 31, 2014 at 4:38 PM, Muhammad Shahzad <shaheryarkh at gmail.com>
> wrote:
>
>> Thanks for good insight in to this topic.
>>
>> As mentioned in my first email, there are a number of reasons for trying
>> out custom encryption schemes. Low-end android devices is just one of them.
>> There is a huge market for low-end android devices in south and south east
>> Asia for example, where over 35% of world population lives. The people
>> there are poor and don't have much understanding of latest cutting edge
>> smart devices and related technologies. Big brands like Apple, Samsung,
>> Nokia etc. are virtually non-existent or have so high price that people
>> simply can't afford them. So cheap Chinese and Indian cell phones which
>> barely run Android are considered "smart phones" and are very popular here.
>> Using SSL, TLS, DTLS etc. are nightmare on these devices.
>>
>> The other reasons to develop and try out custom encryption algorithms are
>> voip blockage by GSM providers in various Middle Eastern and European
>> counties,
>>
>> http://www.linphone.org/news/11/26/Linphone-over-3G.html
>> http://xerocrypt.wordpress.com/2012/07/06/inspecting-your-packets/
>>
>> http://www.telecomrecorder.com/world-premium-telecom/pak-telecom-authority/pta-and-ip-blocking/
>>
>> And the rogue agencies of evil empires,
>>
>> http://en.wikipedia.org/wiki/Five_Eyes
>> http://en.wikipedia.org/wiki/PRISM_%28surveillance_program%29
>>
>> http://en.wikipedia.org/wiki/Booz_Allen_Hamilton#Activities_in_foreign_countries
>>
>> http://www.itv.com/news/update/2013-09-06/report-us-and-uk-agencies-cracked-encryption-codes/
>>
>> Nearly all encryption algorithms are defined and advocated by US and UK
>> intelligence agencies and it is quite obviously possible that they either
>> have crack or backdoors into them. So, we can't blindly trust them anymore
>> and should look into defining our own algorithms and security standards.
>>
>> Just to note, i don't claim that ITV or any other custom encryption
>> discussed here can or would resolve all these problems. The main focus is
>> on trying something new and out of the box to improve the voip and network
>> security conditions. I find Kamailio as open source SIP server and doubango
>> as open source SIP SDK as best platforms for these efforts and
>> experimentation.
>>
>> Thank you.
>>
>>
>>
>>
>> On Thu, Jul 31, 2014 at 2:08 PM, Daniel Tryba <daniel at pocos.nl> wrote:
>>
>>> [remove dev from cc]
>>>
>>> > The key purpose of ITV encryption is to avoid making a pattern of any
>>> sort.
>>>
>>> The pattern is in SIP itself, regardless of encryption.
>>>
>>> -OPTIONS keepalives and response at regular intervals of nearly fixed
>>> size.
>>> -INVITE and its predictable responses of nearly fixed sizes per type
>>> followed
>>> by a steady stream of upd on random ports with the same bandwidth
>>> flowing both
>>> sides.
>>>
>>> Unless this random utp traffic is encrypted it is obvious you are using
>>> rtp
>>> with something like SIP. Even if it is encrypted the symmetric streams
>>> give
>>> away clues. A simple xor isn't enough, silences will result in the same
>>> pattern.
>>>
>>> Daniel(-Constanting) already suggested interval randomizing (which is to
>>> be
>>> applied to any response) and padding of all data.
>>>
>>> But I wouldn't trust any non vetted encryption scheme, it is much easier
>>> to
>>> fix timing/padding with the standard tls scheme. Which brings me to the
>>> question: what kind of device on the market capable of running apps
>>> isn't fast
>>> enough for TLS?
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140802/673dffb6/attachment.html>


More information about the sr-dev mailing list