I am trying to protect the client from: Session fixation Session hijacking Assure that requests that are received in an established session can't be modified in transit (integrity of requests). Maybe I also want to check integrity of the response since otherwise an active MitM attack can still modify this. An attack could consists of an attacker modifying the action attribute of a form to send login data to the attacker instead of the web application. But this again looks a lot like TLS with DH_anon. Al we want is to replace the current session mechanism where the ID is a bearer token by a mechanism based on a shared secret (shared via DH). This will inhibit script based attacks that steal the SID and also eavesdropping attacks. It's not perfect but we also believe that if you have an active MitM, you have bigger problems than securing your session management. The perfect solution is still something including SSL/TLS (it's not cookie based since even over SSL cookies can be leaked if not set properly and we don't want a configuration mistake to become a security issue).
I am not trying to protect from: An active MitM attack during session establishment Malware at either client or server-side 2015-11-24 15:19 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net >: > Roel, > > On 11/24/15 5:12 AM, 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! > > Are you trying to protect the client and server from an evil proxy, or > are you trying to protect the server from an evil client? > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
