Let's say I use Jitsi to make VoIP conference calls using XMPP. What determines the security, is it a feature of the XMPP protocol itself or is it the account/server I am using (eg, www.jabber.org)? On the Jabber website they mention using SSL and TLS, would this be for VoIP?
What is the advantage of using ZRTP over just making a regular voice call through XMPP, assuming there is already some security with XMPP?
Is there a difference in using SIP vs. XMPP for voice calls, with or without ZRTP?
Thanks!
XMPP and SIP are known as "signalling protocols". They are designed to provide channels that allow two clients to communicate small packets of data with each other. SIP was designed primarily with just signalling as a goal, while XMPP was designed primarily with messaging and presence as a goal. Over time both have gradually extended into each others' realm though :)
However neither SIP nor XMPP technically carry the actual voice/video data. This is left up to other protocols, such as RTP, ZRTP, etc., which the clients use the signalling protocol to negotiate (e.g. they need to exchange IP addresses and port information, and keys for ZRTP).
This means that running your XMPP over SSL is essential for security, but it only protects the signalling part (the clients negotiating the media channel). The voice/video does not go over the XMPP channel, and must be separately protected, by using ZRTP.
Related
Is there any way in which the messages that are send by COAP over UDP packets can be secured ? Any open source projects that I can implement. This message exchange is with a server and the client would be an embedded device. So the cryptographic algorithm must be able to run on it too. Also I came across cyassl. But the problem is that it uses TCP protocol rather than UDP ? Any ideas ?
Thanks
DTLS can be used to secure CoAP unicast messages, however, CoAP multicast messages are not protected by the existence DTLS protocol. Because efficient key distribution problem has not been solved yet. This means the header of multicast messages might be exposed to the sniffer tool, including the URI path.
Nowadays, there is a protocol called OSCoAP might help with this. It is still in implementation.
This is the latest draft IDTF document of OSCoAP: https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security-02
However, there are doubts about it. It mentions the OSCoAP will encrypt the URI path in section 4. Then key distribution still might be a problem in multicast. But it didn't mention any difficulties there. But someone who has interests in the security of CoAP messages can have a look at OSCoAP.
The way to secure CoAP is DTLS (TLS for Datagram)
The RFC is pretty clear on the subject:
https://datatracker.ietf.org/doc/rfc7252/?include_text=1
See section 9 for the details.
DTLS is simply the well-known TLS/SSL but adapted to run on UDP transport.
A nice and simple implementation for embedded device is tinydtls (http://trinydtls.sf.net)
For the server side you can use Californium and Scandium (http://eclipse.org/californium)
Encryption of data before sending lets you not bother about the transfer protocol (i.e. is it UDP, TCP etc). Of course you will need to decrypt the data on the server.
If you want transport-layer security, you should look for DTLS implementations. DTLS is a flavor of SSL/TLS designed to be run over UDP and similar transports. I am not sure if DTLS implementations exist for constrained devices, though.
I recently came across WebSockets and my mind was blown about the possibilities they bring. I searched for a full list of such realtime (and near-realtime) communication protocols and technologies - such as XMPP, WebRTC but I couldn't find any near complete list. So please help me assemble the list here.
UPDATE: I'm looking for realtime protocols available for the web.
WebSocket
WebSocket is a web technology providing full-duplex communications channels over a single TCP connection. The WebSocket API is being standardized by the W3C, and the WebSocket protocol has been standardized by the IETF as RFC 6455.
XMPP (Jabber)
Extensible Messaging and Presence Protocol (XMPP) is a communications protocol for message-oriented middleware based on XML (Extensible Markup Language).
WebRTC
WebRTC (Web Real-Time Communication) is an API definition being drafted by the World Wide Web Consortium (W3C) to enable browser to browser applications for voice calling, video chat and P2P file sharing without plugins.
The Bayeux Protocol
Bayeux is a protocol for transporting asynchronous messages (primarily over HTTP), with low latency between a web server and a web client.
Server-Sent Events
Server-Sent Events (SSE) are a way for server to initiate data transfer to clients after the client connects. It is used for streaming continuous or low latency messages to the client. The browser API is called EventSource.
Wave Federation Protocol
The Wave Federation Protocol (formerly Google Wave Federation Protocol) is an open protocol, extension of the Extensible Messaging and Presence Protocol (XMPP) that is used in Apache Wave. It is designed for near real-time communication between the computer supported cooperative work wave servers.
IRC
Internet Relay Chat (IRC) is a protocol for real-time Internet text messaging (chat) or synchronous conferencing. It is mainly designed for group communication in discussion forums, called channels, but also allows one-to-one communication via private message as well as chat and data transfer, including file sharing.
Real-Time Publish-Subscribe (RTPS) Protocol
The Real-Time Publish-Subscribe (RTPS) protocol is designed for use with Internet Protocol (IP) one-to-many Multicast and connectionless best-effort transports such as IP User Datagram Protocol (UDP). It enables, among other things, best-effort and reliable publish-subscribe communications for real-time applications using standard IP networks.
Socket.IO
Socket.IO is a popular library for real-time communication from a browser. Socket.IO primarily uses the WebSocket protocol, but if needed can fallback on multiple other methods, such as Adobe Flash sockets, JSONP polling, and AJAX long polling, while continuing to provide the same interface. Although it can be used as simply a wrapper for WebSocket, it provides many more features, including broadcasting to multiple sockets, storing data associated with each client, and asynchronous I/O.
I'm developing a SIP mobile softphone, customer needs a complete hiding of SIP messages from softphones to SIP servers as VOIP calls are regionally prohibited, however using TLS connection was not sufficient since the message headers are easily recognized as a SIP message. What are the best common alternative?
what about openvpn, IPSec tunneling?
Transmitting SIP over TLS means the SIP headers will only be viewable if someone is able to compromise your TLS keys, i.e. it's highly unlikely unless some national security agency is on your case.
What you might be encountering is port 5061 being blocked since it's the default and therefore well known SIP TLS port. To get around that simply use a different port for your SIP TLS connection. As far as anyone viewing the traffic goes if it's not suing port 5061 they won't have any idea that SIP is being used in your TLS stream.
Of course you also need to consider the RTP traffic which is what will carry the audio part of the call once SIP has set it up. There are no standardised ports for RTP but some popular VoIP softswitches do use certain ranges by default. For example Asterisk uses UDP 10,000 to 20,000. To work around that you'd really need to use SRTP but that's going to be harder to set up since not that many SIP user agents and servers support it. It will also be easier to detect for someone watching your traffic since even without knowing the contents the profile of RTP packets would be detectable. Still it's likely to need a sophisticated entity monitoring your traffic to detect a VoIP call using SIP over TLS on a non-standard port and SRTP call amongst the general noise of internet traffic.
I'm looking for options for securing UDP traffic (mainly real-time video) on a wireless network (802.11). Any suggestions apart from Datagram Transport Layer Security (DTLS)?
Thanks.
You must be more clear about the attacks you are trying to defend against. For instance if your only concern is spoofing then you can use a Diffie–Hellman key exchange to transfer a secret between 2 parties. Then this secret can be used to generate an Message Authentication Code for each packet.
If you need any more protection I strongly recommend using DTLS. It should be noted that all TLS/SSL connections can be resumed so you can cut down on the number of handshakes. Also, certificates are free.
Are you trying to wrap an existing application or writing your own? What client server setup do you have? Do you want to prevent snooping or tampering?
I am assuming here that you
are developing an application
are trying to prevent snooping
have access to client and server.
The simple approach is to use any off the self strong encryption. To prevent tampering use any signing algorithm with a private/public key scheme. You can use the same key pair for encryption and authentication.
The drawback of this approach is that it is on layer 7 and you have to do most of the work on your own. On the other hand, DTLS is a viable option...
Have you considered IPSEC? This article provides some good guidance on when and when not to use it.
You can look into ssh with port forwarding. That comes at the cost of maintaining a TCP connection over which the UDP traffic can be secured.
Please let me know what architecture do VoIP applications use, P2P or Client-Server?
Thank you.
Some of each in general. There are three protocols involved, usually. One of them, for example SIP, is used to establish the connection. you need a server for that because someone has to establish the original connection; that means advertising availability and such. The other two are essentially always RTP and RTCP -- "real time protocol" and "real time control protocol", and those are better P2P, because you want fast transmission with no intermediate bottleneck.
There's a nice article on the whole discussion here.
There's usually some kind of "presense server": devices register ("I exist here!") and calls are established via the server (when you say "I want to connect to device (555) 555-1234" that connection request is routed via presence servers).
After the call is established and the real-time voice/media is streaming, that traffic is usually peer-to-peer (bypassing any central server), except if there's a complication like both devices being behind firewalls.