I was wondering if it was possible to implement a server that only has encrypted data and authorization (so without TLS that requires also authenticating the certificate). Similar to SSH but works with mobile app development platforms (iOS/Android/React Native/etc).

Edit: We do not want to have to manually install keys on each client, nor to run a custom certificate authority (CA). And most devices will be running on private LAN using reserved IP addresses, so standard CA's will not issue certificates because that is no longer allowed for reserved IP addresses. This is essentially the emerging IoT issue of having encrypted data transfers over private networks. But it appears that the common mobile platforms MUST use SSL/TLS to get encryption. SSH would be fine, except that there do not appear to be good solutions available for mobile platforms like React Native, Nativescript, Ionic, etc.

closed as too broad by Steffen Ullrich, Steve, Xander, Serge Ballesta, CaffeineAddiction Mar 3 '17 at 19:34

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Yes, but why would you do it when TLS is so much easier? – immibis Mar 3 '17 at 3:50
  • There's a couple of parts of your question that are quite vague. What is a server that only **has** encrypted data. Did you mean SSL, instead of SSH? – Jedi Mar 3 '17 at 14:11
  • yes, you can implement encryption purely on the application layer; that's how E2E works. – dandavis Mar 3 '17 at 20:33

Yes it is possible. But why would you do that?

All mobile platforms supports TLS, why reinvent the wheel?

Encryption is very hard to get right, and easy to get wrong. If you can invent a better encryption than the guys that write TLS software, you wouldn't be asking this question.

  • How would you do it? Where would you bootstrap trust that would work cross-platform? – Jedi Mar 3 '17 at 4:48
  • 1
    @Jedi: please don't ask new questions in a comment. Your original question (if it is possible) was answered with yes and asking how to do it is a new question and apart from that too broad. But, if you look at how TLS does things and understand why it does things this way you will probably also understand how to do it yourself and maybe realize that in most cases it makes no sense to reinvent the wheel (i.e. TLS) again. – Steffen Ullrich Mar 3 '17 at 5:20
  • 2
    It wasn't his question; the comment here seems intended to prompt how exactly this would actually work, rather than taking the answer's "yes" at face value. – Xiong Chiamiov Mar 3 '17 at 6:34
  • 1
    @Jedi The question is about securing an API, not about distributing an application. The application could be distributed through a package manager or an App Store. Even for a web application you could theoretically distribute the application via https and have it communicate with a plain http API. – CodesInChaos Mar 3 '17 at 9:31
  • @CodesInChaos, I'm not worried about the mechanics of app distribution-- just curious about how we could roll-our-own TLS without any way to create the huge infrastructure that supports it. XiongChiamiov, yes, that was my intent. – Jedi Mar 3 '17 at 14:09

TLS doesn't just give you encryption. It gives you trusted authentication. All the privacy in the world doesn't matter if you don't know who it is you're having that private conversation with.

Without a PKI and a CA it would be very hard to implement your own form of trusted authentication, unless you are willing to distribute keys ahead of time.

So I'm going to vote "No," it's not really possible, unless you are willing to do a lot of work.


It is possible, but SSH specifically may not be a good model for this application in the first place.

SSH has a Trust On First Use (TOFU) approach, which requires the user to decide whether or not to accept a server's key on first connection. TLS, in comparison, has (admittedly imperfect) means of trying to determine whether a given key can be reasonably accepted to identify a server. Only if something unusual is found (e.g. self-signed cert, mismatched/expired/invalid cert, etc) is the user asked to think (and there is much evidence that the thinking is replaced with just clicking OK without reading the message).

In other words, one requires you both trust your users, and assume them to be capable of making informed decisions when presented with a trust association. The other requires you to use an imperfect but well established, and mostly functional, system for establishing that trust.

Another factor is that your setup sounds an awful lot like you would have a single encryption key for clients to send data to you. Which means, in the absence of TLS, anyone with that key (i.e. extracting it from your app) can decrypt ALL traffic sent to your API. TLS solves that for you too.

You could argue that you would have per-client keys, but that:

  • needs managing
  • requires the keys to be shared somehow
  • and presumably, requires users to be able to communicate with you without encryption...

tl;dr: Possible, but even if you found a perfect means of doing all this correctly, you would still have a compelling use case for TLS to cover all kinds of edge (and quite possibly, core) cases.

Not the answer you're looking for? Browse other questions tagged or ask your own question.