I was having a conversation with some programmer friends about securing an API without server modification.

Only SFTP access to the filesystem is allowed and OpenSSL extension is installed, the admin won't allow you to install SSL certificates and therefore in this thought experiment, you're only allowed to upload normal code files to the server.

I'd be very happy if somebody here can tear holes in the solution.

Please ignore identity problems, this solution ignores MITM attacks from knowing WHO the client and server are proved to be who they are supposed to be. So all manner of DNS or network level attacks are not part of the discussion.

So, the communication goes like this

  • Client generates it's own public key, so secure replies
  • Client knows the endpoint in the server to request it's public key
  • Client connects to endpoint, obtains public key of server
  • Client wants to login to server, builds message and inserts it's public key for any replies to be encrypted with
  • Server receives message, decrypts using it's private key, extracts public key and interprets and builds reply message
  • Server encrypts final message using client public key and sends the data back
  • Client decrypts the data using it's public key and the cycle begins again

First question arise in that does this system already exist and has a name?

Of course SSL certificates can solve this problem, but in this thought experiment, you cannot install them, so they won't help to solve this problem.

Is the above method secure? and if not, what holes can you think of?

  • 1
    1. Protection against passive attacks only is not very useful. 2. Don't reinvent TLS or libsodium. – Z.T. Oct 26 '15 at 19:52
  • sure, but the only tool you have available to you in this mental experiment, is the language itself, or a library installed within it, no server level access is allowed. lets make this even more restrictive, it's a shared host, you have only FTP access, so you can't even install a SSL cert, even if you wanted to. I'll modify my question to make that part of the requirements – Christopher Thomas Oct 26 '15 at 19:53
  • libsodium was a nice keyword to google around on though, thanks! – Christopher Thomas Oct 26 '15 at 19:56
  • The browser needs to load your app's code (javascript), but it cannot trust the download from your site because it's in the clear. So maybe it runs your code and implements secure communication with your server, and maybe it runs a modified app that give all your bitcoins to the bad guys. – Z.T. Oct 26 '15 at 23:23
  • 1
    That part is a solved problem. ECDH (X25519) gives you an anonymous shared secret, you use the secret as seed for shared encryption keys, you use AEAD (chacha20+poly1305) to talk securely, inside the encrypted channel you use Ed25519 digital signatures to make the other side prove they have the secret keys to the public keys you expect, now you know who you're talking to. Libsodium gives you high level API for all this, and once SIMD in JS is standardized, chacha20 in JS will be fast. – Z.T. Oct 27 '15 at 11:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.