Web Profile and security

[Mark Taylor]

On Wed, 15 Dec 2010, Tom McGlynn wrote:

> Hi Mark,
> 
> I'm a bit confused as to whether HTTPS really does what we want. Since I don't
> know enough to frame this question succinctly let me set things up to clarify
> what bothers me.
> 
> Let's suppose we have a situation where we have two SAMP enabled applications
> that are talking to each other using the WebSAMP hub.
> At least one of these applications is a Web application (we're only going to
> talk about that one and the hub in fact).
> 
> If we add the browser there are four 'applications' that are collaborating
> here.
> 
> For simplicity, I assume that the user explicitly starts the hub (though it
> would be nice if a Web application could autostart the hub the way Aladin or
> TOPCAT do.  Perhaps this would be possible with a browser plugin).
> 
> Next the user uses FireFox to open a SAMP-enabled database query page.  This
> automatically looks for a hub to connect to at the standard port.  It's here
> that I gather we need to think about http or https?
> 
> If it's just an HTTP request I think I follow what can happen.  The page sends
> information to the hub and then can poll for updates and make additional posts
> to send messages.  All is good.
> 
> So let's suppose we are thinking of doing this as an HTTPS connection.
> Normally in an HTTPS connection, the browser is attempting to connect to a
> certified service.  The browser/client looks at the service's certificate and
> if satisfied proceeds with the connection.
> 
> However if I'm understanding what Ray is suggesting, we're really inverting
> this process.  The Web application is nominally the client in the process
> where it connects to the hub, e.g., it's a JavaScript processing that's using
> XMLHttpRequest invocations of something like:
>    https://localhost:99999/
> to start communications with the hub.  So in this case it's the client that we
> want to certify not the hub (which the user started and presumably trusts).

Yes, this is what I understand too.  The purpose of the https connection
in this scenario would be so that the https server (the hub) can 
authenticate the https client (the web app requesting SAMP registration).

>From what I gather, such client authentication is part of
TLS/https, but it's optional, and not usually done in practice
(because the trust concerns usually operate in the opposite direction).

However, thinking about it more, I don't know if this is going to be
possible, at least from JavaScript.  Although JavaScript clients can
at least in principle make https requests (XMLHttpRequest Level 2 says 
that https is one of the options), I don't know any way that a 
JavaScript client can explicitly associate a certificate with an
outgoing request.  If the hosting web page is itself served by https
then the appropriate certificate would be that associated with the
web page's origin.  However as I understand public key cryptography
(not very well) the JavaScript client, which is running in the
user's browser and not on the author's web server, will not have
access to the private key and so can't sign the messages which it
needs to send.  If that reasoning is correct (can somebody confirm/deny?)
then JavaScript clients can't perform the client authentication
part of https, in which case authenticated SAMP communications 
from JavaScript web clients sounds like a non-starter.

There is a slightly different approach which would make use of https
authentication.  In the case of Cross-Origin Resource Sharing, the
HTTP server (the Hub) is informed of the Origin of the web app
(aspiring SAMP client) - the Origin is basically the URL of the
root of the web server that provided the page.  If that origin uses 
the https protocol, the hub can in principle acquire authentication 
information about the origin of the page by establishing a new 
https connection with it; if it uses http, then the client was 
not signed.  I think this means that for CORS-based communications, 
authenticated identity can be determined, though how 
easy/hard that is from an implementation point of view I don't know.
However, in the case of the non-CORS sandbox-busting technologies 
I've talked about (crossdomain.xml, clientaccesspolicy.xml) the origin
information is not made available to the server in this way.  
That means that Silverlight- and Flash-based access (Flash-based 
access includes Flash-based JavaScript fallbacks for older browsers) 
cannot be so authenticated.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/