[Opensim-users] Banning "bad" viewers was Re: Can this be done?

[diva at metaverseink.com]

This is all good, and we're going in this direction. However, this 
doesn't address the issue raised by the original poster of this thread, 
i.e. he wanted to prevent certain viewers (not users) from connecting to 
his grid, probably because some viewers out there can store copies of 
the downloaded content.

That is a very hard problem to address. It would require verification of 
binaries, i.e. the piece of software connecting to the grid would have 
to send some sort of code identifying itself as "I'm a piece of software 
that has been assembled by Linden Lab", and then the grid would contact 
Linden Lab in order to verify that code. That's the only way to 
guarantee its origin. Other than that, we're left with the extremely 
unreliable method of filtering upon the id string, and trying to detect 
certain patterns of behavior, as Teravus suggested, but any 
viewer-writer with bad intentions can work around that.


Kyle Hamilton wrote:
> re the traffic camera issue being off-topic: Alright, and thank you
> for the pointer to the blog.  I look forward to reading it.
> 
> In an attempt in bringing this discussion back above the squelch
> threshold, I'll describe the process necessary for mutual
> cryptographic authentication (which is mathematically-provably more
> secure than trying to keep any string, including a password, secret):
> 
> 1) Server must generate a key, and [details omitted] obtain a server
> certificate from a place the Client trusts.
> 2) Client must generate a key, and [details omitted*] obtain a client
> certificate from a place the Server trusts.
> 3) All references to grid services must be to https URLs, all of which
> must [currently**] require mutual authentication on the initial
> negotiation.  TLS handles this.
> 4) Once the identity is verified (in the same place in the protocol
> flow that the First/Last/Password would be verified), the access token
> is created.
> 
> Sounds simple, right?  Conceptually, it is... but the devil is in the details.
> 
> Servers have it easier in this respect: they typically have technical
> expertise enough to learn to use openssl to generate the key and
> either the certificate or a request for a certificate from a public
> authority.  (Note that Linden Labs distributes its own root
> certificate with its viewer.)
> 
> Clients, though... they're a completely different ball of wax.  In
> order to use openssl to generate the key, obtain the certificate, and
> import it into Mono or .Net's keystore, they must learn an extra
> command that most admins don't ever have to learn about, and thus
> can't provide assistance with: openssl pkcs12.  This generates a .p12
> (or .pfx) file which contains the private key, the certificate, and
> the certificate chain up to the trust anchor, which must then be
> imported (in some way) into the keystore and marked accessible to the
> viewer.
> 
> Atop this, the Server and the Client must both support mutual
> authentication, by allowing the keys and certificates to be loaded
> into them.  The Server has it easy, once again; it's difficult and may
> well be impossible for the Client.
> 
> The pieces that don't exist:
> 
> 1) A means of provisioning Clients with keys and certificates.
> 2) A mechanism for associating a Client's key/cert pair with a
> particular grid connection.
> 3) A mechanism for provisioning Clients with the root certificates for
> any given grid.
> 4) A key generation system with certificate enrollment in Mono/.NET
> for the server (and for Mono/.NET clients)
> 5) The glue code necessary to pull the underlying authentication data
> from the TLS layer on the server.
> 
> #1 has had several attempts made at it by browser vendors over the
> years, from Netscape's <keygen> to Microsoft's CEnroll to Apple's
> Keychain Access.  Thus far, none of them have worked, and all of them
> suffer from one or more major issues which prevent the larger
> corporations (banks etc) from using them.  (cf
> http://www.financialcryptography.com/ )
> 
> #2 has problems even in the alternate context of associating
> certificates with email, for S/MIME.  Mozilla and Microsoft haven't
> figured out ways to do that; Apple has, but it's still a chore because
> it's not possible to set a *default* identity for who you want to be
> to any given person.  (It's made even worse because most S/MIME
> certificates only allow for 1 email address to be listed, at least as
> far as commercial CAs go.)
> 
> #3 should be relatively easy -- this is the portion of the system
> where a user wants to connect to a given grid; the reason it's
> difficult is because there is no key/cert management system out there
> that allows a user to specify "I trust this root certificate to
> authenticate things related to this grid (site) only".  Thus, this
> falls under the problem of both #1 and #2, which is "there is no
> useful user interface for the user side of the process".
> 
> #4 should be fairly easy to write, but I don't know where the keystore
> is and I don't know the API to access it.
> 
> #5 is, of course, a matter of simply requesting the authentication
> data from the underlying TLS connection, rather than demanding a
> First/Last/Pass tuple... and to ensure there's no problem with
> backward compatibility, create an index over both the Subject and the
> Authority of the certificate mapping to the named account.  (Bonus
> points if you hash the S&A into a GUID, so you don't even know the
> details embedded in the certificate.  However, this might cause some
> issues, most notably in account recovery.)
> 
> All of these are technically outside the realm of OpenSim proper,
> though proper key/certificate provisioning would be nice for the
> services.  It's the user side which nobody's paying attention to, and
> I don't even know if there's a way to make it usable by the masses.
> 
> -Kyle H
> 
> *: It's *drastically* more difficult to use the "easy UIs" than it is
> to use the certificate signature request submission method.
> **: TLS currently suffers from an attack which can be used to inject
> unauthorized data at the beginning of a stream, including HTTP headers
> or ESMTP commands, which relies on the semantics of renegotiation
> during an established connection.  The IETF TLS working group is
> *extremely* close to publishing a proposed standard for an indication
> that a given side supports secure renegotiation.
> 
> 
> On Thu, Jan 14, 2010 at 9:51 AM, Karen Palen <karen_palen at yahoo.com> wrote:
>> You are quite correct in saying that the traffic camera comments belong elsewhere! Sorry.
>>
>> http://camerafraud.wordpress.com/ is a website devoted to this issue and is the appropriate place for any more discussion.
>>
>> I will merely note that so far 11 states have banned the cameras and 17 out of 17 ballots on the issue have also done so.
>>
>> I do agree with your comments on the ID string, although I have other posts which cover my thoughts in more detail.
>>
>> Karen
>>
>> --- On Thu, 1/14/10, Kyle Hamilton <aerowolf at gmail.com> wrote:
>>
>>> From: Kyle Hamilton <aerowolf at gmail.com>
>>> Subject: Re: [Opensim-users] Banning "bad" viewers was Re: Can this be done?
>>> To: "opensim-users" <opensim-users at lists.berlios.de>
>>> Date: Thursday, January 14, 2010, 10:40 AM
>>> My apologies, Karen;  I was
>>> actually directing most of this to Imago.
>>>
>>> (My comments about Arizona, photo radar, red-light cameras,
>>> and
>>> California are all still directed toward you, but they open
>>> a
>>> different topic which is outside the scope of this list.)
>>>
>>> -Kyle H
>>>
>>> 2010/1/14 Kyle Hamilton <aerowolf at gmail.com>:
>>>> This is completely off-topic at this point, and after
>>> this (unless someone adds useful signal) I'm ignoring this
>>> thread.
>>>> On Thu, Jan 14, 2010 at 8:36 AM, Karen Palen <karen_palen at yahoo.com>
>>> wrote:
>>>>> In fact it takes a certain amount of effort to
>>> change the default ID which is built into the viewer code.
>>> Effort that no malware writer will expend!
>>>> ...until you issue a challenge like that. Further, the
>>> 'default ID' can be changed *on the commandline*. Because of
>>> this, there's no requirement to recompile/relink the viewer
>>> when you want to change that ID string, which reduces (by
>>> several orders of magnitude) the amount of time necessary to
>>> brute-force the string necessary. And, since you've
>>> essentially stated that you want the "official" Linden
>>> viewer, all someone has to do is figure out which version
>>> string(s) of the released viewer your grid will accept.
>>>> If you want security through obscurity, that's
>>> wonderful... but when you make it no longer obscure, it's no
>>> longer secure. You have definitely removed the obscurity
>>> from your system through your announcement of your plans in
>>> this thread.
>>>> I have already stated the only even-remotely-secure
>>> way to do it, and even that, if you want any kind of grid
>>> population at all, is going to require some kind of
>>> automation. (That way is server/client mutual cryptographic
>>> authentication, handled via TLS.) Personally, I'd rather
>>> each change to a primitive be written to a log as a
>>> revertable changeset... but I'll let you know when I figure
>>> out how to do that.
>>>>> There are a great many crazy ideas that hide under
>>> the banner of "security".
>>>>> Here in Arizona we have a traffic camera scam
>>> which is being promoted as "safety". The huge amount of
>>> statistical evidence which proves this to be false is simply
>>> ignored.
>>>> Traffic cameras have been held unconstitutional in the
>>> state of California. I used to live in Arizona; I pity that
>>> you do.
>>>> The problem that those traffic cameras were supposed
>>> to stop can be resolved, much more effectively, by
>>> increasing the length of the yellow light to at least 2
>>> seconds. The bigger problem is that most city councils were
>>> convinced that it could be a revenue-generation system, and
>>> thus most councils directed that yellow lights be shortened,
>>> thus increasing the danger of entering an intersection in
>>> the first two seconds after a green light.
>>>>> Many people are receiving citations for speeding
>>> when in fact they are sick or travelling outside the US.
>>>> ...which is why they've been held unconstitutional in
>>> CA. (As has photo-radar, since the operator of the vehicle
>>> is the one responsible for the violation -- not the owner or
>>> registered owner of the vehicle used for the violation.)
>>>>> Karen
>>>> The point is to identify the end result of what you
>>> want, and you've identified it as "I don't want anyone
>>> fucking with the prims on my grid unless I grant them
>>> permission." You have generalized this to "I don't want
>>> anyone I can't trust not to fuck with the prims on my grid
>>> to connect to my grid," and are now trying to find a way to
>>> enforce that. We've all told you *why* your approach is
>>> flawed. We've all told you *how* your approach is flawed.
>>> We've even tried to provide you with *better directions* to
>>> find the solution to your problem.
>>>> All the while, you've been stubbornly refusing to
>>> accept any solution more complex than the not-a-solution
>>> that you've come up with, and have been vocally defending
>>> something that, to be effective, must be kept secret. (Since
>>> it's no longer a secret, it no longer has any effectiveness.
>>> Congratulations on shooting yourself in the foot.)
>>>> -Kyle H
>>> _______________________________________________
>>> Opensim-users mailing list
>>> Opensim-users at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-users
>>>
>>
>>
>> _______________________________________________
>> Opensim-users mailing list
>> Opensim-users at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-users
>>
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
>