Can not enable SSL just for the login page

[jnordstrom]

I am using an apache reverse proxy as an SSL termination point. In order for apache to redirect the user's browser to HTTPS for login the apache server needs to be notified that the user is viewing a login page. This is usually accomplished by the application issuing a redirect to /login when the user is not authenticated or a user's session has expired, unfortunately roundcube does an internal forward as a result apache has no knowledge the user is seeing the login page and is unable to enable HTTPS. This issue will also apply to other security systems and SSL termination products. Using SSL for all communication is way to expensive. Moving to a REST based URL structure might resolve the issue.

[till]

I don't have SSL at my disposal.

Can you test if you login on e.g:
​https://server/roundcube

Are you automatically logged on here:
​http://server/roundcube

I'm not sure if the session "persists" on both. Let me know what you find.

Also, in 99% of all browsers the user is presented with a popup when he lives an encrypted (= SSL) connection to another which is unencrypted. IMO a no-go. I would stop using your webmail.

I also reset the issue to "none" (along with Severity and Priority) since this is not a security issue. More an issue of "I don't have enough resources". ;-) Personally I know that many people indeed want SSL on their entire mail session because the login and password to their email account is not the only thing that is confidential.

I also don't know what this got to do with ​REST. I sense buzzwords. ;-)))

Anyway, let me know what you find out!

[jnordstrom]

Since I setup apache as a reverse proxy which terminates the SSL session. Only the communication between the client(browser) and the apache server is using SSL. Once the request hits the server it is sent clear text to roundcube, meaning roundcube has no knowledge the session is encrypted. So roundcube's session if unaffected.

I think most users disable the SSL warning and watch for the pad lock in their browser window to confirm a valid SSL session.

The problem with full time SSL is the cost, I think it's something like 5x normal HTTP request. I believe Yahoo gives you the option to login via SSL. Sites like buy.com, amazon.com etc, only use SSL for login and checkout.

Sorry for the buzzwords what I was trying to say was use:

​http://server/roundcube/mail/logout
instead of
​http://www.coolkidmail.net/?_task=mail&_action=logout&true

and

​http://www.coolkidmail.net/mail/INBOX/show/17
instead of
​http://www.coolkidmail.net/?_task=mail&_action=show&_uid=17&_mbox=INBOX

For my proposes all I need is a redirect to ​http://server/roundcube/login when a user is required to login (is not logged in, session has expired, etc)

When the server issues a redirect to the browser (​http://server/roundcube/login), the browser will redirect, the apache server will see a request for ​http://server/roundcube/login and redirect the browser to ​https://server/roundcube/login (SSL). If the next URL does not have /login in it apache will redirect the browser back to http.

[till]

I see your point, and I'll review this again as soon as I have time. Give us a while, or work up a patch to speed things up.

[jnordstrom]

Thanks so much, I spend a day or two in the PHP code trying to resolve this, the problem I was having it triggering a redirect at the right points and circular redirects, I'll give it another go.

[trisk]

The patch adds a prefer_http option which can be used in combination with force_https to require SSL logins with unencrypted sessions. RoundCube now redirects to an HTTP URL after logging in.

This also corrects two minor issues:

• Logouts did not redirect to HTTPS when force_https was enabled.
• Session cookies did not carry over from HTTPS to HTTP. They now respect the global session.cookie_secure setting (which is 1 for HTTPS connections unless prefer_http is is set).

[alec]

I didn't test this patch, but we should care to use secure connection for password change process.

[trisk]

The updated patch correctly enforces HTTPS for the "plugin.password" (form) and "plugin.password-save" (post location) actions in the "settings" task.

One drawback of the script is that

A further enhancement would be to make the redirect function redirect to HTTP or HTTPS as appropriate instead of having to redirect twice when logging in. Looks like make_absolute_url might be useful for this.

[trisk]

I've updated the patch again to apply cleanly to current trunk (just config/main.inc.php changes).
If there is a potential for sensitive data to be transferred while in the settings task with plugins other than password, the entire settings task could be left encrypted.

[trisk]

Patch to add 'prefer_http' config option.

[bubble]

I think we should have an option at the login screen to "Stay with HTTPS" (or a three-state selector - HTTP/HTTPS/default) and probably an two-state (HTTP/HTTPS) UI configuration option for that (which should be remembered in per-user config if user selects something that is not 'default' at the login screen).

Not only passwords should be secured, e-mails can contain sensitive information too.

[dennylin93]

Replying to bubble:

Not only passwords should be secured, e-mails can contain sensitive information too.

True, but most emails aren't encrypted while they're transmitted over the Internet during through SMTP.

Perhaps we can add this feature to RC first and improve the functionality later on?

[qnrq]

Replying to dennylin93:

Replying to bubble:

Not only passwords should be secured, e-mails can contain sensitive information too.

True, but most emails aren't encrypted while they're transmitted over the Internet during through SMTP.

Yeah, but that's nothing that we can do something about. Without SSL the information may fall in the hands of an attacker through sniffing locally transmitted data, e.g. by connecting to a WiFi? sniffing packets (remember Google?). If an attacker would like to read somebody else's email it would be easier to go straight at the victim rather than somehow trying to perform a MITM attack on the SMTP servers for individual emails. The transmission between IMAP and MUA is far more vulnerable to such attacks than SMTP->SMTP.

In my opinion, it's a great mistake to let all information travel to the presentation layer unsafely by justifying that the transmission layer is usually insecure.

[thomasb]

I think the availability of the firesheep extension to hijack sessions justifies to stay on https for the entire session.

[jtl]

I object to the addition of this "feature." In my opinion everybody should be forced to use SSL whether they want to or not. As for the transmission layer being insecure, some of us do turn on opportunistic TLS for our MTAs...

Here is some research from Google you can read about the cost of correctly configured SSL encryption in modern web applications: ​http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

[alec]

-1 from me too.