Bug 825334 - OpenShift apps should service both http and https requests. But after I switch to https, I can't go back to http.
OpenShift apps should service both http and https requests. But after I swit...
Status: CLOSED NOTABUG
Product: OpenShift Origin
Classification: Red Hat
Component: Containers (Show other bugs)
2.x
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Rob Millner
libra bugs
: Security, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-25 13:50 EDT by Nam Duong
Modified: 2015-08-12 05:47 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-25 22:23:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nam Duong 2012-05-25 13:50:43 EDT
Description of problem:
This was reported by a user on IRC:
OpenShift apps should service both http and https requests.  But after I switch to https, I can't go back to http.

Steps to reproduce:
1) Create a sample app called test on domain foo.
2) hit http://test-foo.rhcloud.com
3) then hit https://test-foo.rhcloud.com
4) Then try to hit http://test-foo.rhcloud.com again

Expected:  Should work.
Actual:  Browser forces back to https://test-foo.rhcloud.com

This happens with PHP, Ruby, JBoss sample/default apps
Comment 1 Rob Millner 2012-05-25 22:23:59 EDT
The server sets the following header in the response on both http and https sessions:

Strict-Transport-Security: max-age=15768000, includeSubDomains

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

The header is in place to prevent downgrading back to an http connection from https as part of a man in the middle attack.  As a side effect, you can't intentionally go back to http.

I'm going to close this as NOTABUG since its specifically designed this way.  Refer to bugzilla ticket 801848 for the underlying rational.
Comment 2 alphaone2k 2012-08-01 16:29:30 EDT
https://bugzilla.redhat.com/show_bug.cgi?id=825334

If every normal site that provides both http & https allows for switching on the STS supporting browser and your Openshift doesn't then there is something wrong with your product.

And in fact: "Strict-Transport-Security headers must be sent via HTTPS responses only.", but you send it on HTTP

HTTP/1.1 200 OK
Date: Wed, 01 Aug 2012 20:23:35 GMT
Server: Apache/2.2.15 (Red Hat)
Content-Type: text/html
Cache-control: private
Set-Cookie: GEAR=ed16003007-w; path=/
Strict-Transport-Security: max-age=15768000, includeSubDomains
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked

Fix it

FYI: "You are not authorized to access bug #801848"
Comment 4 Ben 2013-02-09 20:25:36 EST
Why is this closed? And why is the max-age so large? I've installed a drupal site and now cannot view the frontend in a non-secure setting because I once visited the site using https.

I absolutely must have the ability to view the site in both http and https when I want. Without that feature Openshift is fundamentally unusable to host any sort of website I want to develop on. 

For example, in an e-commerce site you want to display the majority of your content in a non-secure manner. This allows assets to download quicker. Only when a purchase is made and credit card details need to be sent should the site then switch to https. Once the order is complete the user should then be viewing the site in a non-secure fashion again. 

With the current openshift security setup this is impossible. I don't understand why this is not viewed as a bug by the OpenShift development team.
Comment 5 Rob Millner 2013-02-11 13:09:24 EST
We re-examined the underlying rational over the past few weeks and concluded that its best to make this optional.  The behaviour should change when we do our next push to production.
Comment 6 Stijn de Witt 2015-08-12 05:47:56 EDT
"We re-examined the underlying rational over the past few weeks and concluded that its best to make this optional.  The behaviour should change when we do our next push to production."

But it's still doing it? And this bug is marked as closed wontfix?

I tried to set up a certificate but I failed and now every request (to HTTP) gets routed to HTTPS and then gets some warning page that my site might be malicious... Even after I removed the certificate from the alias again... Help!

Note You need to log in before you can comment on or make changes to this bug.