Securing Video Streams!

Topic: “Securing Video Streams”

Many camera manufacturers mention in their technical sheets “Encrypted file transfer using Hyper Text Transfer Protocol Secure (HTTPS)”, and this even for the video streams.

During PEN testing the findings show that the video stream, which are in RTP or RSTP, are not secured with SSL or TLS HTTPS. Thus only the communication to the camera resides under the HTTPS (port 443) and not the video streams.

In our setup all other security measures are enforced, such as 802.1X with NAC certificate (Radius server) and strong passwords. Even then the video streams can still be viewed and even replaced. For security reasons this is not acceptable.

Also mentioning that at this time we are not using VPN tunnels for every camera which are in Unicast streaming to an VMS system, although this could be an answer. At this time we were counting on the built in security of the mentioned “encryption techniques offered by the camera setup”. We are using the strength of the company network in a separate VLAN, thus not separating the video segment for physical access.

Are these findings correct?

Is HTTPS the answer to security?

If not, why couldn’t the camera manufacturers straiten this out as they are contradictory to their claims in the Spec Chart?

Which spec sheet mentions encryption?

You name it, AXIS, Bosch, Sony to name a few.

On any given camera Data Sheet @ page with Technical Specifications under Network Security. They all specify HTTPS encryption, also as supported protocols.

To expand on Dirk's point, here is Axis explanation of HTTPS:

"HTTPS (Hyper Text Transfer Protocol Secure) is identical to HTTP but with one key difference: the data transferred is encrypted using Secure Socket Layer (SSL) or Transport Layer Security (TLS). This security method applies encryption to the data itself. Many Axis network video products have built-in support for HTTPS, which makes it possible for video to be securely viewed using a web browser." [Emphasis Added]

It seems to me that Axis is implying that the video stream is encrypted as well (the second bold part).

Yes, they surely imply that, but they don’t. That’s what I want to point out, and they are not the only one.

Dirk, I reached out to Axis for comment as well as a few specialists in this area. Thanks for bringing this up.

Some cameras use a native protocol, which may be different than RTSP and ONVIF. When using a manufacturer's naitive protocol, that may then be encrypted when using SSL/HTTPS/TLS.

A few years ago, the main concern was username/password leakage, whereas video stream security is now a newer concern. In addition, some cameras use digest encryption for username/password transfer even with SSL disabled.

What it would take to properly solve it is most likely much more than the solution is worth in the broader market. Having some background with large banks and common network security best practices, I looked into this in depth a few years ago. For the most part, to be *truly* compliant, most manufacturers would have to make custom high-security firmware, with a lot of common features (email, ftp, etc.) stripped out, and other things (endpoint auth, forced HTTPS tunnelling, unqie certs for each device, certification authentication service) added in.

IP cameras are already more secure than non IP cameras for basic snooping. Then you layer that with some networking best practices (switches in locked/secured rooms, VLANs, physical segregation, endpoint encryption, SNMP link up/down trap alerts from switches) and you have something that would be secure against anything other than a very concerted insider, in which case you technically have no REAL solution. You can go one step further and add tamper switches to housings, pressurized conduits, and things like that as well. It's been done.

The honest answer though is that 98% of the market doesn't care about network security to that level of depth. I know of a few companies that won't put ANY IP device on the outside of their building (for fear of network hacking through outside accessible drops), though some of them are slowly making special exceptions.

What (honestly) are you trying to secure/what is your anticipated threat? Are you worried about someone getting access to the video feeds? (live or recorded?) Are you worried about mitm attacks where video feeds are replaced/altered? Something else?

Indeed, head on to what I expected, the marked does not care enough at this point. I think they can do better to secure against tapping the video feeds.

Our findings were acquired through the help of an Eth. Hacker whom was authorized to perform a mitm setup for PEN-testing. But the techniques used are not so uncommon that it can be expected to arise in certain environments.

I think they can do better to secure against tapping the video feeds.

Where exactly is this a problem? It's certainly not something you hear people complaining about in day-to-day installations. Are you proposing more security options because you have a bona-fide anticipated threat, or simply because this is theoretically possible?

And by "tapping the video feeds" I'm still not clear if you're talking about unauthorized viewers, or people injecting dummy feeds into the system (or both)?

The question is what's really at stake if somebody does manage to eavesdrop on your video feeds? In most cases, not much. They say 99% of the video in our business is never watched, and for good reason--it's boring as all hell.

Yes, I know there are some environments where somebody could gain some knowledge via video that they could use against you in other ways. But again if they've penetrated your network safeguards to the point that they're watching your IP streams you've likely got bigger problems.

I wouldn't quite say 98% of the market doesn't care about NETWORK security, just security of their video streams. Network security is a big deal, and IP video is a payload on that network. It's the need/desire to explicity protect that video from leakage that's in question.

What's more interesting to me isn't somebody watching my video but rather somebody using a denial of service attack to in some way prevent me from watching my video. Taking down a camera or a recorder is a bigger vulnerability, with potentially more at stake, than is eavesdropping on video.

Axis response:

"When using RTSP over HTTPS then everything is encrypted including the video. VMS partners would need to be able to support calling RTSP over HTTPS from the camera as well."

RTSO over HTTPS is not unique to Axis, but what I don't know about their implementation is does that disable RTSP over TCP/UDP at the same time? Is there a setting to force the camera to ONLY do RTSP over HTTPS, or could you still access "raw" RTSP over TCP/UDP?

We will look in to it, AXIS was one of the camera’s used. Does Sony underwrite the same settings?

I have seen some cameras over the years that when you do turn on SSL encryption, the CPU takes a huge hit on performance, and the web interface is slowed down, responses to commands are slower, and you lower the number of clients that can connect.

Hopefully newer generations of cameras have more CPU to handle this, or maybe even hardware SSL offloading from the CPU...??

IMO you need to encrypt the business data. That means the video streams too.

I don't think 802.1X is viable as it's too complicated for all but the most well funded network environments. IPSec between clusters of cameras and the VMS is an adequate answer, sometimes.

Remember many vendors don't even allow TCP let alone TLS, claiming cameras are too weak to run TCP (while running H.264, so this is a weak argument...)

By the way, that's TLS, 1.2, with AES GCM and SHA-256, using properly deployed 2048 bit RSA keys...


afaik, there are only 4 non-proprietary ways to deliver video: Rtp, rtp interleaved with rtsp, interleaved tunneled by http and interleaved tunneled via https.

to avoid leaks via pure rtp, rtsp and http should be explicitly turned off.

from onvif perspective, if camera support https, it must support video over https. At the same time, onvif conformancy do not support proved claims of https support - this is the business of new profile a (advanced security), coming next year.

summary: If camera is onvif profile s conformant and support https and it is possible to swith off rtsp and http via web interface - there are chances thay you will have secure stream. But i have no idea about vms that can handle it.

i expect that next autumn, when there will be devices and vms conformant to profiles S and A, you will be on a safe side.