Roel, On 11/24/15 9:17 AM, Roel Storms wrote: > 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.
So, you want to support caching and don't want to deal with authentication. If you don't care about authentication, why do you care about integrity? > You have to get your certificate > from an authority, keep it safe, install it and pay for it. That's pretty easy. It's possible to get free certificates [1] [2]. Let's Encrypt is even making it all automated. > 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. TLS + cookies is the only workable solution for the foreseeable future. To support anything else, you'd have to have code running on both the client and the server (or, alternatively, get a change made to one or more specifications to force clients to implement your strategy). > 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. If you know what you are doing, you can set up a TLS server from scratch in about 5 minutes. The problem is that most people don't understand X.509 and just Google for "how to configure SSL" and type-in whatever commands happen to be there. > Using TLS without certificates is only possible with the DH_Anon > cyphersuite which is often disabled by clients and server. The use of encryption without (cert) authentication is certainly an interesting use-case. I think the only reason it's usually disabled is because browsers don't have a really good way to say to a user "this channel is encrypted, but we can't prove AT ALL who is on the other end. so your transaction is secure to the extent that nobody ELSE is observing it, but ... the party at the other end might not be trustworthy, so it's all moot". > 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. Session-hijacking is pretty much always a possibility when the client is providing its own identification to the server: the only defense is to use SSL sessions (meaning, SSL-session as the authentication mechanism) or to try your best not to ever disclose the session cookie's value over a cleartext channel. -chris [1] https://www.startssl.com/ [2] https://letsencrypt.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
