itman

There is no information in the help files or context menu that says so, also it would be illogical. From the Smart Security ver. 8 user manual: Use HTTPS protocol checking for selected ports – The program will only check those applications that are specified in the Web and email clients section and that use ports defined in Ports used by HTTPS protocol. Port 443 is set by default. Encrypted communication will be not scanned. To enable the scanning of encrypted communication and view the scanner setup, navigate to SSL protocol checking in Advanced setup section, click Web and email > Protocol filtering > SSL and enable the Always scan SSL protocol option. To me this means disable that option and HTTPS traffic will not be scanned. What is unclear is if port 443 was added to the HTTP port list, would it be scanned?

It's already implemented: First activate SSL scanning, after that you can deactivate https-scanning under Web and E-Mail -> Web protection -> HTTP, HTTPS If you do that, then no port 443 scanning will be done. Note that there can be web traffic that uses port 443 that is not encrypted. That is why by default, Eset scans port 443 with SSL protocol scanning disabled; it just ignores encrypted traffic. Also the Eset cert. remains in the Windows root CA using your suggestion which I consider a security risk. Eset should only use the like cert. installed in Thunderbird's root CA. The e-mail SSL protocol scanning options should override globally setting off SSL protocol scanning for everything which currently is the case.

I created a HIPS rule to protect it from modification. Using Process Explorer checked to see if any Eset .dlls injected indicating that it is indeed protected. Zip, Nada, nothing present. Eset .dlls have been injected into everything else where I created a HIPS rule for them. Ieplorer, explorer, etc. have Eset .dlls injected. Emsisoft Anti-malware and EMET have their .dlls injected into Adobe Reader. Just how is Eset protecting Abode Reader?

The "excluded applications" option turns off all protocol scanning for the selected app. I do want my browser HTTP traffic scanned; just not the HTTPS traffic.

You can eliminate the port 137 and 138 issue by disabling NetBIOS for the IPv4 or IPv6 connection for your modem. No reason for NetBIOS to be enabled these days.

I would also like to see SSL protocol scanning decoupled from e-mail scanning. I very much need this feature to scan my Thunderbird encrypted e-mail received from my e-mail ISP. I don't want to turn it on for browser use however.

My advice is go to this web site: https://www.grc.com/x/ne.dll?bh0bkyd2 . Click on "Proceed." Then click on the "Common Ports" tab. It will run a scan to determine if any of the commonly used ports are open and therefore visible to the outside world. All your ports after the scan is complete should show "Stealth."

Well... the researcher (alias the author of the blog post) mentioned that none of the AVs he tested would do this. So all would not scan EV certificates. As for ESET this is wrong as I showed in the topic I linked. However back to your suggestion. Even some guys who want to spread malicious files could register a EV-certificate. It would be quite expensive for them and they would maybe have to hide behind a (fake) company, but it could be possible. Or just think of the file hosters which use an EV certificate. However on the other hand of course sites which host static content (or at least no user-submitted files) could be excluded this way. So I would agree to have an option in the SSL scanning settings to exclude all EV certificates from SSL scanning, but not to do this automatically. The user should be able to choose whom he trusts and whom not. I posted this under a topic in the Smart Security forum and will duplicate here. I believe this is the best overall solution. Also I don't believe this suggestion wouldn't be too difficult for Eset to quickly implement. Here's my suggestion to make SSL protocol usable. Add an option to the Eset's desktop taskbar icon display to turn SSL protocol scanning on and off. You can even add time intervals that it will remain off. This way I could easily turn off SSL protocol scanning when I wanted to use a site where I wanted my privacy maintained and when finished, easily re-enable SSL protocol scanning.

(the same is valid for OCSP stapling too BTW) BTW here is the complete topic about this: https://forum.eset.com/topic/4806-ways-anti-virus-software-lowers-your-https-security/ What Eset should be doing is not unencrypting sites with EV certs. like Avast and Kapersky. Validate the cert pinning path and leave it at that. If you can't trust a web site with an EV cert., you shouldn't be doing business there.

A thought here to point in a source direction. Check your Event log and see if there have been any recent program module updates.

Perhaps because you have Eset's firewall setting set to default; allow all outbound traffic? Switch it to interactive mode and rerun Comodo's leak tests. Also, Comodo's leak tests are test for the firewall primarily with a few HIPS thrown in for good measure.

Here's a few other "goodies" I found about SSL protocol scanning. If you turn it off then turn it back on, Eset will generate a new self-signed root CA cert.. No problem with that. However, any previous certificate exclusions you have established no longer work with the new Eset cert. What the ..............! Appears Eset somehow pins those exclusions to the cert. in existence at the time the exclusion was set. Bottom line, you have to repeat all those exclusions again ............. ridiculous! URL Address Management. Appears to work just fine but has no effect on SSL protocol scanning. I verified this by setting on the notify option and having the popup appear when I navigated to the web site whose URL domain name was excluded. However, when I looked at the root cert in use for that SSL web site, it was Eset's.What the .............! Here's my suggestion to make SSL protocol usable. Add an option to the Eset's desktop taskbar icon display to turn SSL protocol scanning on and off. You can even add time intervals that it will remain off. This way I could easily turn off SSL protocol scanning when I wanted to use a site where I wanted my privacy maintained and when finished, easily re-enable SSL protocol scanning.

When is Eset going to fix this and other security issues of SSL protocol scanning mentioned in the below referenced article? Disabling of HTTP Public Key Pinning Each and every TLS intercepting application I tested(Avast, Eset, and Kapersky) breaks HTTP Public Key Pinning (HPKP). It is a technology that a lot of people in the IT security community are pretty excited about: It allows a web page to pin public keys of certificates in a browser. On subsequent visits the browser will only accept certificates with these keys. It is a very effective protection against malicious or hacked certificate authorities issuing rogue certificates. Browsers made a compromise when introducing HPKP. They won't enable the feature for manually installed certificates. The reason for that is simple (although I don't like it): If they hadn't done that they would've broken all TLS interception software like these Antivirus applications. But the applications could do the HPKP checking themselves. They just don't do it. ref: https://blog.hboeck.de/archives/869-How-Kaspersky-makes-you-vulnerable-to-the-FREAK-attack-and-other-ways-Antivirus-software-lowers-your-HTTPS-security.html

About time to put this thread to sleep. I saw the explorer.exe process running again today that I mentioned previously. Here it is: C:\Windows\explorer.exe /factory,{75dff2b7-6936-4c06-a8bb-676a7b00b24b} -Embedding This is a normal shell execution of explorer.exe. It can be initiated for a number of reasons. No need to get into all that now. It is sufficient to say it is not a malicious process. As far as I am concerned, Eset did indeed update its certificates. Again whether they admit it is immaterial since I have no intentions of activating SSL protocol scanning again. As we say here in the States, "it's not ready for prime time." As far as the screen shots in temp storage, I strongly suspect those were caused by SLL protocol scanning "flaking off" when its exclusion processing of my bank web sites malfunctioned due to the Eset certificate update and EMET certificate pinning interaction. If malware originally updated the Eset certs., it would have most certainly tried again since the original incident. No such activity like that has been observed by me.

Did you notify your bank yet? If someone else really did take those screen shots then you should notify your bank immediately. If they were able to take the screen shots then they were definitely able to obtain that information remotely. Edited 4/28 @10:51: Are you sure they were screen shots? I don't think there is an option to save screen shots as .htm. htm is like html. I'm not sure if the browsers should be saving web images of secure logins in the cache. I think that is the question that should be asked. The other instance of explorer.exe can't be good though. Sorry, they are .html files and I actually saved them in folder on my PC. I did change my bank userid. I am not too concerned since the bank uses multi-factor authorization. The password screen is tied to your PC. Anyone attempting to log into that screen from another PC will have to answer a hidden validation question. Like I said previously, I believe the screen shots were due to the collision of EMET cert validation and Eset SSL protocol scanning. Caused by Eset not excluding the web site as should have.

LiveGrid I have used previously and ran yesterday. Results - all green. Ran SysInspector yesterday and it did not show anything malicious. If this was indeed malware, it must have been an exploit. Also it must have been targeted specially for users of Eset with SSL protocol scanning turned on. A bit of a stretch here ......... The only thing changed in my root CA store was the Eset self-signing cert.. It is also beyond me how it could have added the new Eset cert. to Thunderbird since its certs are stored in a .db file. Nothing else has been changed in Win or Thunderbird root CAs since this incident. If malware had access to those root stores, I assume it would be still attempted to add its own certs there. Below are two screen shots of areas in the registry that Eset appears to use for SSL protocol scanning. If you are using it, check what Eset is storing there. If it's root certificate is there and stored in an insecure manner, it would explain how something could access and update the Eset cert.. However it would have to be running with Creator credentials to do that. Again, I am at a loss to explain how the Thunderbird Authorities root store had a new Eset root certificate added to it.

No. Eset's cert is in WIN's CA root store. It has to be there for Eset to create a new countersigned browser cert for every HTTPS web site. The WIN Root CA is the "Holy Grail" of all areas in Windows. In Thunderbird, the Eset cert was stored in the Authorities store which is the equivalent of WIN's Root CA. If Eset did update their cert's last week, I do not how it could be possible that they could add this new cert to Thunderbird since I had to manually add it originally. The only possible explanation is Eset has an arrangement with Mozilla. Then Thunderbird update processing will search for an issuing authority and if it finds a match will add the new cert to that respective authority. Note the word "add" since the original Eset cert was still present in the TBird Authorities store as shown in my prior posting.

I am really more concerned over how something could update Eset root cert in WIN 7 and in Thunderbird CA area. I did observe how Eset stores it root cert in the registry and it's not locked down like normal root certs are. There is one possible explanation for the screen shots. At the time of the incident as I explained originally, both Eset and EMET were performing pinning activities on the bank web site. This was due to the failure of Eset to exclude the bank web site; appears due to a change in its root certificate. I had the web site set to block mode in EMET which didn't work; I only received the pop-up alert. Again, this occurred due to the pinning conflict. It is possible EMET is actually the process that wrote the pages to temp storage in an attempt to block connection in IE. In a normal scenario, EMET would have deleted those temp storage web pages after blocking them.

Yes, I use Process Explorer on a daily basis usually. No unusual activity or processes. Only issue I have had for some time, well before this incident, is svchost -netsvcs using a huge amount of system memory at boot time. For example, this morning peak usage was over 2 GB! Note I have 8 GB of memory, so that is only 25% of available memory. But rapidly drops to 18 KB or so and stays there afterwards. Only outbound I/O during that time is WIN Updates for the most part.

I just wanted Eset to know that this issue was serious. After the incident, I checked my C:/Users/username directory areas and found .htm screen shots of my bank logon screens; one showing my user id. Of course, I promptly deleted those. Also at the time of the incident, appears a shell or something of the like had started another explorer.exe process using C:\Windows\explorer.exe /factory,{75dff2b7-6936-4c06-a8bb-676a7b00b24b} -Embedding since this was running. I have scanned my PC using multiple AVs and anti-malware plus anti-rootkit software and am clean as a whistle. I also downloaded and ran Eset's PowerLiks cleaner and it did not detect anything. I have had no further above activity like this since the original incident. Of course, I immediately deleted the Eset cert from both WIN 7 root store and Thunderbird and turned off SSL protocol scanning.

Yesterday, I had something occur I can find no logical explanation for. I also find it more than a bit concerning. I went to access my bank site and I received an alert from EMET about a certificate issue. Previously I had excluded all my bank HTTPS sites from Eset's SSL protocol scanning and had pinned those same sites in EMET thankfully. Everything worked fine until yesterday. A bit of PC detective worked yielded the following: 1. Something replaced the original Eset certificate in my Windows 7 root certificate store. From the date on the new certificate, it appeared to occur two hours prior to the access of my bank site or approx. 10 AM EST. Note - I had made no changes to SSL protocol scanning prior to this event. Does Eset periodically update it's self-signed root certificate? If so, then why do prior created exclusions no longer work with the new certificate? 2. Additionally, this same new Eset certificate was added to the root certificate area in Thunderbird? I now had two Eset certificates present in Thunderbird. How is this possible since I had to manually add the original Eset certificate to Thunderbird? Note - am using the latest version of Thunderbird and as I was lead to believe, there is no automatic integration between Eset's e-mail facility and the later versions of Thunderbird. Below are two screen shots of the original and new Eset certificates from Thunderbird. The original certificate is dated 4/14/2015. I am also attaching my EMET event log entry that show the full public key of the new Eset certificate that was installed. EMET_Eset_SSL_Cert_Detection.txt

Elaborating on my initial posting, I believe Eset SS is presently working as designed. Quoting the documentation manual when you select "No" from the initial untrusted certificate prompt, the following occurs: 1. "Marks the certificate as untrusted for the current session - the alert window will be displayed on the next attempt to use the certificate. 2. "You can select Block communication that uses the certificate to always terminate an encrypted communication to a site that uses the unverified certificate. The connection is indeed being blocked, but only for this specific instance. Hence, when the web page again attempts to access the bad cert, the whole process repeats. In my instance, the web page was repeatedly trying to access the bad cert and I was stuck in a loop. My recommendation is to add the following: 1. An "Untrusted" section to the existing "Trust" and "Exclude" sections where bad certs would be stored. 2. Add a "No, always" option to the existing unknown/unverified cert prompt. This will mark the certificate as untrusted for all sessions and will add it to the list of untrusted certificates - no alert windows will be displayed for untrusted certificates. All communication using this certificate will be automatically blocked. Additionally, I recommend Eset provide wording on the initial SSL warning window to click on the shown cert name to determine the issue with the cert. The average user would not know to do that.

A bit more info on this incident. I checked the source code on my browser home page and the actual connection was to a sub-domain: https://comet.yahoo.com/comet. Also this web site cert was expired since April 10 and I was only alerted to a problem by Eset on April 19. I believe also that the only reason I was alerted was because there finally was finally an issue with the cert path validation. I consider this a serious problem with Eset since I can no longer trust that it will properly verify the web site certificate when the SSL protocol scanning option is enabled.

I just checked domain comet.yahoo.com at Quals. Its thumbprint is 45a7c9c571177f12486686dd53c0f08ec7efa31f Here is a screenshot of the original cert. with its thumbprint.It is clearly expired: Eset forum will not let me attach the actual .cer file What I figure is going on is AT&T hasn't updated its cert server with the correct certificate. The thumbprint you posted is for the root CA cert. -EDIT- Had a "brain cramp" when I originally posted this ......... Attached is a zip folder containing the cert. comet.yahoo.com.zip

I am on the public profile and my Internet connection is just fine. I am connected to my router via a D-Link USB WAP; ID of which is what is penciled out in the screen shot.