Can not enable SSL just for the login page

[rcubetrac]

Reported by jnordstrom on 9 Feb 2008 03:47 UTC as Trac ticket #1484764

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.

Keywords: ssl login
Migrated-From: http://trac.roundcube.net/ticket/1484764

[rcubetrac]

Comment by @till on 9 Feb 2008 16:14 UTC

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!

[rcubetrac]

Status changed by @till on 9 Feb 2008 16:14 UTC

new => assigned

[rcubetrac]

Severity changed by @till on 9 Feb 2008 16:14 UTC

major => minor

[rcubetrac]

Owner changed by @till on 9 Feb 2008 16:14 UTC

=> till

[rcubetrac]

Comment by jnordstrom on 12 Feb 2008 19:02 UTC

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.

[rcubetrac]

Comment by @till on 13 Feb 2008 01:58 UTC

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.

[rcubetrac]

Milestone changed by @till on 13 Feb 2008 01:58 UTC

=> 0.2-stable

[rcubetrac]

Comment by jnordstrom on 13 Feb 2008 20:46 UTC

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.

[rcubetrac]

Milestone changed by @thomascube on 12 Sep 2008 14:33 UTC

0.2-stable => later

[rcubetrac]

Comment by trisk on 12 Feb 2010 06:21 UTC

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).

[rcubetrac]

Milestone changed by trisk on 12 Feb 2010 06:21 UTC

later => 0.4-beta

[rcubetrac]

Keywords changed by trisk on 12 Feb 2010 06:21 UTC

ssl login

[rcubetrac]

Comment by @alecpl on 24 Feb 2010 17:41 UTC

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

[rcubetrac]

Comment by trisk on 25 Feb 2010 20:07 UTC

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.

[rcubetrac]

Comment by trisk on 25 Mar 2010 19:26 UTC

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.

[rcubetrac]

Comment by bubble on 31 Mar 2010 10:54 UTC

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.

[rcubetrac]

Comment by dennylin93 on 17 Jul 2010 11:45 UTC

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?

[rcubetrac]

Comment by qnrq on 29 Jul 2010 12:11 UTC

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.

[rcubetrac]

Comment by @thomascube on 24 Nov 2010 12:24 UTC

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

[rcubetrac]

Comment by jtl on 9 Jan 2011 20:32 UTC

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

[rcubetrac]

Comment by @alecpl on 14 Feb 2011 08:22 UTC

-1 from me too.

[rcubetrac]

Status changed by @alecpl on 14 Feb 2011 08:22 UTC

assigned => closed