-1 Against CLEREZZA-479 commits (was Re: logging in with undereferenceable webid)

[Reto Bachmann-Gmuer <re...@apache.org>]

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 <he...@bblfish.net>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/
>
>

Re: -1 Against CLEREZZA-479 commits (was Re: logging in with undereferenceable webid)

[Henry Story <he...@bblfish.net>]

On 11 May 2011, at 08:57, Reto Bachmann-Gmuer wrote:

> I can confirm that I now longer have all permission when using an webid that
> cannot be dereferenced or where the key in invalid. In both cases I don't
> get an error message but seem to be user anonymous. So I suspend my -1 at
> the current stage.

Cool :-)

> 
> Still I'm sceptical about the current partial solution of the issue. I'm
> puzzled by the creation of a test suite requiring such massive changes to
> the system under test. I understand a test-suite might require adding some
> hooks to the tested system, but here it seems a major redesign is being done
> to the whole authentication system for clerezza to be testable with the
> suite being implemented. I don't think I'm opposing to this changes but I'd
> like them to be under smaller issues describing their scope.

WebID is quite a big improvement to the authentication process, as will 
become evident when people start using it (and after we solve a couple of minor 
issues left over). It uses TLS which is not what any of the auth systems you had were
using, and it is a very different animal. Not only that but WebID is all about
making TLS user friendly. TLS until now was deployed in a centralised way by large
army based organisations where user friendliness is not at all a priority -
quite the opposite in fact.  So even people working regularly with TLS are surprised
about how we are using it: since we are

  1. making it decentralised
  2. making it friendly

A key to making it friendly, is to not reject people without explanation when 
something does not work. Imagine you go to a shop to buy some shoes, and on arriving 
as you are  about to enter, the whole thing shuts down with barbed wire and armed 
guards, dogs barking and you are told to get out of the way. That is the user 
experience of a simple  out of the box implementation of TLS. What we are doing
here is different: when you arrive at the shop instead of shutting everything down:
we can let you walk around parts you are allowed to access  - the tills and the 
stocks area is out of bounds (everything ANONYMOUS can not access) - and if you want more 
we can tell you why your credentials are not accepted: your passport is out of date 
for example, or it is clearly a fake one. We could go even further and if you try to
force your way into the till area, we could build you a fake till area, and allow
you to think you are taking over - that is known as a honeypot. The more subtle 
parts of the army use those a lot.

> 
> Question regarding the latest commit:
> Implementation of AuthenticationMethod can now add principals to the
> subject, I assume that with this one can log-in with multiple authentication
> methods to gain more permission (e.g. standard set of permission from the
> webid, occasionally entering password for admin rights), what I don't
> understand is why the implementation of AuthenticationMethod remove
> principals (the anonymous principal) that is already associated to the
> subject.

I suppose that if the authentication system were a Partially Ordered Set, with 
ANONYMOUS at the bottom (like Nil is the bottom of the scala class hierarchy) then 
there would be no need to remove ANONYMOUS. This may be the case, in which
case removing anonymous may not be necessary. 


> 
> 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
>> 
> I'm looking forward to a documentation of the test suite.

There are two parts: there is a human readable version which is quite easy 
to understand, and there is the Machine readable version with an ontology 
that is already partly documented by EARL at W3C and that the WEbID XG 
will document too.

Here the nice thing is that we are also being friendly to machines :-)

> I'd recommend to
> use clerezza commands rather than felix-commmands with :f

perhaps we should have 
:z for clerezza specific commands

I think it is good to have something memorable to distinguihs those
from user functions people may want to add later.

Btw. I am starting to see the use of having some scripts at startup
be loaded to improve my work environment. Any way to do that?

> 
>> 
>> then one needs to start the test suite.
>> 
> What does this mean? starting the first of the bundles above?

yes

> 
> 
>> 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?
>> 
> Well, I think this occurs when acting as client. Afaik we rely solely on
> traditional PKI with jvm CA configuration there (I have some code somewhere
> to turn this verification off, but obviously this isn't a real solution)

Ah ok, so what we need to do is make SSL connections started by clerezza
work... I'll look into 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.
>> 
> I'm not sure, this sounds like something which should be part of clerezza
> rather than an optional test-suite

agree. But the UI needs to be improved.

> 
> 
>> 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.
>> 
> Haven't been using the test-suite yet, is it documented somewhere?

There were 900 lines of code there. Can't do everything here. We had 
to write a paper for http://d-cent.org/fsw2011/ and for the W3C 
http://www.w3.org/2011/identity-ws/ Identity in the browser. 
The paper we submitted there has been accepted btw.

It is very easy to understand. It explains in broken english what
is wrong with your certificate.
> 
> 
>> 
>> 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.
>> 
> sure, but having small issues (as well as competence with the source-control
> tool used) allow to easily revert to last approved version while the issue
> is being solved.

Well I am getting more familiar with git. I was able to apply one patch
in a stack of patches that I had been working on.

> 
> 
> 
>> 
>>> 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 :-)
>> 
> 
> You mean I'm obviously lacking work if I have time to complain about a
> blatant security whole?

"hole"

No, just that there is another blatant security hole that should also be
fixed. :-) So all the arguments you are applying to me above should be applied there too.



> 
> Reto

Social Web Architect
http://bblfish.net/

Re: -1 Against CLEREZZA-479 commits (was Re: logging in with undereferenceable webid)

[Reto Bachmann-Gmuer <re...@apache.org>]

I can confirm that I now longer have all permission when using an webid that
cannot be dereferenced or where the key in invalid. In both cases I don't
get an error message but seem to be user anonymous. So I suspend my -1 at
the current stage.

Still I'm sceptical about the current partial solution of the issue. I'm
puzzled by the creation of a test suite requiring such massive changes to
the system under test. I understand a test-suite might require adding some
hooks to the tested system, but here it seems a major redesign is being done
to the whole authentication system for clerezza to be testable with the
suite being implemented. I don't think I'm opposing to this changes but I'd
like them to be under smaller issues describing their scope.

Question regarding the latest commit:
Implementation of AuthenticationMethod can now add principals to the
subject, I assume that with this one can log-in with multiple authentication
methods to gain more permission (e.g. standard set of permission from the
webid, occasionally entering password for admin rights), what I don't
understand is why the implementation of AuthenticationMethod remove
principals (the anonymous principal) that is already associated to the
subject.

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
>
I'm looking forward to a documentation of the test suite. I'd recommend to
use clerezza commands rather than felix-commmands with :f


>
> then one needs to start the test suite.
>
What does this mean? starting the first of the bundles above?


> 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?
>
Well, I think this occurs when acting as client. Afaik we rely solely on
traditional PKI with jvm CA configuration there (I have some code somewhere
to turn this verification off, but obviously this isn't a real solution)



>
> >
> > 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.
>
I'm not sure, this sounds like something which should be part of clerezza
rather than an optional test-suite


> 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.
>
Haven't been using the test-suite yet, is it documented somewhere?


>
> 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.
>
sure, but having small issues (as well as competence with the source-control
tool used) allow to easily revert to last approved version while the issue
is being solved.



>
> > 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 :-)
>

You mean I'm obviously lacking work if I have time to complain about a
blatant security whole?

Reto

Re: -1 Against CLEREZZA-479 commits (was Re: logging in with undereferenceable webid)

[Henry Story <he...@bblfish.net>]

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 <he...@bblfish.net> 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/