[Thali-talk] How should we solve this particular problem? HTTP vs HTTPS

[Yaron Goland]

I think that makes a ton of sense. It’s not idea since it means that the same router will be handing our secure and insecure information but obviously we can use the ACL layer to enforce who can get to what. I think this is probably the lowest risk approach at the moment. It’s just a bummer that this means there will be no endpoint exposed by a Thali node that can be reached over normal HTTP, not even when connected to WiFi. But we can solve that later.

From: Ville Rantala
Sent: Thursday, January 28, 2016 9:50 AM
To: Yaron Goland <yarong at microsoft.com>
Cc: thali-talk at thaliproject.org; Shawn Cicoria <Shawn.Cicoria at microsoft.com>; Toby Bradshaw <Toby.Bradshaw at skype.net>; Tomi Paananen <tomi.paananen at microsoft.com>
Subject: Re: [Thali-talk] How should we solve this particular problem? HTTP vs HTTPS

I was wondering would it be possible to exchange discovery beacons also over TLS?

In that approach, Thali apps could ship with a globally known PSK just to simplify the implementation (and not as a security feature at all since a globally known PSK is not a secret). The rest of the communication (that actually needs to be secret) would be using "real secrets”.

Ville

From: Thali-talk <thali-talk-bounces at thaliproject.org<mailto:thali-talk-bounces at thaliproject.org>> on behalf of Yaron Goland <yarong at microsoft.com<mailto:yarong at microsoft.com>>
Date: Thursday 28 January 2016 at 00:12
To: "thali-talk at thaliproject.org<mailto:thali-talk at thaliproject.org>" <thali-talk at thaliproject.org<mailto:thali-talk at thaliproject.org>>, Tomi Paananen <tomi.paananen at microsoft.com<mailto:tomi.paananen at microsoft.com>>, Toby Bradshaw <Toby.Bradshaw at skype.net<mailto:Toby.Bradshaw at skype.net>>, Shawn Cicoria <shawn.cicoria at microsoft.com<mailto:shawn.cicoria at microsoft.com>>
Subject: [Thali-talk] How should we solve this particular problem? HTTP vs HTTPS

[Note: This is going to the public mailing list, we really need to get better about discussing public topics, well, publicly.]

In our current set up when we exchange discovery beacons over Android or iOS we do so via a HTTP server we host on the device. Eventually this will change on Android once the Android GATT server becomes stable but that a’int today.

Similarly, with Wi-Fi we also use a HTTP server to exchange the beacons.

The issue is that beacons should go out unencrypted over normal HTTP while everything else should be using our TLS solution (with pre-shared keys) over HTTPS.

But right now with Android/iOS all requests from the native layer go to a single mux port. And in the case of Wi-Fi we only advertise a single port over SSDP.

So how do we make sure that requests go to the right place? There are a couple of potential solutions and I wanted to get feedback on them.

Mux – We would start a HTTP server and a HTTPS server on a localhost port. We would then pass these two ports into thaliMobileNativeWrapper. When a request comes in over the multiplex connection from the native layer we would check the stream ID at the multiplex layer and based on the ID (which we can create) we would have a known prefix to identify if the connection should be forwarded to the HTTP server or the HTTPS server.
               Similarly, when we call connect on thaliMobileNativeWrapper the response callback would have two mux listeners, one for HTTP and the other for HTTPS requests running on localhost. Both of those listeners would mux to the same multiplex object over the same TCP/IP connection but when we create each stream we would use an ID that indicates if the stream is intended for HTTP or HTTPS.
               In the case of WiFi we would have to advertise two network accessible ports, one for HTTP and one for HTTPS. That shouldn’t be a big deal.

Httpolyglot – This is an open source package that can handle hosting both TLS and normal HTTP connections on the same port. We would have to put in protection to make sure that HTTP requests only go to HTTP approved Express paths. So this would mean having a white list of HTTP safe routes.

Proxy – We could set up a HTTP server and a HTTPS server on a localhost port like in the Mux solution. The difference being that we could write a simple proxy (Httpolyglot shows how) to detect a HTTP vs HTTPS connection and then have the proxy forward the connection either to the HTTP or HTTPS server as appropriate. This would make it look like we are hosting HTTP and HTTPS on a single port to external callers but let us have two totally separate servers on the device. Note that in the case of WiFi we would set up a separate instance of the proxy with the same forwarding behavior but with a publicly accessible IP address.

The mux solution seems like the cleanest and most efficient but I’m loath to do anything more at the mux layer. There are already way too many things happening there as it is. So my suspicion is that the lowest risk approach is the proxy approach. It’s low risk first because it doesn’t require messing with the mux layer. And it’s low risk because it lets us keep the HTTP and HTTPS router objects completely separate which I suspect will significantly reduce the chance of accidentally putting secret things in an insecure location.

Thoughts?

               Thanks,

                              Yaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist10.pair.net/pipermail/thali-talk/attachments/20160129/dbfc4594/attachment.html>