11:15 p.m.
Good morning, over the weekend I was thinking about how to protect the way how the
passphrases are provided in UPS (https://issues.jboss.org/browse/AGPUSH-358) and would
like to propose some changes, but before moving forward let's validate if what I am
saying makes sense.
**Note**: Matthias already started some thread about it
(http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Question-around-en...).
But I didn't get the chance to look UPS and have a decent answer.
I would like to hear what do you think to start to file Jiras or change the proposal.
URL: https://gist.github.com/abstractj/4c6cd242584f4ab406aa
# 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/datast...)
- 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
- Generate a key pair on the client side to sign our HTTP requests
- Generate the keys per session (http://en.wikipedia.org/wiki/Ephemeral_key)
--
abstractj