Re: [discovery] improving the acceptability of the NSD API

Le 8/10/13 07:40 , Rich Tibbett a écrit :
> On Tue, Oct 8, 2013 at 4:10 AM, Jean-Claude Dufourd
> <jean-claude.dufourd@telecom-paristech.fr
> <mailto:jean-claude.dufourd@telecom-paristech.fr>> wrote:
>
>     Dear all,
>
>     Re-reading the security issues brought to this list by Youenn,
>     I wonder if we should drastically tighten up the security of the NSD
>     API.
>     Can we not just _remove_ the fields url and config from the
>     NetworkService interface ?
>     This way, the discovering web app would have no direct route to the
>     discovered
>     services: it would have only a handle that is useless for
>     fingerprinting or hacking.
>     One additional field would be a blob for the service description, if
>     any.
>
>     Then, to allow communication between the discovering web app and the
>     discovered
>     service, the NSD implementation would offer an _indirect_
>     communication channel(s).
>
>
> This is an interesting idea and I explored it thoroughly before
> proposing the initial NSD API to this group.
>
> If we were inventing a new sharing protocol and starting from scratch
> this would probably be my preferred approach. However...
>
>     One possibility for the indirect communication channel could be
>     Ajax-like, another
>     could be WebSocket-like, another could be using UPnP messaging
>     (HTTP+SOAP...)
>
>
> ...this is a non-trivial problem: there is no abstraction (other than
> URLs) that is capable of conveniently incorporating all of these
> concepts well.
>
> The more you design this kind of abstract interface the more you realize
> you need the ability to e.g. set HTTP request headers (for e.g. UPnP)
> and read HTTP response headers (again for UPnP) and also allow
> flexibility in messaging channel types and format types for different
> types of services.

OK, I agree it is non-trivial to try to manage a proxy for Ajax or 
WebSocket while allowing it to communicate with UPnP devices...

> What this approach introduces is the need to define some black magic
> that converts abstracted API comms interfaces in to the HTTP messaging,
> WebSocket messaging or any other type of messaging that each device
> speaks. The implementation also needs to know what to do with each API
> interaction according to the network service the page is interacting
> with (does it need to be translated in the HTTP+SOAP, WebSockets,
> HTTP+ProtocolBuffers, HTTP+Custom XML, etc?).
>
> The more you explore this idea and design an abstract API you come to
> realize that URLs provide the most suitable abstraction point. URLs are
> the entry point for a lot of other communication-based APIs currently
> available in the web platform (XHR, WebSockets, SSE, etc). A lot of
> prior work has happened in designing network communication-based APIs
> and we should not have to discard that huge body of prior work here.

OK, you convinced me you tried to think of a similar solution for 
proxying raw communication through NSD.

However, I do not think you considered communication by native UPnP 
messaging. UPnP messaging is restricted to a declared set of actions, 
with declared arguments (all described in the service description), as 
well as a declared set of events.

I have a one method API covering UPnP messaging. A method bindToService 
is given a serviceId and returns a proxy object which has as many 
properties as there are actions in the service, plus one subscribe and 
unsubscribe property for events.

If discovery of services does not involve disclosing URLs or IPs to the 
web app, and communication with the service is restricted to using this 
proxy object to call actions and receive events, is the security not 
much tighter than with the current situation ?

I am very conscious that this proposal only works with UPnP.
But if this makes NSD acceptable for implementation in browsers, then
let's do this as a first step.
We can spend more time later on a Bonjour-compatible solution.

>     What I mean is the API offered by NSD would replace, in the original
>     API, any URL or IP
>     with the handle, and if necessary remove any address from returned
>     information.
>     I have already implemented the last (UPnP-style messaging), have
>     created various
>     examples and never needed to provide to the web apps any direct link
>     to the services.
>
>     It would be quite a powerful argument against NSD detractors that
>     the url
>     or IP of the service is never shared with the web app,
>
>
> This would be a good thing and it is something we do need to explore
> further in the current NSD API spec also. That doesn't mean we need to
> throw out URLs altogether. We may want to use a custom URL scheme that
> abstracts away IP-based communication. That is of course very
> non-trivial but may be worth looking - achieving the same benefits of
> obfuscating IP addresses as you present here.

I am not really obfuscating the URLs, but rather sealing the URLs away 
from the web apps.

>
>      > and that all communication
>     passes through/can be checked by the NSD implementation.
>
>
> Sound like asking for the user agent to perform black magic to me. What
> exact checks did you have in mind here?

I was thinking some simple filtering, in the spirit of removing zips and 
exe from email attachments, or filtering scripts out of textfields (XSS 
attacks)... it could be naive of me to think it is realistic.

What I was clear about was that if communication was restricted to UPnP 
messaging valid wrt the service description, it would probably be quite 
hard to hack devices.

Best regards
JC
-- 
Télécom ParisTech <http://www.telecom-paristech.fr>  *Jean-Claude
DUFOURD <http://jcdufourd.wp.mines-telecom.fr>*
Directeur d'études
Tél. : +33 1 45 81 77 33  37-39 rue Dareau
75014 Paris, France

Site web <http://www.telecom-paristech.fr>Twitter
<https://twitter.com/TelecomPTech>Facebook
<https://www.facebook.com/TelecomParisTech>Google+
<https://plus.google.com/111525064771175271294>Blog
<http://jcdufourd.wp.mines-telecom.fr>

Received on Tuesday, 8 October 2013 16:24:26 UTC