HOWTO securely access your NVR on your Smartphone without using the hardware provider cloud (without VPN)
Hi,
I see sometimes people wondering how to securely access their NVR or cameras on their smartphone (or from outside the LAN), without using the cloud servers from the hardware provider. Especially for Chinese brands that have built-in CCP backdoor...
So here's what I did and why. First, I will assume that you have some knowledge on IP network, and on how to secure the NVR and cameras on your LAN (use the firewall to block both inbound and outbound traffic on router level, segregate on a separate VLAN if needed).
What I wanted to achieve is the creation of a secure tunnel between my NVR and my smartphone, have an automatic authentication in order to make sure the smartphone is allowed (and possibly have several possible smartphone with each their own authentication), and have the tunnel working without the need to connect to my LAN (so not a VPN, just a tunnel on a dedicated port).
To achieve that I used
STUNNEL to create a double layered tunneling: one layer to create a secure TLS tunnel with a 2048 RSA key, and a second layer to have a client authentication with a 64 characters key dedicated to each smartphones.
I used my home server, but it could work on a Raspberry Pi. I also use a dedicated NVR from the same vendor as the cameras, but it could work with a VMS (and even share the same PC as the VMS).
1/ Generate certificates and keys: You'll need to generate a certificate for the server. To do so, you can use the CLI commands:
openssl genrsa -out key.pem 2048 openssl req -new -key key.pem -out auth_cert.pem openssl x509 -req -days 3650 -in auth_cert.pem -signkey key.pem -out cert.pem
Those commands will generate a private key, then generate a certificate for signature request, and finally use that request to generate an self signed certificate for 10 years (you'll have to answer interactive questions to sign the certificate). Here the certificate is self-signed and it's enough since I check if the certificate is the correct one on the client side.
Then generate a key for each clients:
openssl rand -base64 64
And put them all in a file "psksecrets.txt" with a dedicated client name:
client_name_1:generated_key_1 client_name_2:generated_key_2 client_name_3:generated_key_3 . . .
2/ Server side: On the server side, in the LAN, you'll need at least to install STUNNEL version 5.09 or higher.
In the "stunnel.conf" file, use a configuration like the following one that to complete the provided example:
cert = cert.pem key = key.pem [server_psk] accept = 12345 connect = 23456 ciphers = PSK PSKsecrets = psksecrets.txt [server_proxy] accept = 23456 connect = 192.168.1.123:34567 sslVersion = all ciphers = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PS options = NO_SSLv2 options = NO_SSLv3 options = CIPHER_SERVER_PREFERENCE
In that example, 192.168.1.123:34567 is IP and port to access the NVR (for me a Xiongmai NVR). 23456 is port used to chain the two tunnels. 12345 is the entry port for the connection, it's this port that need to be forwarded to the WAN. I filtered out the weak ciphers for the first tunnel.
3/ Smartphone side: On each smartphones, you also need to install STUNNEL version 5.09 or higher. With an Android smartphone, you can use the app called
SSLSocks, it works great.
In the client "stunnel.conf" file, use a configuration like the following one to complete the provided example:
client = yes [client_psk] accept = 23456 connect = your_domain_name:12345 PSKsecrets = psksecrets.txt [client_proxy] accept = 34567 connect = 23456 CAfile = cert.pem verifyPeer = yes
And in the client "psksecrets.txt" just copy the line for that specific client from the server file:
client_name_1:generated_key_1
In that example, your_domain_name:12345 is your domain name (it also works with your public IP) and public port to access the tunnel. 23456 is port used to chain the two tunnels. 34567 on the localhost (IP 127.0.0.1) is the port and IP to use by the smartphone CCTV app you use (for instance XMEye). You authenticate using the client_name_1 key.
4/ How does it work? The communication will work like that:
Smartphone CCTV app < [client_proxy] < [client_psk] <=WAN=> [server_psk] < [server_proxy] <=LAN=> NVR
< is traffic on localhost (internal to the device), <=LAN=> is LAN traffic, <=WAN=> is two layer tunneled WAN traffic, and [] is specific STUNNEL configuration steps.
When you'll connect with the client to the first tunnel, you'll check if the server is the correct one (by checking the server certificate and comparing with a local copy of it, to avoid Man In The Middle) and establish a 2048 RSA strong TSL connection. Then the client will connect to the second tunnel using its key, and the server will allow that connection only if that same key is known in his own keys file.
That way we first make sure the server is the correct one and establish a strong connection, and after we make sure the client is allowed and establish a less secure connection on top of the first one. Keep in mind the whole second connection is done through the first one, so it's VERY secure.
The Android SSLSocks app works very well, and you can have it always ON from the startup in the background. The tunneling will establish on demand when you access the smartphone CCTV app: No need to activate/deactivate SSLSocks, it's completely transparent for the end user. And you won't be connected to your LAN like you would with a VPN.
submitted by
shellbross to
homesecurity
Certificate still valid although on revoked and on CRL
Hi,
I've noticed some issue with revoking certificates on Mikrotik with external CRL.
I'm using easy-rsa on linux box (
192.168.0.151) to generate/sign/revoke certificates. some sort of small PKI
I've generated certificate, exported it as p12 and imported on mikrotik as shown below:
[
[email protected]] /certificate> print detail
Flags: K - private-key, L - crl, C - smart-card-key, A - authority, I - issued, R - revoked, E - expired, T - trusted
0 KL T name="midgard" issuer=CN=Easy-RSA CA digest-algorithm=sha256 key-type=rsa common-name="midgard" key-size=2048 subject-alt-name=DNS:midgard
days-valid=1080 trusted=yes key-usage=digital-signature,key-encipherment,tls-server serial-number="
D9D17FDF8F7EB1C67C2854EBAFAA4AC1"
fingerprint="bdcadff977debbe2cd16a9205f65d818e062190c0686b9ee88c4926559fde9ca" akid=037b5d142c858e5ce791d2aa20530864cf9f8e76
skid=6c3514c6f3f58370da93d8f6e4ada9853cef23f9 invalid-before=oct/30/2020 22:53:42 invalid-after=oct/15/2023 22:53:42
expires-after=154w1d23h31m11s
1 T name="CA" issuer=CN=Easy-RSA CA digest-algorithm=sha256 key-type=rsa common-name="Easy-RSA CA" key-size=2048 subject-alt-name=""
days-valid=3650 trusted=yes key-usage=key-cert-sign,crl-sign serial-number="37D39CF490CB2C4F48A98B6556B5E17907BAE12A"
fingerprint="be6a29c2ab9c96f216d87706f98536204bd1854d3c37ffa60127058f27205d79" akid=037b5d142c858e5ce791d2aa20530864cf9f8e76
skid=037b5d142c858e5ce791d2aa20530864cf9f8e76 invalid-before=oct/30/2020 22:46:09 invalid-after=oct/28/2030 22:46:09
CRL is configured as below:
Flags: E - expired, D - dynamic, I - invalid
# CERT LAST-UPDATE NUM REVOKED URL
0 D midgard oct/30/2020 23:05:39
1 http://192.168.0.151/crl.pem
as shown above, mikrotik got information from CRL that some certificate was revoked. ok, lets look on it from linux box:
index file shows cert with s/n "D9D17FDF8F7EB1C67C2854EBAFAA4AC1" is revoked:
[email protected]:~/pki# cat index.txt
R 231015215342Z 201030220332Z
D9D17FDF8F7EB1C67C2854EBAFAA4AC1 unknown /CN=midgard
checking revocation list crl.pem:
[email protected]:~/pki# openssl crl -in crl.pem -noout -text
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = Easy-RSA CA
Last Update: Oct 30 22:05:03 2020 GMT
Next Update: Apr 28 22:05:03 2021 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:03:7B:5D:14:2C:85:8E:5C:E7:91:D2:AA:20:53:08:64:CF:9F:8E:76
DirName:/CN=Easy-RSA CA
serial:37:D3:9C:F4:90:CB:2C:4F:48:A9:8B:65:56:B5:E1:79:07:BA:E1:2A
Revoked Certificates: Serial Number: D9D17FDF8F7EB1C67C2854EBAFAA4AC1 Revocation Date: Oct 30 22:03:32 2020 GMT Signature Algorithm: sha256WithRSAEncryption
92:84:40:e8:7c:b0:20:53:0c:f8:24:c4:65:b9:f2:85:9b:e7:
68:c5:d0:94:61:05:8a:8d:33:44:51:28:37:45:d6:8a:56:5b:
c2:a7:31:8e:8d:8c:dd:d5:fa:7b:64:c8:e5:51:ee:8b:0c:8d:
7f:86:0f:2f:01:c0:2a:66:f0:d3:65:2a:fa:7c:99:38:bf:38:
83:ca:17:d5:85:e1:e4:20:59:48:2c:f2:6e:14:e7:11:c2:f8:
b7:a8:55:03:fd:1f:05:ef:9e:bd:3c:8c:d1:8b:53:b4:21:4b:
25:2b:54:75:a1:2c:88:87:70:c9:10:fd:c2:c2:2e:7d:c2:5a:
56:d0:6c:f9:7e:4b:50:de:bd:6b:bc:4d:69:33:77:ff:76:49:
08:20:5a:bb:91:f0:74:c5:9c:04:a3:b8:99:43:c8:09:ef:44:
49:bb:1c:28:9c:15:0a:59:23:03:f5:cd:3e:a3:ac:ca:1a:67:
82:37:4f:7d:d9:62:6d:3f:c8:ad:9b:62:bf:2c:9c:0b:e8:27:
26:55:56:df:8a:f5:0d:ee:ac:a2:68:ef:49:0e:11:68:bd:37:
a5:80:41:ae:af:ef:38:ed:11:63:b4:23:6d:15:b8:cb:8f:bb:
4e:97:58:3c:03:f7:e5:a9:48:68:e0:53:3b:2d:65:b1:ea:2f:
25:87:71:0b
Any idea why from Mikrotik end, certificate is visible as valid ?
EDIT: RoS version: 6.47.7
submitted by
babujnik to
mikrotik