Can not enable SSL just for the login page #1320
Comments
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! |
Status changed by @till on 9 Feb 2008 16:14 UTC new => assigned |
Severity changed by @till on 9 Feb 2008 16:14 UTC major => minor |
Owner changed by @till on 9 Feb 2008 16:14 UTC => till |
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 and http://www.coolkidmail.net/mail/INBOX/show/17 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 @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. |
Milestone changed by @till on 13 Feb 2008 01:58 UTC => 0.2-stable |
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. |
Milestone changed by @thomascube on 12 Sep 2008 14:33 UTC 0.2-stable => later |
Comment by trisk on 12 Feb 2010 06:21 UTC The patch adds a This also corrects two minor issues:
|
Milestone changed by trisk on 12 Feb 2010 06:21 UTC later => 0.4-beta |
Keywords changed by trisk on 12 Feb 2010 06:21 UTC ssl login |
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. |
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 @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. |
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 |
Comment by @alecpl on 14 Feb 2011 08:22 UTC -1 from me too. |
Status changed by @alecpl on 14 Feb 2011 08:22 UTC assigned => closed |
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
The text was updated successfully, but these errors were encountered: