I an responsible for deploying a large amount of embedded devices and want to add https.
I've done a bit of googling and am a little confused as to where exactly my plan falls through.
Get a certificate signed by a reputable CA
Use the corresponding private key to sign new certs for each device
User connects to device (e.g.192.168.1.40) and receives 2 certificates
User's browser verifies that the device's cert. was issued by my company
User's browser verifies that my companies cert. was issued by reputable CA
Can someone please poke a few holes in that??
Similar question here
Related
I'm building my first web app and I have two questions about security.
I'll send and receive very sensitive data with POST request to my
api which will be hosted on Azure or AWS. Can I send and receive
data in plaintext over SSL, is it secure? I can access my
azure web site over https, is it secure enough or should I buy another
SSL sertificate?
I've searched a little bit and there are different types of SSL
certificates, I read some certificates provide green padlock or green address bar but I don't need these kinds of things since my web app only
will be available to my mobile app and there will be no content to browse. Only one page with download links to my mobile app in case someone finds this site. So all certificates are secure on same level for my situation?
P.S. I won't add custom domain name, if that's relevant.
Answering your questions one at a time;
Modern implementations of SSL are generally considered to be pretty
rock-solid; its used by banks, healthcare institutions, and major
internet companies. Sending data in plaintext, over SSL, is
safe enough for those applications, and trying to replace SSL with
your own encryption scheme is almost certainly more trouble than its worth.
You should probably get your own SSL certificate; I don't know what restrictions Azure has on https access, if any, and its always bad practice to rely on a key you cannot control.
SSL relies on networks of trust; browsers (and other internet applications) validate the certificates sites send them against a
set of trusted authorities. If the certificate has been approved
(signed with the authority's private key), the browser accepts the
certificate as genuine and uses it to negotiate an SSL connection
with the site without further complaint. This is what that green
padlock/address bar means; that a site has provided a valid
certificate signed by an authority the browser trusts. This doesn't
mean that a signed certificate is inherently more secure than an
unsigned certificate, however. Both use the same cryptographic
algorithms, and (can) have the same length keys, and the SSL
connections each can set up are equally secure. The difference
between the two is that you can't verify the "authenticity" of an
unsigned/self-signed certificate; an attacker could intercept the
connection and replace an unsigned certificate with their own
certificate, and the browser would have no way of telling if it got
the right certificate or not. You can overcome this problem in your
application, however, with a technique called "certificate
pinning".
Essentially, you package the public key for your certificate with
your application, and your application only accepts the certificate
associated with that key when setting up a connection.
Ultimately, it depends on your attacker model. Are you protecting this data from criminals and casual wiretappers? Or are you trying to hide it from government surveillance and intelligence agencies? For the former, an SSL certificate signed and issued by a reputable authority is more than sufficient. For the latter, you have to consider where your certificate is coming from, and who can access the root CA that issued it; it might be better to generate your own, and devise some further scheme on top of SSL.
I currently develop a small system consisting of an embedded server (including a small display) and some mobile devices (at the moment just Android phones).
These mobile devices should be able to talk to the embedded server over a secure channel. For this purpose, the server generates a self-signed SSL certificate during the very first boot process.
If a new mobile device should be connected to the server, the server displays a QR code consisting of:
Server IP
SSL certificate fingerprint
Random device ID
The user scans this QR code using his mobile device. The mobile device connects to the server and checks whether the SSL certificate fingerprint matches the one scanned before.
Is this considered secure? If not, how would you solve this problem?
An alternative approach:
On the very-first boot, the server generates a certificate request and sends it to a central CA server which signs the certificate. The client devices has installed the CA certficate and verifies the server certificate against it.
However, everyone could send a certificate request to the CA server and would get a signed certificate. (One could propably implement some authentication for the CA server using a "master key" but once that is extracted from a system image, the whole authentication becomes useless). In addition this setup requires a central server which I like to avoid since the product may be used in a "offline" environment.
Yes, this is considered secure because the fingerprint of the server's certificate is transferred to the client via a trusted mechanism (being physically next to the server to receive the fingerprint via a difficult to tamper with transport mechanism). If a MITM attack were to be attempted after the initial setup, even though server name would be the same, different keys would have been generated so the fingerprint would be different and the client would detect this and can appropriately reject the communication.
It could also be argued that this method is more secure because the client does not need to trust a 3rd party to verify the authenticity of the certificate. CAs do occasionally issue fraudulent certificates.
I have an embedded device which runs a web server.I need to integrate the server SSL certificate for the web server. If I have multiple such boxes, is it required to have different SSL for each box?
You can buy a wildcard certificate say for *.mydevices.mydomain.com, then give each device a name like myRouter1.mydevices.mydomain.com and that's it. Certificate Authorities do sell wildcard certificates, yet they are more expensive (but if you have many devices, this will be cheaper).
You need to consider one thing though - if the certificate's private key leaks from the device in any way (eg. the device is stolen altogether), you can revoke the certificate. But if you have one certificate shared on all devices, then the leak will invalidate all devices at the same time and you will have to replace the no more valid certificate on all devices.
Of course, you're going to get an "it depends":
If your users require a CA-signed certificate, then you'll have to pay for one for each box and load it some way. Browser's then won't complain...
If your users will allow a self-signed certificate, then you can just have the box generate one when it is commissioned. But, your user's browser's will complain...
If you ship with the same certificate, then it's kind of a security problem for you.
I would build a mechanism in so the user can load a certificate to the box in the field. Then you can satisfy whatever need comes up.
I don't have any experience on using a digital cert.
Recently I wrote an application in J2ME and Qt for the Nokia S40 and S60 /Symbian ^3/Anna/Belle series phones.
My question is mainly on S40 J2ME phones.
My app need to read /write from memory cards and thus needs a digital cert signing.
I plan to let users download my apps from my site and my questions are:
If I bought a cert, does it mean that I use the same cert to sign any number of J2ME apps? Or one cert one app?
After signing an app with a cert, will it run after the cert expired? Suppose the cert is valid at the time signing the code. I read some articles about timestamp for PDF documents and Microsoft code signing, and not sure whether it is needed for J2ME apps.
I assume many S40 users won't connect to internet. But when a user tries to install the MIDlet, is it necessary to connect through network to the cert issuer's site to verify the cert?
You can use the purchased certificate to sign any number of applications until it expires
Your midlet will still work and install but you will not be able to sign new ones with an expired certificate. See also this post
certificate validation does not require network access. The root certificate of the issuer is already on the device. Be aware that you should use a certificate issuer whose root certificate is on your target devices.
In J2ME when you sign a JAR with a certificate chain that includes an intermediate certificate (such as one from obtained from Verisign), does the device need to have the intermediate certificate installed as well as the root certificate during verification?
I am guessing the answer is no because the intermediate certificates are stored in the JAD file in the MIDlet-n-m properties where m is 2 or greater, and I believe the device references these while verifying. If that is true then J2ME certificates are different from SSL website certificates which require the intermediate certificates be installed in the browser, correct?
Finally if this is all true then couldn't anyone who gets a certificate from Verisign or any other CA with their root certificate on the device just go ahead and sign their friend's certificates and then their friends will be trusted?
Seems like a flaw in the system if this is all true...
The certificate one gets from verisign would typically be trusted to sign a MIDlet but not another certificate. Certificates trusted to sign MIDlets usually are not trusted to sign native applications either.
Between this and the (admitedly advanced and not always available) ability to revoke certificates, the system is fairly safe as long as trust is preceded by due diligence (so your Mobile Network Operator doesn't start trusting trojans and such...)
Frankly, it's not like mobile airwaves are inherently secure anyway.