"Christopher Schultz" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dave,
>
> Dave wrote:
> |   I moved the <user-data-constraint> inside the
> <web-resource-collection> as the following:
> |
> |        <security-constraint>
> |                 <web-resource-collection>
> |                         <web-resource-name>Automatic SLL
> Forwarding</web-resource-name>
> |                         <url-pattern>/login.html</url-pattern>
> |                         <user-data-constraint>
> |
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> |                         </user-data-constraint>
> |                 </web-resource-collection>
> |         </security-constraint>
> |
> |   But http://www.mydomain.com/login.html  did not redirect to secure 
> URL.
>
> :(
>
> It's possible that Tomcat ignores that setting during its own
> authentication process (which would suck if it were the case). What the
> the URL say when you are being asked to login?
>

Well, the first problem is that the <user-data-constraint> has to come after 
the </web-resource-collection> according to the spec.  If you nest it in the 
<web-resource-collection>, Tomcat will quietly ignore it (there are enough 
xml validators for you to check your web.xml syntax).

However, this won't work at all in Tomcat if you are using Container auth. 
The reason is that Tomcat (at least 5.5 and higher) does a forward to the 
login page, not a redirect.  As a result, Tomcat never checks the security 
permissions for the /login.html URL.

> | As you mentioned, If I start as http, then redirect to https when
> | login, and keep https after login. Does that mean https is using the
> | http session?
>
> Well, it's not a "http session" per-se... it's the session that was
> created while you were in http mode. The answer is yes: Tomcat will
> continue to use that session. If, however, you kill any sessions
> (yourself) as you switch to https, then any fallback to http will lose
> the session (because the browser will refuse to send a "secure" cookie
> through a non-secure channel.
>
> | Is there any security hole? If a man-in-the-middle knows the session
> | id from http and the same session id is used by https?
>
> This does not require man-in-the-middle. It's just plain-old session
> hijacking. This can happen whether you are using SSL or not -- if
> someone can guess your session id, you're pwned.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkerLLYACgkQ9CaO5/Lv0PBSbQCgs51ON7Uwam/6mMs+5w4e0dv4
> AwgAoK//OfuOISynFSbnV+jU6kqI2N6N
> =14Kp
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> 




---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to