How to secure the web login of an equipment with public IP address

0 投票
最新提问 用户: (120 分)

We have equipment which have public IP addresses and we don't have SSH access to it. In order to secure their login screens, we need to use the HTTPS, but when we do that it is always complaining about insecure connection due to wrong SSL certificate. I am aware that we cannot issue SSL cert on an IP, but the other problem is that we don't have access to the equipment either in order to install a new SSL certificate. So what are the security recommendations in this case. Is the traffic still secure and encrypted in case of SSL mismatch.

I know that we can limit the networks who have access to this IP, but are there any other security measures?


0 投票
最新回答 用户: (500 分)

Your main problem here is an active attacker. When you connect via HTTPS, the server will send its certificate, claiming to be the web server where you're trying to connect (let's call it "SecureServer"), and the Certificate Authority (CA) will be the one in charge of letting you know if "SecureServer" really is who it claims to be. When using a self-signed certificate or something like that, there'll be a warning letting you know that it's not a secure connection, because there's no way to verify that "SecureServer" is really who it claims to be, after all, you're not a CA, and because of that, you can even create certificates for "", but since you aren't an authority, nobody's going to trust you.

Now, the problem here is that if someone wants to connect to your device, they'll see that warning and they'll be like "oh yeah, that happens all the time. Just skip it and keep working", but an active attacker can intercept that communication, add his own certificate, instead of the server certificate and voil谩, now he'll have access to your encrypted communication, because now the communication is between you and the attacker, and if you're waiting for a response from the server, he can also establish a communication with the server, so he'll forward all your requests to the server, while reading all your requests and server responses. All this is possible because once the active attacker has intercepted the communication, you'll see that warning, but all your users are used to just ignoring that warning, and they'll just accept the communication anyway, while when using a certificate issued by a CA, if they see that warning, they'll know that there's something wrong.

Honestly, for me, the best thing that you can do here is to use a certificate issued by a CA. Also, according to this answer, you can issue an SSL certificate on an IP address (I've never tried it before, but it might be worth to give it a try). You also mentioned that you don't have access to the hardware to install that certificate, but I'm guessing that you can request that to someone who has access to it, just explain the situation and if he/she is a reasonable person, he/she will understand the problem and will install a new certificate. Because honestly, just limiting the IPs range or something like that, is just a workaround for something that should be implemented correctly.

发表于 用户: (120 分)
Thanks Esteban for the detailed reply. It really makes sense what you said. I will think how we can secure the connection using proper SSL certificates. And honestly speaking SSL certificate on an IP address makes very little sense for me.
欢迎来到 Security Q&A ,有什么不懂的可以尽管在这里提问,你将会收到社区其他成员的回答。