TLS will sign everything and therefor will not allow fine-grained integrity
checking. Why do we want this? Middleboxes might alter some non-security
sensitive information and I don't want to drop those requests. But I am
looking into TLS already to see if I can use it for my purpose. We
certainly don't want the full encryption or authentication that TLS can
offer. No encryption since we don't want to interfere with caching and no
authentication since setting up the certificates is often one of the
reasons for small web apps not to use TLS. You have to get your certificate
from an authority, keep it safe, install it and pay for it. We notice that
adoption of TLS is not as great as we'd like it to be for securing cookie
based session management so we need an alternative that will be adopted
more easily and guarantee security of sessions better than plain cookie
based session management. As a thesis it is an interesting subject to study
although it's quite probable that the people too busy to use TLS will also
be too busy to use our session management mechanism.
Using TLS without certificates is only possible with the DH_Anon
cyphersuite which is often disabled by clients and server.
" The server MUST send a Certificate message whenever the agreed-
upon key exchange method uses certificates for authentication
(this includes all key exchange methods defined in this document
except DH_anon)." RFC 5246 (TLS 1.2)
" The following cipher suites are used for completely anonymous
Diffie-Hellman communications in which neither party is
authenticated. Note that this mode is vulnerable to man-in-the-
middle attacks. Using this mode therefore is of limited use: These
cipher suites MUST NOT be used by TLS 1.2 implementations unless the
application layer has specifically requested to allow anonymous key
exchange." RFC 5246
Also we want to support mixed content web apps without having the risk of
being vulnerable to session hijacking. Some of these properties can be
obtained by using SSL session identifier in Tomcat as your session
mechanism. Again, I am still doing some research and maybe what I am doing
is not worth it.
2015-11-24 11:36 GMT+01:00 Mark Thomas <ma...@apache.org>:
> On 24/11/2015 10:12, Roel Storms wrote:
> > It's to implement a new session mechanism that guarantees integrity of
> the
> > requests sent in the session and also protect the session from attacks
> > based on stealing or replacing the session identifier. This is a thesis
> I'm
> > working on and this Tomcat valve should prove that migration from cookie
> > base session management to this new session management can go without
> large
> > modifications at client and server-side. That's why it is important to
> make
> > it transparent to the user/developer. Performance is already going to be
> an
> > issue in multiple places but I'll see what I can come up with.
> >
> > I am weighing of transparency, ease of migration, performance and
> security
> > all the time. Checking at the Apache httpd level will make it harder to
> > migrate to this new session management mechanism and has some other
> > disadvantages. In theory i could do this session management in a proxy
> but
> > this has it's own disadvantages. Session scope is an important aspect in
> > it's security and scope is harder to get right in a proxy or in the httpd
> > server since I want to limit scope to the web application context and
> maybe
> > allow explicit session sharing between web applications. As you can see I
> > still have a lot to do. If I need any more information I will not
> hesitate
> > to ask. Thanks for all the info!
>
> What does this get you over and above using TLS (which is rapidly
> becoming a given due to HTTP/2) and configuring Tomcat to use the TLS
> session ID as the HTTP session identifier?
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
