Passphrase protection proposal and UPS
by Bruno Oliveira
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
10 years, 3 months
aerogear.org revamp: where to fit in platform example page?
by Corinne Krych
Hello Hylke,
We already discussed it in this thread [1], but I rather have the question
in its own dedicated thread.
Atm, the mockup defines 3 pages/layers: HOME, GET IT, and EXMAPLE page. I
think we're missing a PLATFORM EXAMPLE page. This page wil explain in more
details with the user prefered platform how to deal with AG Core Pipe etc...
Idally this page will have a github cookbook repo assiciated to it. We have
cookbook for the 3 plaforms: android, iOS, JS so far and we also have demo
repo. A crossrefence table like this one [2] could also be useful.
An example page with high level concept and definition illustrated with
code snippet is good. But not enough. Besides, atm we have an extensive
documentation that goes in much more details and i really think we should
keep this level of details.
My question is: How do me transition from EXAMPLE to PALTFORM EXAMPLE? Does
it make sense to you? wdyt?
Last time I did a hackengarten on AeroGear, people told me: Woah, you've
got such a great documentation, explaining step by step. And I told them
wait until we've got our killer revamp ;)
++
Corinne
[1]
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Fwd-Website-restru...
[2] https://github.com/aerogear/aerogear-ios-cookbook/blob/master/README.md
10 years, 3 months
Bump up version of aerogear-push-ios-registration
by Christos Vasilakis
Hi team,
since the last 0.8 release of the aerogear-push-ios-registration lib, we have upgraded it to use AFNetworking lib to 1.3.3. Since the release of aerogear-ios has been upgraded too 1.3.3 also, and can depend on push lib, in order to not have problems with the dependency what to you think of bumping up the version of aerogear-push-ios-registration to 0.8.1 and releasing to cocoapods.
Thoughts?
Thanks,
Christos
10 years, 3 months
Re: [aerogear-dev] [aerogear-issues] Update
by Matthias Wessendorf
Hello Miguel,
forwarding this to our developer list (see [1]). Feel free to subscribe to
it.
Looking at your stacktrace, I think the problem here is that you are not
using the https scheme
(02-16 15:51:30.899: E/HttpRestProvider(21213): Error on POST of
http://aerogear-metalpush.rhcloud.com/rest/registry/device)
when posting to http, the server does a redirect (302) to the https scheme,
looks like this is not understood by our Android library.
Can you try the same registration process, but instead using https (
https://aerogear-metalpush.rhcloud.com ) ?
Greetings,
Matthias
[1] https://lists.jboss.org/mailman/listinfo/aerogear-dev
On Sun, Feb 16, 2014 at 5:25 PM, Miguel Lemos <miguel21op(a)gmail.com> wrote:
> Dear all,
>
> I made an update to your last library version and I get the same errors.
> My app uses Cordova 3.3 and the device where I test the plugin runs
> Android 4.1.
>
> I attach a small logcat file where is summarized what makes the app not
> register (?) to the service.
>
> The errorHandler function, as I said before, throws this error:
>
> java.io.IOException:BufferedinputStream is closed
>
> The app itself keeps running, though...
> I appreciate any help because I don't know what else I can do.
>
> A thing I noticed:
>
> Inside the Aerogear Console, where is the Android Variant with all data,
> the table that describes the Token, Device, etc, is empty. I presume it's
> only filled the first time the device manages to register, or else...?
>
> I think your solution is very promising and makes the right approach to a
> real problem, but i must manage to make it work :-(
>
> Thanks again
>
> Miguel
>
> _______________________________________________
> aerogear-issues mailing list
> aerogear-issues(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-issues
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 3 months
AeroGear project leadership updates
by Jay Balunas
Hi All,
The AeroGear project has come a long way and Qmx a.k.a. Douglas Campos has been at the helm. Qmx has decided to transition to an individual contributor and full time code monkey :-) Thanks for your time and effort leading the project Qmx!
I'm very happy to announce that Matthias Wessendorf has agreed to take over the AeroGear project lead role! He's been part of the team since nearly the beginning and has already shown great leadership qualities to go along with his technical experience in both mobile, enterprise, and open source domains.
As part of this transition we're also announcing some additional leadership roles within client teams. These tech leads will help Matthias coordinate and navigate the complex waters of mobile client SDK development.
Corinne Krych iOS -- a.k.a. "Corrine.dmg"
Luke Holmquist JavaScript -- a.k.a. "Luke.js"
Daniel Passos Android -- a.k.a. "Passos.apk"
I just want to say that i'm proud of the whole team, and I'm excited to see what we can accomplish in the coming year.
Congratulation to everyone and thanks again Qmx for you time at the helm!
-Jay
10 years, 3 months
