Should IP Cameras Default To HTTPS?

JH
John Honovich
Dec 18, 2016
IPVM

Almost all IP cameras support HTTPS (except for Arecont) but almost non have it enabled by default.

So, should IP cameras switch to that?

It would help make cameras more secure but would also increase complexity / potentially cause issues with VMS integration. What do you think?

UE
Undisclosed End User #1
Dec 18, 2016

It would also allow attackers to have "secure" communication while attacking / exploiting.

U
Undisclosed #2
Dec 18, 2016
IPVMU Certified

Amen to that.

It can be frustrating to setup a classic MITM attack, only to realize that you are not the only 'man in the middle'.

(1)
JH
John Honovich
Dec 18, 2016
IPVM

Our worst two members.... :)

For us mortals, can you elaborate on the pros and cons of HTTPS here?

U
Undisclosed #2
Dec 18, 2016
IPVMU Certified

Pros:

  1. Secure communication

If the camera is only connected to a VMS and not on the WAN, this benefit may be of limited use.

Cons:

  1. Can impose significant performance degradation while encrypting video.
  2. Must have a valid certificate, either self-signed or thru trusted chain.

This is assuming you are encrypting an embedded video stream as well. If not performance is not much affected.

In case of a self-signed cert, you get one of those "stop - you are one click away from hell" when accessing the camera directly.

(3)
AT
Andrew Tierney
Dec 18, 2016

Which devices have the capability to encode video at reasonable resolutions and bitrates, but not perform HTTPS?

U
Undisclosed #2
Dec 19, 2016
IPVMU Certified

The one I put up for you https://184.179.106.56:31313

is mighty pathetic in https mode.

UM
Undisclosed Manufacturer #3
Dec 19, 2016

When Panasonic first launched HTTPS in their older 1/3/5 series models, they were slower than mud when put in HTTPS mode.

I believe they fixed this in their newer line up, which were designed better for HTTPs by design as opposed to by firmware upgrade to win a project.

UE
Undisclosed End User #1
Dec 18, 2016

Well, HTTPS/SSL is pretty good if you want to have a pretty good secure channel between the enduser and the device.

However, for example, to detect and/or to try prevent malicious traffic that is transported with HTTPS/SSL encryption by using IDS/IDPS - it’s needed to have support of decrypting. Actually, you will need to have some sort of legal MITM here.

Unencrypted (plaintext) malicious (read attacking/exploiting) HTTP traffic has greater risk to be detected that HTTPS/SSL traffic, so by enabling HTTPS I would say you give the attacker a favour to keep his traffic less detectable.

(1)
AT
Andrew Tierney
Dec 19, 2016

Are you arguing that devices are at higher risk by enabling HTTPS because you can't trivially inspect traffic?

I'm just trying to work out what situations you put an IDS in place, but can't intercept SSL and don't restrict access to the cameras using a VPN or similar.

UE
Undisclosed End User #1
Dec 19, 2016

For example: https://www.snort.org/faq/readme-ssl

(1)
UE
Undisclosed End User #1
Dec 19, 2016

Little more to read;

https://www.sans.org/reading-room/whitepapers/analyst/finding-hidden-threats-decrypting-ssl-34840

/*

Encryption has not gone unnoticed by external attackers and abusive employees. As NSS Labs said in a recent report, “Ironically, increased use of SSL in attempt to make our online lives more secure can create ‘blind spots’ that can actually reduce security…”8

*/

https://www.bluecoat.com/fr/documents/download/a9d0843e-85be-4ff1-b871-cbcb5b2d7ad6

/*

While encrypting web sessions protects end-user data from being viewed in transit over the Internet, it creates a blind spot for IT administrators; they typically have no visibility into SSL-encrypted traffic. For that reason SSL has unfortunately become one of the most popular ways to mask malicious code, such as Trojan horses and viruses. Incoming and outgoing threats can hide in SSL to bypass security solutions and spread freely throughout and between organizations.

*/

.... and so on, ask Ms. Google if you need more to read.

AT
Andrew Tierney
Dec 19, 2016

They aren't relevant to public facing web applications though, where it's perfectly possible to implement SSL inspection using a web application firewall, load balancer or reverse proxy.

I just can't see why you'd put in place IDS that cannot inspect SSL, but not basic access control or a VPN. It would show a serious lack of appreciation of the real risks involved.

UE
Undisclosed End User #1
Dec 19, 2016

I also said you will need to have "legal MITM", where HTTPS/SSL traffic is terminated and where you can inspect the plaintext traffic.

The point is, by enabling HTTPS/SSL on public facing web application (read: Camera / DVR, as that we speaking about here) without thinking one step further, you can actually do an attacker a favour to be less detectable for admin (and also for ISPs where the traffic passing thru) - but as legal user/admin you feel more (false) secure.

If the purpose by enabling HTTPS/SSL on public facing Cam / DVR on Internet for sensitive video feeds, then I think this isn't right choice of bearer of that traffic.

Ironically, for instance, it seems to be less important for protecting e-mail traffic with SSL/TLS than .html/.shtml/JavaScript traffic on some Cam / DVR's.

Only my 0.02$ worth thoughts.

AT
Andrew Tierney
Dec 19, 2016

But what admins are performing IDS on cameras at the HTTP level, but not performing basic IP whitelisting or VPNs?

It makes no sense to be implementing an IDS without these things in place.

UE
Undisclosed End User #1
Dec 19, 2016

And I would feel more comfortable to make an exploiting / attack within HTTPS/SSL than plaintext HTTP connection.

U
Undisclosed #2
Dec 19, 2016
IPVMU Certified

It makes no sense to be implementing an IDS without these things in place.

Sometimes the attack comes from within the network...

AT
Andrew Tierney
Dec 20, 2016

Indeed, it does. But what class of attack is this IDS (that can't decrypt SSL) going to detect that is a higher risk than someone sniffing credentials and using that access?

UE
Undisclosed End User #1
Dec 20, 2016

Sniffing credentials demands already local access to the network, and is less likely to be a threat(but still there, of course) since most network equipment is switches nowadays and not hubs.

Sniffing credential could of course also be achieved outside local network by setting up an public proxy server and let people to use that for "hiding their IP". Quite successful if you listen on this; https://www.youtube.com/watch?v=xDslqMCaLZM

What I wanted to point out, is that you doesn't get more secure from "bad guys" attacking your devices by forcing HTTPS/SSL, if you want to be secure from "bad guys" - keep the stuff of Internet. And if you still need to have stuff online, use HTTPS/SSL (with no public proxy) and go away from common known/used ports (I.e. 80,443,8080,8443), that will give yourself less detectable from "bad guys and/or bad worms".

I surely like HTTPS/SSL and always trying use that along non well known ports on my own devices.

Well, whatever, quite boring thread now...

U
Undisclosed #2
Dec 20, 2016
IPVMU Certified

Well, whatever, quite boring thread now...

Was that your 'Mic Drop'? 

UE
Undisclosed End User #1
Dec 20, 2016

yep

(1)
AT
Andrew Tierney
Dec 21, 2016

Sniffing credentials only requires that you can intercept traffic anywhere along the path. There are many ways of achieving this, and switches don't inherently provide protection against this.

AT
Andrew Tierney
Dec 19, 2016

Yes, Snort can't intercept SSL. It's not an appropriate solution for a public facing web application.

UM
Undisclosed Manufacturer #3
Dec 18, 2016

I vote no. Leave HTTPS as an option, but should be encouraged to be used.

Many integrations such as with home automation don't support HTTPS. Many vms don't support HTTPS. Some countries do not have access to cryptographic products.

(2)
AT
Andrew Tierney
Dec 20, 2016

Why not set it by default and allow those edge cases to disable it?

U
Undisclosed #2
Dec 20, 2016
IPVMU Certified

Tech. Support.

UM
Undisclosed Manufacturer #3
Dec 20, 2016

I don't have a current axis camera to try out... do axis cameras come with a self signed certificate so you can use HTTPS out of the box? Or do you need a CA/buy a certificate?

I though self signed certs were pretty standard, but the manual makes it sound like you need to install one.

Maybe this should be moved to a new thread, but any ideas which ip camera and nvr manufacturers come with a self signed certificate?

NOTICE: This comment has been moved to its own discussion: Which Ip Camera And Nvr Manufacturers Come With a Self Signed Certificate?

New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions