10 มีนาคม 2551 15:35
The security team where I am working are very interested in OCS for it ability to have voice conversations encrypted point to point.
I have been asked, taking a random network monitor sample, to prove that the data is encrypted.
Network Monitor 3.1 seems to have no specific filters for RTAudio and all I can see is a lot of UDP traffic.
Any suggestions on how to tell if the data is encrypted would be appreciated.
11 มีนาคม 2551 22:48
If you see RTP in your trace for audio (Real-time Tranport Protocol) it is not secured Audio
Look for SRTP in your network trace for audio (Secure Realtime Transport Protocol) for Secured Audio
Look for SIP TLS in your network trace for encrypted signaling
12 มีนาคม 2551 11:12
Thanks for the reply.
I am using network monitor 3.1 which doesn't have a filter for RTP or SRTP. (I may be being a bit stupid though!)
So I am only seeing the packets as being marked UDP.
Is there is a filter I can add in to Network Monitor or is there another network capture tool I should use?
12 มีนาคม 2551 23:27
You should try with Wireshark
13 มีนาคม 2551 10:33Sorry but I tried Wireshark Version 0.99.8
Now I am not an expert with the tool.
In its default state it also shows packets as UDP and doesn't seem to recognise that the packets are SRTP.
Thaks for your help so far.
13 มีนาคม 2551 18:18In the filter bar, put in SIP or RTP or SRTP. This will show you the appropriate packets.
14 มีนาคม 2551 14:19
Sorry but if I type SRTP in to the filter I get an error ‘"srtp" is neither a field not a protocol name.’
Putting other strings into the filter such as RTP, STUN etc works fine.
(RTP shows no hits so good news. At least there is no obviously non encrypted traffic but the security team will really only be happy if I can prove that SRTP is being used)
14 มีนาคม 2551 23:54
I had a look and indeed found no support for SRTP (Yet)
You could however turn your problem arround and tell the network team if they find unencrypted data that they show it to you!
17 มีนาคม 2551 13:39
I like your thinking
However you know what security people can be like!
Thanks for all your help.
2 เมษายน 2551 8:25
I have done a bit more research _The header for RTP \ SRTP is the same. The only difference is that the payload in encrypted.Using Wireshark it is thus possible to right click, decode as & choose RTP. (The UDP packets are then shown as RTP)It is still difficult to tell if the payload is encrypted. The suggested approach is to send DTMF tones and look at what is sent. (The unencrypted header will say that DTMF is being sent).If the data is not being encrypted it will be easily shown in wireshark.The following advice was kindly given to me by an MS contact"You need to have Netmon/WireShark parsers to see RTP traffic in Netmon/Wireshark. If you do not have parsers, then you will have to manually see where the RTP begins (RFC 3550 can help you to see the RTP header - generally it begins with 0x80 as v=2, p=0,X=0 and CC = 0 for peer to peer call). Sometime RTP is sent over TCP and then you need to be able to see the RTP packetization as mentioned in RFC 4571.
MOC 2007 - MOC 2007 traffic is generally encrypted via SRTP (unless you have changed the setting not to use encryption). In SRTP, the RTP header is not encrypted but the payload is encrypted (RFC 3711).
One way to verify this is by making a call between two MOC 2007 clients and one end presses a number (say 1) in the MOC UI. Using RFC 4733 you can know the RTP payload format (i.e., DTMF) for the digit you have pressed. If the data is encrypted via SRTP then you will see that the RTP payload for DTMF (RTP payload in RTP header is generally 101) is very different from what you should be expecting from RFC 4733 . This is becasue the payload is encrypted. Please note that MOC does not playback the DTMF (so do not expect this to be played back to the receiver).