I can't understand which is the real benefit of using a CA certificate when it comes to secure communications between servers and IoT devices.
I'm working at an IoT device that uses Ubuntu as OS and I was planning to use CA certificate. But what happen if my users are not updating their devices firmware?
now that certificates expires after 1 year and considering that some users are not updating their IoT devices for a long time... the risk I'll run into is that those devices could not be updated after the cert expires since they can't communicate with my servers.
With a self signed cert I can set an expiration of 45 years and anyway I'll be to authority and I can revoke or decide when it is time to release a new cert or even cross signing certificate.
I'm obviously talking only about the communication between the device and servers... the rest api for users will use a default CA cert.
Another option that I'm considering is to use a CA cert for device and servers communication but also adding a self signed certificate that I can use as backup in case the the main certificate expires and the device needs to download new software (that will contain the new certificate) is this a viable solution?
Should I handle certificates in this way?! or maybe should I just use the OS root store and ensure that it is updated somehow? (in this case ... how?... the only way is to release an update of the device firmare I suppose)
Certificates are used for authentication and encryption. See https://www.ssl.com/faqs/what-is-a-certificate-authority/
If you want to make sure that, data you are receiving is coming from authenticated devices then you will use certificates.
You can use certificates to encrypt each and every request. But it will be heavy on resources. Or you use certificates to for authentication and return an JWT token for further request. (This is how service account works in cloud.)
Manual certificate management will become complicated in no time.
Service account is a common way to authenticate apps/ devices. Keycloak is an open source option to support service accounts.
You should keep device updation separate from authentication. Device updation may or may not happen on authenticated device. And waiting for certificate expiration to update the device sounds strange.
Related
I have a problem with insecure SSL certificates. My proyect consist on two parts:
ESP32 iot device with a https server
VUE2 + Vuetify PWA web app deployed to firebase hosting.
Imagine that one client buy my iot device, and connect it to the power. The device will boot in AP mode, creating a WiFi AP net.
The client login to the web app and wants to add his new device. So, for that, the iot device needs clients wifi credentials.
The web app asks to the client his ssid and password, and when the client click on 'Configure device', the web app send a https POST request to the esp32 server, and here is the problem...
Because the SSL certificate used in esp32 server is not validated by an authority, the web app can´t make the POST request...
How can I get a valid server SSL certificate for a lot of iot devices? I don´t know how to manage this situation...
Thanks everyone!!
It is possible to get a valid SSL certificate for the device, but I wouldn't recommend it. Here is how you could do it if you wanted to:
Ensure that when your device is in AP mode, it's always available at the exact same IP address. For example, ensure that the ESP32 is listening at 192.168.1.1.
Register a domain like example.com. Add an A record to your DNS server for iot.example.com, with the value 192.168.1.1.
Obtain a valid SSL certificate for iot.example.com from any trusted authority. Put that certificate and associated key on your device.
Now, when your user connects to your soft AP, they can browse to https://iot.example.com and actually see a valid certificate.
However, I would really recommend not doing this. You'll have three major issues to contend with:
The key for your SSL certificate will be on your device's flash. If anyone extracts it, they can masquerade as iot.example.com. You can mitigate this by using flash encryption, but it's still not great.
The maximum validity period for an SSL certificate is around two years. So your provisioning flow will break after a couple years.
If the CA that issued your certificate hears that the private key is floating around and could potentially be compromised, they will probably revoke your certificate.
Instead, what you should do is secure your soft AP with WPA2, and a password that you can give to users. This will ensure that the connection is encrypted, and you can serve your provisioning form over HTTP instead of HTTPS.
An even better approach rather than trying to implement this yourself, is to use the ESP-IDF unified provisioning API. It takes care of the implementation details, and supports both Wi-Fi and Bluetooth as transports.
Regardless of what you decide to do, I'd highly recommend reading the ESP-IDF documentation on unified provisioning and the documentation on Wi-Fi provisioning, since they'll give you an idea of what's going on under the hood and what all is required for a secure implementation. In particular, you'll see that the Wi-Fi provisioning library does actually use a static WPA2 password like I suggested above.
I am looking for device authentication where
I want to make sure that all calls to my web service\Website (hosted on Google App Engine) Is coming from an authorized device only, using a device certificate.
Each device will have a unique certificate that cannot be transferred to other devices.
A device certificate can be revoked anytime.
To achieve the above, I am planning to have another Service which would issue certificate to devices which is approved to use my service. I will issue the certificate via email to the user where he will install it manually. My users will use browser to access my service.
But I am not sure how would I achieve points 2 and 3.
Can you please guide as to how to achieve this using a self signed certificate?
I want to make sure that all calls to my web service\Website (hosted on Google App Engine) Is coming from an authorized device only, using a device certificate.
You can use a SSL channel with client authentication or adding a digital signature to your messages
Each device will have a unique certificate that cannot be transferred to other devices.
it is not possible to ensure this using software certificates. If you distribute them by email, the user could install them in several devices.
You could use a hardware token (nfc/bluetooth) or preinstall the certificate in the Android/iOS KeyChain so it would not be extractable. but this complicates the distribution very much.
A device certificate can be revoked anytime.
Check revocation at server side before accepting a request from a client. There are standard protocols to do this ( OCSP, CRL), or use a custom mechanism since you issue them yourself
I have installed a SSL certificate (comodo PositiveSSL) for my domain and forced NGINX to only use HTTPS.
I run the test on SSL analyzer
https://sslanalyzer.comodoca.com/?url=domain.com
Validation Type Domain Validated (DV)
Trusted by Microsoft? Yes
Trusted by Mozilla? Yes
We have our mobile app for Android and IOS getting some data from our https://example.com/api webservices.
So i have installed Packet Capture mobile app on my android to verify whether the data transferred between the webservice api and our mobile app is secured.
First i tried with enabling the following in Packet capture mobile app :-
I have contacted comodo ssl support, they said
that the certificate is installed well and its working fine. There is
nothing wrong with the certificate and installation process and the
web-site https://example.com/ is also completely secured with Green Pad
lock on it.
I run the same test on instagram app, when open instagram , showing network error. Like instagram discovering by some way that i am trying to capture a network packets so their app network will be disabled.
I want to do the same way of what instagram did .
Please Advice.
Don't worry, if your certificate is valid and contains the right domain name then you've already done everything needed.
A "man in the middle attack" is an attack done on the client.
The client think the attacker is the website by compromising his DNS
Then the attacker relay in and out traffic from/to the real server.
The server is secure but not the client.
Like RamKumar said the client need to trust the attacker certificate like you did
EDIT:
You can also use TLS with mutual authentication (mTLS).
With this protocol the client AND the server exchange certificate public keys.
It work as follow:
A client requests access to a protected resource.
The server presents its certificate to the client.
The client verifies the server’s certificate.
If successful, the client sends its certificate to the server.
The server verifies the client’s credentials.
If successful, the server grants access to the protected resource requested by the client.
Some sample:
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/october/mutual-authentication-in-android-and-ios/
With this protocol the man in the middle attack is still possible but the attacker's certificates need to be trusted by both client and server
Another custom approach would be to add another layer of encryption using asymetric cipher.
To remove that possibility you can use Certificate Pinning to make sure that only the specific Certificate you use can be used to prevent the device from using any other Certificate, even if it was signed from a trusted CA. This may still be circumvented by a user, but now he has to modify the application itself in order to disable the check, or change the pinned certificate
Have a look at how Certificate Authority (CA) works. In your case, what happens is that the Packet capture mobile app installs it's own CA. Now Packet capture becomes a trusted CA for your device and certificates signed by them are accepted. Then this app creates its own certificate saying example.com and signs it.
So when it performs man in the middle attack, the client (your app) communicates with Packet capture and not example.com, but your app believes it's communicating with the example.com, since the certificate provided by Packet capture is signed by a trusted CA (Packet capture CA itself).
Hence this works only when your install their CA. However a secured connection is made between Packet capture and example.com
I am trying to understand how client certificate authentication works with smart cards.
I've read about configuring Apache to authenticate users with a certificate. There are a lot of tutorials online, like APACHE web server and SSL authentication from LinuxConfig.
As far as I understand, once a certificate has been imported, anyone who can access the computer can launch the browser and use it. Thus, in the scenario of several users sharing the same account (or of an attacker having physical access to the computer and being able to log in), the user cannot be authenticated unequivocally. To avoid such a problem, when an account is shared, I could try not to store certificates in the browser.
Nowadays there are several USB tokens that can have certificates inside, which can be used to perform client certificate authentication to websites. Here are my questions about such devices:
By importing the certificate as a physical device, will the browser let me use the certificate as I imported it?
What happens if the certificate has a PIN? Does the browser ask for the PIN every time it is launched?
Can I be sure that the certificate cannot be extracted from the token/smart card reader? Therefore, unless the token is stolen, can I be sure that the certificate cannot be cloned?
by importing the certificate as a physical device, will the browser
let me use the certificate as I imported it?
Yes. However you may recognize a higher delay when using a hardware token compared to a software token (e.g. for a smartcard 2-3 seconds).
what happens if the certificate has a pin? Does the browser ask for
the pin every time it is launched?
by default e.g. Firefox only tries to access the client certificates if you connect to a web-page that has HTTPS client auth enabled. Then the PIN will be requested.
Usually the PIN is then no longer needed as long as the token is not removed but that behavior may differ depending on the used PKCS#11 module (the software that connects Firefox with the token).
can I be sure that the certificate cannot be extracted frmo the
token/smart card reader? Therefore, unless the token is stolen, can I
be sure that the certificate cannot be cloned?
Then depends on the token. Some may have an API for extracting the private key but usually you can only use or delete private key + certificate from the token.
I'm implementing a client with python's twisted that checks the server ssl certificate when connecting, following basically this recipe. I've seen in many HOWTOs such as this one the server checking the client's authenticity through a ssl certificate as well. Currently i authenticate my clients using an unique id and 1024 char string (they are automated clients without human interaction).
What I don't understand is what reason would I have to use the whole ssl thing for this instead of just sending the "password" to the server. After all the connection is already ssl encrypted, checking the server certificate and everything. This is a similar question but I want to know why people use ssl client certs and not just what is the best way to do it instead.
A client certificate restricts access to people authorized with certificates. Assuming your certificates are distributed and managed correctly, this makes it more difficult to connect from an unauthorized location (or say, a bot network), since you need more than just a username and password.
Client-side certificates are a potential part of a defense-in-depth strategy, if you are in an environment where you can manage client certificates.
Certificates are easy to revoke. Passwords can be stolen, but stealing a client side certificate would be much harder.
Using client certificate based mutual authentication prevents at least the following attacks/problems:
Phishing the password
Key logging the password
Shoulder surfing the password
Guessing the password
Password reuse on several services
Additionally, using client certs gives you the possibility to store client certificate (and the matching private key) on a smartcard, USB token or other hardware security module (HSM), thereby going from "something you know" (password) to "something you possess physically" (token, card) plus "something you know" (PIN). This is also called two-factor authentication.
In your specific case of using passwords as shared keys in a technical, system to system communication link, using certificates has two advantages:
scales better: with shared keys, every node has to share a different key/password with each other node, resulting in (n-1)! passwords, while with certificates, each node needs only one certificate and private key (n certificates plus a CA)
the possibility of storing the key on a HSM and thereby prevent it from being copied/stolen digitally.
The main advantage of client-side authentication (i.e. when server checks client certificate) is that if server gets compromised, the client's secret, which is private key for certificate, won't be compromised. Whereas if client uses credentials they could be compromised along with server.
Owning SSL certificates that are signed by a certificate authority means that the SSL certificate owners have gone through the hassle of being verified by the CA that the owner is who they say they are. For instance, if you have an ecommerce store called widgetsdeluxe.com and you have a certificate for the domain widgetsdeluxe.com that has been signed by Verisign, et. Al., shoppers will know that when they go to that site and the name on the certificate matches the actual domain name they went to, then they can trust that the information is secured and is coming from the widgetsdeluxe.com domain (this is to prevent spoofing and man-in-the-middle attacks).