You may also want to consider sending hsts headers

[Marking bug public as no issues in the bug require secrecy]

@Der_Keks Future reference, if you file a security issue only subscribers can see it. If you file one against XTools, please subscribe at least myself, MusikAnimal, or Samwilson.

Is there any progress on this?

Probably won’t see any progress until we move this task into “working” on our work board.

Man, I'm really tired. We have another option (and this might be the smartest), is just do an apache-side configuration. See https://wiki.apache.org/httpd/RedirectSSL for the simple way to do it.

Since we're already configuring things with Puppet, T170514: Set up XTools servers with Puppet might be the place to chase that down. @MaxSem since you did the initial puppet work (with gerrit 368101), could you make this a thing?

Yeah guys that i am thinking about since 2 Month but noone made this suggestion...
In Nginx i realized this on my own Nextcloud-Server without any CMS. I hate CMS *shaking*
http://xtools.wmflabs.org/ is using nginx too. So heavy to go into the configs and change it? Don't worry, you can test the config via shell: nginx -t

server {
	listen 80;
	server_name xtools.wmflabs.org;
	server_tokens off;
		location / {
			return 301 https://$host:443$request_uri;
		}
}

It is a simple operation and it takes sooo long?

This is what's done in IA Upload:

	if ( $request->headers->get( 'X-Forwarded-Proto' ) == 'http' ) {
		$uri = 'https://' . $request->getHost() . $request->headers->get( 'X-Original-URI' );
		return new RedirectResponse( $uri );
	}

Ok you get the host and the uri manually. The variable $host and $request_uri does this for you automatically, so "$request->getHost()" == "$host". You method has no HTTP Status Code to define. I defined 301, because Google and other SE will compensate this instead of 302 (downranking)

No, sorry, what I was getting at is that you have to examine the X-Forwarded-Proto header, rather than the port number, because all requests come in on port 80 from the proxy (because we can't see the original request, for privacy reasons).

(I think.)

Please do not remove my user project while I’m assigned to a task.

There is actually another option: https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet

This is what ACC uses.

The proper way to set headers in Symfony: https://symfony.com/doc/current/introduction/http_fundamentals.html - Hoping that we can set it based on subdomain.

I feel like this discussion is over-complicating this - it should be pretty trivial to implement I think. For example, my HTTPS redirector in Python is exactly 4 lines of code: https://github.com/legoktm/toolforge/blob/master/toolforge/__init__.py#L99

The solution outlined in T170989#3575779 seems fine.

In T170989#3583064, @Legoktm wrote:

I feel like this discussion is over-complicating this - it should be pretty trivial to implement I think. For example, my HTTPS redirector in Python is exactly 4 lines of code: https://github.com/legoktm/toolforge/blob/master/toolforge/__init__.py#L99

The solution outlined in T170989#3575779 seems fine.

Except for the obvious problem that we don't use nginx. We use Apache. Hense my further investigation into this.

In T170989#3583073, @Matthewrbowker wrote:

In T170989#3583064, @Legoktm wrote:

The solution outlined in T170989#3575779 seems fine.

Except for the obvious problem that we don't use nginx. We use Apache. Hense my further investigation into this.

I think I'm missing exactly what part of T170989#3575779 relies on nginx. The X-Forwarded-Proto proto header should be set by the proxy.

For such a small intervention wasted so much time O_o

In T170989#3649294, @Der_Keks wrote:

For such a small intervention wasted so much time O_o

Yes, this is a relatively low priority change. We're putting it into our puppet configuration when it is finally built, which is ongoing.

This should have nothing to do with puppet. The code snippet pasted in T170989#3575779 should probably cover it.

I'll confirm what @Legoktm said. Cloud dynamicproxy sets the header, regardless of the backend server, apache or nginx.

In T170989#3649344, @Legoktm wrote:

This should have nothing to do with puppet. The code snippet pasted in T170989#3575779 should probably cover it.

We've opted to force a header via apache config. That's the easiest way to handle it, as Symfony has some strange configuration settings for forcing HTTPS (and we don't want those necessarily set for other users of XTools). That's also why it has to be puppetized (we maintain virtual 3 servers right now, with possibly more in the future depending on need)

In T170989#3649361, @zhuyifei1999 wrote:

I'll confirm what @Legoktm said. Cloud dynamicproxy sets the header, regardless of the backend server, apache or nginx.

Do you have any documentation on this "Cloud dynamicproxy" and how to inject headers into it? If so I'd love to see it.

In T170989#3655690, @Matthewrbowker wrote:

Do you have any documentation on this "Cloud dynamicproxy" and how to inject headers into it? If so I'd love to see it.

I'm unaware of the documentation, but the code is at https://github.com/wikimedia/puppet/blob/production/modules/dynamicproxy/templates/domainproxy.conf#L90