You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jeffrey Janner <Je...@PolyDyne.com> on 2013/07/29 21:29:10 UTC

secure cookies

Have a client that is wanting us to implement the following in web.xml:
<session-config>
    <cookie-config>
        <http-only>true</http-only>
        <secure>true</secure>
    </cookie-config>
</session-config>
But from what I can tell, that's only available in 7+ and we are running at 6.latest with plans to upgrade.
Found a site that says I can accomplish the same in 6 by setting useHttpOnly="true" in the context and setting secure="true" in the non-SSL connector.
I know the former is correct, but the latter seems a stretch.  Am I correct in not trusting that answer?

Jeffrey Janner
Sr. Network Administrator
jeffrey.janner@polydyne.com<ma...@polydyne.com>
PolyDyne Software Inc.
Main:   512.343.9100
Direct:  512.583.8930

 [cid:image002.png@01CC0FB7.4FF43CE0]

Speed, Intelligence & Savings in Sourcing


Re: secure cookies

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Prafull,

On 7/30/13 9:44 AM, Prafull wrote:
> On Tue, Jul 30, 2013 at 6:51 AM, Christopher Schultz < 
> chris@christopherschultz.net> wrote:
> 
> Jeffrey,
> 
> On 7/29/13 4:09 PM, Jeffrey Janner wrote:
>>>> Thanks for the verification, Mark.  I was under the
>>>> impression you'd only want to [set secure="true"] if you were
>>>> already front-ending the site with something that was doing
>>>> the SSL for you (e.g. httpd or a proxy), and the server spoke
>>>> HTTP between each other.
> 
> We use secure="true" for loopback-only connectors to avoid the 
> overhead of SSL when we know the requests are going to come from 
> localhost (we have Apache Cocoon running in a separate JVM 
> calling-back to our main webapp for some XML). So there are some 
> non-fronting use cases, too.
> 
> (Note that mod_jk already sets the "secure" flag with each request
> if the original request to httpd came over HTTPS.)
> 
>>>> Our app accepts an initial request to the login page on HTTP,
>>>> but should be automatically routed to the HTTPS connector due
>>>> to <transport-guarantee> before the page is actually sent
>>>> back.  Then we actually invalidate the session and create a
>>>> new on successful login, and that session/cookie is used for
>>>> the rest of the user's time on the site. So all I really need
>>>> to do to implement at 6.x is the context change.
> 
> Tomcat changes the session id (without actually destroying the 
> session) after authentication, so if you are using Tomcat's 
> authentication, then there is no need for the invalidation you 
> describe above.
> 
> -chris
>> 
>> ---------------------------------------------------------------------
>>
>> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>> 
>> Hi Christopher,
> 
> When you say after successful authentication tomcat re-creates a
> new session, what do you mean by that? Can you explain it in bit
> more details?

I didn't say that Tomcat "re-created a new session". In fact, I said
the opposite: Tomcat does not destroy the session. Instead, it changes
the session identifier associated with the existing session. This is
done to prevent session-fixation attacks.

You can read all about it here:
http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJR98zLAAoJEBzwKT+lPKRYgUYP/1NOvgOUEP7Oe74J36pTEzeH
ixUJrV2B9Iiju9XLrkhwRwEXALcVyUoDPeXMfGnsoJY5o26XnXLApXDwoNCIGnPu
NbbLNOs7syHJsd1ClptU3V8ySQ39X00BRF/qiT+32HmMoSb9gIoMyU7Wj/+Eytpi
QJ8a1G2IwyUlCfmfcZSXGbfOTNIO8bwJeeZtRamioCuSrZjVhguB7XK+IL2llhUP
sgp5tpc5LXiJaTF/C81i1dJjfffae2/lY/zNWTv7uxBQ+bgQWMG53yR0GRaWVtuo
EtM4N79eM/2b5kWCcOHBn7DNmhwITTvsOJGh0TRIMwdVT/AsiKXw4w+REHA9xB6r
0gpGR2Zdpf63IktWwfG/ZnFqmEgbABasV6O4/Vv0Idwxx1D00IyLm1KStvv8sOha
78eQ5RZM+iQ22L3KvBKn+o3spmQ66m7QPr/I9nkbipsTHxDK0MObM8ei6SAhBQec
RT7vHk+WoUomaLJUQFnyuIVkiOdPtefsGQM9m8Q5TtQ7hyPRLydUwnSd7yRnUenO
nMKfQT/zImhrcXjy8jKH9fVQWBlOmKJNcU/WZogJ7s23PS8/Ei1PLMNiXh60N/Ok
xZxQ9LP4O/60EYHE4zRToj95qILnBxqwIhWM9h8lpv/YeqrF9/yltfql0BDXs5XO
z+cdjl7S/BFf7ZUNKVmO
=B93k
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: secure cookies

Posted by Prafull <pr...@gmail.com>.
On Tue, Jul 30, 2013 at 6:51 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Jeffrey,
>
> On 7/29/13 4:09 PM, Jeffrey Janner wrote:
> > Thanks for the verification, Mark.  I was under the impression
> > you'd only want to [set secure="true"] if you were already
> > front-ending the site with something that was doing the SSL for you
> > (e.g. httpd or a proxy), and the server spoke HTTP between each
> > other.
>
> We use secure="true" for loopback-only connectors to avoid the
> overhead of SSL when we know the requests are going to come from
> localhost (we have Apache Cocoon running in a separate JVM
> calling-back to our main webapp for some XML). So there are some
> non-fronting use cases, too.
>
> (Note that mod_jk already sets the "secure" flag with each request if
> the original request to httpd came over HTTPS.)
>
> > Our app accepts an initial request to the login page on HTTP, but
> > should be automatically routed to the HTTPS connector due to
> > <transport-guarantee> before the page is actually sent back.  Then
> > we actually invalidate the session and create a new on successful
> > login, and that session/cookie is used for the rest of the user's
> > time on the site. So all I really need to do to implement at 6.x is
> > the context change.
>
> Tomcat changes the session id (without actually destroying the
> session) after authentication, so if you are using Tomcat's
> authentication, then there is no need for the invalidation you
> describe above.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJR9xURAAoJEBzwKT+lPKRYVdIQAIrWoSOO3bSCTb0Ot6B7r9xy
> mGGlc3AwAImitS/FvWB2Rjx60doth8MqTD8A31abK+Ec9Gd1cbsWqTgea3VddYO7
> HYJfFrC4Nn7hcnsBXKkCjfJ/fnDzcodQrfg1aw/fbQpxVFzuEFI0JkIHdT1XE196
> zz6yy/hIo0X32HMRVK4rQYVdxDtDbgMyWbHB62PilxiLXvSzX3X2BN5F6qECy3+N
> BsVKeuG5SYITOySQ5lfCxSY47e9tzjmYcvfoEh+PqZoLl28SjRuv8j8zUqLVUBzf
> n+w3GFK7qdEt7QJdOA2uMmNS8NV5B18NjckVI5xyKtHmGrLlLBSSSVNHaQbZbYK/
> KzpBDdCv77UMS+RMgl7v1SfoNhRjiE+TYaDevwKrKs59+vXiv7TxyTcSuwDyB9zh
> zx9vxK/OGA667FesOUkTC4NFewl/5HWpulJvhhs2jj61E54EqzemQO789mZykhyZ
> COujCJXYqcpvas4gp+UGviacrjFTbQ7DWi0dzGhTzrlexLyK/5TjMsurUaK/lBYv
> GsDXxkQVGGZoP0ZKfoi+bYJKFTb3nUqHEGc17BXjlFT+nSB0Otb5QbpumtBpoOmQ
> dyltiro4acsP5fxSpJnHYXVr7i+UQg+c+RiHeJRPFKBLWKcwLYf/Dcu1AD9Crfw0
> eCjLf9tOerjoA+PeKGFr
> =ZKug
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> Hi Christopher,

When you say after successful authentication tomcat re-creates a new
session, what do you mean by that? Can you explain it in bit more details?


-- 
BR,
Prafull

Re: secure cookies

Posted by Prafull <pr...@gmail.com>.
On Tue, Jul 30, 2013 at 9:39 PM, Jeffrey Janner <Jeffrey.Janner@polydyne.com
> wrote:

> > -----Original Message-----
> > From: Christopher Schultz [mailto:chris@christopherschultz.net]
> > Sent: Monday, July 29, 2013 8:21 PM
> > To: Tomcat Users List
> > Subject: Re: secure cookies
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > Jeffrey,
> >
> > On 7/29/13 4:09 PM, Jeffrey Janner wrote:
> > > Thanks for the verification, Mark.  I was under the impression you'd
> > > only want to [set secure="true"] if you were already front-ending the
> > > site with something that was doing the SSL for you (e.g. httpd or a
> > > proxy), and the server spoke HTTP between each other.
> >
> > We use secure="true" for loopback-only connectors to avoid the overhead
> > of SSL when we know the requests are going to come from localhost (we
> > have Apache Cocoon running in a separate JVM calling-back to our main
> > webapp for some XML). So there are some non-fronting use cases, too.
> >
> > (Note that mod_jk already sets the "secure" flag with each request if
> > the original request to httpd came over HTTPS.)
> >
> > > Our app accepts an initial request to the login page on HTTP, but
> > > should be automatically routed to the HTTPS connector due to
> > > <transport-guarantee> before the page is actually sent back.  Then we
> > > actually invalidate the session and create a new on successful login,
> > > and that session/cookie is used for the rest of the user's time on
> > the
> > > site. So all I really need to do to implement at 6.x is the context
> > > change.
> >
> > Tomcat changes the session id (without actually destroying the
> > session) after authentication, so if you are using Tomcat's
> > authentication, then there is no need for the invalidation you describe
> > above.
> >
> We don't use Tomcat Auth, though I'm arguing for changing to Tomcat w/Form
> Auth so it's easier to support 2-factor auth for those customers who insist
> on it.  I'm not sure of the exact methodology employed, but I'm sure it's
> similar.
>


Thanks Christopher for the clarification and the link
-- 
BR,
Prafull

RE: secure cookies

Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Monday, July 29, 2013 8:21 PM
> To: Tomcat Users List
> Subject: Re: secure cookies
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Jeffrey,
> 
> On 7/29/13 4:09 PM, Jeffrey Janner wrote:
> > Thanks for the verification, Mark.  I was under the impression you'd
> > only want to [set secure="true"] if you were already front-ending the
> > site with something that was doing the SSL for you (e.g. httpd or a
> > proxy), and the server spoke HTTP between each other.
> 
> We use secure="true" for loopback-only connectors to avoid the overhead
> of SSL when we know the requests are going to come from localhost (we
> have Apache Cocoon running in a separate JVM calling-back to our main
> webapp for some XML). So there are some non-fronting use cases, too.
> 
> (Note that mod_jk already sets the "secure" flag with each request if
> the original request to httpd came over HTTPS.)
> 
> > Our app accepts an initial request to the login page on HTTP, but
> > should be automatically routed to the HTTPS connector due to
> > <transport-guarantee> before the page is actually sent back.  Then we
> > actually invalidate the session and create a new on successful login,
> > and that session/cookie is used for the rest of the user's time on
> the
> > site. So all I really need to do to implement at 6.x is the context
> > change.
> 
> Tomcat changes the session id (without actually destroying the
> session) after authentication, so if you are using Tomcat's
> authentication, then there is no need for the invalidation you describe
> above.
> 
We don't use Tomcat Auth, though I'm arguing for changing to Tomcat w/Form Auth so it's easier to support 2-factor auth for those customers who insist on it.  I'm not sure of the exact methodology employed, but I'm sure it's similar.

Re: secure cookies

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jeffrey,

On 7/29/13 4:09 PM, Jeffrey Janner wrote:
> Thanks for the verification, Mark.  I was under the impression
> you'd only want to [set secure="true"] if you were already
> front-ending the site with something that was doing the SSL for you
> (e.g. httpd or a proxy), and the server spoke HTTP between each
> other.

We use secure="true" for loopback-only connectors to avoid the
overhead of SSL when we know the requests are going to come from
localhost (we have Apache Cocoon running in a separate JVM
calling-back to our main webapp for some XML). So there are some
non-fronting use cases, too.

(Note that mod_jk already sets the "secure" flag with each request if
the original request to httpd came over HTTPS.)

> Our app accepts an initial request to the login page on HTTP, but 
> should be automatically routed to the HTTPS connector due to 
> <transport-guarantee> before the page is actually sent back.  Then
> we actually invalidate the session and create a new on successful
> login, and that session/cookie is used for the rest of the user's
> time on the site. So all I really need to do to implement at 6.x is
> the context change.

Tomcat changes the session id (without actually destroying the
session) after authentication, so if you are using Tomcat's
authentication, then there is no need for the invalidation you
describe above.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJR9xURAAoJEBzwKT+lPKRYVdIQAIrWoSOO3bSCTb0Ot6B7r9xy
mGGlc3AwAImitS/FvWB2Rjx60doth8MqTD8A31abK+Ec9Gd1cbsWqTgea3VddYO7
HYJfFrC4Nn7hcnsBXKkCjfJ/fnDzcodQrfg1aw/fbQpxVFzuEFI0JkIHdT1XE196
zz6yy/hIo0X32HMRVK4rQYVdxDtDbgMyWbHB62PilxiLXvSzX3X2BN5F6qECy3+N
BsVKeuG5SYITOySQ5lfCxSY47e9tzjmYcvfoEh+PqZoLl28SjRuv8j8zUqLVUBzf
n+w3GFK7qdEt7QJdOA2uMmNS8NV5B18NjckVI5xyKtHmGrLlLBSSSVNHaQbZbYK/
KzpBDdCv77UMS+RMgl7v1SfoNhRjiE+TYaDevwKrKs59+vXiv7TxyTcSuwDyB9zh
zx9vxK/OGA667FesOUkTC4NFewl/5HWpulJvhhs2jj61E54EqzemQO789mZykhyZ
COujCJXYqcpvas4gp+UGviacrjFTbQ7DWi0dzGhTzrlexLyK/5TjMsurUaK/lBYv
GsDXxkQVGGZoP0ZKfoi+bYJKFTb3nUqHEGc17BXjlFT+nSB0Otb5QbpumtBpoOmQ
dyltiro4acsP5fxSpJnHYXVr7i+UQg+c+RiHeJRPFKBLWKcwLYf/Dcu1AD9Crfw0
eCjLf9tOerjoA+PeKGFr
=ZKug
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: secure cookies

Posted by Mark Thomas <ma...@apache.org>.
On 29/07/2013 22:09, Jeffrey Janner wrote:
>> -----Original Message-----
>> From: Mark Thomas [mailto:markt@apache.org]
>> Sent: Monday, July 29, 2013 2:54 PM
>> To: Tomcat Users List
>> Subject: Re: secure cookies
>>
>> On 29/07/2013 21:31, Jeffrey Janner wrote:
>>> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
>>> Sent: Monday, July 29, 2013 2:29 PM
>>> To: 'Tomcat Users List'
>>> Subject: secure cookies
>>>
>>> Have a client that is wanting us to implement the following in
>> web.xml:
>>> <session-config>
>>>     <cookie-config>
>>>         <http-only>true</http-only>
>>>         <secure>true</secure>
>>>     </cookie-config>
>>> </session-config>
>>> But from what I can tell, that's only available in 7+ and we are
>> running at 6.latest with plans to upgrade.
>>> Found a site that says I can accomplish the same in 6 by setting
>> useHttpOnly="true" in the context and setting secure="true" in the non-
>> SSL connector.
>>> I know the former is correct, but the latter seems a stretch.  Am I
>> correct in not trusting that answer?
>>
>> The web.xml settings are configuring all cookies to use the secure and
>> httpOnly flags.
>>
>> For Tomcat 6, useHttpOnly="true" at the Context level will achieve the
>> first. (OK so far)
>>
>> Setting secure="true" on a HTTP connector is a recipe for a massive
>> security hole. There are some very limited cases where it is the right
>> thing to do but I doubt this is one of them. What that setting will do
>> is tell Tomcat that all connections to that connector are secure and
>> Tomcat will treat them as if they were HTTPS connections and *not*
>> redirect things to real HTTPS if, for example, your webapp has a
>> transport guarantee.
>>
>> The only way I can think to set the secure flag on all cookies for
>> Tomcat 6 is to add a Filter that wraps the response and modifies every
>> cookie added via HttpServletResponse.addCookie()
>>
>> Even then if you have a request that creates a session on an HTTP
>> request I don't think you'll catch that.
>>
>> Mark
>>
> 
> Thanks for the verification, Mark.  I was under the impression you'd only want to do that if you were already front-ending the site with something that was doing the SSL for you (e.g. httpd or a proxy), and the server spoke HTTP between each other.

Correct. That is the valid use case for setting secure="true" on an HTTP
connector.

> From what I understand, if the cookie is created in response to a request that came in on HTTPS then it will be secure, otherwise not.

Correct.

> Our app accepts an initial request to the login page on HTTP, but should be automatically routed to the HTTPS connector due to <transport-guarantee> before the page is actually sent back.  Then we actually invalidate the session and create a new on successful login, and that session/cookie is used for the rest of the user's time on the site.
> So all I really need to do to implement at 6.x is the context change. Correct?

Assuming the app creates no other cookies that should be fine.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: secure cookies

Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Mark Thomas [mailto:markt@apache.org]
> Sent: Monday, July 29, 2013 2:54 PM
> To: Tomcat Users List
> Subject: Re: secure cookies
> 
> On 29/07/2013 21:31, Jeffrey Janner wrote:
> > From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
> > Sent: Monday, July 29, 2013 2:29 PM
> > To: 'Tomcat Users List'
> > Subject: secure cookies
> >
> > Have a client that is wanting us to implement the following in
> web.xml:
> > <session-config>
> >     <cookie-config>
> >         <http-only>true</http-only>
> >         <secure>true</secure>
> >     </cookie-config>
> > </session-config>
> > But from what I can tell, that's only available in 7+ and we are
> running at 6.latest with plans to upgrade.
> > Found a site that says I can accomplish the same in 6 by setting
> useHttpOnly="true" in the context and setting secure="true" in the non-
> SSL connector.
> > I know the former is correct, but the latter seems a stretch.  Am I
> correct in not trusting that answer?
> 
> The web.xml settings are configuring all cookies to use the secure and
> httpOnly flags.
> 
> For Tomcat 6, useHttpOnly="true" at the Context level will achieve the
> first. (OK so far)
> 
> Setting secure="true" on a HTTP connector is a recipe for a massive
> security hole. There are some very limited cases where it is the right
> thing to do but I doubt this is one of them. What that setting will do
> is tell Tomcat that all connections to that connector are secure and
> Tomcat will treat them as if they were HTTPS connections and *not*
> redirect things to real HTTPS if, for example, your webapp has a
> transport guarantee.
> 
> The only way I can think to set the secure flag on all cookies for
> Tomcat 6 is to add a Filter that wraps the response and modifies every
> cookie added via HttpServletResponse.addCookie()
> 
> Even then if you have a request that creates a session on an HTTP
> request I don't think you'll catch that.
> 
> Mark
> 

Thanks for the verification, Mark.  I was under the impression you'd only want to do that if you were already front-ending the site with something that was doing the SSL for you (e.g. httpd or a proxy), and the server spoke HTTP between each other.
>From what I understand, if the cookie is created in response to a request that came in on HTTPS then it will be secure, otherwise not.
Our app accepts an initial request to the login page on HTTP, but should be automatically routed to the HTTPS connector due to <transport-guarantee> before the page is actually sent back.  Then we actually invalidate the session and create a new on successful login, and that session/cookie is used for the rest of the user's time on the site.
So all I really need to do to implement at 6.x is the context change. Correct?
Jeff


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: secure cookies

Posted by Mark Thomas <ma...@apache.org>.
On 29/07/2013 21:31, Jeffrey Janner wrote:
> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
> Sent: Monday, July 29, 2013 2:29 PM
> To: 'Tomcat Users List'
> Subject: secure cookies
> 
> Have a client that is wanting us to implement the following in web.xml:
> <session-config>
>     <cookie-config>
>         <http-only>true</http-only>
>         <secure>true</secure>
>     </cookie-config>
> </session-config>
> But from what I can tell, that's only available in 7+ and we are running at 6.latest with plans to upgrade.
> Found a site that says I can accomplish the same in 6 by setting useHttpOnly="true" in the context and setting secure="true" in the non-SSL connector.
> I know the former is correct, but the latter seems a stretch.  Am I correct in not trusting that answer?

The web.xml settings are configuring all cookies to use the secure and
httpOnly flags.

For Tomcat 6, useHttpOnly="true" at the Context level will achieve the
first. (OK so far)

Setting secure="true" on a HTTP connector is a recipe for a massive
security hole. There are some very limited cases where it is the right
thing to do but I doubt this is one of them. What that setting will do
is tell Tomcat that all connections to that connector are secure and
Tomcat will treat them as if they were HTTPS connections and *not*
redirect things to real HTTPS if, for example, your webapp has a
transport guarantee.

The only way I can think to set the secure flag on all cookies for
Tomcat 6 is to add a Filter that wraps the response and modifies every
cookie added via HttpServletResponse.addCookie()

Even then if you have a request that creates a session on an HTTP
request I don't think you'll catch that.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: secure cookies

Posted by Jeffrey Janner <Je...@PolyDyne.com>.
From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
Sent: Monday, July 29, 2013 2:29 PM
To: 'Tomcat Users List'
Subject: secure cookies

Have a client that is wanting us to implement the following in web.xml:
<session-config>
    <cookie-config>
        <http-only>true</http-only>
        <secure>true</secure>
    </cookie-config>
</session-config>
But from what I can tell, that's only available in 7+ and we are running at 6.latest with plans to upgrade.
Found a site that says I can accomplish the same in 6 by setting useHttpOnly="true" in the context and setting secure="true" in the non-SSL connector.
I know the former is correct, but the latter seems a stretch.  Am I correct in not trusting that answer?
[Jeff Janner] Forgot to mention that the site is already configured to require SSL for everything.