Web Profile and security

[Mark Taylor]

Paul,

On Mon, 20 Dec 2010, Paul Harrison wrote:

> I too have security worries about this proposal -
> ...

thanks for your contribution to this discussion.

> If we are really interested in getting reliable identity information
> to the hub then it could be done with a  signed java applet - as we know
> there is already a sandbox busting mechanism for applets that asks the
> user to allow the breakout and gives them a strong mechanism for verifying
> where the request came from (the certificate). So the protocol would go
> something like this;
> 
> 1. the applet makes first contact with the hub and passes a verifiable
> identifier - the verifiable identifier could be the web application's
> url  that is signed with the same certificate that was used to sign
> the applet in the first place (and is compiled into the applet) The hub
> then does not need to challenge the user if it can verify the signature,
> and it knows the origin of the request.
> 
> 2. the applet then writes the returned SAMP secret into the browser
> DOM so that it can be used by javascript - I am not sure how easy this
> is as it was really the fact that the DOM api of the java plugin was
> fairly sparse that lead people to want to use javascript - but I believe
> something basic could be done.
> 
> 3. General SAMP communications are then started up with a javascript client.
> 
> This would be reasonably easy to implement, as it would not involve
> having to install any local keys - though perhaps not a absolutely
> bullet-proof as it might be - the applet could be stolen by a malicious
> site for instance,so would need to be hardened to work only when served
> from its intended origin, and perhaps a way is needed for the hub to
> verify this for itself by contacting the origin web server as well   -
> the only downside  I can really see is that java is not available on
> some snazzy portable devices that people like nowadays..

That sequence sounds reasonably plausible, though I haven't worked
through the details on the nature of the verifiable identifier 
and the DOM cache.

However, one of the main drivers for designing the Web Profile was to 
remove the dependency on (signed) java applets, for reasons including 
their patchy support in browsers.  If the profile relies on a signed
applet to work, it doesn't solve any problems that aren't solved
already by WebSampConnector or some other implementation that uses
a signed applet to do Standard Profile SAMP communications.

> This message is "signed" with my e-science certificate, so you should trust that is me ;-)
> 
> Cheers,	
> 	Paul.

My mail client in response issued the following warnings:

    [Couldn't verify S/MIME signature: certificate verify error]

    [ This message was cryptographically signed but the signature ]
    [ could not be verified. ]

I haven't looked into the details of what went wrong there (most likely
to do with using a rather old mail client), but I feel this backs
up my intuition that although there is a lot of clever security
machinery out there, actual user practice means it's not currently
in a position to do much useful work.  That's not to say it couldn't
be pushed in that direction, but I think there's a fair bit of work
still to do.

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/