Jump to content

Zero LL security ??


GideaNinja Dagger
 Share

You are about to reply to a thread that has been inactive for 3118 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

A sim owner passed this along to his clients and customers as to why he was having network difficulty.
Apparentyl LL has zero security and no digital signature certificates.

http://dragononlineservices.com/helpdesk/serverstatus.php

 

some highlights--

  • **UPDATE:  We have filed a ticket with Linden Labs (SEC-1555) to address this issue with their servers.  It would seem the lack of any kind of security from their end on the SIM servers (even a self-signed security certificate) is the cause for this issue.  The individual SIM servers LL uses do not have any security or encryption mechanism on them to prevent any kind of hacking or enable any secure transactions what-so-ever when it comes to data transactions of any kind.  This concerns us greatly when dealing with sensitive information concerning account information for the web-site and our members.  When we updated our Security on our servers, they refuse to "talk" to LL servers because there isn't even minimal security on them.

    At this point we will be putting this issue in a "HOLD" until LL updates the security on their servers, and may end up removing the In-World system altogether to avoid any kind of security breaches for our members.

    *** UPDATE:  Since LL seems to be unconcerned about this issue we are working to set up another server on our system with less-then-ideal security to enable the in-world panels to work again.  We are hopeful that this server, which will reside on our internal network, and only be used to change the panels (unless there is further issue with getting information to the in-world system) will resolve the issues seeing in-world.

  • Date - 09/25/2015 23:10
  • Last Updated - 09/28/2015 15:00
Link to comment
Share on other sites

I am not surprised. As a retired IT professional for a major telecommunication company for over 25 years, I have felt that Linden Lab's turning of a blind eye to security in Second Life has ALWAYS been naive at best and criminal at worst. Bottom line, DO NOT DEPEND ON LINDEN LAB TO DO ANYTHING BUT COLLECT YOUR MONEY.

Link to comment
Share on other sites

Excuse the FUD-spreaders, they are mostly crazy.

Sounds like miscommunication or misunderstanding the problem. Secure HTTP is hard, perhaps you don't fully understand it? But it's not surprising given the part you quoted contains inaccuracies for what I can only assume is dramatic effect.

The link does not go to a SEC JIRA, but to a BUG JIRA - in short, this isn't an issue that affects platform security. A cursory reading of the JIRA posting makes this clear.

It sounds like the company at the other end (whoever Dragon people are) were the ones who were trying to send their customer data insecurely into SL. Sometimes certs break, and LL have recently changed their process for this in response to exploits in HTTPS tech. This does not expose any of your Second Life account data - only any data you store with Dragon Online Services. Ordinary users are not exposed by this issue.

The functionality that Dragon people want (the ability to set up a secure link to scripts hosted in sims via the web - for sending data from webservers into SL) will most likely be back. While it is not back, it is likely not adequate security for them to do whatever it is that they do - perhaps they would be breaking data protection laws in their locality. These are normal pressures when relying on online service providers, and is a good thing that Dragon are reacting and keeping LL (and presumably, their customers) informed.

What's probably not necessary is drumming up sensational junk by claiming "LL has zero security". It's not accurate or helpful to any discussion about the problem. These are serious claims and there is no evidence to support them.

Sim is also not an acronym (unlike for cellphones, where it stands for Subscriber Identity Module) and so doesn't need to be capitalised.

Hope this helps. As usual I'll discard follow-ups that focus on the sensational claims instead of facts (unless they're entertaining).

Link to comment
Share on other sites

I have found that there are two types of people inhabiting Second Life. The first, like me, are simply here to have a good time and escape from the real world. The second have elevated Second Life to cult status and react very belligerently if you dare to question the cult leader, in this case, Linden Lab. Bottom line, THE ONLY THING LINDEN LAB IS INTERESTED IN DOING
IS COLLECTING YOUR MONEY. SECOND LIFE IS NOTHING MORE THAN JUST ONE MORE CRAZY CALIFORNIAN CULT AND I DO NOT DRINK THEIR KOOL-AID.

Link to comment
Share on other sites



 


EdmundPendragon wrote:

I have found that there are two types of people inhabiting Second Life. The first, like me, are simply here to have a good time and escape from the real world. The second have elevated Second Life to cult status and react very belligerently if you dare to question the cult leader, in this case, Linden Lab. Bottom line, THE ONLY THING LINDEN LAB IS INTERESTED IN DOING

IS COLLECTING YOUR MONEY. SECOND LIFE IS NOTHING MORE THAN JUST ONE MORE CRAZY CALIFORNIAN CULT AND I DO NOT DRINK THEIR KOOL-AID.

Guestimating your age from your posts it seems that this would be more appropriate for you. 

Link to comment
Share on other sites


EdmundPendragon wrote:

I have found that there are two types of people inhabiting Second Life. The first, like me, are simply here to have a good time and escape from the real world. The second have elevated Second Life to cult status and react very belligerently if you dare to question the cult leader, in this case, Linden Lab. Bottom line, THE ONLY THING LINDEN LAB IS INTERESTED IN DOING

IS COLLECTING YOUR MONEY. SECOND LIFE IS NOTHING MORE THAN JUST ONE MORE CRAZY CALIFORNIAN CULT AND I DO NOT DRINK THEIR KOOL-AID.

Could you put those caps in bold so we can hear you better?

Link to comment
Share on other sites

  • Lindens


Freya Mokusei wrote:

Sounds like miscommunication or misunderstanding the problem.

Pretty much. But it's more productive when people are loud and paranoid about security than when they're quiet and trust blindly. Questions are good.

The reporter has now figured out that they're only encountering a problem when they upgrade their own PHP server to a newer version. Their old code accepted the cert without complaint.

I added a comment to the issue that explains some fundamentals on how to extract the Linden Lab CA certificate and add it to trusted certs in order to properly validate certificates. Hopefully that will get them up and going again regardless of which scripting engine they use.

And yes, a proper SSL certificate has been in place for as long as llRequestSecureURL has existed. We do operate our own CA rather than using a public CA, as generic web browsers aren't the intended consumers for back end LSL APIs.

Link to comment
Share on other sites


Soft Linden wrote:

 

And yes, a proper SSL certificate has been in place for as long as llRequestSecureURL has existed. We do operate our own CA rather than using a public CA, as generic web browsers aren't the intended consumers for back end LSL APIs.

I hope you did a Jedi hand wave while saying that sentence "You are not the customers we are looking for..."

I understand what you're getting at but this approach to a CA is somewhat immature and usually only considered for internal work on an enterprise basis.  While we may not be the customers that you're looking for, the fact that the services are accessible publicly, people will use them in ingenious ways and while that happens, it's not unreasonable to expect a more mature approach to your PKI, one where your internal issuing CA is an intermediate from an existing trusted root CA.

The issue apart from the extra hoops just to import a Linden Lab root CA certificate is the sentence where you said "if you generally trust us".  Of course, that's what it's all about and one could reasonably ask the question "why are you connecting if you don't" but there's a difference between trusting you NOW at this present time and not trusting you after a compromise to your issuing CA, where the customers that you aren't looking for, have been forced to set up a point of trust to a subsequently compromised system.

There's a reason that existing roots exist.  Which of the following is true?

a) A bean counter said "How much?" when presented with the Purchase Order for a suitably issued signing root CA certificate.

b) A developer lashed an internal CA together and said "this will do".

Just curious, it has already been established that we are not the customers you are looking for ;)

Link to comment
Share on other sites

  • Lindens

Your post is based on a wrong premise. The use of a private CA is very common for back end services for financial institutions or for other services that deal in sensitive information. This is not at all limited to enterprise. It's not a less mature approach either. The general trend is one of moving away from public CAs for non-browser web APIs.

Some background basics:

Browsers use common CAs as a matter of convenience; it's a trade off at the expense of increasing users' vulnerability to fraudulent certificates. This is part of the reason why all major browser developers do work to offset that additional exposure. HPKP, certificate class downgrade checks, DNSChain, revocation lists, and Perspectives Project all exist or are under development toward that end.

It's trivial to get an SSL certificate issued without controlling a domain. This isn't the 90s, when even the most basic certificate cost hundreds of dollars and extensive checking was the norm. Standards slipped as certificate sellers began to compete on cost and speed. Smash cut to today, and you can go to many different registrars to have your own certificate issued for just about any uncommon domain within an hour. It doesn't even cost anything anymore. If a domain isn't in Alexa's top rankings, there's often no human checking whatsoever.

So the answer is not (a) or (b) above. It's ©: Given the number of SL services that use external servers to authorize L$ movement or transmit personal information, it's appropriate to treat LSL based services as highly sensitive. Asking SL scripters to implement various fraudulent certificate checks sets a higher bar than does asking devs to rely on a separate CA in order to establish trust.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3118 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...