I’ve seen the first certificate has just been released in helloworld.letsencrypt.org. I see right now it is needed to perform some actions (add the ISRG root certificate) in order to have it working on browsers. I understand this won’t be needed once browsers accept this certificate as a trusted authority. So far so good.
But I do have one doubt for another use (not browsers); regardless of browsers trusting let’s encrypt or whenever that happens, if I were to use this certificate for a REST api, could I do it without any problems? To give some context, I develop android applications and I have REST apis for many of them. One problem I’ve had is securing important calls with private information (like /login). My solution so far has been to obfuscate sensitive data, but I’ve read that if I use https:// schema the data is encrypted and sniffers like wireshark cannot read it.
Is this reasoning correct? Or should I mark this as “trusted” somewhere in the Android app? As you can tell I know next to nothing about this certificates.
You should definitely start using HTTPS for private information.
I’m not familiar with Android development so treat my reply accordingly. I would assume that Chrome for Android will get the ISRG root certificate in a future update but I doubt that will make the whole system trust the certificate. Only way to automatically get the certificate trusted by the system might be an OS update. The certificate can of course be added manually but that would be too difficult for the users of your apps.
You should be able to set the certificate as trusted by the app. Here’s an example how to do it if you are using URLConnection: https://developer.android.com/training/articles/security-ssl.html#UnknownCa. Of course if you are doing this then there is no need to use Let’s Encrypt at all. You can just create your own certificates.
Thanks mkoko, I understand it perfectly now. So the correct approach would be to implement what’s indicated in that link you passed from Android documentation, thanks!
It’s true that I don’t have to use let’s encrypt for that, but as I said I don’t know much about certificates, and let’s encrypt aims to make things easier, so that’s why I prefer to use it.
You will need the root certificate in your certificate store somehow. However, at launch all issued certificates will be cross-signed by another CA that is already trusted to prevent issues like this.
I assume the cross-signing will be dropped in the future when there are enough clients supporting LE for a long enough time, but I don’t have any recent information for you here.
If the only intended recipient of the certificates is an application that you develop yourself, you don’t necessarily need to use the public PKI at all. You could instead tell your application to accept particular certificates or to accept certificates from a CA that you control.
I don’t have a reference to this handy, but people have written about this quite a bit.
@rugk What do you think is so bad about that? At least like this it’s not possible to take someone’s password only seeing the request (you’d be surprised how many apps don’t hide anything and simply by watching the requests you can get the password of users). And I’m already trying to improve that, so I don’t see why you should react like that.
No, but after 5 minutes they get out what's the request 'obscurity' is and that's all.
No I'm not surprised, because this is bad - very bad. And that's also one of the reasons for LE - a simple and free CA for real security on the web (not only related apps).
Sorry I couldn't react another way. If I see things like this I have to warn other people from using this as a guide, so it's not about you.
Finally, now to the most important question:
It's 'security through obscurity', which is not real security. But here are more information:
Security through obscurity is the reliance on the secrecy of the
implementation of a system or components of a system to keep it secure.
Security though obscurity is a weak security control, and nearly always
fails when it is the only control.
