On Wed, Feb 12, 2014 at 3:15 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
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.
![](
http://photon.abstractj.org/keymgmt_20140212_113030_20140212_113032.jpg)
### 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...
)
You mean the new "key server" supports multiple databases, right ?
- 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
Changing from POST to GET (for UPS login) is fine we me. The Login is
really only relevant to the Admin UI.
Historically: I picked POST because that's what all of our client libraries
use as the default HTTP method for login (JS, iOS and Android)
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:
What clients do you mean? The only thing that really does a login against
the server is the Admin UI (or a direct curl, using the same 'management'
rest-endpoints which are accessed by the AdminUI).
- 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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf