New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTPS by default on openstreetmap.org #117

Open
grischard opened this Issue Nov 5, 2016 · 59 comments

Comments

Projects
None yet
@grischard

grischard commented Nov 5, 2016

This ticket is intended to be a central place to discuss the possibility of switching openstreetmap.org to be https by default.

This is a subject many people feel passionate about, one way or the other, and not a switch that can simply be flicked on and off. Everyone's concerns, issues on the way, hopes, desires, possible solutions, etc. should be discussed or linked here.

Wikipedia did the switch in 2015, The Guardian in 2016.

This isn't about making all content available over https - that's AFAIK already the case, and users of the HTTPS Everywhere will always use HTTPS when loading the website.

The questions that we should address are:

What advantages would a switch to HTTPS by default bring?

A few so far:

What issues would a switch to HTTPS by default cause?

  • People on bad connections might have trouble loading the site.

    • @systemed is concerned that HTTPS connections are less reliable over bad mobile links.
    • Can anyone show cases where openstreetmap.org is reproducibly slower or less reliable over https?
    • Is this something that can be mitigated or improved on the OWG side, for example by enabling http/2 everywhere?
    • I couldn't reproduce the issue by loading https://www.httpvshttps.com on a simulated lossy Edge network. (5% packet loss). The tile servers upgrade to http/2 on modern browsers anyway. Unless anyone can show that this effect exists, it sounds a lot like superstition.
  • People using OSM where HTTPS is blocked couldn't navigate the site.

    • petschge (who's on IRC but not on github) was at a private university in Germany in 2015 where a faulty proxy made https browsing impossible. Unfortunately, he's not in contact with them anymore, and can't confirm that the problem still exists. Similarly, @Zverik was in a classroom where HTTPS was blocked in the past. A lot has happened since then: many major sites, e.g. wikipedia and github, now use HSTS, and Wikipedia's 2015 switch might have forced educational institutions to fix this.
    • Does anyone know of users who can't access openstreetmap.org over https at all?
    • A possible way of measuring this would be by including two identical tracker pixels on openstreetmap.org, one served over http and the other over https, and compare the hit counts after a week.
    • Logging in requires https in any case.
  • Legacy browsers would be locked out.

  • Content that the iD editor embeds from other sites must be served over https. But that's already the case, since not doing so breaks the embed for users who are already editing over https.

Should we redirect any traffic to HTTPS, or only strongly encourage it?

Forcing and strongly encouraging are different things.

Sending HSTS headers, converting all links to https://, or both, would move most traffic to HTTPS while still replying to legacy HTTP requests. Sending 301 redirects would make sure every client is using https, but make it impossible to use http.

What issues would HSTS cause?

HSTS breaks any site that accesses the OAuth API with http URLs.
@mojodna has offered to patch our OAuth library to mitigate the issue.

HSTS could also be selectively enabled, for example only for the http/2 enabled tile servers, which could make the loading of maps faster. Note that clients that are http/2 capable automatically upgrade to https when they connect to a http/2 capable server.

What would technically need to be done to make the switch?

Many pieces of our infrastructure would probably need to be changed or configured differently. How much work would this be for the OWG? Andy is saying it's doable.

Considering the pluses and minuses, is it worth it?

Many of us, myself included, have (strong) opinions on this. I would like us to reach a decision based on measurable facts, and hypothetically review that decision if those facts change over time.

This list of questions is not meant to be exhaustive. I'll try to update the ticket to maintain visibility as comments come in.

@grischard

This comment has been minimized.

Show comment
Hide comment
@grischard

grischard Nov 5, 2016

CC @tyll @gravitystorm @bhousel @rorym @tomhughes @genodeftest because you've all shown interest in this before.

grischard commented Nov 5, 2016

CC @tyll @gravitystorm @bhousel @rorym @tomhughes @genodeftest because you've all shown interest in this before.

@tomhughes

This comment has been minimized.

Show comment
Hide comment
@tomhughes

tomhughes Nov 5, 2016

Member

Ignore IE6 and Java 6 as they are already unsupported - you can't login using them to start with as that already requires https.

Member

tomhughes commented Nov 5, 2016

Ignore IE6 and Java 6 as they are already unsupported - you can't login using them to start with as that already requires https.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Nov 5, 2016

Collaborator

Easing the load on the servers if we can serve all content over HTTP/2?

Probably not significant. Tiles are over HTTP/2 when possible, and that's where the many is particularly useful.

What issues would HSTS cause

I consider HSTS an implementation detail to the question of requiring all osm.org traffic to use HTTPS. How to implement is best discussed after the policy decision is made.


A couple of years ago I'd have disagreed, but HTTP/2 and overall HTTPS support have reduced the costs to requiring HTTPS, and Chrome has made a big change:

image

This means the "Show my Location" button doesn't work in Chrome over HTTP. To be clear, I think what Chrome is doing with blocking the location API is wrong, not addressing a real thread, and doesn't follow their own proposal because it's not a new feature. But we're stuck with it. The fix for this is to redirect any page on openstreetmap.org that shows a map to HTTPS. This is most pages.

I think the advantage of getting geolocation working in Chrome outweighs any current disadvantages of requiring HTTPS.

Collaborator

pnorman commented Nov 5, 2016

Easing the load on the servers if we can serve all content over HTTP/2?

Probably not significant. Tiles are over HTTP/2 when possible, and that's where the many is particularly useful.

What issues would HSTS cause

I consider HSTS an implementation detail to the question of requiring all osm.org traffic to use HTTPS. How to implement is best discussed after the policy decision is made.


A couple of years ago I'd have disagreed, but HTTP/2 and overall HTTPS support have reduced the costs to requiring HTTPS, and Chrome has made a big change:

image

This means the "Show my Location" button doesn't work in Chrome over HTTP. To be clear, I think what Chrome is doing with blocking the location API is wrong, not addressing a real thread, and doesn't follow their own proposal because it's not a new feature. But we're stuck with it. The fix for this is to redirect any page on openstreetmap.org that shows a map to HTTPS. This is most pages.

I think the advantage of getting geolocation working in Chrome outweighs any current disadvantages of requiring HTTPS.

@gravitystorm

This comment has been minimized.

Show comment
Hide comment
@gravitystorm

gravitystorm Nov 6, 2016

Collaborator

This means the "Show my Location" button doesn't work in Chrome over HTTP

This is also the case for Safari on iOS, and is a bit annoying and I doubt many people can figure it out.

Given that you can't log into the site without HTTPS, any use-case that involves mis-configured proxies etc aren't a high priority. However, I'm interested to hear more about slow connections and how it impacts, and to see if this is still a problem.

How much work would this be for the OWG?

It's not trivial, but I don't think it's excessively large. If we decide to make the policy for https-everywhere, then we can work through whatever needs doing at a steady rate.

Collaborator

gravitystorm commented Nov 6, 2016

This means the "Show my Location" button doesn't work in Chrome over HTTP

This is also the case for Safari on iOS, and is a bit annoying and I doubt many people can figure it out.

Given that you can't log into the site without HTTPS, any use-case that involves mis-configured proxies etc aren't a high priority. However, I'm interested to hear more about slow connections and how it impacts, and to see if this is still a problem.

How much work would this be for the OWG?

It's not trivial, but I don't think it's excessively large. If we decide to make the policy for https-everywhere, then we can work through whatever needs doing at a steady rate.

@grischard

This comment has been minimized.

Show comment
Hide comment
@grischard

grischard Nov 6, 2016

Ignore IE6 and Java 6 as they are already unsupported - you can't login using them to start with as that already requires https.

You're right, no one edits with them anymore, but are they also insignificant for the tile server user agent statistics?

@simonpoole also expressed concern about Android users on version 2.2 or less. I don't know if you can get that from the user agents.

grischard commented Nov 6, 2016

Ignore IE6 and Java 6 as they are already unsupported - you can't login using them to start with as that already requires https.

You're right, no one edits with them anymore, but are they also insignificant for the tile server user agent statistics?

@simonpoole also expressed concern about Android users on version 2.2 or less. I don't know if you can get that from the user agents.

@systemed

This comment has been minimized.

Show comment
Hide comment
@systemed

systemed Nov 6, 2016

@systemed is concerned that HTTPS connections are less reliable over bad links

I'll opt out of this discussion, I'm afraid. I have consistently been in areas of poor mobile coverage where https:// sites wouldn't load but http:// would (in particular, the boatyard in Burton-on-Trent where I moored for several years).

However, the arguments used for https are sufficiently emotive that I have no great interest in wasting hours on this that could be more productively spent elsewhere. As long as there are other mapping sites still available over http:// which I can use in areas of poor reception, I no longer have the energy to argue as to what OSM might do. But thank you for the mention.

systemed commented Nov 6, 2016

@systemed is concerned that HTTPS connections are less reliable over bad links

I'll opt out of this discussion, I'm afraid. I have consistently been in areas of poor mobile coverage where https:// sites wouldn't load but http:// would (in particular, the boatyard in Burton-on-Trent where I moored for several years).

However, the arguments used for https are sufficiently emotive that I have no great interest in wasting hours on this that could be more productively spent elsewhere. As long as there are other mapping sites still available over http:// which I can use in areas of poor reception, I no longer have the energy to argue as to what OSM might do. But thank you for the mention.

@zerebubuth

This comment has been minimized.

Show comment
Hide comment
@zerebubuth

zerebubuth Nov 6, 2016

Collaborator

You're right, no one edits with them anymore, but are they also insignificant for the tile server user agent statistics?

IE6 (or user-agents claiming to be it) accounted for 0.16% of tile hits yesterday.

@simonpoole also expressed concern about Android users on version 2.2 or less. I don't know if you can get that from the user agents.

As far as I can tell Android <= 2.2 accounts for about 0.01% of site visitors and 0.005% of tile views according to user-agent headers yesterday. It is likely that there are apps running on Android versions <= 2.2 which wouldn't show up in this analysis, as they don't report the OS version, but I'd be surprised if it were a large proportion.

On a different subject, the title of this ticket is "HTTPS by default", but much of the discussion has been around HSTS, "requiring all osm.org traffic to use HTTPS" or "converting all links to https://". To me, these are very different things. "By default" doesn't shut the door to people who make the choice to use HTTP, whereas HSTS or converting all links to https:// would.

As pointed out, it is already the situation that logging in or other secure actions require HTTPS. It is already the situation that anyone choosing to use HTTPS Everywhere uses the site in a fully secure manner.

The only real problem appears to be the fairly minor issue that "show my location" doesn't work for some recent browsers. Would it be possible to "un-break" Chrome and Safari by detecting the failure condition and reloading the page over HTTPS?

Collaborator

zerebubuth commented Nov 6, 2016

You're right, no one edits with them anymore, but are they also insignificant for the tile server user agent statistics?

IE6 (or user-agents claiming to be it) accounted for 0.16% of tile hits yesterday.

@simonpoole also expressed concern about Android users on version 2.2 or less. I don't know if you can get that from the user agents.

As far as I can tell Android <= 2.2 accounts for about 0.01% of site visitors and 0.005% of tile views according to user-agent headers yesterday. It is likely that there are apps running on Android versions <= 2.2 which wouldn't show up in this analysis, as they don't report the OS version, but I'd be surprised if it were a large proportion.

On a different subject, the title of this ticket is "HTTPS by default", but much of the discussion has been around HSTS, "requiring all osm.org traffic to use HTTPS" or "converting all links to https://". To me, these are very different things. "By default" doesn't shut the door to people who make the choice to use HTTP, whereas HSTS or converting all links to https:// would.

As pointed out, it is already the situation that logging in or other secure actions require HTTPS. It is already the situation that anyone choosing to use HTTPS Everywhere uses the site in a fully secure manner.

The only real problem appears to be the fairly minor issue that "show my location" doesn't work for some recent browsers. Would it be possible to "un-break" Chrome and Safari by detecting the failure condition and reloading the page over HTTPS?

@grischard

This comment has been minimized.

Show comment
Hide comment
@grischard

grischard Nov 7, 2016

You're right @zerebubuth, these are different things, and identifying the possible tools we have is essential to decide which ones to use.

FWIW, http://caniuse.com/#search=hsts says that switching on HSTS would affect 90% of the users.

grischard commented Nov 7, 2016

You're right @zerebubuth, these are different things, and identifying the possible tools we have is essential to decide which ones to use.

FWIW, http://caniuse.com/#search=hsts says that switching on HSTS would affect 90% of the users.

@grischard

This comment has been minimized.

Show comment
Hide comment
@grischard

grischard Nov 7, 2016

It would still be very interesting to know under what circumstances https://openstreetmap.org is broken while http:// isn't.

Something like https://github.com/jonocole/disable-hsts-chrome-extension could be useful to @systemed and other hypothetical affected users.

grischard commented Nov 7, 2016

It would still be very interesting to know under what circumstances https://openstreetmap.org is broken while http:// isn't.

Something like https://github.com/jonocole/disable-hsts-chrome-extension could be useful to @systemed and other hypothetical affected users.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Nov 7, 2016

Collaborator

On a different subject, the title of this ticket is "HTTPS by default", but much of the discussion has been around HSTS, "requiring all osm.org traffic to use HTTPS" or "converting all links to https://". To me, these are very different things. "By default" doesn't shut the door to people who make the choice to use HTTP, whereas HSTS or converting all links to https:// would.

Using HTTPS by default to me means that when someone types in openstreetmap.org they end up on the HTTPS site. The only ways to accomplish that I know of are direct all traffic requesting the front page to HTTPS. That could be by means of HSTS, 301 redirects, or similar. This will effectively make it impossible or very difficult to browse openstreetmap.org with HTTP.

The only real problem appears to be the fairly minor issue that "show my location" doesn't work for some recent browsers. Would it be possible to "un-break" Chrome and Safari by detecting the failure condition and reloading the page over HTTPS?

About 75% of browsers require HTTPS for geolocation, and I suspect we'd have to have them redirected to HTTPS on page load, or press the geolocate button twice.

Collaborator

pnorman commented Nov 7, 2016

On a different subject, the title of this ticket is "HTTPS by default", but much of the discussion has been around HSTS, "requiring all osm.org traffic to use HTTPS" or "converting all links to https://". To me, these are very different things. "By default" doesn't shut the door to people who make the choice to use HTTP, whereas HSTS or converting all links to https:// would.

Using HTTPS by default to me means that when someone types in openstreetmap.org they end up on the HTTPS site. The only ways to accomplish that I know of are direct all traffic requesting the front page to HTTPS. That could be by means of HSTS, 301 redirects, or similar. This will effectively make it impossible or very difficult to browse openstreetmap.org with HTTP.

The only real problem appears to be the fairly minor issue that "show my location" doesn't work for some recent browsers. Would it be possible to "un-break" Chrome and Safari by detecting the failure condition and reloading the page over HTTPS?

About 75% of browsers require HTTPS for geolocation, and I suspect we'd have to have them redirected to HTTPS on page load, or press the geolocate button twice.

@tyll

This comment has been minimized.

Show comment
Hide comment
@tyll

tyll Nov 7, 2016

tyll commented Nov 7, 2016

@zerebubuth

This comment has been minimized.

Show comment
Hide comment
@zerebubuth

zerebubuth Nov 7, 2016

Collaborator

About 75% of browsers require HTTPS for geolocation, and I suspect we'd have to have them redirected to HTTPS on page load, or press the geolocate button twice.

I was thinking that, if the failure can't be detected until the button is pushed, then we'd have to pop up some sort of div with a message saying "This feature is only available over HTTPS, please click this link to reload."

Alternatively, if it's possible to detect before the button is pressed, then the button could be greyed out with a tooltip explaining why it's greyed out, possibly also with a link to reload over HTTPS.

Using HTTPS by default ... will effectively make it impossible or very difficult to browse openstreetmap.org with HTTP.

I think so too. While it would technically be possible to copy each link by hand into the address bar and edit the scheme to "http"... that would be so much work that no one would do it.

In summary so far:

Pros:

  • No development needed to "un-break" Chrome & Safari.
  • People using OSM over HTTP over public WiFi are safer from cookie-stealing attacks. (Although we could mitigate this with the secure attribute on cookies)

Cons:

  • People on slow or mobile connections might find it difficult to load the site.
  • People using OSM over networks where HTTPS is interdicted would find it unusably difficult to navigate the site (although they would not have been able to log in anyway).
Collaborator

zerebubuth commented Nov 7, 2016

About 75% of browsers require HTTPS for geolocation, and I suspect we'd have to have them redirected to HTTPS on page load, or press the geolocate button twice.

I was thinking that, if the failure can't be detected until the button is pushed, then we'd have to pop up some sort of div with a message saying "This feature is only available over HTTPS, please click this link to reload."

Alternatively, if it's possible to detect before the button is pressed, then the button could be greyed out with a tooltip explaining why it's greyed out, possibly also with a link to reload over HTTPS.

Using HTTPS by default ... will effectively make it impossible or very difficult to browse openstreetmap.org with HTTP.

I think so too. While it would technically be possible to copy each link by hand into the address bar and edit the scheme to "http"... that would be so much work that no one would do it.

In summary so far:

Pros:

  • No development needed to "un-break" Chrome & Safari.
  • People using OSM over HTTP over public WiFi are safer from cookie-stealing attacks. (Although we could mitigate this with the secure attribute on cookies)

Cons:

  • People on slow or mobile connections might find it difficult to load the site.
  • People using OSM over networks where HTTPS is interdicted would find it unusably difficult to navigate the site (although they would not have been able to log in anyway).
@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Nov 7, 2016

Collaborator

we'd have to pop up some sort of div with a message

I'd rather redirect, I think it's a much better user experience. A div popup turns a one-click operation into a three-click operation.

In summary so far: ...

What about the API calls? These have different usage patterns and user-agents, and they get into OAuth signing. Or are we only looking at the HTML pages right now?

Collaborator

pnorman commented Nov 7, 2016

we'd have to pop up some sort of div with a message

I'd rather redirect, I think it's a much better user experience. A div popup turns a one-click operation into a three-click operation.

In summary so far: ...

What about the API calls? These have different usage patterns and user-agents, and they get into OAuth signing. Or are we only looking at the HTML pages right now?

@genodeftest

This comment has been minimized.

Show comment
Hide comment
@genodeftest

genodeftest Nov 7, 2016

The only real problem appears to be the fairly minor issue that "show my location" doesn't work for some recent browsers. Would it be possible to "un-break" Chrome and Safari by detecting the failure condition and reloading the page over HTTPS?

http://caniuse.com/#search=geolocation says:
HTTPS is required for Chrome, Safari, Opera, iOS Safari, Android Browser, Chrome for Android. Only major browsers without this requirement are IE, Edge and Firefox.

genodeftest commented Nov 7, 2016

The only real problem appears to be the fairly minor issue that "show my location" doesn't work for some recent browsers. Would it be possible to "un-break" Chrome and Safari by detecting the failure condition and reloading the page over HTTPS?

http://caniuse.com/#search=geolocation says:
HTTPS is required for Chrome, Safari, Opera, iOS Safari, Android Browser, Chrome for Android. Only major browsers without this requirement are IE, Edge and Firefox.

@grinapo

This comment has been minimized.

Show comment
Hide comment
@grinapo

grinapo Nov 7, 2016

Just a sidenote: a site got burned by lack of entropy in the entropy pool when using it up for all kinds of crypto at a changeover.
If one's using blocking random access (rejecting the use of "bad" quality randoms when there isn't enough entropy available) it simply blocks for extended periods of time. Non-blocking randoms with no entropy mean deteriorated security (without the blocking, obviously :-)).
Usually a non-issue for "normal" configs, but just in case keep an eye on the gauge.

grinapo commented Nov 7, 2016

Just a sidenote: a site got burned by lack of entropy in the entropy pool when using it up for all kinds of crypto at a changeover.
If one's using blocking random access (rejecting the use of "bad" quality randoms when there isn't enough entropy available) it simply blocks for extended periods of time. Non-blocking randoms with no entropy mean deteriorated security (without the blocking, obviously :-)).
Usually a non-issue for "normal" configs, but just in case keep an eye on the gauge.

@tyll

This comment has been minimized.

Show comment
Hide comment
@tyll

tyll Nov 7, 2016

tyll commented Nov 7, 2016

@Firefishy

This comment has been minimized.

Show comment
Hide comment
@Firefishy

Firefishy Nov 7, 2016

Collaborator

We enabled haveged across all services a few years ago to avoid entropy pool starvation.

Collaborator

Firefishy commented Nov 7, 2016

We enabled haveged across all services a few years ago to avoid entropy pool starvation.

@grischard

This comment has been minimized.

Show comment
Hide comment
@grischard

grischard Nov 8, 2016

Although we could mitigate this with the secure attribute on cookies

If all map pages aren't redirected to https, this would be confusing. "Why can't I edit? I've just logged in!"

grischard commented Nov 8, 2016

Although we could mitigate this with the secure attribute on cookies

If all map pages aren't redirected to https, this would be confusing. "Why can't I edit? I've just logged in!"

@zerebubuth

This comment has been minimized.

Show comment
Hide comment
@zerebubuth

zerebubuth Nov 8, 2016

Collaborator

If all map pages aren't redirected to https, this would be confusing. "Why can't I edit? I've just logged in!"

Logging in switches the scheme to HTTPS, so this wouldn't be a natural navigation flow for the user. Clicking the edit button could also redirect to HTTPS, as one needs to be logged in for that anyway.

Collaborator

zerebubuth commented Nov 8, 2016

If all map pages aren't redirected to https, this would be confusing. "Why can't I edit? I've just logged in!"

Logging in switches the scheme to HTTPS, so this wouldn't be a natural navigation flow for the user. Clicking the edit button could also redirect to HTTPS, as one needs to be logged in for that anyway.

@grischard

This comment has been minimized.

Show comment
Hide comment
@grischard

grischard Nov 8, 2016

HSTS does not mean that it is impossible to use the site with HTTP. It
only means that once someone accessed the site via HTTPS they will
continue to use HTTPS for a certain amount of time.

Section 7.2. of the HSTS RFC says: "An HSTS Host MUST NOT include the STS
header field in HTTP responses conveyed over non-secure transport."

A while ago, I asked Jeff Hodges, one of the RFC's author, why that was. If you provide both HTTP and HTTPS for compatibility reasons, HSTS on HTTP responses would seem to be a neat way of encouraging HTTPS without forcing it.

Jeff replied:

The rationale for not including the STS header field in unsecured HTTP responses is that it (the sts header field) is a security directive and http clients must not heed such directives obtained over unsecured channels. So it is best if webapps do not issue the STS header over unsecured channels. We made it a "MUST NOT" to try to get folks' attention. it is much more critical for the clients to get this right, as stipulated in section 8.1.

grischard commented Nov 8, 2016

HSTS does not mean that it is impossible to use the site with HTTP. It
only means that once someone accessed the site via HTTPS they will
continue to use HTTPS for a certain amount of time.

Section 7.2. of the HSTS RFC says: "An HSTS Host MUST NOT include the STS
header field in HTTP responses conveyed over non-secure transport."

A while ago, I asked Jeff Hodges, one of the RFC's author, why that was. If you provide both HTTP and HTTPS for compatibility reasons, HSTS on HTTP responses would seem to be a neat way of encouraging HTTPS without forcing it.

Jeff replied:

The rationale for not including the STS header field in unsecured HTTP responses is that it (the sts header field) is a security directive and http clients must not heed such directives obtained over unsecured channels. So it is best if webapps do not issue the STS header over unsecured channels. We made it a "MUST NOT" to try to get folks' attention. it is much more critical for the clients to get this right, as stipulated in section 8.1.

@grischard

This comment has been minimized.

Show comment
Hide comment
@grischard

grischard Nov 8, 2016

Hitting the 'Edit' button to load the map in JOSM from an https page can apparently sometimes fail to work. (Can anyone reproduce this?)

I remember running into that and fixing it, although I don't remember how. Osmose had the same problem and uses a redirect hack.

grischard commented Nov 8, 2016

Hitting the 'Edit' button to load the map in JOSM from an https page can apparently sometimes fail to work. (Can anyone reproduce this?)

I remember running into that and fixing it, although I don't remember how. Osmose had the same problem and uses a redirect hack.

@SomeoneElseOSM

This comment has been minimized.

Show comment
Hide comment
@SomeoneElseOSM

SomeoneElseOSM Nov 8, 2016

JOSM HTTPS remote control support depends on Java trusting a self-signed certificate for "localhost" doesn't it? Presumably there are going to be a bunch of people out there who don't have write access to the Java keystore (or who just are going to be put off by the scary message that you get when enabling remote control HTTPS support).

Obviously JOSM remote control isn't the only way to get to start editing in an area (FWIW I tend to start via "download object" or locating somewhere on the imagery).

SomeoneElseOSM commented Nov 8, 2016

JOSM HTTPS remote control support depends on Java trusting a self-signed certificate for "localhost" doesn't it? Presumably there are going to be a bunch of people out there who don't have write access to the Java keystore (or who just are going to be put off by the scary message that you get when enabling remote control HTTPS support).

Obviously JOSM remote control isn't the only way to get to start editing in an area (FWIW I tend to start via "download object" or locating somewhere on the imagery).

@tyll

This comment has been minimized.

Show comment
Hide comment
@tyll

tyll Nov 8, 2016

tyll commented Nov 8, 2016

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Nov 8, 2016

Collaborator

There is a different technique to notify that HTTPS is preferred: ...

I think the techniques should wait until after the policy discussion.

Collaborator

pnorman commented Nov 8, 2016

There is a different technique to notify that HTTPS is preferred: ...

I think the techniques should wait until after the policy discussion.

@Komzpa

This comment has been minimized.

Show comment
Hide comment
@Komzpa

Komzpa Nov 8, 2016

HTTP 2.0 for tiles can move them away from [abcd].tile.osm.org scheme, keeping less connections, allowing browser to request all the tiles at once and get them in single round-trip. From my experience with Wargaming GlobalMap, this is especially good thing for slow / laggy connections. This requires HTTPS.

Ensuring HTTPS via HSTS for tiles will likely make sure browsers will send Referer header to the server (they skip it when loading http image into https page), which allows more precise traffic source tracking.

Komzpa commented Nov 8, 2016

HTTP 2.0 for tiles can move them away from [abcd].tile.osm.org scheme, keeping less connections, allowing browser to request all the tiles at once and get them in single round-trip. From my experience with Wargaming GlobalMap, this is especially good thing for slow / laggy connections. This requires HTTPS.

Ensuring HTTPS via HSTS for tiles will likely make sure browsers will send Referer header to the server (they skip it when loading http image into https page), which allows more precise traffic source tracking.

@Klumbumbus

This comment has been minimized.

Show comment
Hide comment
@Klumbumbus

Klumbumbus Nov 9, 2016

Hitting the 'Edit' button to load the map in JOSM from an https page can apparently sometimes fail to work. (Can anyone reproduce this?)

In Firefox remote control to JOSM via https is not working at all. Only http works. More info at

Klumbumbus commented Nov 9, 2016

Hitting the 'Edit' button to load the map in JOSM from an https page can apparently sometimes fail to work. (Can anyone reproduce this?)

In Firefox remote control to JOSM via https is not working at all. Only http works. More info at

@SomeoneElseOSM

This comment has been minimized.

Show comment
Hide comment
@SomeoneElseOSM

SomeoneElseOSM Nov 9, 2016

Not something that affects the main map site, but I was trying to translate https://lists.openstreetmap.org/pipermail/talk-es/2016-November/014568.html from Spanish to English for the OSM weekly news. Google Translate screws up the formatting somewhat, so I thought I'd try http://www.bing.com/translator - and that says "Translation of secure pages is not supported". This is a problem we have now rather than a theoretical future one as OSM's pipermail site redirects from http to https already.

SomeoneElseOSM commented Nov 9, 2016

Not something that affects the main map site, but I was trying to translate https://lists.openstreetmap.org/pipermail/talk-es/2016-November/014568.html from Spanish to English for the OSM weekly news. Google Translate screws up the formatting somewhat, so I thought I'd try http://www.bing.com/translator - and that says "Translation of secure pages is not supported". This is a problem we have now rather than a theoretical future one as OSM's pipermail site redirects from http to https already.

@scaidermern

This comment has been minimized.

Show comment
Hide comment
@scaidermern

scaidermern Nov 12, 2016

In Firefox remote control to JOSM via https is not working at all. Only http works.

Works fine here. I always use HTTPS with Firefox on openstreetmap.org (thanks to HTTPS Everywhere). To get JOSM's remote control to work via HTTPS you have to open https://127.0.0.1:8112 in your browser and permanently store an exception for this self-signed certificate. Afterwards the remote control should work.

scaidermern commented Nov 12, 2016

In Firefox remote control to JOSM via https is not working at all. Only http works.

Works fine here. I always use HTTPS with Firefox on openstreetmap.org (thanks to HTTPS Everywhere). To get JOSM's remote control to work via HTTPS you have to open https://127.0.0.1:8112 in your browser and permanently store an exception for this self-signed certificate. Afterwards the remote control should work.

@Klumbumbus

This comment has been minimized.

Show comment
Hide comment
@Klumbumbus

Klumbumbus Nov 12, 2016

OK, thanks. Works for me.

Klumbumbus commented Nov 12, 2016

OK, thanks. Works for me.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Oct 25, 2017

Collaborator

Blocking: hotosm/osm-tasking-manager2#988

I don't see that blocks the OSMF servers from forcing HTTPS.

Collaborator

pnorman commented Oct 25, 2017

Blocking: hotosm/osm-tasking-manager2#988

I don't see that blocks the OSMF servers from forcing HTTPS.

@Bisaloo

This comment has been minimized.

Show comment
Hide comment
@Bisaloo

Bisaloo Oct 26, 2017

Maybe blocking is a strong word but https on openstreetmap.org breaks stuff from hotosm (and similar sites) due to MCB.

Forcing https will make this problem worse. Unless task.hotosm.org and others get https support first.

See EFForg/https-everywhere#13211 (comment) for steps for reproduce this issue. It will probably be clearer.

Bisaloo commented Oct 26, 2017

Maybe blocking is a strong word but https on openstreetmap.org breaks stuff from hotosm (and similar sites) due to MCB.

Forcing https will make this problem worse. Unless task.hotosm.org and others get https support first.

See EFForg/https-everywhere#13211 (comment) for steps for reproduce this issue. It will probably be clearer.

@grischard

This comment has been minimized.

Show comment
Hide comment
@grischard

grischard Oct 26, 2017

So the issue in general is that content that the iD editor embeds from other sites will have to be served over https. Solving hotosm/osm-tasking-manager2#988 and sending https gpx links is the way to solve that.

Https usage on openstreetmap.org isn't uncommon, and showing the gpx boundary from hot is already broken for all those users. I'm actually surprised that tasks.hotosm.org isn't available over https at all.

I've added this issue to the list.

grischard commented Oct 26, 2017

So the issue in general is that content that the iD editor embeds from other sites will have to be served over https. Solving hotosm/osm-tasking-manager2#988 and sending https gpx links is the way to solve that.

Https usage on openstreetmap.org isn't uncommon, and showing the gpx boundary from hot is already broken for all those users. I'm actually surprised that tasks.hotosm.org isn't available over https at all.

I've added this issue to the list.

@SomeoneElseOSM

This comment has been minimized.

Show comment
Hide comment
@SomeoneElseOSM

SomeoneElseOSM Oct 26, 2017

@grischard Apologies if I'm missing something here, but how is the fact that tasks.hotosm.org doesn't support https at all relevant to whether it's a good idea to force users of openstreetmap.org to use https whether they want to or not?

SomeoneElseOSM commented Oct 26, 2017

@grischard Apologies if I'm missing something here, but how is the fact that tasks.hotosm.org doesn't support https at all relevant to whether it's a good idea to force users of openstreetmap.org to use https whether they want to or not?

@grischard

This comment has been minimized.

Show comment
Hide comment
@grischard

grischard Oct 26, 2017

@SomeoneElseOSM openstreetmap.org doesn't exist in a vacuum; it'd be relevant if forcing https broke a lot of things for the mappers, just like hsts breaking oauth is. The fact that it took almost one year for this to come up makes me think that it won't, and the issue can easily be mitigated on hot's side anyway, but I want to be thorough in looking at the possible issues.

grischard commented Oct 26, 2017

@SomeoneElseOSM openstreetmap.org doesn't exist in a vacuum; it'd be relevant if forcing https broke a lot of things for the mappers, just like hsts breaking oauth is. The fact that it took almost one year for this to come up makes me think that it won't, and the issue can easily be mitigated on hot's side anyway, but I want to be thorough in looking at the possible issues.

@rugk

This comment has been minimized.

Show comment
Hide comment
@rugk

rugk Oct 27, 2017

Maybe depreciate/announce that you are removing HTTP support and let sites some time to switch to HTTPS. Just note that OAUTH and any password/authentication over insecure channels (HTTP) is not secure. Everyone can sniff your password, so…
In any case the aim should at some point be HTTPS-only. Before that you may redirect to HTTPS e.g. only on the main site or on most sites (e.g. login page) with some exceptions.

rugk commented Oct 27, 2017

Maybe depreciate/announce that you are removing HTTP support and let sites some time to switch to HTTPS. Just note that OAUTH and any password/authentication over insecure channels (HTTP) is not secure. Everyone can sniff your password, so…
In any case the aim should at some point be HTTPS-only. Before that you may redirect to HTTPS e.g. only on the main site or on most sites (e.g. login page) with some exceptions.

@HolgerJeromin

This comment has been minimized.

Show comment
Hide comment
@HolgerJeromin

HolgerJeromin Oct 27, 2017

Just note that OAUTH and any password/authentication over insecure channels (HTTP) is not secure. Everyone can sniff your password, so…

With oauth no passwort is transmitted

HolgerJeromin commented Oct 27, 2017

Just note that OAUTH and any password/authentication over insecure channels (HTTP) is not secure. Everyone can sniff your password, so…

With oauth no passwort is transmitted

@rugk

This comment has been minimized.

Show comment
Hide comment
@rugk

rugk Oct 27, 2017

But session tokens, or some other identifier. Any MITM possibility is bad. And you still submit passwords over http, so we don't even need to argue about oauth.

rugk commented Oct 27, 2017

But session tokens, or some other identifier. Any MITM possibility is bad. And you still submit passwords over http, so we don't even need to argue about oauth.

@simonpoole

This comment has been minimized.

Show comment
Hide comment
@simonpoole

simonpoole Oct 27, 2017

@rugk please get your facts straight, if you are using OAuth as essentially all major editors do, you do NOT authorize (aka login once with login/password) over http, but over https.

simonpoole commented Oct 27, 2017

@rugk please get your facts straight, if you are using OAuth as essentially all major editors do, you do NOT authorize (aka login once with login/password) over http, but over https.

@bhousel

This comment has been minimized.

Show comment
Hide comment
@bhousel

bhousel Oct 27, 2017

Member

@simonpoole - @rugk is correct that OAuth secrets can be transmitted over http when embedding a browser editor like Potlatch or iD on the openstreetmap website, if the website was first loaded via http. There is no really secure way to do communication between the embedding site and the editor iframe.

Member

bhousel commented Oct 27, 2017

@simonpoole - @rugk is correct that OAuth secrets can be transmitted over http when embedding a browser editor like Potlatch or iD on the openstreetmap website, if the website was first loaded via http. There is no really secure way to do communication between the embedding site and the editor iframe.

@simonpoole

This comment has been minimized.

Show comment
Hide comment
@simonpoole

simonpoole Oct 27, 2017

@bhousel nobody was claiming anything else, the authorisation process however takes place over https and you don't send login/password over http for external apps, just as I wrote (iD is a very special case and not the norm).

simonpoole commented Oct 27, 2017

@bhousel nobody was claiming anything else, the authorisation process however takes place over https and you don't send login/password over http for external apps, just as I wrote (iD is a very special case and not the norm).

@don-vip

This comment has been minimized.

Show comment
Hide comment
@don-vip

don-vip Dec 16, 2017

Hello,
From https://josm.openstreetmap.de/ticket/10033#comment:38 I discover that all recent browsers now accept http://127.0.0.1:8111 from https (or will very soon).
So JOSM is no longer a reason to block https by default on osm.org. I even plan to remove https support on port 8112 as it does not work properly everywhere and appears to be useless now.

don-vip commented Dec 16, 2017

Hello,
From https://josm.openstreetmap.de/ticket/10033#comment:38 I discover that all recent browsers now accept http://127.0.0.1:8111 from https (or will very soon).
So JOSM is no longer a reason to block https by default on osm.org. I even plan to remove https support on port 8112 as it does not work properly everywhere and appears to be useless now.

@grischard

This comment has been minimized.

Show comment
Hide comment
@grischard

grischard Dec 31, 2017

What do you all think of already adding HSTS to the tile server?

AFAICT this wouldn't break anything, and modern browsers already upgrade to http2 with tls anyway. We would also hear back from hypothetical users for whom https is completely blocked.

grischard commented Dec 31, 2017

What do you all think of already adding HSTS to the tile server?

AFAICT this wouldn't break anything, and modern browsers already upgrade to http2 with tls anyway. We would also hear back from hypothetical users for whom https is completely blocked.

@grischard

This comment has been minimized.

Show comment
Hide comment
@grischard

grischard Jan 17, 2018

For those of us only following this ticket, see #190 also.

grischard commented Jan 17, 2018

For those of us only following this ticket, see #190 also.

@rugk rugk referenced this issue Jan 18, 2018

Open

HTTPS #8

@nmxcgeo

This comment has been minimized.

Show comment
Hide comment
@nmxcgeo

nmxcgeo Feb 5, 2018

Hi,

I saw today, that you still send out e-mails with http-links for e.g. comments on your changesets / notes / whatever. As yo are already serving HSTS headers for www.openstreetmap.org I think it's reasonable to change these links to https as well.

Greetings
Nmxcgeo

nmxcgeo commented Feb 5, 2018

Hi,

I saw today, that you still send out e-mails with http-links for e.g. comments on your changesets / notes / whatever. As yo are already serving HSTS headers for www.openstreetmap.org I think it's reasonable to change these links to https as well.

Greetings
Nmxcgeo

@grischard

This comment has been minimized.

Show comment
Hide comment
@grischard

grischard commented Feb 5, 2018

@tomhughes

This comment has been minimized.

Show comment
Hide comment
@tomhughes

tomhughes Feb 5, 2018

Member

I'm not sure we can merge either of those as is, as lots of other people use our code base and they may not be running on an https capable site so we probably need to make it configurable in some way.

I'll have a think about it...

Member

tomhughes commented Feb 5, 2018

I'm not sure we can merge either of those as is, as lots of other people use our code base and they may not be running on an https capable site so we probably need to make it configurable in some way.

I'll have a think about it...

@HolgerJeromin

This comment has been minimized.

Show comment
Hide comment

HolgerJeromin commented Feb 5, 2018

@tomhughes

This comment has been minimized.

Show comment
Hide comment
@tomhughes

tomhughes Feb 5, 2018

Member

Not really - that is code designed to be cut and pasted on a third party site and that would go wrong if it was pasted on an https site and referenced an http only site.

Member

tomhughes commented Feb 5, 2018

Not really - that is code designed to be cut and pasted on a third party site and that would go wrong if it was pasted on an https site and referenced an http only site.

@HolgerJeromin

This comment has been minimized.

Show comment
Hide comment
@HolgerJeromin

HolgerJeromin Feb 5, 2018

Sorry, you are right. Thanks for the explanation.

HolgerJeromin commented Feb 5, 2018

Sorry, you are right. Thanks for the explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment