You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Olivier Lefevre <le...@yahoo.com> on 2011/03/07 11:16:22 UTC
Forcing SSL use
I put this in my webapp's web.xml, then intent being to
allow GET and POST over https and nothing else:
<security-constraint>
<web-resource-collection>
<web-resource-name>forbidden</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>HEAD</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint/>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>secure</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
However when I try an http URL @ port 8080, i.e., a GET request,
instead of getting a 403 error as expected the URL in the browser
mutates all by itself to an https @ post 8443 and succeeds. Is
it the correct behaviour? To my reading the spec is vague as to
what exactly should happen then.
Thanks,
-- O.L.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Forcing SSL use
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeffrey,
On 3/7/2011 3:18 PM, Jeffrey Janner wrote:
> No one so far has mentioned it, but yes, you are seeing behavior as
> designed. The CONFIDENTIAL setting causes Tomcat to send a redirect
> to SSL if the request comes in on standard HTTP.
You might be able to trigger an error by removing the "redirectPort"
attribute from your HTTP connector.
> If your true intent is not to allow *ANY* traffic over HTTP, then you
> need to remove your HTTP <Connector> from the server.xml. However,
> leaving it this way is a "nicety" for the end user.
+1
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk135WYACgkQ9CaO5/Lv0PBoVwCfQgAAZXpxNgS98UoThbyWQEnH
lxMAnRgGw3e3XOjGPXxiKEZA1+BZro/e
=S1i0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Forcing SSL use
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
Olivier -
No one so far has mentioned it, but yes, you are seeing behavior as designed. The CONFIDENTIAL setting causes Tomcat to send a redirect to SSL if the request comes in on standard HTTP.
If your true intent is not to allow *ANY* traffic over HTTP, then you need to remove your HTTP <Connector> from the server.xml. However, leaving it this way is a "nicety" for the end user.
Jeff
> -----Original Message-----
> From: Olivier Lefevre [mailto:lefevrol@yahoo.com]
> Sent: Monday, March 07, 2011 4:16 AM
> To: users@tomcat.apache.org
> Subject: Forcing SSL use
>
> I put this in my webapp's web.xml, then intent being to
> allow GET and POST over https and nothing else:
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>forbidden</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>HEAD</http-method>
> <http-method>PUT</http-method>
> <http-method>DELETE</http-method>
> <http-method>OPTIONS</http-method>
> <http-method>TRACE</http-method>
> </web-resource-collection>
> <auth-constraint/>
> </security-constraint>
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>secure</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
>
> However when I try an http URL @ port 8080, i.e., a GET request,
> instead of getting a 403 error as expected the URL in the browser
> mutates all by itself to an https @ post 8443 and succeeds. Is
> it the correct behaviour? To my reading the spec is vague as to
> what exactly should happen then.
>
> Thanks,
>
> -- O.L.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
__________________________________________________________________________
Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Forcing SSL use
Posted by André Warnier <aw...@ice-sa.com>.
Olivier Lefevre wrote:
> On 3/7/2011 1:27 PM, Konstantin Kolinko wrote:
>> Why do you forbid HEAD? IMHO it should have the same constraints as
>> GET, because browsers use them together.
>
> OK. That doesn't answer my question, though.
>
> But in the meantime I realized that in the access log there are pairs
> of entries with status 302 and then 200 for each of these requests.
> Using the Live HTTP headers plugin confirmed the behaviour: the
> server responds with 302 and the https URL, following which the
> browser retries with that URL.
>
Slightly off-topic, but maybe of interest about the above :
From previous experience, I remember that at least several versions of IE, systematically
issue first a HEAD request for any request, and then follow-up with a GET request for the
same resource.
Many robots have a similar behaviour : they will first try HEAD (because they are being
nice and a HEAD is less costly for the server), and only if the HEAD fails, they try a GET.
So only for efficiency reasons, you may want to allow the HEAD requests.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Forcing SSL use
Posted by Olivier Lefevre <le...@yahoo.com>.
On 3/7/2011 1:27 PM, Konstantin Kolinko wrote:
> Why do you forbid HEAD? IMHO it should have the same constraints as
> GET, because browsers use them together.
OK. That doesn't answer my question, though.
But in the meantime I realized that in the access log there are pairs
of entries with status 302 and then 200 for each of these requests.
Using the Live HTTP headers plugin confirmed the behaviour: the
server responds with 302 and the https URL, following which the
browser retries with that URL.
-- O.L.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Forcing SSL use
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/3/7 Olivier Lefevre <le...@yahoo.com>:
> I put this in my webapp's web.xml, then intent being to
> allow GET and POST over https and nothing else:
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>forbidden</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>HEAD</http-method>
> <http-method>PUT</http-method>
> <http-method>DELETE</http-method>
> <http-method>OPTIONS</http-method>
> <http-method>TRACE</http-method>
> </web-resource-collection>
> <auth-constraint/>
> </security-constraint>
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>secure</web-resource-name>
> <url-pattern>/*</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
>
> However when I try an http URL @ port 8080, i.e., a GET request,
> instead of getting a 403 error as expected the URL in the browser
> mutates all by itself to an https @ post 8443 and succeeds. Is
> it the correct behaviour? To my reading the spec is vague as to
> what exactly should happen then.
Why do you forbid HEAD? IMHO it should have the same constraints as
GET, because browsers use them together.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org