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
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: 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]
