In the discussion Ocean 11 Camera Hack Real World?, there was some question about whether https enabled cameras actually will encrypt video data, or just the commands and config communication between the camera and VMS.
This simple test shows its possible to encrypt the transmission between an Axis M3006, running in HTTPS only mode, and Milestone Xprotect (Corporate), with HTTPS enabled.
Having said that, it is not enough, in this case to merely enable HTTPS in Milestone and Axis, equally important is to set the streaming mode to tunnel RTSP over HTTP.
Highlights from the video:
Start Wirehark unfiltered capture 0:07
Start Milestone recording/management server 0:13
Show encrypted TLS packets in Wireshark 0:18
Open Axis m3006 webpage 0:22
Show HTTPS only setting 0:33
Open Milestone management server 0:46
Show Milestone setting of HTTPS enable for Axis camera 1:46
Show rtsp over http streaming mode setting 1:49
Change streaming mode to rtsp/rtp, no tunnel 1:51
Show unencrypted rtp packets in Wireshark 2:06
Change streaming mode back to rtsp over http 2:34
Show encrypted TLS packets in Wireshark again 2:41
Hopefully this shows enough for someone to replicate the behavior, if not let me know what else might be helpful...
The RTP/RTSP/HTTP/TCP stream option is the tunnel.
The RTP/RTSP/TCP option is the default. HTTPS is not enabled by default in Milestone.
When you enable HTTPS in Milestone, IMHO, it is only a directive to encrypt any HTTP and put it on port 443. But if you are using RTSP/RTP/TCP as your streaming method, then that remains unencrypted. So by first putting everything inside HTTP first, it insures everything gets encrypted.
Btw, the reason that tunneling RTP/RTSP over HTTP is NOT the default is because, encryption aside, it takes more processing to do the interleaving and encapsulation of the streams.
Also, since the media control stream (RTSP) has to be serialized with the video payload (RTP), this makes the stream less responsive to media commands, as there is no true OOB (out-of-band) signaling.
On the other hand, I'm just guessing what their motivation is, as I did not find any documentation regarding the necessity of using HTTPS and tunneling together for end to end encryption.