Re: Tomcat-Lite update
And what about some sort of OSGI glue and Maven as build tool ? 2009/11/6 Costin Manolache : > On Fri, Nov 6, 2009 at 12:19 PM, Tim Funk wrote: > >> I am intrigued by the idea and have similar constraints (kids+job). >> >> My longer term interest in lite was a simpler deployment and moving config >> into scripting and out of xml. (But this was more dream due to time >> requirements) >> > > Yes, tomcat-lite should still be able to run servlets - but all the > 'framework' from the servlet API will be out of scope. > Tomcat-lite won't create or configure servlets for you, won't have class > loaders or process annotations. That would be > the job of whatever DI framework you chose - or just plain java or > scripting. > > It will also not have declarative authentication - instead should have > filters implementing auth schemes beyond what's possible > now - for example OpenID. > > IMO the servlet spec - 10 years ago - was a great answer to 'how to I write > web applications in java'. Then the J2EE and framework > stuff got added and added. The whole philosophy is to take away control from > application developer and have the framework > provide it ( typically with a 'lowest common' flavor ). > > There are plenty of good DI frameworks - spring, guice, various OSGI > implementations - that do a better job configuring objects or > handling class loading. > > I think it's much better to focus on HTTP-related features. It is also a > tractable project for people with jobs and kids, and I think > it would be a better value for both beginners and advanced users. > > > > >> >> As an aside, I am wondering if the long term effect to simplification will >> break things like the security manager. And with the capabilities we see in >> VM's today - is it better to just ignore the security manager and just tell >> people to use an isolated VM if they wish to lock things down. Is there a >> good reason to use a security manager today? (This might be a survey >> question for the user list) >> >> > The applet-style security manager is history. I doubt anyone is using it - > or is using it correctly - on server side. It was a dead end anyways > without good isolation and resource limitting. > > Isolated processes and/or isolated OS instances seems to be a much better > approach for anyone who really needs to run untrusted code. > > That's one of the reasons for the proxy focus - I want at some point to have > tomcat-lite run a single context per process, and proxy/load > balance requests. > > > Costin > > > >> -Tim >> >> >> Costin Manolache wrote: >> >>> Hi, >>> >>> Tomcat-Lite was started few years ago as an effort to produce a smaller, >>> cleaner version of tomcat. Unfortunately >>> it didn't get lots of development time - I was very busy at work ( and at >>> home - 2 kids now ), and it didn't >>> seem to be in a state where other people would start using it and >>> contribute. >>> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48157] New: describe how to disable X-Header trick to attack client cert auth
https://issues.apache.org/bugzilla/show_bug.cgi?id=48157 Summary: describe how to disable X-Header trick to attack client cert auth Product: Tomcat 5 Version: Unknown Platform: All OS/Version: All Status: NEW Severity: critical Priority: P2 Component: Connector:Coyote AssignedTo: dev@tomcat.apache.org ReportedBy: hau...@acm.org as per http://extendedsubset.com/Renegotiating_TLS.pdf p. 4: Is there a way to disable X-Headers with GET like paths in coyote - is so, describe in http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html see also bug 3463 and http://forums.sun.com/thread.jspa?messageID=10857837 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48158] New: warn that "per directory client certificate authentication" is harmful
https://issues.apache.org/bugzilla/show_bug.cgi?id=48158 Summary: warn that "per directory client certificate authentication" is harmful Product: Tomcat 5 Version: Unknown Platform: All OS/Version: All Status: NEW Severity: critical Priority: P2 Component: Connector:Coyote AssignedTo: dev@tomcat.apache.org ReportedBy: hau...@acm.org in http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html#Miscellaneous%20Tips%20and%20Bits 1) put a warning that not using clientAuth=false and using /something is harmful 2) describe how to turn off TLS re-negotiation see also Bug 48157 and Bug 34643 and http://forums.sun.com/thread.jspa?messageID=10857837 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48157] describe how to disable X-Header trick to attack client cert auth
https://issues.apache.org/bugzilla/show_bug.cgi?id=48157 --- Comment #1 from Ralf Hauser 2009-11-07 08:09:41 UTC --- see also Bug 48158 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 34643] document how to use certificate-based "clientAuth" on a per user or per session basis also with self-signed/expired client certs
https://issues.apache.org/bugzilla/show_bug.cgi?id=34643 --- Comment #11 from Ralf Hauser 2009-11-07 08:09:50 UTC --- see also Bug 48157 and Bug 48158 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat-Lite update
On Sat, Nov 7, 2009 at 1:25 AM, Henri Gomez wrote: > And what about some sort of OSGI glue Thanks for volunteering :-). Note that my goal is to _remove_ any framework feature from tomcat-lite - leave just http and services, no config file or class loading. The current 'integration' interface seems to be enough for spring - feel free to add hooks/listeners for any other framework, but no direct dependency. > and Maven as build tool ? > > Well, you know my opinion on Maven. However - I'm now using ant-ivy for all downloads, and use a pom.xml file to declare the dependencies ( ant-ivy can use either its format or pom ). I also added the 'compile' section - and it seems to at least compile and test. I'm not planning to maintain or use it - but if other people want to use mvn I have no problem as long as build.xml and eclipse .classpath keep working. Costin > 2009/11/6 Costin Manolache : > > On Fri, Nov 6, 2009 at 12:19 PM, Tim Funk wrote: > > > >> I am intrigued by the idea and have similar constraints (kids+job). > >> > >> My longer term interest in lite was a simpler deployment and moving > config > >> into scripting and out of xml. (But this was more dream due to time > >> requirements) > >> > > > > Yes, tomcat-lite should still be able to run servlets - but all the > > 'framework' from the servlet API will be out of scope. > > Tomcat-lite won't create or configure servlets for you, won't have class > > loaders or process annotations. That would be > > the job of whatever DI framework you chose - or just plain java or > > scripting. > > > > It will also not have declarative authentication - instead should have > > filters implementing auth schemes beyond what's possible > > now - for example OpenID. > > > > IMO the servlet spec - 10 years ago - was a great answer to 'how to I > write > > web applications in java'. Then the J2EE and framework > > stuff got added and added. The whole philosophy is to take away control > from > > application developer and have the framework > > provide it ( typically with a 'lowest common' flavor ). > > > > There are plenty of good DI frameworks - spring, guice, various OSGI > > implementations - that do a better job configuring objects or > > handling class loading. > > > > I think it's much better to focus on HTTP-related features. It is also a > > tractable project for people with jobs and kids, and I think > > it would be a better value for both beginners and advanced users. > > > > > > > > > >> > >> As an aside, I am wondering if the long term effect to simplification > will > >> break things like the security manager. And with the capabilities we see > in > >> VM's today - is it better to just ignore the security manager and just > tell > >> people to use an isolated VM if they wish to lock things down. Is there > a > >> good reason to use a security manager today? (This might be a survey > >> question for the user list) > >> > >> > > The applet-style security manager is history. I doubt anyone is using it > - > > or is using it correctly - on server side. It was a dead end anyways > > without good isolation and resource limitting. > > > > Isolated processes and/or isolated OS instances seems to be a much better > > approach for anyone who really needs to run untrusted code. > > > > That's one of the reasons for the proxy focus - I want at some point to > have > > tomcat-lite run a single context per process, and proxy/load > > balance requests. > > > > > > Costin > > > > > > > >> -Tim > >> > >> > >> Costin Manolache wrote: > >> > >>> Hi, > >>> > >>> Tomcat-Lite was started few years ago as an effort to produce a > smaller, > >>> cleaner version of tomcat. Unfortunately > >>> it didn't get lots of development time - I was very busy at work ( and > at > >>> home - 2 kids now ), and it didn't > >>> seem to be in a state where other people would start using it and > >>> contribute. > >>> > >> > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
SSL & Tomcat
All, I was thinking about this on my way back from ApacheCon and we probably need to get some advice out to users early next week. My current understanding is that the MITM attack is triggered by a renegotiation. On this basis I suggest something along the following lines: SSL using JSSE (BIO and NIO connectors) - Don't use SSL configs that require renegotiation. i.e. SSL config should be the same for the entire host. Sites that require SSL in some places and SSL + CLIENT-CERT in others will require reconfiguration. Sites that require SSL for some parts should be OK. - Keep watch for a Sun update to the JDK that may help address the issue SSL using tc Native - tcnative does not support renegotiation (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now users of tc native with SSL should be OK We also need to think about what to do with tc native. Maybe something like: - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is disabled) - keep an eye on httpd and if they find a work-around, copy it and release 1.1.18 with renegotiation enabled For now, I'm not proposing any changes to the docs although we may want to put a summary of the advice - once agreed - on the security pages. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48157] describe how to disable X-Header trick to attack client cert auth
https://issues.apache.org/bugzilla/show_bug.cgi?id=48157 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from Mark Thomas 2009-11-07 09:09:42 GMT --- Chances are any attempt to filter these out could be defeated and there is always a risk of a false positive. In addition, there may be other, more complex, attack vectors that would not be blocked. I just kicked off a discussion on the dev list. Feel free to join in there. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48158] warn that "per directory client certificate authentication" is harmful
https://issues.apache.org/bugzilla/show_bug.cgi?id=48158 --- Comment #1 from Mark Thomas 2009-11-07 09:10:34 GMT --- Agreed the warning needs to go out although the docs aren't the best place for it. Please join the discussion on the dev list. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL & Tomcat
On Sat, Nov 7, 2009 at 8:59 AM, Mark Thomas wrote: > All, > > I was thinking about this on my way back from ApacheCon and we probably > need to get some advice out to users early next week. > > My current understanding is that the MITM attack is triggered by a > renegotiation. > > On this basis I suggest something along the following lines: > > SSL using JSSE (BIO and NIO connectors) > - Don't use SSL configs that require renegotiation. i.e. SSL config > should be the same for the entire host. Sites that require SSL in some > places and SSL + CLIENT-CERT in others will require reconfiguration. > Sites that require SSL for some parts should be OK. > IMO we could disable ACTION_REQ_SSL_CERTIFICATE ( with a flag "allowManInMiddle" or completely ). - Keep watch for a Sun update to the JDK that may help address the issue > > Or ask people to switch to tcNative ( i.e. openSSL ) or stop using client cert auth. > SSL using tc Native > - tcnative does not support renegotiation > (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now > users of tc native with SSL should be OK > > > We also need to think about what to do with tc native. Maybe something > like: > - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is > disabled) > - keep an eye on httpd and if they find a work-around, copy it and > release 1.1.18 with renegotiation enabled > > > For now, I'm not proposing any changes to the docs although we may want > to put a summary of the advice - once agreed - on the security pages. > > Thoughts? > > How about the cypher suites - I don't think we allow per-context config of allowed cyphers. Also not sure about client-initiated re-negotiation - I guess using a fixed openssl ( do they have a fix ? ) and native would avoid this, otherwise we need to wait for a jsse fix ? Costin
Re: SSL & Tomcat
"Mark Thomas" wrote in message news:4af5a776.70...@apache.org... > All, > > I was thinking about this on my way back from ApacheCon and we probably > need to get some advice out to users early next week. > > My current understanding is that the MITM attack is triggered by a > renegotiation. > > On this basis I suggest something along the following lines: > > SSL using JSSE (BIO and NIO connectors) > - Don't use SSL configs that require renegotiation. i.e. SSL config > should be the same for the entire host. Sites that require SSL in some > places and SSL + CLIENT-CERT in others will require reconfiguration. > Sites that require SSL for some parts should be OK. > - Keep watch for a Sun update to the JDK that may help address the issue > IMHO, we will have to add an option to the that allows the user to have the current renegotiation behavior. It can even print out an annoying warning in the log file if you set it. But without this option, what will happen is that users that are using CLIENT-CERT simply won't upgrade. And there a plenty of use cases where the user really isn't to worried about MITM. For example, if I am running an intranet server that uses CLIENT-CERT to identify employees, then if a black-hat can get in a position to exploit this, MITM is the least of my worries. > SSL using tc Native > - tcnative does not support renegotiation > (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now > users of tc native with SSL should be OK > > > We also need to think about what to do with tc native. Maybe something > like: > - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is > disabled) > - keep an eye on httpd and if they find a work-around, copy it and > release 1.1.18 with renegotiation enabled > At the moment, https seems to be going for rejecting attempts by the client to renegotiate, but server renegotiation is unchanged (i.e. there is no configuration change necessary to force CLIENT-CERT for a specific directory). Perhaps tc-native could do something along the lines of r833582 (the httpd patch). > For now, I'm not proposing any changes to the docs although we may want > to put a summary of the advice - once agreed - on the security pages. > > Thoughts? > > Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r833800 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: billbarker Date: Sun Nov 8 01:50:41 2009 New Revision: 833800 URL: http://svn.apache.org/viewvc?rev=833800&view=rev Log: vote Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=833800&r1=833799&r2=833800&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Sun Nov 8 01:50:41 2009 @@ -206,7 +206,7 @@ Alternative patch that adds a new PrivilegedAction. The test case provided passes with this patch http://people.apache.org/~markt/patches/2009-11-06-bug48097-alt.patch - +1: markt, funkman + +1: markt, funkman, billbarker -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47893 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL & Tomcat
On Sat, Nov 7, 2009 at 8:59 AM, Mark Thomas wrote: > All, > > I was thinking about this on my way back from ApacheCon and we probably > need to get some advice out to users early next week. > > My current understanding is that the MITM attack is triggered by a > renegotiation. > > On this basis I suggest something along the following lines: > > SSL using JSSE (BIO and NIO connectors) > - Don't use SSL configs that require renegotiation. i.e. SSL config > should be the same for the entire host. Sites that require SSL in some > places and SSL + CLIENT-CERT in others will require reconfiguration. > Sites that require SSL for some parts should be OK. > - Keep watch for a Sun update to the JDK that may help address the issue Also IBM, BEA, Apple etc. I'm not sure if JSSE is something Sun license to everyone, or if other JVMs have their own implementation (maybe OpenSSL based?). Harmony presumably does, though no idea if it's OpenSSL or clean room (couldn't see anything on a vague browse through their svn). > SSL using tc Native > - tcnative does not support renegotiation > (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now > users of tc native with SSL should be OK +1 > We also need to think about what to do with tc native. Maybe something like: > - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is > disabled) > - keep an eye on httpd and if they find a work-around, copy it and > release 1.1.18 with renegotiation enabled Plus keeping an eye on the next openssl version for https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt ? Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
