https

[davidearl]

Why the inconsistency with https? As you have a certificate for signing in, why not apply it everywhere. As it stands this seems misleading to the user and has the potential for many security problems.

[mvl22]

Yes, I agree this would be fine now. I've been moving some other sites of mine to full HTTPS throughout without any problems.

[gravitystorm]

The original problem (and the current one still) is whether all external resources - notably map tile layers - are also available via https, otherwise you get mixed content warnings. The situation was much different back when this was first built! All of my layers, for example, are now available via https and we can check the status of the others.

[mvl22]

The CycleStreets tileserver (which is caching/proxying tiles from OCM and others) now runs under https and http as of a few months ago.

[mvl22]

Agree; let's go full HTTPS now.

Google is now favouring HTTPS in its ranking criteria:
http://googlewebmastercentral.blogspot.co.uk/2014/08/https-as-ranking-signal.html

New SSL cert about to go in anyway.

[davidearl]

Good. Do add a HSTS header too.

BTW, if you don't already know about letsencrypt.org, then you definitely should! It's currently intended to go live on Nov 16, but it's been delayed a few times already.

[mvl22]

letsencrypt.org

Yep; will be a real gamechanger for SSL deployments. Hadn't realised they were so near to launch now.

Note: it seems that wildcard certs are not initially going to be supported, so at present this is not an option for us anyway:

https://community.letsencrypt.org/t/please-support-wildcard-certificates/258/69

[mvl22]

Do add a HSTS header too.

Now noted as a separate issue, on the deployment side:

cyclestreets/cyclescape-chef#34

As noted there, I think this needs to be added cautiously; my experience so far is that you absolutely have to get it right first time, as you can't back out - a browser (as designed) caches the instruction for the given time.

[davidearl]

As I thought, letsencrypt has pushed back again a little. They are now saying "public beta" available from 3 December (not full release on Nov 16). https://letsencrypt.org/2015/11/12/public-beta-timing.html

[mvl22]

@nikolai-b Are we in a position now to have https:// enabled throughout with http:// -> https:// redirection to force it?

Would rather avoid full HSTS until the above is shown to be unproblematic.

[nikolai-b]

Which above problem? Do you mean this #420 (comment) ? If so then that is fixed on the #621

[mvl22]

Which above problem?

Sorry, I was really unclear!

I was just referring to the previous paragraph in that same posting, i.e. that HSTS should only be considered once the http:// -> https:// redirection has been in place for a month or so and is shown to be working fine.

[nikolai-b]

Ah, yes, fully agree, get the https working for a month seems very sensible.

[nikolai-b]

I've switched on SSL by default. If we are happy in a few weeks we can add https://github.com/josh/rack-ssl gem to rails which adds a HSTS header.

[mvl22]

Am getting a redirect loop on Safari on iOS at least.

[mvl22]

Confirmed this is the case on all browsers. Rollback urgently needed please.

[smsm1]

I can confirm the redirect loop here too.

[nikolai-b]

Very sorry about that. I checked but maybe the deploy hadn't finished or I was logged in. Apologies again.

I've fixed this an redeployed so we should be on https.

[mvl22]

Looks good now - when signed in I get HTTPS on all pages. Thanks, Nikolai.

This should be extended to all traffic when a stable implementation can be confirmed.

[nikolai-b]

Regarding

should be extended to all traffic

it is turned on for all users but probably only kicks in when they try to log in.

In a few days if we get no issues I can force SSL from rails (not setting the HSTS header so revertible) and if that is ok for a month then we can set HSTS, secure cookies and close this.

[mvl22]

not setting the HSTS header so revertible

In general I really don't like HSTS for exactly the kind of problem we had today - if something is wrong, it is basically impossible to revert unless the timeout is set low. I think this is a very high bar.

[nikolai-b]

Are you suggesting we close this then or just that we wait?

[mvl22]

Are you suggesting we close this then or just that we wait?

I'm suggesting that all requests for HTTP should be redirected to HTTPS, i.e. /whatever on http to /whatever on https. This could either be a deployment consideration (i.e. put in Apache) or an application-level thing (as long as it doesn't result in a burden for developers having to get a cert to start doing anything).

Currently the site works in HTTPS but this is not forced. I hope this is simple to get in place now.

I'm also saying that we should not put in HSTS - but that is a separate matter.

Once HTTPS is what users always get, you can close this call, and we can revisit HSTS if there's really a need at a later time.