
Forcing Wordpress sites to use https even when not directed - martius
https://code.google.com/p/chromium/issues/detail?id=505268
======
pilif
I don't understand this in the context of Wordpress and PHP. As a relic of the
CGI spec, a header called "Foo" would be turned into an array index called
"HTTP_FOO".

For a header called "HTTPS" to be turned into $_SERVER['HTTPS'] as opposed to
$_SERVER['HTTP_HTTPS'] would require quite an impressive misconfiguration of
the web server which also requires _additional_ work compared to default
settings (including possibly even patching PHP itself depending on SAPI).

~~~
geofft
From the Google bug report
([https://crbug.com/505268](https://crbug.com/505268)), it looks like
WooCommerce was looking explicitly for $_SERVER['HTTP_HTTPS'], and this code
was removed when the Chrome behavior was discovered:

[https://github.com/woothemes/woocommerce/issues/8479](https://github.com/woothemes/woocommerce/issues/8479)

So "breaking web applications everywhere" is an exaggeration.

It also looks like this is the implementation of the W3 "upgrade-insecure-
requests" spec, so "Chrome 44 sending HTTPs header by mistake" is also not
true. It's intentional.

[http://www.w3.org/TR/upgrade-insecure-
requests/](http://www.w3.org/TR/upgrade-insecure-requests/)

But it sounds like they're going to implement a different header / propose
changes to the spec based on real-world feedback like this.

~~~
tomsommer
WooCommerce is not the only one doing stupid things with HTTP_HTTPS:
[https://github.com/search?l=php&q=HTTP_HTTPS&type=Code&utf8=...](https://github.com/search?l=php&q=HTTP_HTTPS&type=Code&utf8=%E2%9C%93)

Has anyone actually confirmed the problem on a non-WooCommerce site? or a site
without bad PHP code?

------
Twirrim
It seems crazy to:

1) Implement a _draft_ header from the W3 at this stage (which I think this is
from what I can see.. there's even some fun debate about how many characters
long it should be:
[https://github.com/w3c/webappsec/issues/216](https://github.com/w3c/webappsec/issues/216)).
Do they really expect webservers to handle this correctly?

2) Despite having a bug like this open in Beta, allow this to get out to Prod!
Surely it's obvious this is a major breaking change?!

edit: here's the working draft document: [http://www.w3.org/TR/upgrade-
insecure-requests/#preference](http://www.w3.org/TR/upgrade-insecure-
requests/#preference)

~~~
tomsommer
The header is 9 days old, and now Chrome is sending it by default:
[https://github.com/w3c/webappsec/commit/eeac3922418bfa6cb254...](https://github.com/w3c/webappsec/commit/eeac3922418bfa6cb254071c74ddd962ee418c80#diff-3545c71e29140b0ee305d62eefac12f4)

Header bloat, ~28 extra bytes per request from every Chrome user in the world.

The whole idea of the header is odd, it should be something the server could
send to the client, if needed, not something the client should announce
support for.

Crazy indeed.

~~~
MichaelGG
Yeah I read the draft and the rationale seems very weak. What's wrong with
just sending the Content-Security-Policy header in responses and letting UAs
do what they will? Nothing. Same as redirecting to HTTPS if you support it.
But for some reason, they had to combine things and want to know if it's
"safe" to use HTTPS. They didn't appear to list any real scenarios for this
behavior. (Maybe there are, it's not readily apparent though.)

------
martius
Basically, now Chrome sends the header HTTPS: 1 when issuing a request over
HTTP to notify it "prefers" HTTPS.

However, this header is (or was) used by several HTTP servers/proxies
(including Apache, I believe) to notify the application that the client
connection is established in HTTPS. Wordpress reacts to this header by
generating [https://](https://) URLs, which may not work if the server doesn't
serve HTTPS with a properly configured certificate.

~~~
jrockway
Shouldn't the frontend remove the header if it's something that it would
normally add? It's a major problem if your application is expecting a header
to be set by the frontend web server, but is actually getting the value from
the user agent.

~~~
k8tte
Agree. I'm having a hard time to see how this is Chrome's fault. All
discussion i've seen indicate that wordpress and woocommerce treat the HTTPS
header in special (and non-standard) ways

~~~
martius
It's Chrome fault to use push for a new standardized header without properly
checking its impact: the issue has been raised during the beta phase, but they
underestimated it and did not rollback.

I believe it is known that some old reverse-proxies used this header before a
standard solution emerged (X-forwarded-proto), Wordpress probably had to deal
with this surprising behavior at some point.

Also, by naming a header "HTTPS", one could expect collision with a non-
standard behavior: this is very common with HTTP/1.1.

~~~
k8tte
I agree. However, non-standard conforming software should continue to use the
X- prefix, like if these proxies used a "X-HTTPS" indicating it is a non-
standard header, this would be a non-issue.

------
icebraining
Here's the discussion on the W3 mailing list (the new header is a draft
standard): [https://lists.w3.org/Archives/Public/public-
webappsec/2015Ju...](https://lists.w3.org/Archives/Public/public-
webappsec/2015Jun/0075.html)

------
cpach
The current title of this post (”Chrome 44 breaks any wordpress site not able
to serve in HTTPS”) seems exaggerated.

This issue does _not_ render _all_ non-HTTPS WP sites useless. I tried on a
friend’s site and it served fine in Chrome version 44.0.2403.89.

After skimming the bug report it seems to mostly affect the login
functionality and not the user-facing parts of WP. Still problematic but less
severe than what it sounds like.

~~~
lmm
If the admin can't log in to do anything I think it's fair to say the site is
broken.

~~~
cpach
Yep. But many Wordpress sites are rarely updated, and the owners of those
sites need not panic :)

------
jbverschoor
Chrome isn't breaking the applications. The applications are breaking the
applications

~~~
Cakez0r
Sounds more like a language issue.

    
    
        $_SERVER is an array containing information such as headers, paths, and script locations.
    
        You may or may not find any of the following elements in $_SERVER.
        'HTTPS'
        Set to a non-empty value if the script was queried through the HTTPS protocol.
    

[https://secure.php.net/manual/en/reserved.variables.server.p...](https://secure.php.net/manual/en/reserved.variables.server.php)

~~~
detaro
But then the environments violate that specification if they set this variable
off a random HTTP header?

~~~
Cakez0r
If the language spec says that $_SERVER['HTTPS'] is an indicator of whether
the request was made over HTTPS, then it should ensure that it adheres to its
own spec (I.E. not overwrite $_SERVER['HTTPS'] with the value from a header,
if it's present).

~~~
nolok
It does. The problem is in Apache, not the language.

Apache's says to look into the HTTPS variable (that it adds itself before
passing the call to the handler) to know if the call was made over https, but
then it overwrite that variable with the browser-sent header if there is one
(or more exactly, it uses the same variable name for that header and it's own
HTTPS indicator; so it overwrites if both are present, and if only the header
is present then it creates it when it shouldn't -- the issue in this post).

------
codeshaman
What Unit test could have cought that ? Is this a Bug at all ?

Chrome doesn't do anything wrong, but somehow the fix still has to be done
inside Chrome.

Interesting how it all starts looking like one giant app, were a small change
in one part leads to failures in completely unpredictable places.

~~~
Ensorceled
No unit test suite can cover all situations, you actually have to "use it in
anger" before shipping it to something like 50% of all web users.

Chrome is "breaking the internet" for its users, so Chrome _is_ doing
something wrong.

~~~
paulmd
That's what Canary Releases are for. You roll it out to (say) 2% of your users
and see whether it shits the bed. If it does, NBD, you roll it back or patch.
If it's good you roll it out to everyone.

------
Mojah
The reason this is happening is bad PHP code implementations, checking
HTTP_HTTPS instead of HTTPS. Most likely the result of proxy configs, that
prefixed "legit" headers with HTTP_.

More technical info here: [https://ma.ttias.be/chrome-44-sending-https-header-
by-mistak...](https://ma.ttias.be/chrome-44-sending-https-header-by-mistake-
breaking-web-applications-everywhere/)

------
SasnycoN
Here is one solution of the issue without disabling any plugins:
[http://bgroot-eng.blogspot.com/2015/07/wordpress-fixing-
your...](http://bgroot-eng.blogspot.com/2015/07/wordpress-fixing-your-
connection-is-not.html)

------
kup0
Yeah, some fairly large sites being affected by this. Especially in regards to
the "too many redirects" symptom.

------
wrigby
Just to summarize, from what I've read this affects only Apache installations
(possibly only Apache + mod_php).

I just stood up a WordPress site on Sunday running on nginx + HHVM (FastCGI),
and it's not experiencing any issues.

------
miscfuck
Maybe if they focused less on inverting binary trees then they'd ship less
busted software.

------
tazjin
> This is not going to be a fun week for Chrome users

Disagreed! This is a great week to see which sites break because of this in
order to avoid them in the future. (Yes, leading a life without Flash, PHP,
Node and all the other horrible technologies that came out of the web is
possible!)

~~~
LukeB_UK
Why does it matter if someone's site is running PHP or Node on the backend?
Doesn't change anything about your client side experience.

