gregorio2

Thanks Marcos, I thought I had done a proper search of the ESET_config.xml that I got from choosing export from bottom of initial Setup page, Went back and searched again and yeah, there it was, I will cut and paste from that file to one I have saved for laptop and import. Desktop is setup for aggressive scans because it is fast, but laptop set to defaults because it is slow single core. Again thanks, Marcos

Wanted to export Banking and Payment Protection, BBP, Protected websites list to another computer and also for backup. I opened regular settings export which is in .xml and did not see it there. My list is long because I manually added all sites I regularly make bank payments to, not just banks, but utilities, insurance, credit agencies, anyone with auto-pay on my bank accounts. Best I could figure would be to individually copy each line because page copy does not work except for Print Screen. Anyone know if there is .dat or .xml file hidden somewhere? Looked through AppData, ProgramData and Program files and exported settings file already. Did I miss it? ProgramData/ESET/ESET Smart Security/local.db was only file I found that updated same-time I added new address. But that file is in constant use. Plus my database browser would not open it.

Haole Boy seemed to indicate in 2nd post that ESET Moderator's suggestion worked, since he thanked him twice. But, I had no such luck! Did anyone else have luck? Per ESET Moderators suggestion: "If you use LastPass, just enable pre-release updates to get the latest BPP module which supports it." I went to advanced setup/Update/Basic/Update type/ and set as Pre-release update and saved. Went to Update and clicked Update now. After update, I checked Product update and it is at latest, 9.0.375.0 . Opened ESET Banking & Payment protection which opened Chrome Version 50.0.2661.75 m (64-bit) with "Secured by ESET" flag on top bar. Tried loading 3 different LastPass Extensions: 1. From Get more extensions / chrome webstore / Version: 4.1.6 - Updated: April 14, 2016 2. From https://lastpass.com/misc_download2.php - LastPass for Chrome (No Binary Features) - https://chrome.google.com/webstore/detail/hdokiejnpimakedhajhdlcegeplioahd Which it turns out is same as 1. 3. From Lastpass support ChrisN sent link to a Pre-build version https://lastpass.com/lpchromepre.php Which said in info section that it too was Version: 4.1.6 - Updated: April 14, 2016 All 3 versions gave same error: "Package is invalid: 'CRX_FILE_NOT_READABLE'." LastPass extension loads in Secure IE11 just fine with no hiccups. Too bad I can't stand using IE11. Okay ESET Staff, please answer this. I wanted ESET Banking & Payment protection to work in Chrome as it does in IE. Support Chat is submiting feature request to developers for a change to let LastPass Extension load in Secure Chrome as it does in Secure IE. A product functionally difference was the reason the error occurs according to Chat Help and request for feature change was submitted by LauraG. "We submitted a feature request for Last Pass to be added as an allowed extension in Google Chrome. " per email after chat. Over at LastPass support after I told them the prebuild extension did not work they pointed me to this thread and that only ESET could fix this.

Arakasi, The four tools listed on Hut3's blog as good or fixed are: https://www.ssllabs.com/ssltest/index.html hxxp://possible.lv/tools/hb/ hxxp://nmap.org/nsedoc/scripts/ssl-heartbleed.html hxxp://heartbleed.criticalwatch.com/ edited I will not list all that failed to detect, go to blog, but total listed as tested was 15 with 4 good or fixed. edited The 3 most used were tested, The four tools listed on Hut3's blog as good or fixed are: https://www.ssllabs....test/index.html hxxp://possible.lv/tools/hb/ hxxp://nmap.org/nsed...heartbleed.html hxxp://heartbleed.criticalwatch.com/ edited I will not list all that failed to detect, go to blog, but total listed as tested was 15 with 4 good or fixed. edited The 3 most used were tested, Symantec's was not tested. Flilippo noted the script and said to be working on it: hxxp://www.reddit.co...test_site_ama/# ( hxxp://filippo.io/Heartbleed/ ) This is significant in that, it is basis for Chrome extension: Chromebleed: "Chromebleed uses a web service developed by Filippo Valsorda and checks the URL of the page you have just loaded." The Hut3 tool is a python script and needs to run with python and so is not for general use like most of the other tools.t. Filippo noted the script and said to be working on it: hxxp://www.reddit.com/r/IAmA/comments/233161/i_am_the_author_of_the_heartbleed_test_site_ama/# ( hxxp://filippo.io/Heartbleed/ ) This is significant in that, it is basis for Chrome extension: Chromebleed: "Chromebleed uses a web service developed by Filippo Valsorda and checks the URL of the page you have just loaded." The Hut3 tool is a python script and needs to run with python and so is not for general use like most of the other tools.

Over at possible.lv they had note to sys admins I had not heard before: "Patch your OpenSSL and statically linked binaries; Change your certificates, if you've been affected." That part about binaries not heard before. Also possible.lv updated at CNS Hut3 blog as fixed tool. hxxp://possible.lv/tools/hb/

On blog over at CNS Hut3 they have posted results of tests on Heartbleed detection tools and have developed their own and provide gist of how they developed it. They also pointed out that 95% of current tests are providing false feel good results and false vulnerables: hxxp://www.hut3.net/blog/cns---networks-security/2014/04/14/bugs-in-heartbleed-detection-scripts- The date on blog is Apr 14, 2014, so some of those detection tools may have fixed their respective tools if they paid notice of CNS Hut3's work. A few updates to blog show some have done just that. A review of that work and other insight over at theguardian.com: hxxp://www.theguardian.com/technology/2014/apr/16/heartbleed-bug-detection-tools-flawed Heartbleed bug and all those suspect certificates are far from being cleaned up. Reported arrest in Canada of Heartbleed hacker: hxxp://arstechnica.com/tech-policy/2014/04/heartbleed-hacker-arrested-charged-in-connection-to-malicious-bug-exploit/

Arakasi posted link to another test at hxxp://filippo.io/Heartbleed/ . Results: / All good, forum.eset.com Fixed or seems unaffected! / End results. The results are similar to the no detail, feel good results McAfee gave. That is why I posted the results from LastPass that showed Apache server which usually uses OpenSSL. Marcos posted link to ESET blog that at bottom had this quote: "Web services are not used ESET affected versions of OpenSSL, customers therefore do not change passwords." That quote is neither clear or referencing forums.eset.com. I assume Marcos you were pointing to that vague quote. But it seems to imply ESET did use OpenSSL and therefore should replace certificates even if they are currently using safe version or not using OpenSSL now. They have not replaced certificate since 4/9/2013.

Marcos, do you speak for the person maintaining that server? A shorter answer then the short long story would be the version of SSL that is used. Edit: I finally read to bottom of link Marcos provided. See reply below.

The Heartbleed OpenSSL bug has definitely brought out the paranoid side to any web activity. It behooves all who run HTTPS sites to first check their site maintenance and if at any time since Dec 2011, OpenSSL Versions 1.0.1a through 1.0.1f were used, then 1.0.1g should be applied and certificates re-keyed or revoked and new ones issued. If OpenSSL was replaced certificates still must be re-keyed or revoked and new ones issued. I would like all HTTPS sites to make it publicly clear that they have checked and addressed this to take some of my paranoia away. Even if they did not use OpenSSL!! LastPass and McAfee both have posted tools to check sites. LastPass tool link found by going to their blog page and searching for Heartbleed article. I used it to check this page and results follows: /LastPass Heartbleed Checker Site: forum.eset.com Server software: Apache/2.2.15 (CentOS) Was vulnerable: Probably (known use OpenSSL, but might be using a safe version) SSL Certificate: Possibly Unsafe (created 1 year ago at Mar 14 22:40:10 2013 GMT) Assessment: It's not clear if it was vulnerable so wait for the company to say something publicly, if you used the same password on any other sites, update it now. /End of results. Since supposedly 66% of internet or 66% of HTTPS sites use OpenSSL that paranoia is probably good right now and also why techs stocks are nose diving right now. Please ESET post as why you have not replaced your certificate. Or tell us you have not used OpenSSL since most Apache servers usually do. If the bad guys compromised the certificates then the man in middle attack is like an in the clear wire tap, right? tool links: hxxp://tif.mcafee.com/heartbleedtest?utf8=%E2%9C%93&q=forum.eset.com&commit=Scan https://lastpass.com/heartbleed/ Edit: Earlier I said revoke and re-issue certificate because most blogs I read said that but re-keying is being cited as what maybe all that is necessary. The details are between the CA and the server in question to determine that question. Here lies another question as how each website handles this risk to customers. Certificates are not free and neither is time paid to have this problem fixed. Re-keying is sometimes free except for time to do it. And is re-keying anywhere reflected in certificate by a date? It does not seem to be if looking at standard certificate details page?? Only dates I see are issue and expire dates.