On 10 May 2011, at 21:55, Reto Bachmann-Gmuer wrote: > This is a -1 against the commits to trunk for CLEREZZA-479
Your issues are fixed with commit #1101645 http://svn.apache.org/viewvc?view=rev&rev=1101645 > > Reasons: With this patches a user can log in even when the claimed identity > cannot be verified, this is a major security leak. > > Steps to reproduce the problem: > > - Start clerezza > - Log in as admin > - Get a webid with the account-control-panel > - shut down clerezza > - delete felix-cache > - start clerezza again, this time with --https_keystore_clientauth want > - delete all you cookies (just to be sure) > - go to https://localhost:8443/ and when asked for a certificate choose the > one of the newly created webid > - you're in, even though clearly the public key could not be retrieven from > the webid profile (which has been delete with felix-profile) > > you can even use your http://localhost:8080/ webid to login to > https://bblfish.net:8443/, see https://bblfish.net:8443/i-was-here Thanks for pointing this out. The problem was that returning a non ANONYMOUS user gave the user a lot more power. The code has now been tightenened to make sure users with no credentials are anonymous. > > On Tue, May 10, 2011 at 4:44 PM, Henry Story <[email protected]> wrote: >> >> Perhaps it is simply that you have a cookie set, and that you logged in with >> your cookie? > > no > > What does the test suite tell you, if you go to /test/WebID on you > installation after having installed it > > with > > :f install > mvn:org.apache.clerezza/platform.security.foafssl.core/0.1-incubating-SNAPSHOT > > Why should I install it like that? clearly the bundle is installed (its part > ot the launcher), also the bundle has to be started to, the default way to > install and start would be: > start("mvn:org.apache.clerezza/platform.security.foafssl.core/0.1-incubating-SNAPSHOT") Sorry I meant that one should do :f install mvn:org.apache.clerezza/platform.security.foafssl.test/0.1-incubating-SNAPSHOT :f install mvn:org.bouncycastle/bcmail-jdk16/1.46 then one needs to start the test suite. I need to do something so that at least the second install is not necessary. > anyway, the page says: > java.security.PrivilegedActionException: javax.net.ssl.SSLHandshakeException: > sun.security.validator.ValidatorException: PKIX path building failed: > sun.security.provider.certpath.SunCertPathBuilderException: unable to find > valid certification path to requested target yes, that's what it things say when they are not installed recently. I think you told me that is now how it used to happen at some point. Any idea where one should look to fix that? > > This is an improvement, since it is what will allow automated testing of > the whole thing. > As I understood you want a tool to test an arbitrary webid implementation. > This shouldn't require changes to our implementation as any WebId complaint > implementation is supposed to pass, and clearly before it was at least closer > to WebId compliance as it now. Well yes, but the test suite really helped me debug this. For one you can now login with a false certificate and it will tell you exactly why it failed. Imagine what you would have to do without such a test suite and you had a field problem, with some user telling you that he could not log in? Good luck. The UI of the test suit certainly can be improved. I'd love some help there. > > > > If you are so keen on security, please allow me to think about it and fix it, > So keen on security? This whole module is about providing a cryptographic > proof of identity, now this is not working. It is working now. Thanks for pointing out the issue. I just mean you could give me a few hours of slack to solve the issue. > And not in a way to deny users access that should have access (which would be > bad) but by giving access even with a clearly broken proof and allowing > anybody to do staff which requires asmin permission. I don't think I'm being > particularly picky if I ask you to act immediately. It's done. > > and I'd suggest removing the Apache Felix Web Management Console which has a > different admin password than the main admin - so you told me - and which is > bound to leave a back door in every Clerezza installation. That seems easy to > fix. > Not true, it requires the knowledge that the password has to be changes > there, but it's not a back-door in every installation, this is not to say > this shouldn't be changed.BUT: What has this to do with the topic, open an > issue and remove a few lines from storageless parent for a quick fix. Since you have put the heat on me, I just thought I'd give you something to do while I fix the problem :-) > > Reto > > > > >> >> Henry >> >>> >>> Login used to be possible only with a valid WebId so this is a clear >>> regression. @Henry, I assume this is a releted to one of your recent >>> changes (in CLEREZZA-479), could your roll them back in trunk and move them >>> to an issue branch as long as the problems aren't fix so this is not an >>> impediment to release. >>> >>> Cheers, >>> Reto >> >> Social Web Architect >> http://bblfish.net/ >> > > > Social Web Architect > http://bblfish.net/ > > Social Web Architect http://bblfish.net/
