Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-4116

Support SSL for login and optional SSL for remainder of application

    • Icon: Suggestion Suggestion
    • Resolution: Won't Fix
    • None
    • None
    • Stand alone on Linux RH enterprise. Latest Sun JDK.
    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      It's a violation of our campus security policy to allow passwords to be transmitted in plaintext. They must be encrypted. You really need to support better security during the login process by allowing the admin to require SSL to log in.

            [CONFSERVER-4116] Support SSL for login and optional SSL for remainder of application

            Perhaps I should let John reply however:

            Jeff asked:

            I think IE will cache to disk if you have "Do not save encrypted pages to disk" unchecked in Tools -> Options -> Advanced -> Security, which appears to be the default. Can you see if you have checked this?

            John originally said:

            Letting IE cache HTTPS content to disk makes it perform as well as FF, but then all HTTPS content can be cached, not just our Confluence pages.

            Stephen Morad added a comment - Perhaps I should let John reply however: Jeff asked: I think IE will cache to disk if you have "Do not save encrypted pages to disk" unchecked in Tools -> Options -> Advanced -> Security, which appears to be the default. Can you see if you have checked this? John originally said: Letting IE cache HTTPS content to disk makes it perform as well as FF, but then all HTTPS content can be cached, not just our Confluence pages.

            Question, what encryption algorithm is used for the 'seraph.confluence' cookie?

            The encryption is done in EncryptionUtils.java and uses the "PBEWithMD5AndDES" cipher. A salt is used and can be customized in WEB-INF/classes/seraph-config.xml (but in practice, almost never is):

                    <!-- This property controls how your cookie is encrypted.  If you truly want to secure your cookies, you need
                        to change this to a secure password -->
                    <init-param>
                        <param-name>cookie.encoding</param-name>
                        <param-value>jiracookie</param-value>
                    </init-param>
            

            Jeff Turner added a comment - Question, what encryption algorithm is used for the 'seraph.confluence' cookie? The encryption is done in EncryptionUtils.java and uses the "PBEWithMD5AndDES" cipher. A salt is used and can be customized in WEB-INF/classes/seraph-config.xml (but in practice, almost never is): <!-- This property controls how your cookie is encrypted. If you truly want to secure your cookies, you need to change this to a secure password --> <init-param> <param-name> cookie.encoding </param-name> <param-value> jiracookie </param-value> </init-param>

            It all boils down to caching.

            Can you quantify this? Have you tried JIRA with and without HTTPS? Or can you compare the first load (results no cached in memory) with subsequent loads, which should be fast? Perhaps you could use something like http://www.charlesproxy.com/ to get numbers.

            Firefox and Netscape will cache HTTPS content in RAM. IE will cache only to disk.

            I think IE will cache to disk if you have "Do not save encrypted pages to disk" unchecked in Tools -> Options -> Advanced -> Security, which appears to be the default. Can you see if you have checked this?

            I'm not concerned about #1. If someone wants to hijack my Confluence/Jira session, they can have it. I'm concerned about my ldap credentials being sniffed off the wire and used elsewhere in my enterprise.

            Sounds fair enough then, if you're not concerned about JIRA. Implementing the feature request would then involve providing a flag to disable "remember me",

            Jeff Turner added a comment - It all boils down to caching. Can you quantify this? Have you tried JIRA with and without HTTPS? Or can you compare the first load (results no cached in memory) with subsequent loads, which should be fast? Perhaps you could use something like http://www.charlesproxy.com/ to get numbers. Firefox and Netscape will cache HTTPS content in RAM. IE will cache only to disk. I think IE will cache to disk if you have "Do not save encrypted pages to disk" unchecked in Tools -> Options -> Advanced -> Security, which appears to be the default. Can you see if you have checked this? I'm not concerned about #1. If someone wants to hijack my Confluence/Jira session, they can have it. I'm concerned about my ldap credentials being sniffed off the wire and used elsewhere in my enterprise. Sounds fair enough then, if you're not concerned about JIRA. Implementing the feature request would then involve providing a flag to disable "remember me",

            I completely agree with John. And regarding Jeff's comment:

            Furthermore, if you checked "Remember me", your username and password are encrypted (not hashed) in the 'seraph.confluence' cookie. Anyone with a bit of motivation can crack this, and see your raw password. So the argument made that corporate passwords are not exposed is false.

            As John said, disabling the "Remember Me" Option is one mitigation. Secondly, for some of us, the issue isn't ensuring beyond all reasonable doubt that a corporate password is not exposed (even a hashed password is "exposed" if it is weak and subject to a dictionary attack). Instead, it is ensuring that the transmission of the password meets corporate requirements. In my case, the corporate policy requires the password to be encrypted. Period.

            Question, what encryption algorithm is used for the 'seraph.confluence' cookie?

            Stephen Morad added a comment - I completely agree with John. And regarding Jeff's comment: Furthermore, if you checked "Remember me", your username and password are encrypted (not hashed) in the 'seraph.confluence' cookie. Anyone with a bit of motivation can crack this, and see your raw password. So the argument made that corporate passwords are not exposed is false. As John said, disabling the "Remember Me" Option is one mitigation. Secondly, for some of us, the issue isn't ensuring beyond all reasonable doubt that a corporate password is not exposed (even a hashed password is "exposed" if it is weak and subject to a dictionary attack). Instead, it is ensuring that the transmission of the password meets corporate requirements. In my case, the corporate policy requires the password to be encrypted. Period. Question, what encryption algorithm is used for the 'seraph.confluence' cookie?

            I ended up on this issue because of continual complaints about the performance of Confluence.

            We run Confluence and Jira each on their own tomcat server with a single apache server in front of them. All communication with apache is done via HTTPS. After several days of troubleshooting I find:

            • I am not processor bound
            • I am not network bound
            • I am not disk I/O bound
            • The applications work well with Netscape and Firefox
            • The applications work badly with Internet Explorer

            It all boils down to caching.

            Firefox and Netscape will cache HTTPS content in RAM. IE will cache only to disk. A Firefox request which asks for two URLs and results in the transfer of 30KB may require 50 URLs and 111KB from IE. The difference is very apparent to my IE users. Letting IE cache HTTPS content to disk makes it perform as well as FF, but then all HTTPS content can be cached, not just our Confluence pages.

            I write this in response to Jeff Turner's invitation, "If anyone has further evidence suggesting that SSL prevents caching, please let us know."

            I can see two reasons not to restrict HTTPS use to only authentication pages:

            1. Confluence/Jira session hijacking
            2. Storage of authentication credentials in a cookie when the "Remember Me" function is used

            I'm not concerned about #1. If someone wants to hijack my Confluence/Jira session, they can have it. I'm concerned about my ldap credentials being sniffed off the wire and used elsewhere in my enterprise.

            Removing the "Remember Me" function makes #2 a non-issue. If this option could be removed from the login page, I would feel quite comfortable performing authentication by HTTPS and delivering the rest of the content by HTTP.

            john thurston added a comment - I ended up on this issue because of continual complaints about the performance of Confluence. We run Confluence and Jira each on their own tomcat server with a single apache server in front of them. All communication with apache is done via HTTPS. After several days of troubleshooting I find: I am not processor bound I am not network bound I am not disk I/O bound The applications work well with Netscape and Firefox The applications work badly with Internet Explorer It all boils down to caching. Firefox and Netscape will cache HTTPS content in RAM. IE will cache only to disk. A Firefox request which asks for two URLs and results in the transfer of 30KB may require 50 URLs and 111KB from IE. The difference is very apparent to my IE users. Letting IE cache HTTPS content to disk makes it perform as well as FF, but then all HTTPS content can be cached, not just our Confluence pages. I write this in response to Jeff Turner's invitation, "If anyone has further evidence suggesting that SSL prevents caching, please let us know." I can see two reasons not to restrict HTTPS use to only authentication pages: Confluence/Jira session hijacking Storage of authentication credentials in a cookie when the "Remember Me" function is used I'm not concerned about #1. If someone wants to hijack my Confluence/Jira session, they can have it. I'm concerned about my ldap credentials being sniffed off the wire and used elsewhere in my enterprise. Removing the "Remember Me" function makes #2 a non-issue. If this option could be removed from the login page, I would feel quite comfortable performing authentication by HTTPS and delivering the rest of the content by HTTP.

            Thanks for the discussions guys.

            Jeff's arguments are correct and convincing and we have no plans to deliver this feature. Please comment further if there is something we've missed.

            Adnan Chowdhury [Atlassian] added a comment - Thanks for the discussions guys. Jeff's arguments are correct and convincing and we have no plans to deliver this feature. Please comment further if there is something we've missed.

            I think this issue should be closed as "Won't fix", hit over the head, buried, and all records of it erased lest anyone else be tempted to follow the advice given in its comments.

            As Chris says, protecting the password but not the subsequent requests offers almost no security benefit. Let me unpack this, since a lot of people reading this don't understand the problem:

            Why you need https everywhere

            When you first log in over http, your username and password are sent in clear text over the network:

            POST /login.action HTTP/1.1
            ...
            Content-Type: application/x-www-form-urlencoded
            Content-Length: 111
            os_username=jeff&os_password=s3cret%21&os_cookie=true&login=Log+In&os_destination=%2Fhomepage.action
            

            So everyone agrees you want this request done securely over https.

            But then what's less obvious is that your browser sends equivalent authorization cookies on every subsequent Confluence request:

            GET /homepage.action HTTP/1.1
            ...
            Cookie: JSESSIONID=5A6E7C110E43568484C374F26190142E; seraph.confluence=TiXiEh]hiiXi\jXfRgtfTWgQfWYmWk[kThSf\gXgTgOk
            

            If anyone can intercept any of your requests, they can log in to Confluence (or JIRA) as you, simply by using the same cookie. This "session stealing" is trivial to do. Furthermore, if you checked "Remember me", your username and password are encrypted (not hashed) in the 'seraph.confluence' cookie. Anyone with a bit of motivation can crack this, and see your raw password. So the argument made that corporate passwords are not exposed is false.

            Conclusion: if your JIRA or Confluence requests are travelling over an insecure network, you really want them encrypted with SSL.

            Objection 1: Performance

            > 1) we incur the encryption overhead on every page

            I don't believe the performance argument (that SSL puts too much overhead on the system) holds any water. On modern hardware the SSL overhead should be negligible, and utterly dwarfed by the processing overhead of heavyweight Java apps. There are many high-load JIRA and Confluence instances running over https without a hitch. For instance, https://issues.apache.org/jira is getting an average of 5.8 hits/second over SSL (4x 2.8Ghz Xeons).

            If the people claiming poor performance have stats (from a tool like 'ab') proving that SSL is a significant overhead, I'd love to see them.

            Objection 2: Caching

            Then there's the argument that:

            > 2) a lot of caching is disabled client-side since ssl pages/objects aren't cached

            Again, I don't think this is true, based on things Scott discovered:

            http://blogs.atlassian.com/developer/2007/07/when_caching_is_not_caching.html

            If anyone has further evidence suggesting that SSL prevents caching, please let us know.

            Other problems with redirecting to http

            Finally, Atlassian support have had a constant trickle of customers who have tried the customizations on this page, and then have problems as a result. A common case is where the "Remember me" checkbox no longer functions, because the cookie is scoped to https, and then lost after the http redirection.

            Summary

            Redirecting https to http is fundamentally a bad, bad idea to anyone who cares about the security of their site. The supposed benefits (performance) are largely mythical, and the actual problems (weakened security, configuration issues) are very real.

            Perhaps there's reasons for doing this I haven't thought of. If there's a tiny minority for whom redirecting to http makes sense, that's fine: they can follow the hacks on this issue. But Atlassian should not be encouraging something that is harmful to 99% of Confluence users.

            Jeff Turner added a comment - I think this issue should be closed as "Won't fix", hit over the head, buried, and all records of it erased lest anyone else be tempted to follow the advice given in its comments. As Chris says , protecting the password but not the subsequent requests offers almost no security benefit. Let me unpack this, since a lot of people reading this don't understand the problem: Why you need https everywhere When you first log in over http, your username and password are sent in clear text over the network: POST /login.action HTTP/1.1 ... Content-Type: application/x-www-form-urlencoded Content-Length: 111 os_username=jeff&os_password=s3cret%21&os_cookie=true&login=Log+In&os_destination=%2Fhomepage.action So everyone agrees you want this request done securely over https. But then what's less obvious is that your browser sends equivalent authorization cookies on every subsequent Confluence request : GET /homepage.action HTTP/1.1 ... Cookie: JSESSIONID=5A6E7C110E43568484C374F26190142E; seraph.confluence=TiXiEh]hiiXi\jXfRgtfTWgQfWYmWk[kThSf\gXgTgOk If anyone can intercept any of your requests, they can log in to Confluence (or JIRA) as you , simply by using the same cookie. This "session stealing" is trivial to do. Furthermore, if you checked "Remember me", your username and password are encrypted (not hashed) in the 'seraph.confluence' cookie. Anyone with a bit of motivation can crack this, and see your raw password. So the argument made that corporate passwords are not exposed is false. Conclusion: if your JIRA or Confluence requests are travelling over an insecure network, you really want them encrypted with SSL. Objection 1: Performance > 1) we incur the encryption overhead on every page I don't believe the performance argument (that SSL puts too much overhead on the system) holds any water. On modern hardware the SSL overhead should be negligible, and utterly dwarfed by the processing overhead of heavyweight Java apps. There are many high-load JIRA and Confluence instances running over https without a hitch. For instance, https://issues.apache.org/jira is getting an average of 5.8 hits/second over SSL (4x 2.8Ghz Xeons). If the people claiming poor performance have stats (from a tool like 'ab') proving that SSL is a significant overhead, I'd love to see them. Objection 2: Caching Then there's the argument that: > 2) a lot of caching is disabled client-side since ssl pages/objects aren't cached Again, I don't think this is true, based on things Scott discovered: http://blogs.atlassian.com/developer/2007/07/when_caching_is_not_caching.html If anyone has further evidence suggesting that SSL prevents caching, please let us know. Other problems with redirecting to http Finally, Atlassian support have had a constant trickle of customers who have tried the customizations on this page, and then have problems as a result. A common case is where the "Remember me" checkbox no longer functions, because the cookie is scoped to https, and then lost after the http redirection. Summary Redirecting https to http is fundamentally a bad, bad idea to anyone who cares about the security of their site. The supposed benefits (performance) are largely mythical, and the actual problems (weakened security, configuration issues) are very real. Perhaps there's reasons for doing this I haven't thought of. If there's a tiny minority for whom redirecting to http makes sense, that's fine: they can follow the hacks on this issue. But Atlassian should not be encouraging something that is harmful to 99% of Confluence users.

            On another support thread, I was shown this tweak if you are connecting directly to Tomcat. I think this is probably the cleanest solution, although I'm not sure how it could be incorporated with Apache fronting it.

            Also, do we need additional tweaks for WebDAV as WebDAV seems to use use Basic Authentication instead of the login form? Do we need another redirect so that all WebDAV traffic uses HTTPS?

            RewriteCond %{REQUEST_URI} !^/wiki/plugins/servlet/webdav/

            Stephen Morad added a comment - On another support thread, I was shown this tweak if you are connecting directly to Tomcat. I think this is probably the cleanest solution, although I'm not sure how it could be incorporated with Apache fronting it. Also, do we need additional tweaks for WebDAV as WebDAV seems to use use Basic Authentication instead of the login form? Do we need another redirect so that all WebDAV traffic uses HTTPS? RewriteCond %{REQUEST_URI} !^/wiki/plugins/servlet/webdav/

            Our scenario is identical to what Stephen Morad describes. As we have heavily unified usernames/passwords for our 5000+ users around Novell eDirectory (via LDAP), protecting the username/password is critical (as that username/password gives all kinds of access in lots of different systems - VPN, HR, billing, physical security, academic, etc.).

            As we're fronting Confluence with Apache via reverse proxy, we've been able to work around this with mod_rewrite rules to force SSL on certain pages however it's not an optimal approach (does require maintenance/testing with upgrades).

            Andrew Miller added a comment - Our scenario is identical to what Stephen Morad describes. As we have heavily unified usernames/passwords for our 5000+ users around Novell eDirectory (via LDAP), protecting the username/password is critical (as that username/password gives all kinds of access in lots of different systems - VPN, HR, billing, physical security, academic, etc.). As we're fronting Confluence with Apache via reverse proxy, we've been able to work around this with mod_rewrite rules to force SSL on certain pages however it's not an optimal approach (does require maintenance/testing with upgrades).

            Many of you have mentioned that you require this functionality to comply with organisational security policies and we can sympathise.

            The problem is that the setup you require, as expressed in this issue, provides minimal security above the default (if any at all) as the login cookie and session details Confluence maintains with the browser will be subsequently transmitted in unsecure plain text for every page request after the login is completed. If an attacker were in a position to obtain a user's password on the wire during login they are still in a position to hijack the session after login. It is our opinion that if you require secure logins then you probably also require the entire session to be encrypted after login.

            Providing this feature may prove to be treacherous as it conveys a certain feeling of security which, in the end, is false.

            Chris,

            What you may not realize this that for most of us, the concern isn't about securing the Confluence content. I, for one, don't care if someone hijacks Confluence sessions. What I care about is exposing corporate passwords that can be used to get into other, much more sensitive, areas. The issue is one of convience – I want to allow users to be able to use their standard ID/password to access Confluence without the risk of compromising their password in the process.

            Stephen Morad added a comment - Many of you have mentioned that you require this functionality to comply with organisational security policies and we can sympathise. The problem is that the setup you require, as expressed in this issue, provides minimal security above the default (if any at all) as the login cookie and session details Confluence maintains with the browser will be subsequently transmitted in unsecure plain text for every page request after the login is completed. If an attacker were in a position to obtain a user's password on the wire during login they are still in a position to hijack the session after login. It is our opinion that if you require secure logins then you probably also require the entire session to be encrypted after login. Providing this feature may prove to be treacherous as it conveys a certain feeling of security which, in the end, is false. Chris, What you may not realize this that for most of us, the concern isn't about securing the Confluence content. I, for one, don't care if someone hijacks Confluence sessions. What I care about is exposing corporate passwords that can be used to get into other, much more sensitive, areas. The issue is one of convience – I want to allow users to be able to use their standard ID/password to access Confluence without the risk of compromising their password in the process.

            Many of you have mentioned that you require this functionality to comply with organisational security policies and we can sympathise.

            The problem is that the setup you require, as expressed in this issue, provides minimal security above the default (if any at all) as the login cookie and session details Confluence maintains with the browser will be subsequently transmitted in unsecure plain text for every page request after the login is completed. If an attacker were in a position to obtain a user's password on the wire during login they are still in a position to hijack the session after login. It is our opinion that if you require secure logins then you probably also require the entire session to be encrypted after login.

            Providing this feature may prove to be treacherous as it conveys a certain feeling of security which, in the end, is false.

            Christopher Owen [Atlassian] added a comment - Many of you have mentioned that you require this functionality to comply with organisational security policies and we can sympathise. The problem is that the setup you require, as expressed in this issue, provides minimal security above the default (if any at all) as the login cookie and session details Confluence maintains with the browser will be subsequently transmitted in unsecure plain text for every page request after the login is completed. If an attacker were in a position to obtain a user's password on the wire during login they are still in a position to hijack the session after login. It is our opinion that if you require secure logins then you probably also require the entire session to be encrypted after login. Providing this feature may prove to be treacherous as it conveys a certain feeling of security which, in the end, is false.

            AlexH added a comment -

            Dennis - You may wish to consider pursuing fronting Confluence with an apache proxy/rewrite setup to secure the login pages. Though a little complicated to setup initially it's documented very well in this thread and once setup it works beautifully. Not only that but I've found that having apache sitting in front of Confluence has been extremely useful to us for a number of additional reasons:

            • The entire library of apache modules which are useful for directing and controlling the traffic hitting your server.
              • Another rewrite rule that on detection of a file redirects all traffic to a maintenance page
            • Enhanced logging

            And these are just the examples I've put into practice so far.

            At this point even if Atlassian started supporting SSL login pages directly through tomcat/confluence I think I would stick with this apache setup for the flexibility apache provides in controlling the traffic.

            AlexH added a comment - Dennis - You may wish to consider pursuing fronting Confluence with an apache proxy/rewrite setup to secure the login pages. Though a little complicated to setup initially it's documented very well in this thread and once setup it works beautifully. Not only that but I've found that having apache sitting in front of Confluence has been extremely useful to us for a number of additional reasons: The entire library of apache modules which are useful for directing and controlling the traffic hitting your server. Another rewrite rule that on detection of a file redirects all traffic to a maintenance page Enhanced logging And these are just the examples I've put into practice so far. At this point even if Atlassian started supporting SSL login pages directly through tomcat/confluence I think I would stick with this apache setup for the flexibility apache provides in controlling the traffic.

            Like many other companies, we have security / password policies. I had to fully impliment SSL on Jira and Confluence as there was no option to use SSL only on login pages.

            I've read how others have dealt with this issue, but we will continue to wait for Atlassian to provide a solution. I'm sure there are others patiently waiting as well...

            Dennis Baker added a comment - Like many other companies, we have security / password policies. I had to fully impliment SSL on Jira and Confluence as there was no option to use SSL only on login pages. I've read how others have dealt with this issue, but we will continue to wait for Atlassian to provide a solution. I'm sure there are others patiently waiting as well...

            You're correct that that doesn't really apply here....security-related but a separate issue.

            Regardless, currently I'm kind of fudging on the secure LDAP bit since the server running Confluence and the LDAP server are plugged into the same physical switch in the server room. (I might just look at tunneling it over SSH if LDAP ends up being available on a Linux box as well (we're running Novell eDirectory so I'm pretty flexible about what OS hosts the various partition replicas).)

            So, it's on my todo list but I need to get some other LDAP issues resolved before adding the extra load of secure LDAP into the mix (i.e. encryption adds overhead). This issue in particular is relatively more important for me as it's really beating up my LDAP server.

            http://forums.atlassian.com/thread.jspa?messageID=257226979

            Andrew Miller added a comment - You're correct that that doesn't really apply here....security-related but a separate issue. Regardless, currently I'm kind of fudging on the secure LDAP bit since the server running Confluence and the LDAP server are plugged into the same physical switch in the server room. (I might just look at tunneling it over SSH if LDAP ends up being available on a Linux box as well (we're running Novell eDirectory so I'm pretty flexible about what OS hosts the various partition replicas).) So, it's on my todo list but I need to get some other LDAP issues resolved before adding the extra load of secure LDAP into the mix (i.e. encryption adds overhead). This issue in particular is relatively more important for me as it's really beating up my LDAP server. http://forums.atlassian.com/thread.jspa?messageID=257226979

            AlexH added a comment -

            Andrew and Bernard - thanks. I think I'll be able to use all the work you did here to get something similiar working for my company if we decide to start using Confluence.

            I have a question though... this SSL system you've put together sounds like it works for client->server connections, but what about the server->ldap server connection for the authentication? How are you securing that connection?

            I found this document: http://confluence.atlassian.com/display/JIRA/Connecting+to+SSL+services

            But I'm not clear if it applies here. Could you tell me what you're using to secure the connection between your LDAP server and your confluence install?

            AlexH added a comment - Andrew and Bernard - thanks. I think I'll be able to use all the work you did here to get something similiar working for my company if we decide to start using Confluence. I have a question though... this SSL system you've put together sounds like it works for client->server connections, but what about the server->ldap server connection for the authentication? How are you securing that connection? I found this document: http://confluence.atlassian.com/display/JIRA/Connecting+to+SSL+services But I'm not clear if it applies here. Could you tell me what you're using to secure the connection between your LDAP server and your confluence install?

            Ah.....quite nice. The only thing I don't like is the need to copy in the redirect-to-http.jsp page each time I upgrade....but I'll take that as the price of avoiding the "going back to http" error (since there's really no other way around that)......and I already have to copy a bunch of JARs in each time I upgrade anyway.

            In my case since I don't have Confluence as the root Tomcat application, I had to use.... (mostly posting this for anyone else who might be scratching their head)....

            1. Force non-login pages non-SSL
              RewriteCond % {REQUEST_URI} !^/wiki/redirect-to-http.jsp
              RewriteCond %{REQUEST_URI}

              !^/wiki/login.action
              RewriteCond %

              {REQUEST_URI} !^/wiki/images/
              RewriteCond %{REQUEST_URI}

              !^/wiki/download/userResources/logo
              RewriteCond %

              {REQUEST_URI}

              !\.(css|js)$
              RewriteRule (.*) https://wiki.bju.edu/wiki/redirect-to-http.jsp?redirect-to=http://wiki.bju.edu$1 [R,L]

            Now....I'm not quite sure how Atlassian can really incorporate this solution as it relies on Apache (and the ability to modify your http config) however for our purposes it works wonderfully and should work with any future upgrades as far as I can tell.

            Andrew Miller added a comment - Ah.....quite nice. The only thing I don't like is the need to copy in the redirect-to-http.jsp page each time I upgrade....but I'll take that as the price of avoiding the "going back to http" error (since there's really no other way around that)......and I already have to copy a bunch of JARs in each time I upgrade anyway. In my case since I don't have Confluence as the root Tomcat application, I had to use.... (mostly posting this for anyone else who might be scratching their head).... Force non-login pages non-SSL RewriteCond % {REQUEST_URI} !^/wiki/redirect-to-http.jsp RewriteCond %{REQUEST_URI} !^/wiki/login.action RewriteCond % {REQUEST_URI} !^/wiki/images/ RewriteCond %{REQUEST_URI} !^/wiki/download/userResources/logo RewriteCond % {REQUEST_URI} !\.(css|js)$ RewriteRule (.*) https://wiki.bju.edu/wiki/redirect-to-http.jsp?redirect-to=http://wiki.bju.edu$1 [R,L] Now....I'm not quite sure how Atlassian can really incorporate this solution as it relies on Apache (and the ability to modify your http config) however for our purposes it works wonderfully and should work with any future upgrades as far as I can tell.

            Very nice, I took both solutions and created a bit of a hybrid solution to avoid the browser warning that happens when being redirected from HTTPS to HTTP...

            1) Create a simple redirect-to-http.jsp page.

            <%
              final String redirectURL = request.getParameter("redirect-to");
            %>
            
            <html>
              <head>
                <script language="JavaScript">
                  <!-- window.location.replace("<%= redirectURL %>"); // -->
                </script>
            
                <meta http-equiv="Refresh" content="0; url=<%= redirectURL %>">
              </head>
              <body>
                <a href="<%= redirectURL %>">Please, click here if not automatically redirected within a few seconds...</a>
              </body>
            </html>
            

            2) Instead of redirecting to HTTP, redirect the user to redirect-to-http.jsp, so the redirection can be done with JavaScript, thus avoiding the warning.

            # Force all non-login pages back to non-SSL
            RewriteCond %{REQUEST_URI} !^/redirect-to-http.jsp
            RewriteCond %{REQUEST_URI} !^/login.action
            RewriteCond %{REQUEST_URI} !^/images/
            RewriteCond %{REQUEST_URI} !^/download/userResources/logo
            RewriteCond %{REQUEST_URI} !\.(css|js)$
            RewriteRule (.*) https://myserver.com/redirect-to-http.jsp?redirect-to=http://myserver.com$1 [R,L]
            

            ...I've tested this and it seems to work fine in all scenarios. Now if only JIRA allowed for such a simple solution!

            Bernard Durfee added a comment - Very nice, I took both solutions and created a bit of a hybrid solution to avoid the browser warning that happens when being redirected from HTTPS to HTTP... 1) Create a simple redirect-to-http.jsp page. <% final String redirectURL = request.getParameter( "redirect-to" ); %> <html> <head> <script language= "JavaScript" > <!-- window.location.replace( "<%= redirectURL %>" ); // --> </script> <meta http-equiv= "Refresh" content= "0; url=<%= redirectURL %>" > </head> <body> <a href= "<%= redirectURL %>" >Please, click here if not automatically redirected within a few seconds...</a> </body> </html> 2) Instead of redirecting to HTTP, redirect the user to redirect-to-http.jsp, so the redirection can be done with JavaScript, thus avoiding the warning. # Force all non-login pages back to non-SSL RewriteCond %{REQUEST_URI} !^/redirect-to-http.jsp RewriteCond %{REQUEST_URI} !^/login.action RewriteCond %{REQUEST_URI} !^/images/ RewriteCond %{REQUEST_URI} !^/download/userResources/logo RewriteCond %{REQUEST_URI} !\.(css|js)$ RewriteRule (.*) https: //myserver.com/redirect-to-http.jsp?redirect-to=http://myserver.com$1 [R,L] ...I've tested this and it seems to work fine in all scenarios. Now if only JIRA allowed for such a simple solution!

            Actually....some changes after consulting with a coworker this morning. They were to 1) avoid mixed http & https elements in the same page and 2) help mod_rewrite properly escape characters when redirecting the login page to https (so people get returned to their original http page after logging in). I've only pasted in the changed sections (same comment lines as above so you can match them up).

            ~~~~~~~~~~

            1. Force the login page to ssl
              RewriteCond % {REQUEST_URI} ^/wiki/login.action
              RewriteRule (.*) https://wiki.bju.edu/wiki/login.action [R,L,NE]

              ~~~~~~~~~~

              # Force all non-login pages back to non-SSL
              RewriteCond %{REQUEST_URI}

              !^/wiki/login.action
              RewriteCond %

              {REQUEST_URI} !^/wiki/images/
              RewriteCond %{REQUEST_URI}

              !^/wiki/download/userResources/logo
              RewriteCond %

              {REQUEST_URI}

              !\.(css|js)$
              RewriteRule (.*) http://wiki.bju.edu$1 [R,L]

            Andrew Miller added a comment - Actually....some changes after consulting with a coworker this morning. They were to 1) avoid mixed http & https elements in the same page and 2) help mod_rewrite properly escape characters when redirecting the login page to https (so people get returned to their original http page after logging in). I've only pasted in the changed sections (same comment lines as above so you can match them up). ~~~~~~~~~~ Force the login page to ssl RewriteCond % {REQUEST_URI} ^/wiki/login.action RewriteRule (.*) https://wiki.bju.edu/wiki/login.action [R,L,NE] ~~~~~~~~~~ # Force all non-login pages back to non-SSL RewriteCond %{REQUEST_URI} !^/wiki/login.action RewriteCond % {REQUEST_URI} !^/wiki/images/ RewriteCond %{REQUEST_URI} !^/wiki/download/userResources/logo RewriteCond % {REQUEST_URI} !\.(css|js)$ RewriteRule (.*) http://wiki.bju.edu$1 [R,L]

            Ok.....I don't know why I didn't think of this before.....I can just use mod_rewrite (since we're using Apache's 2 mod_proxy instead of mod_jk....if you're using mod_jk it gets executed before mod_rewrite rules). Even better, I don't have to redo any manual changes to the Confluence files when upgrades come out.

            My Apache config is below with comments (although with the SSL cert stuff left out....that's pretty standard)....don't bother trying to hit http://wiki.bju.edu though. Like all good enterprise wikis should, it lives behind a nice secure firewall.

            ~~~~~~~~

            1. Connect to Tomcat for webaccess
              Listen x.x.x.x:80
              NameVirtualHost x.x.x.x:80

            <VirtualHost x.x.x.x:80>
            ServerName wiki.bju.edu
            ServerAlias wiki

            1. this is what makes the proxy to Tomcat work....Tomcat is living on port 8080 and we have Confluence available at /wiki as we run other apps in Tomcat
              <IfModule mod_proxy.c>
              ProxyPass /wiki http://localhost:8080/wiki
              ProxyPassReverse /wiki http://localhost:8080/wiki
              </IfModule>

            RewriteEngine On

            1. Force FQDN (Fully Qualified Domain Name)
              RewriteCond % {HTTP_HOST}

              !^wiki\.bju\.edu$
              RewriteRule (.*) http://wiki.bju.edu/wiki$1 [R,L]

            1. Add /wiki to the end of the URL if it's not there
              RewriteCond % {REQUEST_URI} !^/wiki
              RewriteRule (.*) http://wiki.bju.edu/wiki$1 [R,L]

              # Force the login page to ssl
              RewriteCond %{REQUEST_URI}

              ^/wiki/login.action
              RewriteRule (.*) https://wiki.bju.edu/wiki/login.action [R,L]

            </VirtualHost>

            <VirtualHost x.x.x.x:443>

            RewriteEngine On

            1. Force all non-login pages back to non-SSL
              RewriteCond % {REQUEST_URI}

              !^/wiki/login.action
              RewriteRule (.*) http://wiki.bju.edu$1 [R,L]

            1. have to have mod_proxy setup here as well for the one login page to work
              <IfModule mod_proxy.c>
              ProxyPass /wiki http://localhost:8080/wiki
              ProxyPassReverse /wiki http://localhost:8080/wiki
              </IfModule>

            <more SSL stuff here>

            </VirtualHost>

            Andrew Miller added a comment - Ok.....I don't know why I didn't think of this before.....I can just use mod_rewrite (since we're using Apache's 2 mod_proxy instead of mod_jk....if you're using mod_jk it gets executed before mod_rewrite rules). Even better, I don't have to redo any manual changes to the Confluence files when upgrades come out. My Apache config is below with comments (although with the SSL cert stuff left out....that's pretty standard)....don't bother trying to hit http://wiki.bju.edu though. Like all good enterprise wikis should, it lives behind a nice secure firewall. ~~~~~~~~ Connect to Tomcat for webaccess Listen x.x.x.x:80 NameVirtualHost x.x.x.x:80 <VirtualHost x.x.x.x:80> ServerName wiki.bju.edu ServerAlias wiki this is what makes the proxy to Tomcat work....Tomcat is living on port 8080 and we have Confluence available at /wiki as we run other apps in Tomcat <IfModule mod_proxy.c> ProxyPass /wiki http://localhost:8080/wiki ProxyPassReverse /wiki http://localhost:8080/wiki </IfModule> RewriteEngine On Force FQDN (Fully Qualified Domain Name) RewriteCond % {HTTP_HOST} !^wiki\.bju\.edu$ RewriteRule (.*) http://wiki.bju.edu/wiki$1 [R,L] Add /wiki to the end of the URL if it's not there RewriteCond % {REQUEST_URI} !^/wiki RewriteRule (.*) http://wiki.bju.edu/wiki$1 [R,L] # Force the login page to ssl RewriteCond %{REQUEST_URI} ^/wiki/login.action RewriteRule (.*) https://wiki.bju.edu/wiki/login.action [R,L] </VirtualHost> <VirtualHost x.x.x.x:443> RewriteEngine On Force all non-login pages back to non-SSL RewriteCond % {REQUEST_URI} !^/wiki/login.action RewriteRule (.*) http://wiki.bju.edu$1 [R,L] have to have mod_proxy setup here as well for the one login page to work <IfModule mod_proxy.c> ProxyPass /wiki http://localhost:8080/wiki ProxyPassReverse /wiki http://localhost:8080/wiki </IfModule> <more SSL stuff here> </VirtualHost>

            Thanks much for posting this....I was able to give it a try this evening.

            Unfortunately, it doesn't seem to work in environments using Apache with mod_proxy in front of Tomcat (the URL's come up pointing to localhost).

            For now, I've just changed the POST line in the login.vm to be hardcoded to https for our server (full URL). That way people I meet the security policy that people are always at least https for authentication. If they come back later and still have the cookie from Confluence, they won't get forced to https.

            Any further thoughts would be welcome of course.

            Andrew Miller added a comment - Thanks much for posting this....I was able to give it a try this evening. Unfortunately, it doesn't seem to work in environments using Apache with mod_proxy in front of Tomcat (the URL's come up pointing to localhost). For now, I've just changed the POST line in the login.vm to be hardcoded to https for our server (full URL). That way people I meet the security policy that people are always at least https for authentication. If they come back later and still have the cookie from Confluence, they won't get forced to https. Any further thoughts would be welcome of course.

            This works better for the redirect-to-http.jsp page...

             
            <% 
              StringBuilder redirectURLBuilder = new StringBuilder("http://"); 
              redirectURLBuilder.append(request.getServerName()).append(request.getContextPath()); 
            
              String redirectURL = redirectURLBuilder.toString(); 
            %> 
            
            <html> 
              <head> 
                <script language="JavaScript"> 
                  <!-- window.location.replace("<%= redirectURL %>"); // --> 
                </script> 
            
                <meta http-equiv="Refresh" content="0; url=<%= redirectURL %>"> 
              </head> 
              <body> 
                <a href="<%= redirectURL %>">Please, click here if not automatically redirected within a few seconds...</a> 
              </body> 
            </html> 
            
            1. Edit login.vm and change the <form> to
               
              <form method="POST" action="https://$req.getServerName()$req.getContextPath()/login.action" name="loginform"> 
              
            2. Change the hidden os_destination input at the bottom to
               
              <input type="hidden" name="os_destination" value="https://$req.getServerName()$req.getContextPath()/redirect-to-http.jsp?os_destination=$!generalUtil.escapeXml($!os_destination)"/> 
              

            Bernard Durfee added a comment - This works better for the redirect-to-http.jsp page... <% StringBuilder redirectURLBuilder = new StringBuilder( "http: //" ); redirectURLBuilder.append(request.getServerName()).append(request.getContextPath()); String redirectURL = redirectURLBuilder.toString(); %> <html> <head> <script language= "JavaScript" > <!-- window.location.replace( "<%= redirectURL %>" ); // --> </script> <meta http-equiv= "Refresh" content= "0; url=<%= redirectURL %>" > </head> <body> <a href= "<%= redirectURL %>" >Please, click here if not automatically redirected within a few seconds...</a> </body> </html> Edit login.vm and change the <form> to <form method= "POST" action= "https: //$req.getServerName()$req.getContextPath()/login.action" name= "loginform" > Change the hidden os_destination input at the bottom to <input type= "hidden" name= "os_destination" value= "https: //$req.getServerName()$req.getContextPath()/redirect-to-http.jsp?os_destination=$!generalUtil.escapeXml($!os_destination)" />

            1. Create a redirect-to-http.jsp page
              <%
                StringBuilder redirectURLBuilder = new StringBuilder("http://");
                redirectURLBuilder.append(request.getServerName()).append(request.getContextPath());
              
                String osDestination = request.getParameter("os_destination");
                if(osDestination != null && osDestination.length() > 0) {
                  redirectURLBuilder.append(osDestination);
                }
              
                String redirectURL = redirectURLBuilder.toString();
              %>
              
              <html>
                <head>
                  <script language="JavaScript">
                    <!-- window.location.replace("<%= redirectURL %>"); // -->
                  </script>
              
                  <meta http-equiv="Refresh" content="0; url=<%= redirectURL %>">
                </head>
                <body>
                  <a href="<%= redirectURL %>">Please, click here if not automatically redirected within a few seconds...</a>
                </body>
              </html>
              
            2. Edit login.vm and change the <form> to
              <form method="POST" action="https://$req.getServerName()$req.getContextPath()/login.action" name="loginform">
              
            3. Change the hidden os_destination input at the bottom to
              <input type="hidden" name="os_destination" value="https://$req.getServerName()$req.getContextPath()/redirect-to-http.jsp?os_destination=$!generalUtil.escapeXml($!os_destination)"/>
              

            Bernard Durfee added a comment - Create a redirect-to-http.jsp page <% StringBuilder redirectURLBuilder = new StringBuilder( "http: //" ); redirectURLBuilder.append(request.getServerName()).append(request.getContextPath()); String osDestination = request.getParameter( "os_destination" ); if (osDestination != null && osDestination.length() > 0) { redirectURLBuilder.append(osDestination); } String redirectURL = redirectURLBuilder.toString(); %> <html> <head> <script language= "JavaScript" > <!-- window.location.replace( "<%= redirectURL %>" ); // --> </script> <meta http-equiv= "Refresh" content= "0; url=<%= redirectURL %>" > </head> <body> <a href= "<%= redirectURL %>" >Please, click here if not automatically redirected within a few seconds...</a> </body> </html> Edit login.vm and change the <form> to <form method= "POST" action= "https: //$req.getServerName()$req.getContextPath()/login.action" name= "loginform" > Change the hidden os_destination input at the bottom to <input type= "hidden" name= "os_destination" value= "https: //$req.getServerName()$req.getContextPath()/redirect-to-http.jsp?os_destination=$!generalUtil.escapeXml($!os_destination)" />

            I spent a while trying to adapt the Jira solution linked above to Confluence without much success (modifying the login.vm as there's no login.jsp in Confluence). Unfortunately, I don't have enough time to pursue it further. If anyone is able to figure out a similar procedure, it would be much appreciated.

            Thanks.

            Andrew Miller added a comment - I spent a while trying to adapt the Jira solution linked above to Confluence without much success (modifying the login.vm as there's no login.jsp in Confluence). Unfortunately, I don't have enough time to pursue it further. If anyone is able to figure out a similar procedure, it would be much appreciated. Thanks.

            JIRA has the same issue, of course. I've implemented HTTPS for just the login page, so username/passwords are always sent over HTTPS, but the rest of the application is sent over HTTP. The solution is Tomcat specific, no Apache involved...

            http://jira.atlassian.com/browse/JRA-7250

            ...it's not perfect, but it does work.

            Bernard Durfee added a comment - JIRA has the same issue, of course. I've implemented HTTPS for just the login page, so username/passwords are always sent over HTTPS, but the rest of the application is sent over HTTP. The solution is Tomcat specific, no Apache involved... http://jira.atlassian.com/browse/JRA-7250 ...it's not perfect, but it does work.

            Yes, that's actually how we handle SSL for all of our Java apps that live in Tomcat. We use mod_proxy in Apache to fetch from Tomcat on localhost on port 8080 and then force Apache to serve everything via https. We've found mod_proxy in Apache 2 to generally work better than mod_jk.

            However, this means that....

            1) we incur the encryption overhead on every page
            2) a lot of caching is disabled client-side since ssl pages/objects aren't cached

            So...we don't need Confluence to really have any kind of SSL support that talks to the app server (Tomcat in this case)....just the ability for it to generate correct URL's for a web server that is already set up with http & https available on the same domain.

            If that's not clear, please feel free to contact me.

            Thanks.

            Andrew Miller added a comment - Yes, that's actually how we handle SSL for all of our Java apps that live in Tomcat. We use mod_proxy in Apache to fetch from Tomcat on localhost on port 8080 and then force Apache to serve everything via https. We've found mod_proxy in Apache 2 to generally work better than mod_jk. However, this means that.... 1) we incur the encryption overhead on every page 2) a lot of caching is disabled client-side since ssl pages/objects aren't cached So...we don't need Confluence to really have any kind of SSL support that talks to the app server (Tomcat in this case)....just the ability for it to generate correct URL's for a web server that is already set up with http & https available on the same domain. If that's not clear, please feel free to contact me. Thanks.

            Sulka Haro added a comment -

            We've setup Confluence requests to go through Apache 2 which then maps all requests to use HTTPS. Apache's HTTPS implementation seems much more efficient than Java's libraries and we're seeing no slowdowns with this approach.

            If you want Confluence to use HTTPS, you can do this by changing the application server configuration. To do this with the standalone application, I think http://tomcat.apache.org/tomcat-4.0-doc/ssl-howto.html is still valid.

            Sulka Haro added a comment - We've setup Confluence requests to go through Apache 2 which then maps all requests to use HTTPS. Apache's HTTPS implementation seems much more efficient than Java's libraries and we're seeing no slowdowns with this approach. If you want Confluence to use HTTPS, you can do this by changing the application server configuration. To do this with the standalone application, I think http://tomcat.apache.org/tomcat-4.0-doc/ssl-howto.html is still valid.

            We have a similar policy due to passwords for all applications being tied back to LDAP (so we can't allow passwords to be sent in the clear). An option as described above would be fantastic (implemented in Moodle for instance...open-source LMS). Otherwise I'll have to force all Confluence pages to be https at the web server (fairly significant overhead).

            Andrew Miller added a comment - We have a similar policy due to passwords for all applications being tied back to LDAP (so we can't allow passwords to be sent in the clear). An option as described above would be fantastic (implemented in Moodle for instance...open-source LMS). Otherwise I'll have to force all Confluence pages to be https at the web server (fairly significant overhead).

              Unassigned Unassigned
              017a8da54598 Michael Corn
              Votes:
              16 Vote for this issue
              Watchers:
              18 Start watching this issue

                Created:
                Updated:
                Resolved: