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 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
