This is a -1 against the commits to trunk for CLEREZZA-479 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 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") 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 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. > > 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. 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. > 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. 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/ > >
