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.
Related
I've been breaking my head over how to do this, as it doesn't seem to fit any example I could find online.
My IOT device servers will run on the client network and may be accessed over it or over the open internet (with port forwarding). the device comes with a paper-printed initial pass like a router.
the client is running a mobile app.
As I hate planned obsolescence (ie, the device should keep working even if the company shuts down), I don't want to create a dependence on any third-party auth service, so the server and the app should just establish trust between themselves.
with the initial contact assumed to be trusted.
In all the examples for gPRC auth I could find, the client should somehow have ahead of time the server public key. but as there are many devices, and I want each one to have a unique cert, I don't see how I can ship the app preloaded for the specific device the user will get.
I have come up with the following:
the device generates private/public key
an insecure grpc channel serves the public key to the client
the secure grpc channel is established with that key
the client authenticates with the initial password to use the API over the secure channel
client changes the password
I'm not looking for super-max security, just basic common-sense security.
the main issue I have with the typical scheme where SSL is used to authenticate vs a domain is that I don't know via what domain/address the device would be accessed.
are there any glaring problems in the scheme? or any reason it would not work?
Thanks!
Suppose I have a mobile app which makes API calls to a server using HTTPS.
Would a malicious user be able to install Wireshark + Android emulator to inspect the API calls and by doing so get access to sensitive data like an API key?
I guess my question is whether Wireshark (or some other tool) can inspect the request before it gets encrypted.
If you control the client, then of course yes. Anything the client knows, its user may also know.
Without controlling the client, no, an external attacker cannot inspect or change https traffic unless they know the session keys. For that, they would typically use a fake certificate and make the client accept it (it won't do it by itself, and we are back at controlling the client).
Would a malicious user be able to install Wireshark + Android emulator to inspect the API calls and by doing so get access to sensitive data like an API key?
I guess my question is whether Wireshark (or some other tool) can inspect the request before it gets encrypted.
Yes this possible if the user controls the device he wants to intercept the API calls.
In the blog post Steal that API Key with a Man in the Middle Attack I show how a proxy tool(MitmProxy) can be used to intercept and introspect the https calls:
While we can use advanced techniques, like JNI/NDK, to hide the API key in the mobile app code, it will not impede someone from performing a MitM attack in order to steal the API key. In fact a MitM attack is easy to the point that it can even be achieved by non developers.
In order to protect https calls from being intercepted, introspected and modified the solution is to use certificate pinning:
Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.
and you can learn how to implement it in the article Securing HTTPS with Certificate Pinning on Android:
In this article you have learned that certificate pinning is the act of associating a domain name with their expected X.509 certificate, and that this is necessary to protect trust based assumptions in the certificate chain. Mistakenly issued or compromised certificates are a threat, and it is also necessary to protect the mobile app against their use in hostile environments like public wifis, or against DNS Hijacking attacks.
You also learned that certificate pinning should be used anytime you deal with Personal Identifiable Information or any other sensitive data, otherwise the communication channel between the mobile app and the API server can be inspected, modified or redirected by an attacker.
Finally you learned how to prevent MitM attacks with the implementation of certificate pinning in an Android app that makes use of a network security config file for modern Android devices, and later by using TrustKit package which supports certificate pinning for both modern and old devices.
While certificate pinning raises the bar, its still possible to intercept, introspect and modify https traffic, because it can be bypassed, as I demonstrate in the article Bypassing Certificate Pinning:
In this article you will learn how to repackage a mobile app in order to make it trust custom ssl certificates. This will allow us to bypass certificate pinning.
Conclusion
While certificate pinning can be bypassed I still strongly recommend its use, because it will protect the https communication channel betwwen your mobile app and API server in all other scenarios where is not the user trying to perform the Man in the Middle attack:
In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communications between two parties who believe they are directly communicating with each other. One example of a MITM attack is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all relevant messages passing between the two victims and inject new ones. This is straightforward in many circumstances; for example, an attacker within reception range of an unencrypted wireless access point (Wi-Fi[1][2]) could insert themselves as a man-in-the-middle.[3]
Going the extra mile?
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
HTTPS request is encrypted on your host (client) before sending over the network, so it is not available for Wireshark. Wireshark can get hostname of the HTTPS web serserver you connect but not the URL.
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.