Impossible to log in via HTTP after logging in via HTTPS

[vizovitin]

It's impossible to log in via HTTP after first logging in via HTTPS on modern browsers due to session cookie being both HttpOnly and Secure, which causes (at least) modern Chromium and Firefox versions to block setting the cookie when accessing Roundcube via HTTP.

Steps to Reproduce

1. Install Rouncube on a site available via both HTTPS and HTTP, without redirect from HTTP to HTTPS.
2. Log into Roundcube via HTTPS. Optionally log out.
3. Log into Roundcube via HTTP (with valid credentials).

Actual Result

Login not possible. "Invalid request. No data was saved" error is shown on Roundcube login page.

Expected Result

It's possible to log in after switching to HTTP.

Known Workarounds

• Clean browser cookies for the HTTPS version of the site (cleaning for the HTTP version won't work)
• Use a private browser window
• Don't use HTTP or configure HTTP->HTTPS redirect

Additional Information

Relevant blog post about the issue.

Warning in browser console:

The issue was created based on internal issue PPP-50468.

[vizovitin]

Tested on Roundcube 1.4.8, but I'm pretty sure this is actual for any recent version.

[johndoh]

What is your use case? Why would a user want to switch from HTTPS to HTTP?

HTTP -> HTTPS redirects are trivial to setup either at the server level or by enabling force_https in your Roundcube config.

[alecpl]

As I understand the only way to fix this would be to use different cookie names on different "channels". But if browsers decided to not support this (for better security/privacy), why should we?

ps. session_name and session_auth_name are already configurable, so you can set them conditionally.

[mckaygerhard]

@vizovitin i found the trick, here the path and you able to use in any form, but each sesion will be by it own.. this means that https open sesion must be closed property so no hijacking can be allowed if people are on the https way, but if you are under http afrter close.. you can be trikiy, below the path the explanation:

diff --git a/program/lib/Roundcube/rcube.php b/program/lib/Roundcube/rcube.php
--- a/program/lib/Roundcube/rcube.php
+++ b/program/lib/Roundcube/rcube.php
@@ -442,7 +442,7 @@ class rcube
         $sess_domain = $this->config->get('session_domain');
         $sess_path   = $this->config->get('session_path');
         $lifetime    = $this->config->get('session_lifetime', 0) * 60;
-        $is_secure   = $this->config->get('use_https') || rcube_utils::https_check();
+        $is_secure   = $this->config->get('use_https');

         // set session domain
         if ($sess_domain) {
@@ -459,7 +459,9 @@ class rcube

         // set session cookie lifetime so it never expires (#5961)
         ini_set('session.cookie_lifetime', 0);
-        ini_set('session.cookie_secure', $is_secure);
+        if ( rcube_utils::https_check() ) {
+            ini_set('session.cookie_secure', $is_secure); // coment here for all unsecure if do not want https check
+        }
         ini_set('session.name', $sess_name ?: 'roundcube_sessid');
         ini_set('session.use_cookies', 1);
         ini_set('session.use_only_cookies', 1);

the first commit that used the secure cookie was https://github.com/roundcube/roundcubemail/commit/d5fca0c4902d0c9a7427e6028ddbbc8bb337859e that checks if are under https way, and if are under.. then set a secure cookie.. after the refactoring of the roundcube api at 1.0.X this commit can not be reverted so the new way is a check if it is in https and it uses https always... (it means.. if and user get back from https to http of course could be a suplantation attack)

however contrary to what @alecpl says, tecnically HIS code is wrong, since it assumes always that it goes through https, that is not true, BUT on the contrary, for security purposes the original roundcube code is "just fine", since a user leaving https is assumed to be a phishing attack, that is why this issue is closed and no support will be provided

my path just make legal and respect the way where you browse the rendering.. if you are under http so the cokkie dont be applied, but if you are under https you must close this session correctly to use back over http .. easy. as must be.