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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 >>> [email protected] >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>> >> >> >
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
