<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 12:59 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good morning slackers, moving forward with my attempt to put pants on passphrases. I would like to discuss how the REST API would be with the change, because is better to have feedback instead of work for days and waste some time.<br>
<br>
Register push app:<br>
<br>
- HTTP request<br>
<br>
Remain unchanged<br>
<br>
- HTTP response<br>
<br>
{"id":"2095ab1a-a569-4ae2-a43c-a86b83041592”,<br>
"name":"MyApp”,<br>
"description":"awesome app”,<br>
"pushApplicationID":"ca99487d-6387-41bd-b393-0ce480977efe”,<br>
"masterSecret":"b315d524-e9f9-4d04-946c-b73278ff29be”,<br>
"developer":"admin”,<br>
"androidVariants":[],<br>
"simplePushVariants":[],<br>
“chromePackagedAppVariants":[],<br>
"publicKey":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEpsPA31qRWrtiAhnpGBzgwoE435c18gD42y13urb0JSdx4AHQRthhAUFVnu+RqUU8NTp9tGnEEhyBZfbV67arVw==“,<br>
“nonce”:”6KbYGZKvTusU+IL3sdY9g=="<br>
"iosvariants":[]}<br>
<br>
<br>
publicKey: Is the public key created per application and will be optional for developers who do care about security. If for some reason they don’t want to encrypt their passphrase or certificate, that’s ok.<br>
<br>
nonce: 16 bytes non-deterministic used to encrypt the data on the server<br>
<br>
Note: Both would be stored into UPS database (not perfect, but a good start)<br></blockquote><div><br></div><div>storing both on the server (initially) is fine</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Keep in mind that this is just the initial idea, for example, masterSecret should never return in clear. To the further interactions it will be fixed establishing a key agreement between client and server and encrypt the whole response (only for sensitive data). Yeah, I know, we are protected by SSL, but we shouldn’t trust on it.<br>
<br>
<br>
iOS Variant:<br>
<br>
- HTTP request<br>
<br>
Remain unchanged, but now certificate and passphrase can be send encrypted and the server will store it.<br></blockquote><div><br></div><div><br></div><div>encrptyed w/ the help of the public-key ? </div><div><br></div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- HTTP response<br>
<br>
Remain unchaged<br>
<br>
Sender:<br>
<br>
- HTTP request<br>
<br>
Remain unchanged, </blockquote><div><br></div><div><br></div><div>w/ "unchanged" you basically mean the payload of the "Send request" is the same as it is today, right ?</div><div><br></div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">but now the server will search for the application ID and retrieve the public key to decrypt application's passphrase<br>
</blockquote><div><br></div><div><br></div><div>Ok, that's internal details. So the server basically deprcypts both: cert and its passphrase, in order to establish the connection to APNs</div><div><br></div><div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- HTTP response<br>
<br>
Remain unchanged<br>
<br>
<br>
AeroGear Clients<br>
<br>
- cURL<br>
<br>
Yesterday I had the amusing experience of dig into the sources of OpenSSL and their documentation, to see how people could encrypt it from the command line. If I recommend that people would remember my name for the eternity in a bad way. Another insane idea was to provide encoders for GPG. The simplest idea, I think, would be provide code for people encrypt their passphrase and certificate, instead of trust in some software.<br>
</blockquote><div><br></div><div>but that's really just for the "registration part", right ? I don't care that much about a cumbersome API there :-) Because in 99% of all cases the actual registration (and cert/passphrase upload) is done via the sexy Admin UI.</div>
<div><br></div><div><br></div><div>The CURL for the send stays the same as it is today, right ? </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- aerogear-unifiedpush-java-client<br>
<br>
No problem to implement it.<br>
<br>
- aerogear-simplepush-java-client<br>
<br>
No problem to implement it.<br>
<br>
- aerogear-simplepush-node-client<br>
<br>
Not so easy, but they do OpenSSL behind the scenes<br>
<br>
- aerogear-unifiedpush-nodejs-client<br>
<br>
Not so easy, but they do OpenSSL behind the scenes<br>
<br>
<br>
So, what do you think? Yay/Nay? I would never use that?<br>
<br>
The goal is to provide secure alternatives to developers, but if the whole process will turn into a pain, I won’t move forward.<br></blockquote><div><br></div><div><br></div><div>It looks like it goes towards the right direction!</div>
<div><br></div><div>Thanks for looking into it</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
<br>
<br>
--<br>
abstractj<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br>
<br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div>