We have detected that cookies are not enabled on your browser. Please enable cookies to ensure the proper experience.
Page 2 of 2 FirstFirst 1 2
Results 26 to 42 of 42
  1. #26
    Join Date
    Jun 2010
    Posts
    7,583
    Quote Originally Posted by Hurin View Post
    I'm sorry, but you really should know what you're talking about before you presume to dictate to others what they should post.

    I don't normally put a lot of stock in credentials. But in this case, it might help others to know that I'm a Network and Systems Administrator. Oooooooo!

    ....
    You don't seem to realize, this flaw became known (at least to the good guys) yesterday (or the day before). It has existed for two years. Knowing about something and that something existing are not synonymous.

    One of the rare instances where someone brandishes their creditantals with not only a title but detailed facts.

    That said, one minor disagreement. It became 'widely' known yesterday. The understanding I had was that attempts had been made to get the issue addressed privately before the public disclosure was made. The public disclosure simply forced people to stop messing around and get it done so that users could do their part. Stat.
    Crell-L85-Champion - Riddermark ; Swego-L85-Burglar ; Kotvi-L95-Runekeeper
    Delego-L85 Hunter ; Stodden-L51-Captain ; Edhul-L61-Loremaster
    Deglorion - SoA XP Disabler

  2. #27
    Join Date
    Feb 2007
    Location
    USA
    Posts
    4,312
    Quote Originally Posted by Crell_1 View Post
    One of the rare instances where someone brandishes their creditantals with not only a title but detailed facts.

    That said, one minor disagreement. It became 'widely' known yesterday. The understanding I had was that attempts had been made to get the issue addressed privately before the public disclosure was made. The public disclosure simply forced people to stop messing around and get it done so that users could do their part. Stat.
    Heh, I actually paused as I wrote that. . . and thought about being even more precise. But then didn't want to complicate the narrative even further and just assumed it would be clear that those who announced and released the patch to OpenSSL have probably known about the issue a bit longer than the rest of the world (to say nothing of the person who originally reported it to them. . . someone from Google if memory serves?). I hadn't heard about anyone trying to bring this to the OpenSSL team earlier. But I wouldn't be surprised.

  3. #28
    You guys are really expecting T to comment on this?

    Have you all forgotten, or were you actually unaware of, the fact that prior to the forum revamp they didn't even USE a https connection to transmit your login credentials to Boston, MA, but sent them plaintext across the world?

    They didn't deem us worthy of an acknowledgement or apology, let alone a fix back then, so you probably shouldn't hold your breath for them to speak up now.

    SNy

  4. #29
    Quote Originally Posted by SNy-lotrolinux-EU View Post
    You guys are really expecting T to comment on this?

    Have you all forgotten, or were you actually unaware of, the fact that prior to the forum revamp they didn't even USE a https connection to transmit your login credentials to Boston, MA, but sent them plaintext across the world?

    They didn't deem us worthy of an acknowledgement or apology, let alone a fix back then, so you probably shouldn't hold your breath for them to speak up now.

    SNy
    Heck, they expended significant amounts of ammunition shooting the messengers.

  5. #30
    Join Date
    Jun 2010
    Posts
    7,583
    Quote Originally Posted by SNy-lotrolinux-EU View Post
    You guys are really expecting T to comment on this?

    Have you all forgotten, or were you actually unaware of, the fact that prior to the forum revamp they didn't even USE a https connection to transmit your login credentials to Boston, MA, but sent them plaintext across the world?

    They didn't deem us worthy of an acknowledgement or apology, let alone a fix back then, so you probably shouldn't hold your breath for them to speak up now.

    SNy
    I hope that with the increased amount of communication since Rowan has joined the team. someone will see fit to comment. Yes, I remember that issue and others, which to me were more serious, but which do not seem worth repeating here. It shouldn't take someone long to stop by and say 'You're good to go ahead and change your passwords now, we strongly recommend doing so regularly, even in the absense of any particular alarming incidents to the contrary being brought to light'.
    Crell-L85-Champion - Riddermark ; Swego-L85-Burglar ; Kotvi-L95-Runekeeper
    Delego-L85 Hunter ; Stodden-L51-Captain ; Edhul-L61-Loremaster
    Deglorion - SoA XP Disabler

  6. #31
    Quote Originally Posted by Amrundir View Post
    My guess is, they never were affected.

    Check the server certificates. They are from 2012. If the server were affected, they had to replace the server key and certificate, too. Which is obviously not the case.
    That highly depends. I'm sure the Turbine server admins are well aware of the implications of this leak (as should anyone who manages servers). However, I've seen people just update openssl and be done with it. No renewal of public facing SSL certificates, no renewal of private server keys etc. I'm not saying Turbine have been slacking, their servers have been in service for a while and are most likely running an older (meaning a 0.9 branch, which does not imply less security!!) version of openssl that is not affected by this bug.

    For people who need a less technical explanation of this problem, read http://security.stackexchange.com/a/55350/43874. This excellent answer tries to explain it using as little tech lingo as possible and explains the few terms it has to use.

  7. #32
    Quote Originally Posted by Rhyaehar View Post
    That highly depends. I'm sure the Turbine server admins are well aware of the implications of this leak (as should anyone who manages servers). However, I've seen people just update openssl and be done with it. No renewal of public facing SSL certificates, no renewal of private server keys etc. I'm not saying Turbine have been slacking, their servers have been in service for a while and are most likely running an older (meaning a 0.9 branch, which does not imply less security!!) version of openssl that is not affected by this bug.

    For people who need a less technical explanation of this problem, read http://security.stackexchange.com/a/55350/43874. This excellent answer tries to explain it using as little tech lingo as possible and explains the few terms it has to use.
    You're forgetting that the forums were completely overhauled mid-last year. That's usually a prime opportunity for an upgrade to the latest server packages, which would include the vulnerable version of openssl.

  8. #33
    Currently, they are safe. There is a tech site in Germany that deals a lot with security issues in a way that laypeople can still understand the language, yet they don't dumb it down to over simplistic know-it-all-stories. The english branch simply calls itself The H. They tried several internet tools that check web sites for the heartbleed vulnerability, and found that lastpass doesn't only check for the current existence of this vulnerability, but also if there had been a recent change on the site, indicating that it might have been affected in the past.

    But the result of this check is not really perfect; in fact they found a good number of false positives, making people believe that they cannot trust a site that actually hadn't been vulnerable at all. Because of this, The H recommends the use of SSL-Tools.net which will give more reliable results. It is the page where the screenshots are from, that Brandon_Blackbird made.

    Edit: I just found that The H was shut down last year, because they couldn't make enough revenue. There is only the German page left.

    To make things worse: There seems to have been a zero-day exploit. https://www.eff.org/deeplinks/2014/0...-november-2013


    Greetings, Polymachos
    Last edited by Polymachos; Apr 11 2014 at 04:33 AM.

  9. #34
    Join Date
    Aug 2008
    Location
    Cookie Land
    Posts
    1,617
    Probably unrelated; but my Bitdefender scan just deleted two files.

    C:\Games\Turbine\The Lord of the Rings Online\turbineclientlauncher.e xe

    and

    C:\Games\Turbine\The Lord of the Rings Online\TurbineLauncher.exe

    Claiming they were infected with Gen:Trojan.Heur.Rootkit.dr1@cC mAy2mib


    Needless to say: the game will not start without these files being present.

  10. #35
    Join Date
    Jan 2008
    Location
    East coast, USA
    Posts
    1,910
    Quote Originally Posted by RKL View Post
    Probably unrelated; but my Bitdefender scan just deleted two files.

    C:\Games\Turbine\The Lord of the Rings Online\turbineclientlauncher.e xe

    and

    C:\Games\Turbine\The Lord of the Rings Online\TurbineLauncher.exe

    Claiming they were infected with Gen:Trojan.Heur.Rootkit.dr1@cC mAy2mib


    Needless to say: the game will not start without these files being present.
    Definitely unrelated. Even if the detections on your machine were not false positives, it would not be a Heartbleed issue.

    As for the files, I have LOTRO on 2 machines with a variety of scans running. One of the clients was just recently added for testing and neither have come up with any alerts on LOTRO files.

    Bitdefender is not one I use, so maybe someone else who does can test to confirm, but you may want to keep it out of this thread to avoid confusing the topics. Good luck getting things fixed up quickly so you can get back in the game.

  11. #36
    Join Date
    Jul 2007
    Location
    NYC
    Posts
    1,866
    Quote Originally Posted by frickinmuck View Post
    Until we have final word from Turbine on this, it would be unwise to assume that the sites are vulnerable, or that they are not. We just don't know. The sites that supposedly test for this vulnerability give different and conflicting results. The only authority I will trust on this matter is Turbine.
    http://m.youtube.com/watch?v=XFTihsjO-og

    Even if there's any problem, do you think we would be notified? That's not how corporations work (and Turbine is part of one, either you/hem want it or not).

    Wise words? Well, Jeff Skilling was wise...

  12. #37
    Quote Originally Posted by Sardonyx View Post
    You're forgetting that the forums were completely overhauled mid-last year. That's usually a prime opportunity for an upgrade to the latest server packages, which would include the vulnerable version of openssl.
    Webservers tend to run older, more proven versions of software. Having said that, I can only guess at the exact version of the openssl software they run. Given that they run on nginx 1.1.19 (released april 2012) however, leads me to believe that the servers are running an older version of Debian like squeeze, which packs the 0.9 branch of openssl.

  13. #38
    There are several issues about the Heartbleed bug

    Part The First

    Changing your password on an affected system prior to a complete repair is not effective. There are 3 things that a provider needs to do to resolve the error:

    1. Apply the patch.
      Yes the code is trivial.
    2. Re-Encrypt their entire system.
      This means re-creating all master encryption keys and cascading down from the top
    3. Re-acquire a new SSL certificate.
      There are substantial delays as the CA are swamped and it costs money to get new ones so some companies may need to arrange for payments. There are systems with thousands of servers and those systems may require thousands of certificates.


    Until all of the above happens, changing your password is ineffective for that system

    Part the Second

    Whether you change your password or not, if the provider does not complete all the steps their system remains vulnerable and any data taken is already lost. It will only protect data going forward.

    The way the bug works is that a "stay alive" ping exchange from the client (any client) to the server pulls 64K chunks of active server heap memory per ping exchange. This means whatever is in the 64k heap gets returned to the requester. It's not what's on the hard drives but what's active in the server memory at the time.

    One of the most active sections of server heap memory are the areas reserved for security validation but anything in the heap can be returned. So, user names, passwords can be pulled along with those great photos someone just pushed up on Facebook and all the twitter login credentials and banking information, email and instant message can be in the heap.

    It's a giant grab bag for the person doing the ping. Like a box of chocolates, you never know what you might get. And like a box of chocolates you can keep on eating until you get what you like.

    Some systems MAY have full encryption on both the data packets as well as the data inside the packet or multilayered encryption. Unless the chocolate box returns the master and subordinate keys for that packet, the data is useless. However, a vast number of systems do not do multilayered encryption or when sending data to a "trusted" source send it "clear text".

    If the box yields up the master keys and/or the data is in clear text well you got the Truffle with the Cherry in it.

    Take Away

    The fix isn't hard to implement but it may take time. Responsible companies are responding to the status of their vulnerability and patching process. Any data already taken is "gone with the wind" and the object is to prevent future data from being compromised.


    These 2 sites have listings of major providers and their Heartbleed status.

    Whoever says “I” creates the “you.” Such is the trap of every conscience. The “I” signifies both solitude and rejection of solitude. Words name things and then replace them. Whoever says tomorrow, denies it. Tomorrow exists only for him who does not seek it. And yesterday? Yesterday is Kolvillàg: a name to forget, a word already forgotten.

    The Oath: A Novel by Elie Wiesel

  14. #39
    Join Date
    Feb 2007
    Location
    USA
    Posts
    4,312
    From my much longer post. . .

    Quote Originally Posted by Hurin View Post
    I can't say for sure, but my impression is that Turbine has done step 1 (if they were ever vulnerable to begin with). . . but the date of the certificate currently up indicates that step 2 hasn't been done yet or has been deemed not to be necessary if they were never vulnerable. Based on the version of SSL and TLS they are using as of today, I would guess that step 1 was necessary and step 2 will be happening soon.
    It has come to my attention that (apparently) it's possible to get a certificate reissued or recreated without resetting/changing the "issued" date. So it's technically possible (again, I'm told) that Turbine may have also done step 2 and it's just not terribly apparent to us out here.

    I only work with generating and installing SSL certificates a couple times per year in my duties. So I'm not exactly an expert in their finer points.

    As always, word from Turbine would be appreciated so that we can stop engaging in conjecture about this very real and potentially worrisome issue.

  15. #40
    Quote Originally Posted by Hurin View Post
    From my much longer post. . .



    It has come to my attention that (apparently) it's possible to get a certificate reissued or recreated without resetting/changing the "issued" date. So it's technically possible (again, I'm told) that Turbine may have also done step 2 and it's just not terribly apparent to us out here.

    I only work with generating and installing SSL certificates a couple times per year in my duties. So I'm not exactly an expert in their finer points.

    As always, word from Turbine would be appreciated so that we can stop engaging in conjecture about this very real and potentially worrisome issue.

    A note about SSL Certs:

    Before you get a new certificate companies need to revoke their current certificate as part of the process, otherwise the new one might be compromised. So the Cert re-issue is 2-fold: Revoke Old; Get New in that order.

    This is another reason the Certificate Authorities (CAs) are swamped. Plus there are only a few CAs.
    Whoever says “I” creates the “you.” Such is the trap of every conscience. The “I” signifies both solitude and rejection of solitude. Words name things and then replace them. Whoever says tomorrow, denies it. Tomorrow exists only for him who does not seek it. And yesterday? Yesterday is Kolvillàg: a name to forget, a word already forgotten.

    The Oath: A Novel by Elie Wiesel

  16. #41
    Join Date
    Jun 2011
    Location
    Germany
    Posts
    2,036
    Quote Originally Posted by SabrielofLorien View Post
    Before you get a new certificate companies need to revoke their current certificate as part of the process, otherwise the new one might be compromised. So the Cert re-issue is 2-fold: Revoke Old; Get New in that order.
    First, make sure, your CA is not affected.

    How should the old certificate compromise the new one? I ask my CA for a new certificate. When I get it, I shut down my server process, replace the certificate (usually a simple text file) and restart the server.

    I just quote part of a mail from thawte (a CA).
    ...
    -Install the new SSL certificate and test your installation.
    -After the new certificate is successfully installed, revoke any certificates that were replaced.
    ...

  17. #42
    Quote Originally Posted by Amrundir View Post
    First, make sure, your CA is not affected.


    Quote Originally Posted by SabrielofLorien View Post

    Before you get a new certificate companies need to revoke their current certificate as part of the process, otherwise the new one might be compromised. So the Cert re-issue is 2-fold: Revoke Old; Get New in that order.
    How should the old certificate compromise the new one? I ask my CA for a new certificate. When I get it, I shut down my server process, replace the certificate (usually a simple text file) and restart the server.

    I just quote part of a mail from thawte (a CA).

    ...
    -Install the new SSL certificate and test your installation.
    -After the new certificate is successfully installed, revoke any certificates that were replaced.
    One should always follow the instructions given directly by the issuing company but the reason you need to revoke the old one before installing the new one has to do with the order in which the encryption keys are done on your system. It is possible to contaminate your new SSL Cert with the now obsolete/bad versions of the public/private key, sort of piggy back problem.

    You can ask your CA about this to see if this affects how their certificates work in this instance. It maybe that the "normal" process used presumes a "good" public/private key set and in the case of the Heartbleed bug, some pieces of that set may be compromised. There is also some indication that the pieces of the SSL may not be compromised only keys derived from the base set.

    The other possibility is that when you revoke your SSL Cert all the items that rely on SSL Certs being in place will barf. So, to avoid a barf you delay the revoke until you have the replacement ready to go.

    Again, you would need to discuss this with the CA and other security knowledgeable folks who understand how your system is put together. It varies and it may or may not make a difference in your situation.
    Whoever says “I” creates the “you.” Such is the trap of every conscience. The “I” signifies both solitude and rejection of solitude. Words name things and then replace them. Whoever says tomorrow, denies it. Tomorrow exists only for him who does not seek it. And yesterday? Yesterday is Kolvillàg: a name to forget, a word already forgotten.

    The Oath: A Novel by Elie Wiesel

 

 
Page 2 of 2 FirstFirst 1 2

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

This form's session has expired. You need to reload the page.

Reload