<div dir="ltr">ok,<div><br></div><div style> I will write something, so that we have concrete things to talk about</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 22, 2013 at 11:25 AM, 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">I'm fine on have a hangout anytime, but at least to me (abstractj) will be useless, until I get some working code for Pushee to validate ideas.<br>
<div class="im"><br>
Matthias Wessendorf wrote:<br>
> Let's have hangout to talk about the proposed ideas and the related<br>
> discussion, instead of getting lost in countless emails.<br>
><br>
> I am happy to summarise the out come here, on this ML thread<br>
><br>
><br>
> On Wed, May 22, 2013 at 7:03 AM, Matthias Wessendorf<br>
</div><div class="im">> <<a href="mailto:matzew@apache.org">matzew@apache.org</a> <mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>>> wrote:<br>
><br>
><br>
><br>
><br>
> On Wed, May 22, 2013 at 12:13 AM, Bruno Oliveira<br>
</div><div class="im">> <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a> <mailto:<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>>> wrote:<br>
><br>
> Is it a priority? If yes, please file a jira.<br>
><br>
><br>
><br>
> Nah, not a priority at all.<br>
><br>
><br>
> Matthias Wessendorf wrote:<br>
> > 1a)<br>
> > would perhaps,... add some "monitoring" if an unreasonalble<br>
> about of<br>
> > "new devices" is registered, but that means we need some sort<br>
> > of analysis component (not for the first iteration) :)<br>
> ><br>
> > whoops, typos ===><br>
> > we could perhaps,... add some "monitoring" if an<br>
> unreasonable amount of<br>
> > "new devices" is registered, but that means we need some sort<br>
> > of analysis component (not for the first iteration) :)<br>
> ><br>
> ><br>
> ><br>
> > On Sun, May 19, 2013 at 11:08 AM, Matthias Wessendorf<br>
> <<a href="mailto:matzew@apache.org">matzew@apache.org</a> <mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>><br>
</div><div><div class="h5">> > <mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a> <mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>>>> wrote:<br>
> ><br>
> > Concerns with both approaches<br>
> ><br>
> ><br>
> > 1)<br>
> > It would be possible to register new devices, if the<br>
> pub/private key<br>
> > (or the accessKey:secret combination) would be hacked.<br>
> ><br>
> > HOWEVER, the "hacker" has to know how to generate VALID<br>
> tokens for<br>
> > the different push-networks. Apple and Google will NOT<br>
> accept<br>
> > incorrect tokens, and IMO this as a minimal risk.<br>
> > Similar for SimplePush. The SimplePush Network/Server,<br>
> generates<br>
> > UUIDv4 key, for every channel, so IMO.... it's hard to<br>
> "hijack" that<br>
> > as well.<br>
> > => But I may be just naive.<br>
> ><br>
> ><br>
> > 1a)<br>
> > would perhaps,... add some "monitoring" if an<br>
> unreasonalble about of<br>
> > "new devices" is registered, but that means we need some sort<br>
> > of analysis component (not for the first iteration) :)<br>
> ><br>
> ><br>
> > 2) hacker can update device info<br>
> > If the pub/private key (or the accessKey:secret<br>
> combination) are<br>
> > being compromised. it is possible to update informations<br>
> for a<br>
> > certain device. IF... he know the "token".<br>
> > So... it's than very simple that the hacker can update<br>
> informations<br>
> > for his phone (since that token is VERY easy to read,<br>
> via the<br>
> > platform APIs).<br>
> > IMO not a big deal. If he updates his iPhone metadata<br>
> (e.g. changing<br>
> > "iOS" to "Android"). If he changes his token, he looks<br>
> himself out<br>
> > -> No longer receives "push notification messages"<br>
> ><br>
> > 2a)<br>
> > A hacker could update device infomations for other<br>
> devices. BUT !!!!<br>
> > he has to know the token of other devices, registered<br>
> with our<br>
> > server. This means, he needs access to those devices.<br>
> > => IMO as well not a big risk..<br>
> ><br>
> ><br>
> ><br>
> > Summary:<br>
> > I think, if we really have a "extra" pub/private key<br>
> (or the<br>
> > accessKey:secret combination) for "device<br>
> (un)registration", and not<br>
> > allowing this pub/private key (or the accessKey:secret<br>
> combination)<br>
> > on other HTTP calls (e.g. register Push Application,<br>
> register mobile<br>
> > Varian, sending): The risk is IMO minimal.<br>
> ><br>
> ><br>
> > Thoughts ?<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Sun, May 19, 2013 at 10:58 AM, Matthias Wessendorf<br>
> > <<a href="mailto:matzew@apache.org">matzew@apache.org</a> <mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>><br>
</div></div><div class="im">> <mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a> <mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>>>> wrote:<br>
> ><br>
> > Another idea....<br>
> ><br>
> > We generate, for EACH variant, an "access-key" with<br>
> a generated<br>
> > secret(password). This accessKey:secret combination<br>
> would be,<br>
> > similar to the previous email, ONLY be able to<br>
> perform updates<br>
> > for "device (un)registration".<br>
> ><br>
> > It would be NOT possible to use this combination for<br>
> sending<br>
> > messages to a device, (read: our HTTP send interface<br>
> would not<br>
> > allow this accessKey:secret combination).<br>
> ><br>
> ><br>
> > Not, sure, but this is (I guess) a bit simpler,<br>
> initially,<br>
> > instead of using private/public key approach.<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Sat, May 18, 2013 at 12:48 AM, Matthias Wessendorf<br>
> > <<a href="mailto:matzew@apache.org">matzew@apache.org</a> <mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>><br>
</div><div><div class="h5">> <mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a> <mailto:<a href="mailto:matzew@apache.org">matzew@apache.org</a>>>> wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > once the app is installed on the phone (or<br>
> launched in a<br>
> > browser),<br>
> > we (as discussed in the spec/mailing list) need<br>
> to upload<br>
> > the "device token" (or channelID) from the actual<br>
> > device/channel to the Unified Push Server.<br>
> ><br>
> ><br>
> > My questions:<br>
> > Is it safe, if every "Mobile Variant" has a<br>
> Private/Public<br>
> > Key ???<br>
> ><br>
> > The UP server keeps the private one.<br>
> > Once we register a new mobile variant (e.g. HR<br>
> for Android,<br>
> > HR for iPad, HR for iPhone, ...) EACH variant<br>
> has ONE<br>
> > Private/Public key<br>
> ><br>
> ><br>
> > The Public Key of this combo would be "coded"<br>
> into the<br>
> > actual mobiel application...<br>
> ><br>
> > On EVERY iOS app, it would use the PubKey from<br>
> the iOS<br>
> > Variant, on EVERY JS-app, it would use the<br>
> PubKey from the<br>
> > SimplePush Variant, etc<br>
> ><br>
> ><br>
> > So, that means EVERY installation (on the<br>
> devices) would<br>
> > have that pbulci key...<br>
> ><br>
> > Would that be (extremely) odd, if "1 Mio Russian<br>
> hacker"<br>
> > would have that public key, used on the device,<br>
> to perform<br>
> > some sort of "auth" (e.g. via HTTP BASIC (just<br>
> saying.....))<br>
> > against the server, in order to upload the<br>
> "device token" ??<br>
> ><br>
> ><br>
> > Note: This Private/Public key would/should be<br>
> EXCLUSIVE for<br>
> > "device registration". And really ONLY.. :-)<br>
> ><br>
> > So that this "Private/Public key" pair can NOT<br>
> be used<br>
> > (==invalid) for sending messages to the<br>
> installations, or<br>
> > creating the Push-Applications / Mobile Variant<br>
> Constructs.<br>
> ><br>
> ><br>
> ><br>
> > Greetings,<br>
> > Matthias<br>
> ><br>
> > --<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><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > --<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><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > --<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><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > --<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><br>
> ><br>
> > _______________________________________________<br>
> > aerogear-dev mailing list<br>
> > <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
</div></div>> <mailto:<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>><br>
<div class="im">> > <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
</div>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a> <mailto:<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>><br>
<div class="HOEnZb"><div class="h5">> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
><br>
><br>
><br>
><br>
> --<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><br>
><br>
><br>
><br>
><br>
> --<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><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><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><br>
</div></div></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>