SAMP from HTTPS is (sometimes) working

Thu Jan 9 12:50:36 CET 2020

Hi All,

we would like to share with you our SAMP over HTTPS current implementation and latest tests.

Here at SSDC (ASI) we use the TOPCAT Experimental kindly provided by Mark Taylor, which includes an internal TLS HUB that connects to a relay server where a servlet (also by Mark Taylor) receives and dispatches SAMP messages with our https web pages and TOPCAT itself.
In our inital deployment we relied on the Java Web Start framework to run TOPCAT and manage/enable the https interactions between the TOPCAT JVM and the relay server (tomcat).
We recently noted that the JVM (with Java >= SE8) is able to manage the above https interactions without the Java Web Start framework, so we are changing our web pages accordingly.

We have also tested the browser extension provided by Sonia Zorba for Chrome and Firefox and we confirm that it works as expected.

We will continue to use our current solution, without JWS, eventually revising it when W3C recommendations on
mixed-content will be consistently implemented.

Daniele Navarra,

Francesco Verrecchia

and Cristina Leto

--

ASI, Space Science Data Center

Rome, Italy

www.ssdc.asi.it<http://www.ssdc.asi.it>

On 11/15/2019 05:36 PM, Mark Taylor wrote:

Post Script: the HTTPS server at
https://andromeda.star.bristol.ac.uk/sampjs/
that I invited people to try is currently not available
because of a firewall I didn't realise was there.
I'm trying to get this lifted, I will post back here with updates.

Sorry for the inconvenience,

Mark

On Tue, 12 Nov 2019, Mark Taylor wrote:

> Hi all,
>
> further developments on this long story.  This posting is rather
> technical, but it does represent progress.
>
> Felix Stoehr recently reported to me that Web SAMP over HTTPS actually
> works out of the box, with no browser extensions, for Google Chrome.
> I tested it out, and he's right: using Chromium v78 (on Ubuntu 18.04)
> SAMP connections from HTTPS-hosted web pages work perfectly.
> You can try it yourself using the working examples listed in the
> "Examples" section of https://andromeda.star.bristol.ac.uk/sampjs/.<https://andromeda.star.bristol.ac.uk/sampjs/>
>
> I was, to put it mildly, surprised by this: it means that the
> insurmountable problem I've been bleating about for the last few
> years (see http://andromeda.star.bristol.ac.uk/websamp/)
> just doesn't exist, at least for some browsers, moreover rather
> recent ones.  What's going on?
>
> It turns out that the relevant standards have changed since I last
> read them in detail.  XMLHttpRequest accesses to localhost http
> services (the hub) from an https context (a Web SAMP client)
> is blocked as Mixed Active Content according to the W3C Mixed Content
> document https://www.w3.org/TR/2015/CR-mixed-content-20151008/,
> and that's what I based my analysis of the problem on in my
> presentations in Sydney and Cape Town
> (http://wiki.ivoa.net/internal/IVOA/InteropOct2015Applications/samp-https.pdf,
>  http://wiki.ivoa.net/internal/IVOA/InterOpMay2016-GWS/tlsamp.pdf).
> However, a more recent version of the Mixed Content document
> (https://www.w3.org/TR/2016/CR-mixed-content-20160802/)
> has updated the definition of an "a priori authenticated URL" to
> include "Potentially Trustworthy" URLs.  This in turn via the
> W3C Secure Contexts document (https://www.w3.org/TR/secure-contexts)
> means that any URL whose host is the loopback address
> (127.0.0.1 for IPv4 or ::1 for IPv6) does not count as mixed content.
> The latest unpublished draft of the Secure Contexts document
> (https://w3c.github.io/webappsec-secure-contexts/, 15 March 2019)
> extends this in some cases to use of the hostname "localhost" as well
> as the numeric loopback addresses.
>
> That means that under current W3C recommendations, HTTPS web pages
> should be able to contact the SAMP hub at http://127.0.0.1:21012/,
> and maybe http://localhost:21012/, and thereby use Web SAMP as normal,
> without having to jump through any other hoops.
>
> This is great news, since in principle it means we can forget all about
> the weird and ugly solutions I was talking about recently in Groningen,
> as well as browser extensions.  But it does rely on the browsers people
> are using actually implementing the current W3C recommendations.
> Do they?
>
> As reported above, it looks like Chromium/Chrome does do this,
> apparently since version 53 (2016); see e.g.
> e.g. https://chromium.googlesource.com/chromium/src.git/+/130ee686f
> At least in v79 it works for "localhost" as well as "127.0.0.1".
>
> My reading about Firefox suggests that it *ought* to work since
> version 55 (2017), but it doesn't work for me on version 59 or 70.
> The FF mixed content notes at
> https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content
> say this:
>
>    Note: Since Firefox 55, the loading of mixed content is allowed on
>    http://127.0.0.1/ (see bug 903966). Chrome allows mixed content on
>    http://127.0.0.1/ and http://localhost/.<http://localhost/> Safari does not allow any
>    mixed content.
>
> The discussion at https://bugzilla.mozilla.org/show_bug.cgi?id=903966
> suggests that maybe this works only for GET but not POST, which
> (via XMLHttpRequest) is what SAMP requires, but it's not very clear.
> Trying to use SAMP from HTTPS on firefox v70 tells me:
>
>    "Cross-Origin Request Blocked: The Same Origin Policy disallows
>    reading the remote resource at http://127.0.0.1:21012/.<http://127.0.0.1:21012/>
>    (Reason: CORS request did not succeed).
>    https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSDidNotSucceed
>
> I don't think the problem is to do with CORS though, since there doesn't
> appear to be any network activity associated with this error.
> If anybody can get to the bottom of this firefox issue I'd really like
> to hear.
>
> What now?
>
> Given the above, it looks like just sitting back and waiting might fix
> this problem.  If Chrome is implementing the Web-SAMP-over-HTTPS-enabling
> changes today, then other browsers may follow suit in future
> (Firefox is apparently part-way there).
> In the mean time, browser extensions like the one that Sonia has
> developed for those browsers that don't yet allow this are a good
> sticking plaster, but hopefully won't be a long-term maintenance burden.
>
> I don't think any changes to the SAMP standard are required
> (except possibly an erratum to recommend using the loopback address
> rather than "localhost" in the well-known Web Profile Hub URL at
> sec 5.2.3 and 5.3).
> Some minor changes to software could be useful though:
>
>   - samp.js should probably change to contact the hub at the
>     numeric loopback address rather than localhost.
>     See https://github.com/astrojs/sampjs/issues/7.
>
>   - The JSAMP hub with the minor Origin-checking changes required
>     to get Sonia's extension working
>     (http://mail.ivoa.net/pipermail/apps-samp/2019-November/001018.html)
>     should be released and incorporated into future Hub-containing
>     applications (topcat, aladin, ...).  I'll make a new JSAMP release
>     some time soon.
>
>   - It would be nice to have some boilerplate that HTTPS-Web SAMP
>     pages can incorporate giving user instructions:
>     check current browser and advise on necessary action if any,
>     e.g. upgrade browser version or install browser extension.
>
> Plus, reports about whether other browsers (IE?) are able to do
> Web SAMP from HTTPS (e.g. does
> https://andromeda.star.bristol.ac.uk/sampjs/examples/sendlist.html
> successfully send a table to e.g. topcat?) would be very useful.
>
> Mark
>
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk<http://mail.ivoa.net/mailman/listinfo/apps-samp> +44-117-9288776  http://www.star.bris.ac.uk/~mbt/<http://www.star.bris.ac.uk/%7Embt/>
>

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk<http://mail.ivoa.net/mailman/listinfo/apps-samp> +44-117-9288776  http://www.star.bris.ac.uk/~mbt/<http://www.star.bris.ac.uk/%7Embt/>

________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps-samp/attachments/20200109/e7ef69f0/attachment-0001.html>