[geomoose-psc] https for geomoose.org

[Jim Klassen]

On 05/25/2017 06:51 PM, Eli Adam wrote:
> Yes, good to use https, also if we use https, that is useful testing
> for people who want to run with https.
Good point.
>
> Let's Encrypt is good but we need to have our automated renewal
> working well.  Some sites seem to never figure that out and are always
> down because of it.
Yeah, I know.  I've moved most of the other sites I manage to Let's
Encrypt and it can be a hassle.  In particular, I've been bit by
auto-renew failing and then using up the request quota and thus not
being able to renew.  Generally I get emails when renewals are near if
they haven't auto-renewed.
>>> The FOSS4G image hosted at mapserver.org has no https equivalent that I
>>> have found.  We could self host as an easy work around.
> Seems that this should be hosted on http://2017.foss4g.org/ but that
> isn't https either.
We should probably should just self host.
>
>>> The Google maps API in 2.x is pulled in using
>>> http://maps.googleapis.com  and not https://maps.googleapis.com (or
>>> //maps.googleapis.com).
>>>
>>> OpenStreetMap is pulled in from XYZ using http (defined in the mapbook)
>>>
>>> ArcGIS 9.3 Rest Example is pulled in using http.
>>>
>>> Weather Radar is pulled in using http.
>>>
>>> These will require a patches to all the active 2.x series branches so
>>> they are picked up in the demo.
>>>
>>> There is probably more, but this is what I found in a quick test.  I
>>> haven't checked if the remote sites are available over https or not.  If
>>> they are not, are the mixed-content warnings acceptable?
> If we are demonstrating an https instance, that doesn't really do it.
The options as I see them are:
  * We don't do https and live with browser restrictions on things like
the Geolocation API [1][2].
  * We setup proxies to the external sites (with all the security
issues, probable TOS issues, and making the demo harder to setup for others)
  * We live with mixed-content warnings for the layers with no https
equivalent source.


They are all not ideal and I think the latter might be the least intrusive.
> https is sometimes slower which could make the demo look slow but it
> still seems plenty fast to me testing (although with many images http
> that isn't really testing anything).
I haven't really tested the difference, but with Keep-Alives enabled the
TLS overhead doesn't seem to be very noticeable and most of the recent
articles on the topic say that TLS overhead is a non-issue on modern
hardware.

[1]
https://developers.google.com/web/updates/2016/04/geolocation-on-secure-contexts-only

[2] https://w3c.github.io/webappsec-secure-contexts/