955921 - HTTPS on getfirefox.org lead to LDAP login promp

Status: RESOLVED FIXED

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

Description

[taiki]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.73.11 (KHTML, like Gecko) Version/7.0.1 Safari/537.73.11

Steps to reproduce:

Go to https://getfirefox.com/



Actual results:

Get prompted to log into Mozilla Corporation's LDAP


Expected results:

Redirection to https://www.mozilla.org/fr/firefox/new/

Comment 1

[Chris Turra [:cturra]]

this is the result of redirecting getfirefox through the static cluster. there are two options here: 1) we add ssl support for this static redirect or (2) update the URL to use http instead.

$ curl -IL getfirefox.com
HTTP/1.1 301 Moved Permanently
Server: Apache
X-Backend-Server: pp-web01
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1
Date: Thu, 02 Jan 2014 14:34:06 GMT
Location: https://www.mozilla.org/firefox/?utm_source=getfirefox-com&utm_medium=referral
Keep-Alive: timeout=20, max=999
Transfer-Encoding: chunked
Connection: Keep-Alive
X-Cache-Info: cached

HTTP/1.1 301 MOVED PERMANENTLY
Server: Apache
Vary: Accept-Language, Accept-Encoding
X-Backend-Server: bedrock1.webapp.phx1.mozilla.com
Cache-Control: max-age=600
Content-Type: text/html; charset=utf-8
Date: Thu, 02 Jan 2014 16:41:31 GMT
Location: https://www.mozilla.org/en-US/firefox/?utm_source=getfirefox-com&utm_medium=referral
Expires: Thu, 02 Jan 2014 16:51:31 GMT
Transfer-Encoding: chunked
X-Robots-Tag: noodp
X-Frame-Options: DENY
Connection: Keep-Alive
X-Cache-Info: cached

HTTP/1.1 301 MOVED PERMANENTLY
Server: Apache
X-Backend-Server: bedrock1.webapp.phx1.mozilla.com
Vary: Accept-Encoding
Cache-Control: max-age=600
Content-Type: text/html; charset=utf-8
Date: Thu, 02 Jan 2014 16:44:07 GMT
Location: https://www.mozilla.org/en-US/firefox/new/?utm_source=getfirefox-com&utm_medium=referral
Expires: Thu, 02 Jan 2014 16:54:07 GMT
Transfer-Encoding: chunked
X-Robots-Tag: noodp
Connection: Keep-Alive
X-Frame-Options: DENY
X-Cache-Info: caching

HTTP/1.1 200 OK
Server: Apache
X-Backend-Server: bedrock1.webapp.phx1.mozilla.com
Vary: Accept-Encoding
Cache-Control: max-age=600
Content-Type: text/html; charset=utf-8
Date: Thu, 02 Jan 2014 16:44:07 GMT
Expires: Thu, 02 Jan 2014 16:54:07 GMT
Transfer-Encoding: chunked
X-Robots-Tag: noodp
Connection: Keep-Alive
X-Frame-Options: DENY
X-Cache-Info: caching

Comment 2

[Chris Turra [:cturra]]

i have confirmed that there are no external https links to getfirefox.org through bedrock (www.mozilla.org). as a result, i am going to mark this bug as r/wontfix.

the only way you're going to see if this error if you manually navigate to the url noted by the reporter.

Comment 3

[taiki]

So if I understand your mind, you're punishing the will to access to a website by https directly...

SSL/TLS is not only a privacy feature, it also enable authentification of the server. 
A MitM attack on getfirefox.com could lead to redirect the user on an other server, or to provide a spoofed webpage
 which could lead to the install of a patched installer.
From Snowden's leaks, NSA used such approach.

We have to educate users about adding https:// to the URLs they types but browser whose ancestor introduced SSL doesn't support it on the domain the large majority of users willing to install it will use? Come on... 
Is this patch really complex?

Comment 4

[Chris Turra [:cturra]]

i definitely do not intend to punish any users here! 

looking through the logs for getfirefox.org, there is less than 1% of it's traffic coming from non-redirected traffic. as a result, to add https support, we'd be adding a cost (ssl purchase, monitoring, etc) for little to no business impact.

i understand why you opened this bug and your concerns are valid. however, we need to weigh out the reward here and i don't see any qualitatively compelling reason why https would be a requirement.

Comment 5

[taiki]

Ok, from this message, your decision is easier to understand.

However, isn't the SSL certificate already there? If you go to https://getfirefox.com/ and check the certificate, it seems to be valid (so already bought and maintained, just not used).
A domain included in this certificate is https://nightly.mozilla.org/ and seems to work flawlessly.

I don't get what would change except that the extremely small part of the users who directly type the URL could be sure to communicate with mozilla.
Also, there is a possibility that HTTP/2.0 could require TLS, and then the change will have to be done. Why don't do it today?

Comment 6

[Chris Turra [:cturra]]

good catch! it looks like this domain was included in the subject alternative names for the recent changes we made to the static cluster's ssl certificate!
 
  X509v3 Subject Alternative Name:
    ...
    DNS:getfirefox.com, DNS:www.getfirefox.com


i have updated the vhost config on the static cluster to make this work correctly.

  $ curl -I https://getfirefox.com
  HTTP/1.1 301 Moved Permanently
  Server: Apache
  X-Backend-Server: pp-web01
  Vary: Accept-Encoding
  Content-Type: text/html; charset=iso-8859-1
  Date: Thu, 02 Jan 2014 18:18:09 GMT
  Location: https://www.mozilla.org/firefox/?utm_source=getfirefox-com&utm_medium=referral
  Transfer-Encoding: chunked
  Connection: Keep-Alive
  X-Cache-Info: cached

Comment 7

[taiki]

Awesome, thanks :D