[Freedombox-discuss] Friendika

[Boaz]

Standard disclaimer: non-developer's thoughts follow.

Before I begin, let me apologize for quoting many snippets of text by
Henry Story, out of order and out of context.  I've done this because
I want to structure my reply with thoughts in the order in which I
want my reader to consider them, and my reply addresses and refers to
things which Henry has said in a completely different order than he
chose to say them.  I truly believe and sincerely hope that I've not
misrepresented the intent of any of Henry's statements by taking them
out of context, and I've placed the entirety of his messages at the
end of my own.

>If your web site had a self signed certificate then you would be no further than if you used >only http as far as security goes - which is what people have been doing in the past 15 >years...

>So there is an attack that is possible there. If that is not an issue that could be bypassed, >especially in server to server configuration. Of course in that case each side should >understand that the level of security is lower. But not lower than when we connect to >http://google.com/ .

>Now I think it would be great if everything were behind https. Then when google gave us an >answer we would not be in danger of receiving a man in the middle corrupted answer, >sending us to some other fake page. Security itself is social. If Google is not secure than >most things we do are not secure. If other web sites are not secure then google is not >secure - cause Google's crawler's could be man-in-the-middled.

Right, so let me set the stage for where I'm coming from by saying that:
1. I fully understand that self-signed server certificates are no
worse than lack of encryption (though perhaps not a whole lot better).
2. I am not at all satisfied with the level of security provided by no
encryption (or completely unauthenticated self-signed certificates).

Indeed, the very problem that I yearn to solve is the problem that
most of our communications (web based and otherwise) are not
encrypted.  In other words, your statement "I think it would be great
if everything were behind https", where "https" is a stand in for
generic encryption, is exactly my sentiment.  Which, incidentally, is
why I do not connect to http://google.com/, but rather
https://encrypted.google.com/ (or did until I switched to a different
search engine, also over https).

Good, now with that out of the way, the next two paragraphs are my
thoughts on WebID as a means of signing into
asitethatrequiresregistration.com, some stupid website which requires
that people sign up for an account with it.  I fully recommend that
you skip (or only skim) these two paragraphs :)


For this use case, a self-signed client certificate works just fine.
It can prove the "identity" of the client because it just needs to be
the same one the person used to sign up, just like a password proves
to a website your "identity" as "the same person who picked that
password when he signed up for an account".  The web server has no
prior notion of the identity of a person, so when that person signs
up, he creates an identity, and in the future proves he has that
identity using a secret (password) or a public key (WebID).

Personally, I think that people overstate the advantages of WebID over
password authentication for this use case by emphasizing that WebID
frees people from thinking of and remembering passwords.  It only does
that by having the browser think of key pairs and remember private
keys, for the user.  If the user had to do this himself, it would be a
much scarier nightmare than the password debacle.  Similarly, the
browser could (and indeed Firefox has this feature) remember (and
maybe even think of, I'm not sure if Firefox does this but anyhow it
could) passwords on behalf of the user.  I mean, I do totally see the
advantages (the linkable identity and so on), I just think that the
"don't need to remember passwords" point is a bit overstated.


But I'm really not that interested in how users sign into
asitethatrequiresregistration.com, so I really don't mean to get drawn
into a discussion of the relative merits of passwords and WebID for
this purpose, which is why I advised readers to skip the preceding 2
paragraphs.  I'm very, very interested in how Alice and Bob, 2 real
individual people, who know each other in some way, can communicate
privately with each other over the internet.

>Your client certificate can be self signed without a problem of MITM. IT is the server lacking >a certificate signed by a trusted authority - CA or DNS or some friend - that would enable >MITM.

In the case of Alice and Bob, this distinction breaks down in a hurry,
because both are going to need to play the role of client and server.
Here's my story to demonstrate this: the two characters are meeting at
a party.  After the party, Alice wants to read (privileged)
information on Bob's web page.  How will she do this?

No problem, she'll sign in with a self-signed WebID.  Oh wait, how is
Bob's web server going to know that some random person with a
self-signed certificate should have access to privileged information?
Oh I know, her WebID contains the url of her own home page.  Still,
how does Bob's server know that this url is the url of someone Bob
wants to be able to see this information?  Oh I know, she tells Bob
the url of her homepage (which the short, easy to remember url,
http://wonderland.net/foaf.rdf#alice_doe) at the party.  Fine, so then
the self-signed client certificate that her browser presents Bob's web
server references her homepage.  Bob's server fetches that page, which
corroborates that the key is the right one.  Oh joy, now Bob's server
can present this stranger privileged information.  Oh wait, that's no
good; Mr Evil Man In the Middle Esq. will just present his own
self-signed certificate to Bob's server, referencing Alice's homepage,
and then when Bob's server turns around to fetch Alice's homepage, Mr
Middle masquerades as wonderland.net and provides a page which lists
his own key as Alice's.  Alice can't just act as a client.  She needs
to act as a server, too.  And if we want anything to be at all secure
about all this, she needs to be able to authenticate her server
identity.  And, as you say:

>The server certificates work much better when relying on a CA of course.  Without CA >signed certificates the client or the server would not know if they  have really reached the >server. So there is an attack that is possible there.

>IT is the server lacking a certificate signed by a trusted authority - CA or DNS or some friend >- that would enable MITM.

>If your web site had a self signed certificate then you would be no further than if you used >only http as far as security goes

Okay, so we have a problem here.  Someone has a conceptual notions of
an “identity” for another person, something like, “that girl I met at
that party”, and wants to share secret information with the person
having that identity.  Now he is presented with a public key.  Is that
public key held by the person with the identity he's concerned with?

So, while WebID is a great spec for how the girl he met at the party
will sign into his website everyday  to access today's new round of
secret information, it doesn't really address the question of how he
can be assured that her WebID belongs to the person with the
“identity” that he wants to share secret information with.

This is the problem I refer to as “authentication”.  By
“authenticating” a key, I mean receiving some strong assurance that
that key is owned by the person with the “identity” who you think it
is, that the corresponding private key for the public key:
bf cb b8 10 20 d0 17 54 4c ab b9 49 5a a8 03 dc
ad 74 a7 b3 26 49 48 7e eb 67 21 f9 f6 fe 70 30
f3 f4 4e e6 47 f1 f7 a1 11 59 75 1e a0 0f c5 77
f6 e4 dd dc 4b 9e 12 99 7b 5e f3 c4 10 97 73 fc
7f d0 64 ec 69 eb 62 08 ea 0e 04 c1 1f bf d3 19
52 fe aa 80 61 f8 40 9f 5b 96 ff ea d4 87 bc c9
5b 61 b6 c4 62 45 6b 66 f6 b1 20 8d e4 27 59 81
ac 28 cd c7 d2 60 1c 0b fa 08 ce a3 85 d0 e5 3f
is stored on a machine under the control of “that girl I met at the party”.

If we want the blessings of cryptography to shine upon humanity, we
need to address this problem.

Let's address one solution which doesn't work:

>CA will never be able to do end user certification. It's way beyond them. They are already
>struggling to certify paying businesses. Nobody would want CAs to start certifying individuals.
>This is why nobody thought of using Client Certs for authentication.

I whole-heartedly agree.  Their cumbersome and inelegant solution
doesn't scale to 7 billion users.  Even if it did, I spit on their
solution.  The Electronic Frontier Foundation's SSL Observatory
(https://www.eff.org/observatory), has found that about 650
organizations control certificate authorities that the major web
browsers trust.  Considering that I don't even trust any individual
one of those 650 organizations not to misbehave, I'm not happy with a
solution requiring people to trust all 650 of them not to misbehave.

A few days ago, I sent out an embarrassingly long post describing the
system that I think would effectively solve this problem.  To attempt
to interest you, the reader of this post, to spend the time to read my
very long post from a few days ago, and to convey the main point of it
should you decide not to, I offer the following summary of it:

Persistent keys, tied to individual people, are exchanged,
authenticated, and used.  The authentication may occur before
beginning to use the key, shortly after, or long after.  They key may
be authenticated by any of the means by which it's possible to
authenticate keys, and may be used for all of the purposes for which
it's possible to use keys.

By “means by which it's possible to authenticate keys”, I'm referring
to things like ZRTP's short authentication strings, OpenPGP's web of
trust, OTR's socialist millionaire's protocol, or key fingerprints
exchanged by QR code (each discussed briefly in the very long post).
By “purposes for which it's possible to use keys”, I'm talking about
things like email, IM, VoIP, micro blog posts, web pages, and so on.
That's the doctrine I'm preaching: authentication method need not be
tied to communication protocol.


Boaz

>Hi,
>
>  I am lurking here from time to time. As the chair of http://webid.info/ I welcome people to >join
>the W3C incubator group and help us tighten the spec by producing more implementations. >We are currently working on developing a simple declarative test suite for webid >implementations.
>
>On 13 July, Melvin wrote
>
>>> >> WebID uses SSL, but as far as I understand it doesn't rely in any CA. The
>>> >> certificates can be self-signed and they will work the same.
>yes, the client side certificates don't rely on a CA. Neither does the WebID in the X509 Cert >have to be an httpS URL: it could be an http webid, in which case you have the possibility of >man in the middle attacks - which is a problem with username/passwords and e-mail >authentication nowadays. Of course a Relying Party (to use OpenId lingo) that receives an >http WebID should take that into account, and reduce trust levels. For some services this >may be ok - well it seems to be ok for the 99.99% web at present!
>
>The server certificates work much better when relying on a CA of course.  Without CA >signed certificates the client or the server would not know if they  have really reached the >server. So there is an attack that is possible there. If that is not an issue that could be >bypassed, especially in server to server configuration. Of course in that case each side >should understand that the level of security is lower. But not lower than when we connect to >http://google.com/ . (On the client side connecting to a server that is not CA enabled leads >to ugly UI issues though.)
>
>Now I think it would be great if everything were behind https. Then when google gave us an >answer we would not be in danger of receiving a man in the middle corrupted answer, >sending us to some other fake page. Security itself is social. If Google is not secure than >most things we do are not secure. If other web sites are not secure then google is not >secure - cause Google's crawler's could be man-in-the-middled.
>
>But we can't get everything behind https if we _need_ to rely on CAs, as they are a >bottleneck. DNS is not perfect but already a lot better. So people who want to help increase >security there, should look at the IETF DANE work.
>
>     http://datatracker.ietf.org/wg/dane/charter/
>
>Try to follow what is going on there and try to make sure that servers can put self signed >certs into DNSsec. Then push browsers to implement this. Chrome has an implementation >where you can put a certificate signed by your DNSSec on your https end point, which would >also work.
>
>If you don't want to rely on DNS then I wrote up how to do that on this list
>  http://lists.w3.org/Archives/Public/public-xg-webid/2011Mar/0068.html
>(if someone wants to play on developing httpk, let me know. I just need some help with >distibuted hash tables)
>
>
>>> >> It uses the
>>> >> private key installed in your PC (which might not be very convenient) and
>>> >> checks if it belongs to the public key (which you have copied sometime before)
>>> >> returned by the FOAF file. If they match, your friends server can be sure that
>>> >> you are who you claim to be
>>> >> ( http://www.w3.org/wiki/Foaf%2Bssl ). In this scheme it doesn't matter which
>>> >> the CA is.
>On 13 Jul 2011, at 19:54, Boaz wrote:
>> >
>> > Let's be clear: self-signed certificates provide no protection against
>> > MITM attack.
>Your client certificate can be self signed without a problem of MITM. IT is the server lacking
>a certificate signed by a trusted authority - CA or DNS or some friend - that would enable >MITM.
>
>> >  In other words, no assurance to your friends that you
>> > "are who you claim to be" (unless you gave them your key fingerprint
>> > on a slip of paper or something).  That assurance is the service that
>> > we supposedly get from certificate authorities.
>CA will never be able to do end user certification. It's way beyond them. They are already
>struggling to certify paying businesses. Nobody would want CAs to start certifying individuals.
>This is why nobody thought of using Client Certs for authentication. But with WebID you >don't need the CA for the
>client cert part! So a major problem of client certificates has vanished.
>
>Hope that helps. There is a short introduction video now on http://webid.info/
>
>Henry
>
>PS.
>
>And for those who have time to spare, I put gave a presentation on "Philosophy and the >Social Web" and the first
>philosophy and web conference last year in Paris. Though this is in English:
>http://bblfish.net/tmp/2010/10/26/
>
>
>> >
>> >
>> > Boaz
>> >
>> > _______________________________________________
>> > Freedombox-discuss mailing list
>> > Freedombox-discuss at lists.alioth.debian.org
>> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
>Social Web Architect
>http://bblfish.net/

>On 13 Jul 2011, at 20:50, Boaz wrote:
>
>>> >> You dont need to give your key on a slip of paper (you can if you want
>>> >> of course), it's on your home page.
>>> >>
>>> >> Hopefully your freedom box also hosts a web server too, preferably with https
>> >
>> > Okay, so you have a home page, and on this home page is your key.  And
>> > you know the home page is authentic, because it uses https, which is
>> > protected using - using what now?  Oh, that's right, that same key.
>If your web site had a self signed certificate then you would be no further than if you used >only http as far as security goes - which is what people have been doing in the past 15 >years... I suppose you'd be better off then just with http in order to avoid client error >messages. And if you have been happy with signing into sites using e-mail authentication >then you are not going to be loosing anything having an http WebID.
>
>If you want your profile secured then it is currently easiest to use a CA to certify your Web >Server. There are free CAs out there that work btw. (see the http://webid.info/ wiki) But we >need to put pressure on Browsers to implement IETF Dane so that we no longer need to >rely on that either.
>
>In any case this problem is going to be a problem with all services: without https you won't >know that you have reached the right server, be it your search engine, your identity provider, >or others...
>
>> > This is all well and good, it just doesn't provide any protection
>> > against a MITM attack.  If you're okay with that, this is a fine
>> > arrangement.
>The Relying party with WebID still TLS to get the client's certificate. CA signed ones make >currently for a better user experience with the browsers.
>
>Henry
>
>> >
>> > _______________________________________________
>> > Freedombox-discuss mailing list
>> > Freedombox-discuss at lists.alioth.debian.org
>> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
>Social Web Architect
>http://bblfish.net/