Skip to content

Instantly share code, notes, and snippets.

@abstractj
Last active August 29, 2015 13:56
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save abstractj/4c6cd242584f4ab406aa to your computer and use it in GitHub Desktop.
Save abstractj/4c6cd242584f4ab406aa to your computer and use it in GitHub Desktop.

Passphrase protection and friends

Current scenario

  • At the moment passphrases and certificates are protected with HTTPS, but we also have CRIME, BEAST and friends.
  • From the UPS dictionary (http://aerogear.org/docs/specs/aerogear-server-push/) I understand a Variant as an application (Android, iPhone....)
  • From the usage scenarios, I understand that's possible to send messages to a group of devices. Ex: Bruno sends "ahoy" to 3 different variants.
  • Currently the passphrase is stored in plaintext

Reading the sources from UPS and the whole documentation I could clearly understand that what do we need might be the same thing being developed for offline, a key management server. I think this must be a separated project to everyone benefit of it.

What is the whole idea?

The idea is kinda of simple, but must be validated to check how it meet your needs, each developer with access on the server side will have her own key pair generated and encoded in binary format.

Some considerations

  • The key pair will be generated in a separated project, not on UPS
  • For the key store I'm considering to support the same data stores provided by SPS. What Dan did is a nice a idea (https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores)
  • For each key pair will be generated a self signed certificated encoded in DER format and stored into the database (http://en.wikipedia.org/wiki/X.509)
  • The key pair will be unique per user, like GPG does.
  • We only provide a public key for encryption after successful authentication into the system

Changes suggested on UPS server

  1. Login endpoint

    • Current login endpoint:

        POST		/rest/auth/login
      
    • Suggested change:

      I'm not sure if we really need POST for login, unless we are changing the state of some resource

        GET			/rest/auth/login
      

      Response:

        {public-key: <a binary stream or just plain string>}
      
  2. Register push app

    • Our push clients will need to change to accept the public key provided by the server and encrypt the passphrase. We can make use of AG Crypto for it
    • The basic workflow for our clients would be:
      • Send a login request
      • Get the public key
      • Encrypt the passphrase
      • Send a request like we do at the moment
    • For non AG UPS clients like cURL, the steps with OpenSSL will be provided. I also consider the possibility of use GPG as alternative, but something to be tested and evaluated.

Future

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment