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>

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?

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.

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.

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

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.