RES: RES: [java] RE: http-https url rewrite bug TC 5.0.28?
Thanks a lot, Steven... As you guess, in our case we don't have important security requirements (just personalized contents) most of time and the hardware isn't that good...but we don't fell confortable to accept http login. One more point in order to implement you suggestion: .. and automatically logs the user in to the non-secure site without prompting. Could you email a snippet for that? The cookie stuff and interceptor will not be a problem - but I couldn't find out how to get the credential from the https sesssion to auto-authenticate the user the next time. Thanks in advance... Paulo -Mensagem original- De: Steven J.Owens [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 15 de novembro de 2004 23:39 Para: Tomcat Users List Assunto: Re: RES: [java] RE: http-https url rewrite bug TC 5.0.28? On Mon, Nov 15, 2004 at 05:13:21PM -0300, Paulo Alvim wrote: I have a similar problem: I'd like to use https only with the login.jsp page and come back to http after that. Could you explain why it isn't possible? It's not possible because it's not _proper_ from a security perspective, so they built tomcat to not enable it. I can sorta understand why people want to do it, myself, but you should understand that it's not secure, and be very much aware of the risks you're taking. Still, I can understand some of the motivation behind the request, and I think there's a solution. The key is to realize you're trying to solve the wrong problem. See my explanation at the end for what the right problem is, and how to solve it. To illustrate this properly, imagine that your account has two usernames and two passwords that you can use to access it, the permanent username/password and a temporary username/password. When you login, you first have to send the permanent username and first password over the net. At that point, the server then sets your temporary username and second password to some random value, temporarily, and then sends those back to you. The temporary username/password will last until your user session times out, or until you explicitly log out. Your browser then sends a copy of that temporary username and temporary password along with _every_ _single_ _request_ to the server. Just because you make sure the first communication, where you sent the permanent username/password, is secure, doesn't keep somebody from sniffing the temporary username and password and using those to do all sorts of damage to your account during that window of opportunity. To bring this back to reality, the JSESSIONID cookie is the temporary username/password. This explains why it is not secure to use the same session for both HTTP and HTTPS connections. Thinking about it, I can certainly see why people would want some happy medium between the two. SSL consumes resources* and often you're not worried about securing the entire series of user interactions, just a critical subset. For example, you don't need to SSL-protect the user browsing your catalog, but you do need to SSL-protect the payment authorization. (* Last I heard, the SSL server takes up about 40% extra resources, though that info is years old and may be way out of date.) However, the important point is _not_ that you want to share the session data across secure and unsecure apps, but that you want to avoid making the user log in twice. Here's how I'd approach this. You need two distinct sets of security credentials, serious and trivial. The serious credential is necessary for the SSL-protected portion, the trivial credential is necessary for the non-SSL portion. Then, when the user logs in via SSL, it also creates a trivial security credential, and sets that on a _different_ cookie than JSESSIONID. It's been ages since I've worked with cookies, but you can mark a cookie as Secure, meaning it only gets sent back to the secure server, or not. The tomcat SSL-created JSESSIONID is set secure, for example. Here's what one looks like: Set-Cookie: JSESSIONID=202E506FAD4A9ADB5F062DB3A3310E89; Path=/xyzzy; Secure This is further documented at: http://www.ietf.org/rfc/rfc2109.txt However, you can also set a second cookie, _without_ the secure option, from the SSL response. The browser will then include that cookie value in further requests to the non-secure site at the same domain. You would have to customize the non-secure site's security so that it checks for this cookie and automatically logs the user in to the non-secure site without prompting. One thing you'll have to watch out for is the timeout of the SSL session, since it might get left alone for many hours. You have two choices there: 1) either include an SSL-protected icon on every page, which will keep your SSL session from timing out. This can have some slight complications, since most browsers use some visual cue to indicated SSL traffic. 2) or just set the SSL app's session timeout
http-https url rewrite bug TC 5.0.28?
I'm not sure if this is a bug or a misunderstaning on my part - and I've
been searching the archives and googling for most of the day without
success...
I've got a problem where URL rewriting is failing to correctly encode
the URL when switching from an insecure (non-ssl) connection to a secure
ssl connection FOR THE SAME DOMAIN and where the session already exists
for the insecure connection and COOKIES ARE DISABLED in the browser. I
can reproduce this behaviour with different browsers.
An action servlet receives the non-ssl request and redirects to
another secure action servlet. The call for the redirect should encode
the URL as follows in the first servlet's service(request, response) method:
[snip]
if (gotoCheckout)
{
//goto the checkout
//this generates the URL
//https://www.mytestsite.com/CheckoutAction?action=start
String url = CheckoutAction.getCheckoutActionStartURL(request);
//make sure the JSESSIONID is appended for non-cookie browsers
url = response.encodeRedirectURL(url);
response.sendRedirect(url);
return;
}
[snip]
Looking at the headers, you can see that the JSESSIONID is not appended
to the redirect URL when the protocol switches from http to https:
REQUEST
===
POST
http://www.mytestsite.com/BasketAction;jsessionid=9E490ADF8FB268E3F6BC5FA2FD61E8CF
HTTP/1.1
Host: www.mytestsite.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a)
Gecko/20030728 Mozilla Firebird/0.6.1
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer:
http://www.mytestsite.com/basket;jsessionid=9E490ADF8FB268E3F6BC5FA2FD61E8CF
Content-Type: application/x-www-form-urlencoded
Content-Length: 66
ret=%2Fimage%2F6503740500223action=updbutaction=checkoutqty_0=1
RESPONSE
HTTP/1.x 302 Moved Temporarily
Date: Mon, 15 Nov 2004 13:38:23 GMT
Server: Apache/1.3.29
Location: https://www.mytestsite.com/CheckoutAction?action=start
Content-Length: 0
Content-Type: text/plain
Connection: close
Setup
Apache 1.3.29 + mod_ssl + mod_jk + tomcat 5.0.28 (unix)
Apache is configured with two virtual directives; one for port 80 and
one for post 443 and the requests are forwarded by mod_jk to tomcat
which has the following in its server.xml config:
[snip]
Host name=www.mytestsite.com appBase=/ef02/tc/www.mytestsite.com
Context path= docBase=ROOT debug=0 reloadable=false
ResourceLink name=jdbc/D1DB global=jdbc/D1DB
type=javax.sql.DataSource/
/Context
/Host
[snip]
Tomcat possibly nevers sees that the request is secure because the SSL
part of the transaction is handled by mod_SSL, and I don't know if this
has a bearing on the issue?
My question, should the JSESSIONID be appended in the encoded redirect -
I think so?
And if it should, am I doing something wrong. Or is there a bug?
If there is a bug, should I manually append the ;jsessionid=xxx to
the URL to workaround the problem.
Can anyone shed any light on this?
Many thanks
John Sidney-Woollett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: http-https url rewrite bug TC 5.0.28?
I should have mentioned that the problem I'm seeing is causing a new
session to be created after the redirect when in fact I want the
original session data prior to the redirect...
John Sidney-Woollett
John Sidney-Woollett wrote:
I'm not sure if this is a bug or a misunderstaning on my part - and I've
been searching the archives and googling for most of the day without
success...
I've got a problem where URL rewriting is failing to correctly encode
the URL when switching from an insecure (non-ssl) connection to a secure
ssl connection FOR THE SAME DOMAIN and where the session already exists
for the insecure connection and COOKIES ARE DISABLED in the browser. I
can reproduce this behaviour with different browsers.
An action servlet receives the non-ssl request and redirects to
another secure action servlet. The call for the redirect should encode
the URL as follows in the first servlet's service(request, response)
method:
[snip]
if (gotoCheckout)
{
//goto the checkout
//this generates the URL
//https://www.mytestsite.com/CheckoutAction?action=start
String url = CheckoutAction.getCheckoutActionStartURL(request);
//make sure the JSESSIONID is appended for non-cookie browsers
url = response.encodeRedirectURL(url);
response.sendRedirect(url);
return;
}
[snip]
Looking at the headers, you can see that the JSESSIONID is not appended
to the redirect URL when the protocol switches from http to https:
REQUEST
===
POST
http://www.mytestsite.com/BasketAction;jsessionid=9E490ADF8FB268E3F6BC5FA2FD61E8CF
HTTP/1.1
Host: www.mytestsite.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a)
Gecko/20030728 Mozilla Firebird/0.6.1
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer:
http://www.mytestsite.com/basket;jsessionid=9E490ADF8FB268E3F6BC5FA2FD61E8CF
Content-Type: application/x-www-form-urlencoded
Content-Length: 66
ret=%2Fimage%2F6503740500223action=updbutaction=checkoutqty_0=1
RESPONSE
HTTP/1.x 302 Moved Temporarily
Date: Mon, 15 Nov 2004 13:38:23 GMT
Server: Apache/1.3.29
Location: https://www.mytestsite.com/CheckoutAction?action=start
Content-Length: 0
Content-Type: text/plain
Connection: close
Setup
Apache 1.3.29 + mod_ssl + mod_jk + tomcat 5.0.28 (unix)
Apache is configured with two virtual directives; one for port 80 and
one for post 443 and the requests are forwarded by mod_jk to tomcat
which has the following in its server.xml config:
[snip]
Host name=www.mytestsite.com appBase=/ef02/tc/www.mytestsite.com
Context path= docBase=ROOT debug=0 reloadable=false
ResourceLink name=jdbc/D1DB global=jdbc/D1DB
type=javax.sql.DataSource/
/Context
/Host
[snip]
Tomcat possibly nevers sees that the request is secure because the SSL
part of the transaction is handled by mod_SSL, and I don't know if this
has a bearing on the issue?
My question, should the JSESSIONID be appended in the encoded redirect -
I think so?
And if it should, am I doing something wrong. Or is there a bug?
If there is a bug, should I manually append the ;jsessionid=xxx to
the URL to workaround the problem.
Can anyone shed any light on this?
Many thanks
John Sidney-Woollett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: http-https url rewrite bug TC 5.0.28?
Hi,
Not a bug. You can't share a session that way, whether using cookies or
URL-rewriting.
Yoav Shapira http://www.yoavshapira.com
-Original Message-
From: John Sidney-Woollett [mailto:[EMAIL PROTECTED]
Sent: Monday, November 15, 2004 10:21 AM
To: [EMAIL PROTECTED]
Subject: http-https url rewrite bug TC 5.0.28?
I'm not sure if this is a bug or a misunderstaning on my part - and
I've
been searching the archives and googling for most of the day without
success...
I've got a problem where URL rewriting is failing to correctly encode
the URL when switching from an insecure (non-ssl) connection to a
secure
ssl connection FOR THE SAME DOMAIN and where the session already exists
for the insecure connection and COOKIES ARE DISABLED in the browser. I
can reproduce this behaviour with different browsers.
An action servlet receives the non-ssl request and redirects to
another secure action servlet. The call for the redirect should
encode
the URL as follows in the first servlet's service(request, response)
method:
[snip]
if (gotoCheckout)
{
//goto the checkout
//this generates the URL
//https://www.mytestsite.com/CheckoutAction?action=start
String url = CheckoutAction.getCheckoutActionStartURL(request);
//make sure the JSESSIONID is appended for non-cookie browsers
url = response.encodeRedirectURL(url);
response.sendRedirect(url);
return;
}
[snip]
Looking at the headers, you can see that the JSESSIONID is not appended
to the redirect URL when the protocol switches from http to https:
REQUEST
===
POST
http://www.mytestsite.com/BasketAction;jsessionid=9E490ADF8FB268E3F6BC5
FA2F
D61E8CF
HTTP/1.1
Host: www.mytestsite.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a)
Gecko/20030728 Mozilla Firebird/0.6.1
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/pla
in;q
=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer:
http://www.mytestsite.com/basket;jsessionid=9E490ADF8FB268E3F6BC5FA2FD6
1E8C
F
Content-Type: application/x-www-form-urlencoded
Content-Length: 66
ret=%2Fimage%2F6503740500223action=updbutaction=checkoutqty_0=1
RESPONSE
HTTP/1.x 302 Moved Temporarily
Date: Mon, 15 Nov 2004 13:38:23 GMT
Server: Apache/1.3.29
Location: https://www.mytestsite.com/CheckoutAction?action=start
Content-Length: 0
Content-Type: text/plain
Connection: close
Setup
Apache 1.3.29 + mod_ssl + mod_jk + tomcat 5.0.28 (unix)
Apache is configured with two virtual directives; one for port 80 and
one for post 443 and the requests are forwarded by mod_jk to tomcat
which has the following in its server.xml config:
[snip]
Host name=www.mytestsite.com appBase=/ef02/tc/www.mytestsite.com
Context path= docBase=ROOT debug=0 reloadable=false
ResourceLink name=jdbc/D1DB global=jdbc/D1DB
type=javax.sql.DataSource/
/Context
/Host
[snip]
Tomcat possibly nevers sees that the request is secure because the
SSL
part of the transaction is handled by mod_SSL, and I don't know if this
has a bearing on the issue?
My question, should the JSESSIONID be appended in the encoded redirect
-
I think so?
And if it should, am I doing something wrong. Or is there a bug?
If there is a bug, should I manually append the ;jsessionid=xxx
to
the URL to workaround the problem.
Can anyone shed any light on this?
Many thanks
John Sidney-Woollett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged. This e-mail is intended only for the individual(s) to whom
it is addressed, and may not be saved, copied, printed, disclosed or used by
anyone else. If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender. Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: http-https url rewrite bug TC 5.0.28?
Yoav Either you're wrong or Tomcat 5.0.x may be broken... With cookies enabled you can transfer the session from a non-secure connection to a secure connection for the same domain/webapp. Tomcat does NOT generate a new (secure) session. The problem is that TC 5.0.28 does not exhibit the same behaviour when cookies are disabled. In this case, Tomcat does in fact generate a new (secure) session. So what we have here appears to be non-consistant behaviour from Tomcat based on client behaviour beyond the control of the web app developer... :( And all because response.encodeRedirectURL(url) did not append the jsessionid to the URL when switching protocols. If encodeRedirectURL appended the session id, then you would have consistant behaviour from Tomcat. Now it could be that using response.encodeRedirectURL(url) is not the correct way to pass the session from an http to https connection. And in fact the only way to guarantee that the non-secure session data is passed to the secure connection is using the following hack: url = url + ;jsessionid= + session.getId() when cookies are disabled. My personal preference is to create a new static method which takes the current request and the new request URL and generates a correctly rewritten URL (based on the fact that I want the non-secure session passed to the secure pages). And to use that whereever I have been using response.encodeRedirectURL(url) and response.encodeURL(url) I still that Tomcat is broken/inconsistant on this point... Any other thoughts or solutions, anyone? John Sidney-Woollett Yoav Shapira wrote: Hi, Not a bug. You can't share a session that way, whether using cookies or URL-rewriting. Yoav Shapira http://www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http-https url rewrite bug TC 5.0.28?
Tomcat still seems broken to me because it does in fact share the
session from a non-secure connection to a secure connection when cookies
are enabled, but not when they are not.
But you've given me some inkling as to what is going on.
I can't believe that there isn't a standard solution for dealing with
this issue.
ie, non-ssl when adding things to your basket, switch to SSL going
through the checkout stages, then back to non-ssl after completing the
order.
Thanks for the extra info.
John
Scott Ahten wrote:
To clarify Yoav's response, this is not a bug but by design.
Tomcat does not allow session data to be shared between secure and
non-secure pages. This is to prevent someone from gaining access to
session data that was submitted via a secure page by using a non-SSL
URL and the user's session id, observed during the initial unencrypted
connection.
You will need to either collect all necessary information via SSL or
persist data from the non-secure session (database, serialization,
etc.) for retrieval by the secure session when you make the switch.
- Scott
On Nov 15, 2004, at 10:24 AM, Shapira, Yoav wrote:
Hi,
Not a bug. You can't share a session that way, whether using cookies or
URL-rewriting.
Yoav Shapira http://www.yoavshapira.com
-Original Message-
From: John Sidney-Woollett [mailto:[EMAIL PROTECTED]
Sent: Monday, November 15, 2004 10:21 AM
To: [EMAIL PROTECTED]
Subject: http-https url rewrite bug TC 5.0.28?
I'm not sure if this is a bug or a misunderstaning on my part - and
I've
been searching the archives and googling for most of the day without
success...
I've got a problem where URL rewriting is failing to correctly encode
the URL when switching from an insecure (non-ssl) connection to a
secure
ssl connection FOR THE SAME DOMAIN and where the session already exists
for the insecure connection and COOKIES ARE DISABLED in the browser. I
can reproduce this behaviour with different browsers.
An action servlet receives the non-ssl request and redirects to
another secure action servlet. The call for the redirect should
encode
the URL as follows in the first servlet's service(request, response)
method:
[snip]
if (gotoCheckout)
{
//goto the checkout
//this generates the URL
//https://www.mytestsite.com/CheckoutAction?action=start
String url = CheckoutAction.getCheckoutActionStartURL(request);
//make sure the JSESSIONID is appended for non-cookie browsers
url = response.encodeRedirectURL(url);
response.sendRedirect(url);
return;
}
[snip]
Looking at the headers, you can see that the JSESSIONID is not appended
to the redirect URL when the protocol switches from http to https:
REQUEST
===
POST
http://www.mytestsite.com/BasketAction; jsessionid=9E490ADF8FB268E3F6BC5
FA2F
D61E8CF
HTTP/1.1
Host: www.mytestsite.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a)
Gecko/20030728 Mozilla Firebird/0.6.1
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/ pla
in;q
=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer:
http://www.mytestsite.com/basket; jsessionid=9E490ADF8FB268E3F6BC5FA2FD6
1E8C
F
Content-Type: application/x-www-form-urlencoded
Content-Length: 66
ret=%2Fimage%2F6503740500223action=updbutaction=checkoutqty_0=1
RESPONSE
HTTP/1.x 302 Moved Temporarily
Date: Mon, 15 Nov 2004 13:38:23 GMT
Server: Apache/1.3.29
Location: https://www.mytestsite.com/CheckoutAction?action=start
Content-Length: 0
Content-Type: text/plain
Connection: close
Setup
Apache 1.3.29 + mod_ssl + mod_jk + tomcat 5.0.28 (unix)
Apache is configured with two virtual directives; one for port 80 and
one for post 443 and the requests are forwarded by mod_jk to tomcat
which has the following in its server.xml config:
[snip]
Host name=www.mytestsite.com appBase=/ef02/tc/www.mytestsite.com
Context path= docBase=ROOT debug=0 reloadable=false
ResourceLink name=jdbc/D1DB global=jdbc/D1DB
type=javax.sql.DataSource/
/Context
/Host
[snip]
Tomcat possibly nevers sees that the request is secure because the
SSL
part of the transaction is handled by mod_SSL, and I don't know if this
has a bearing on the issue?
My question, should the JSESSIONID be appended in the encoded redirect
-
I think so?
And if it should, am I doing something wrong. Or is there a bug?
If there is a bug, should I manually append the ;jsessionid=xxx
to
the URL to workaround the problem.
Can anyone shed any light on this?
Many thanks
John Sidney-Woollett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential,
proprietary and/or privileged
RES: [java] RE: http-https url rewrite bug TC 5.0.28?
Hi Yoav,
I have a similar problem: I'd like to use https only with the login.jsp page
and come back to http after that. Could you explain why it isn't possible?
-Mensagem original-
De: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Enviada em: segunda-feira, 15 de novembro de 2004 12:24
Para: Tomcat Users List
Assunto: [java] RE: http-https url rewrite bug TC 5.0.28?
Hi,
Not a bug. You can't share a session that way, whether using cookies or
URL-rewriting.
Yoav Shapira http://www.yoavshapira.com
-Original Message-
From: John Sidney-Woollett [mailto:[EMAIL PROTECTED]
Sent: Monday, November 15, 2004 10:21 AM
To: [EMAIL PROTECTED]
Subject: http-https url rewrite bug TC 5.0.28?
I'm not sure if this is a bug or a misunderstaning on my part - and
I've
been searching the archives and googling for most of the day without
success...
I've got a problem where URL rewriting is failing to correctly encode
the URL when switching from an insecure (non-ssl) connection to a
secure
ssl connection FOR THE SAME DOMAIN and where the session already exists
for the insecure connection and COOKIES ARE DISABLED in the browser. I
can reproduce this behaviour with different browsers.
An action servlet receives the non-ssl request and redirects to
another secure action servlet. The call for the redirect should
encode
the URL as follows in the first servlet's service(request, response)
method:
[snip]
if (gotoCheckout)
{
//goto the checkout
//this generates the URL
//https://www.mytestsite.com/CheckoutAction?action=start
String url = CheckoutAction.getCheckoutActionStartURL(request);
//make sure the JSESSIONID is appended for non-cookie browsers
url = response.encodeRedirectURL(url);
response.sendRedirect(url);
return;
}
[snip]
Looking at the headers, you can see that the JSESSIONID is not appended
to the redirect URL when the protocol switches from http to https:
REQUEST
===
POST
http://www.mytestsite.com/BasketAction;jsessionid=9E490ADF8FB268E3F6BC5
FA2F
D61E8CF
HTTP/1.1
Host: www.mytestsite.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a)
Gecko/20030728 Mozilla Firebird/0.6.1
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/pla
in;q
=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer:
http://www.mytestsite.com/basket;jsessionid=9E490ADF8FB268E3F6BC5FA2FD6
1E8C
F
Content-Type: application/x-www-form-urlencoded
Content-Length: 66
ret=%2Fimage%2F6503740500223action=updbutaction=checkoutqty_0=1
RESPONSE
HTTP/1.x 302 Moved Temporarily
Date: Mon, 15 Nov 2004 13:38:23 GMT
Server: Apache/1.3.29
Location: https://www.mytestsite.com/CheckoutAction?action=start
Content-Length: 0
Content-Type: text/plain
Connection: close
Setup
Apache 1.3.29 + mod_ssl + mod_jk + tomcat 5.0.28 (unix)
Apache is configured with two virtual directives; one for port 80 and
one for post 443 and the requests are forwarded by mod_jk to tomcat
which has the following in its server.xml config:
[snip]
Host name=www.mytestsite.com appBase=/ef02/tc/www.mytestsite.com
Context path= docBase=ROOT debug=0 reloadable=false
ResourceLink name=jdbc/D1DB global=jdbc/D1DB
type=javax.sql.DataSource/
/Context
/Host
[snip]
Tomcat possibly nevers sees that the request is secure because the
SSL
part of the transaction is handled by mod_SSL, and I don't know if this
has a bearing on the issue?
My question, should the JSESSIONID be appended in the encoded redirect
-
I think so?
And if it should, am I doing something wrong. Or is there a bug?
If there is a bug, should I manually append the ;jsessionid=xxx
to
the URL to workaround the problem.
Can anyone shed any light on this?
Many thanks
John Sidney-Woollett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged. This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else. If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender. Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [java] RE: http-https url rewrite bug TC 5.0.28?
Hi,
Someone else already explained it well. It's not impossible, you can do
it with a bit of coding. But the container can't do that bit of coding
for you as it's a security risk.
Yoav Shapira http://www.yoavshapira.com
-Original Message-
From: Paulo Alvim [mailto:[EMAIL PROTECTED]
Sent: Monday, November 15, 2004 3:13 PM
To: Tomcat Users List
Subject: RES: [java] RE: http-https url rewrite bug TC 5.0.28?
Hi Yoav,
I have a similar problem: I'd like to use https only with the login.jsp
page
and come back to http after that. Could you explain why it isn't
possible?
-Mensagem original-
De: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Enviada em: segunda-feira, 15 de novembro de 2004 12:24
Para: Tomcat Users List
Assunto: [java] RE: http-https url rewrite bug TC 5.0.28?
Hi,
Not a bug. You can't share a session that way, whether using cookies
or
URL-rewriting.
Yoav Shapira http://www.yoavshapira.com
-Original Message-
From: John Sidney-Woollett [mailto:[EMAIL PROTECTED]
Sent: Monday, November 15, 2004 10:21 AM
To: [EMAIL PROTECTED]
Subject: http-https url rewrite bug TC 5.0.28?
I'm not sure if this is a bug or a misunderstaning on my part - and
I've
been searching the archives and googling for most of the day without
success...
I've got a problem where URL rewriting is failing to correctly encode
the URL when switching from an insecure (non-ssl) connection to a
secure
ssl connection FOR THE SAME DOMAIN and where the session already
exists
for the insecure connection and COOKIES ARE DISABLED in the browser. I
can reproduce this behaviour with different browsers.
An action servlet receives the non-ssl request and redirects to
another secure action servlet. The call for the redirect should
encode
the URL as follows in the first servlet's service(request, response)
method:
[snip]
if (gotoCheckout)
{
//goto the checkout
//this generates the URL
//https://www.mytestsite.com/CheckoutAction?action=start
String url = CheckoutAction.getCheckoutActionStartURL(request);
//make sure the JSESSIONID is appended for non-cookie browsers
url = response.encodeRedirectURL(url);
response.sendRedirect(url);
return;
}
[snip]
Looking at the headers, you can see that the JSESSIONID is not
appended
to the redirect URL when the protocol switches from http to https:
REQUEST
===
POST
http://www.mytestsite.com/BasketAction;jsessionid=9E490ADF8FB268E3F6BC
5
FA2F
D61E8CF
HTTP/1.1
Host: www.mytestsite.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a)
Gecko/20030728 Mozilla Firebird/0.6.1
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/pl
a
in;q
=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer:
http://www.mytestsite.com/basket;jsessionid=9E490ADF8FB268E3F6BC5FA2FD
6
1E8C
F
Content-Type: application/x-www-form-urlencoded
Content-Length: 66
ret=%2Fimage%2F6503740500223action=updbutaction=checkoutqty_0=1
RESPONSE
HTTP/1.x 302 Moved Temporarily
Date: Mon, 15 Nov 2004 13:38:23 GMT
Server: Apache/1.3.29
Location: https://www.mytestsite.com/CheckoutAction?action=start
Content-Length: 0
Content-Type: text/plain
Connection: close
Setup
Apache 1.3.29 + mod_ssl + mod_jk + tomcat 5.0.28 (unix)
Apache is configured with two virtual directives; one for port 80 and
one for post 443 and the requests are forwarded by mod_jk to tomcat
which has the following in its server.xml config:
[snip]
Host name=www.mytestsite.com appBase=/ef02/tc/www.mytestsite.com
Context path= docBase=ROOT debug=0 reloadable=false
ResourceLink name=jdbc/D1DB global=jdbc/D1DB
type=javax.sql.DataSource/
/Context
/Host
[snip]
Tomcat possibly nevers sees that the request is secure because the
SSL
part of the transaction is handled by mod_SSL, and I don't know if
this
has a bearing on the issue?
My question, should the JSESSIONID be appended in the encoded redirect
-
I think so?
And if it should, am I doing something wrong. Or is there a bug?
If there is a bug, should I manually append the ;jsessionid=xxx
to
the URL to workaround the problem.
Can anyone shed any light on this?
Many thanks
John Sidney-Woollett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential,
proprietary
and/or privileged. This e-mail is intended only for the individual(s)
to
whom it is addressed, and may not be saved, copied, printed, disclosed
or
used by anyone else. If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender. Thank you
Re: RES: [java] RE: http-https url rewrite bug TC 5.0.28?
On Mon, Nov 15, 2004 at 05:13:21PM -0300, Paulo Alvim wrote: I have a similar problem: I'd like to use https only with the login.jsp page and come back to http after that. Could you explain why it isn't possible? It's not possible because it's not _proper_ from a security perspective, so they built tomcat to not enable it. I can sorta understand why people want to do it, myself, but you should understand that it's not secure, and be very much aware of the risks you're taking. Still, I can understand some of the motivation behind the request, and I think there's a solution. The key is to realize you're trying to solve the wrong problem. See my explanation at the end for what the right problem is, and how to solve it. To illustrate this properly, imagine that your account has two usernames and two passwords that you can use to access it, the permanent username/password and a temporary username/password. When you login, you first have to send the permanent username and first password over the net. At that point, the server then sets your temporary username and second password to some random value, temporarily, and then sends those back to you. The temporary username/password will last until your user session times out, or until you explicitly log out. Your browser then sends a copy of that temporary username and temporary password along with _every_ _single_ _request_ to the server. Just because you make sure the first communication, where you sent the permanent username/password, is secure, doesn't keep somebody from sniffing the temporary username and password and using those to do all sorts of damage to your account during that window of opportunity. To bring this back to reality, the JSESSIONID cookie is the temporary username/password. This explains why it is not secure to use the same session for both HTTP and HTTPS connections. Thinking about it, I can certainly see why people would want some happy medium between the two. SSL consumes resources* and often you're not worried about securing the entire series of user interactions, just a critical subset. For example, you don't need to SSL-protect the user browsing your catalog, but you do need to SSL-protect the payment authorization. (* Last I heard, the SSL server takes up about 40% extra resources, though that info is years old and may be way out of date.) However, the important point is _not_ that you want to share the session data across secure and unsecure apps, but that you want to avoid making the user log in twice. Here's how I'd approach this. You need two distinct sets of security credentials, serious and trivial. The serious credential is necessary for the SSL-protected portion, the trivial credential is necessary for the non-SSL portion. Then, when the user logs in via SSL, it also creates a trivial security credential, and sets that on a _different_ cookie than JSESSIONID. It's been ages since I've worked with cookies, but you can mark a cookie as Secure, meaning it only gets sent back to the secure server, or not. The tomcat SSL-created JSESSIONID is set secure, for example. Here's what one looks like: Set-Cookie: JSESSIONID=202E506FAD4A9ADB5F062DB3A3310E89; Path=/xyzzy; Secure This is further documented at: http://www.ietf.org/rfc/rfc2109.txt However, you can also set a second cookie, _without_ the secure option, from the SSL response. The browser will then include that cookie value in further requests to the non-secure site at the same domain. You would have to customize the non-secure site's security so that it checks for this cookie and automatically logs the user in to the non-secure site without prompting. One thing you'll have to watch out for is the timeout of the SSL session, since it might get left alone for many hours. You have two choices there: 1) either include an SSL-protected icon on every page, which will keep your SSL session from timing out. This can have some slight complications, since most browsers use some visual cue to indicated SSL traffic. 2) or just set the SSL app's session timeout to a fairly long time. -- Steven J. Owens [EMAIL PROTECTED] I'm going to make broad, sweeping generalizations and strong, declarative statements, because otherwise I'll be here all night and this document will be four times longer and much less fun to read. Take it all with a grain of salt. - http://darksleep.com/notablog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
