-
Bug
-
Resolution: Won't Fix
-
Low
-
None
-
3.0.2, 3.1
-
None
If you setup the urlrewrite.xml like so:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 2.6//EN" "http://tuckey.org/res/dtds/urlrewrite2.6.dtd">
<urlrewrite>
<!-- For image references in CSS files -->
<rule>
<from>^/s/(.*)/_/download/images/([^\?]*).*</from>
<run class="com.atlassian.plugin.servlet.ResourceDownloadUtils" method="addPublicCachingHeaders" />
<to type="forward">/images/$2</to>
</rule>
<rule>
<from>^/s/(.*)/_/([^\?]*).*</from>
<run class="com.atlassian.plugin.servlet.ResourceDownloadUtils" method="addPublicCachingHeaders" />
<to type="forward">/$2</to>
</rule>
<rule>
<from>^/login.action</from>
<condition type="scheme" operator="notequal">https</condition>
<to type="redirect">https://localhost:8443/login.action</to>
</rule>
<rule>
<from>^/dologin.action</from>
<condition type="scheme" operator="notequal">https</condition>
<to type="redirect">https://localhost:8443/dologin.action</to>
</rule>
<rule>
<from>^/(.*)</from>
<condition type="scheme" operator="equal">https</condition>
<condition type="request-uri" operator="notequal">/login.action.*</condition>
<condition type="request-uri" operator="notequal">/dologin.action.*</condition>
<condition type="request-uri" operator="notequal">/s/.*</condition>
<to type="redirect">http://localhost:8080/$1</to>
</rule>
</urlrewrite>
You are continually redirected to the login page.
It appears when redirecting https://localhost:8443/homepage.action to http://localhost:8080/homepage.action the session is invalidated.
Atlassian Status
All,
We have discussed the use of "HTTPS for login only" in a lot of detail. After looking at the various options, we have concluded that we will not be supporting this configuration in Confluence.
Although this configuration used to work in the past, in Confluence 3.0.2 we implemented a security improvement that helped prevent session fixation attacks (CONF-15108). The implications of this security feature meant that customers could no longer use HTTPS for login only. We did look at enabling this configuration again and concluded that we won't be doing so. There are several reasons for this. Many of these reasons have already been discussed in this post and the related issue (CONF-4116).
The main customer feedback we have received on this issue primarily revolves around the use case of customers who wish to protect their LDAP credentials, but aren't as concerned about session hijacking. Unfortunately, this is a misconception of the security provided by using HTTPS for login only. If the "remember me" functionality is used - it is possible that anyone can intercept network traffic (after login) and can decrypt the users credentials. This is due to the way that the "remember me" functionality works.
It is due to this and all the additional reasons around the support of HTTPS for login only that we will not be implementing this feature.
We will continue work with you in making sure that the configuration you have setup is as secure as possible. Please don't hesitate to contact our support team for assistance in this matter.
Sherif
Confluence Product Manager
- is caused by
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
- is related to
-
CONFSERVER-4116 Support SSL for login and optional SSL for remainder of application
- Closed
[CONFSERVER-18120] Unable to use HTTPS for login only
This is the cause of the observed behaviour:
In order to prevent Session fixation attacks CONF-15108 introduced functionality that creates a new session when the user tries to login.
Using the urlrewrite based "HTTPS for login only" pattern this happens in a secure context.
The session cookie that is created in this context contains the "Secure" attribute (this is at least true for Tomcat 5 and 6, I haven't checked other servlet containers).
From RFC 2965:
When it sends a "secure"
cookie back to a server, the user agent SHOULD use no less than
the same level of security as was used when it received the cookie
from the server.
This prevents the browser from sending back the cookie with the session id that was used to authenticate the user when a non secure (http only) context is used for subsequent requests.
So this is what happens:
- User tries to login
- The urlrewrite mechanism ensures that the login and dologin action can only be requested using https
- The user submits the login credentials
- The session fixation mechanism creates a new session and the response contains a "Set-Cookie" header with a "Secure" attribute and the new session id.
- At this stage (if the user entered valid credentials) the user is authenticated and this is recored against a session for which a new session cookie was created.
- After the login attempt the user gets redirected to the homepage.action (still using https)
- Now the urlrewrite mechanism kicks in and creates another redirect to the homepage.action using http (not https).
- Because the cookie contains the "Secure" attribute the browser does not send back the newly created session id against which the user was authenticated.
- The user can not be recognized as authenticated and is redirected to the login form.
We also need this fix very much due to security and performance reasons. Will it hasten solving this issue if I duplicate it in Altassian Support with high priority?
Ubisoft (Inactive)
added a comment - Hi Atlassian,
Were waiting for this fix before updating our Confluence Instance 
Ubisoft Montréal
Ubisoft (Inactive)
added a comment - Hi Atlassian,
Were waiting for this fix before updating our Confluence Instance
Ubisoft Montréal Is there a bug fix coming out soon for this or an alternative way to login securely? We have +2000 users login in so we can't enable ssl for the entire session because its too CPU intensive. We can't allow clear text login because these are Active Directory account. We can't proceed with our upgrade because of this issue.
Rami Darwish
added a comment - - edited Is there a bug fix coming out soon for this or an alternative way to login securely? We have +2000 users login in so we can't enable ssl for the entire session because its too CPU intensive. We can't allow clear text login because these are Active Directory account. We can't proceed with our upgrade because of this issue. 
Giles Gaskell [Atlassian]
added a comment - Updated both the Confluence 3.0 and 3.1 documentation with the updated urlrewrite.xml code.
Giles Gaskell [Atlassian]
added a comment - Updated both the Confluence 3.0 and 3.1 documentation with the updated urlrewrite.xml code. http://confluence.atlassian.com/pages/viewpage.action?pageId=158106208 These docs are wrong.
All,
We have discussed the use of "HTTPS for login only" in a lot of detail. After looking at the various options, we have concluded that we will not be supporting this configuration in Confluence.
Although this configuration used to work in the past, in Confluence 3.0.2 we implemented a security improvement that helped prevent session fixation attacks (
CONF-15108). The implications of this security feature meant that customers could no longer use HTTPS for login only. We did look at enabling this configuration again and concluded that we won't be doing so. There are several reasons for this. Many of these reasons have already been discussed in this post and the related issue (CONF-4116).The main customer feedback we have received on this issue primarily revolves around the use case of customers who wish to protect their LDAP credentials, but aren't as concerned about session hijacking. Unfortunately, this is a misconception of the security provided by using HTTPS for login only. If the "remember me" functionality is used - it is possible that anyone can intercept network traffic (after login) and can decrypt the users credentials. This is due to the way that the "remember me" functionality works.
It is due to this and all the additional reasons around the support of HTTPS for login only that we will not be implementing this feature.
We will continue work with you in making sure that the configuration you have setup is as secure as possible. Please don't hesitate to contact our support team for assistance in this matter.