Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Can not enable SSL just for the login page #1320
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
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:
Are you automatically logged on here:
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!
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:
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.
Comment by trisk on 12 Feb 2010 06:21 UTC
The patch adds a
This also corrects two minor issues:
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
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).
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.
Comment by dennylin93 on 17 Jul 2010 11:45 UTC
Replying to bubble:
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?
Comment by qnrq on 29 Jul 2010 12:11 UTC
Replying to dennylin93:
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.
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