Strange intermittent https blocking

[charlestek]

Mbam 2.1.0.0002 with Webroot Secure Anywhere.  Intermittently https://www.google.com gets blocked and/or other https sites on Chrome and IE11.  Using windows 7 Ultimate 64 bit.

 

Just tried disabling malicious website protection, doesn't appear to be the issue.    Not too sure it is MBAM itself actually doing this.   This has been going on for a couple weeks.

Mbam log attached.

CheckResults.txt

[charlestek]

Previously on a different topic this occurred with MBAM and KIS 2014, though removing both still seemed to have the issue.    Have other laptop running win 8 and MBAM and WSA, no issues at all.

[Firefox]

Hello and

Looks like your version is NOT Mbam 2.1.0.0002 (that is the version for the check tool)

Your version installed is Malwarebytes Anti-Malware: 2.0.2.1012

That being said, can you provide a copy of some of your protection logs when the blocks occurred?

Also please read the following and post back the requested logs.

Diagnostic Logs

Thank you

NOTE: There is an FAQ section with valuable information located here:

Common Questions, Issues, and their Solutions

[charlestek]

Oddly, firefox does not seem to be affected.

[Firefox]

Maybe you can reset your browser settings in IE to see if that helps.

Please visit each of the following sites and lets reset all of your browsers back to defaults to prevent unexpected issues.

If you are not using one of the browsers but it is installed then you may want to consider uninstalling it as older versions of some software can pose an increase in the potential for an infection to get in.

Internet Explorer

How to reset Internet Explorer settings

Firefox

Click on Help / Troubleshooting Information then click on the Reset Firefox button.

Chrome

Chrome - Reset browser settings

Opera

How to Perform a (really) clean Reinstall of Opera

[charlestek]

In my opinion there is no logic to resetting browser settings given the intermittent nature of this issue and given that firefox has not been affected. Browsers are up to date.

 

Previous discussion had me doing a lot.   https://forums.malwarebytes.org/index.php?showtopic=148609&hl=

A second ago chrome started blocking me from posting a reply to this topic, so I had to switch to firefox.  But for the previous 20 minutes chrome had not blocked https:/forums.malwarebytes.org.

I'd even wonder if there is someone maliciously affecting my web browser get or post.  There is no rhyme or reason for what is happening.

FRST attached.   I will try to do a formal support request under my paid version, but would be glad to get more input from this topic.

 

 

FRST.txt

[Firefox]

There are a lot of policies in effect on this computer, if you want to have an expert look over the computer to make sure its not infected then you will have to follow the instructions below....

To make sure you are not infected, feel free to follow the instructions below to receive free, one-on-one expert assistance in checking your system and clearing out any infections and correcting any damage done by the malware.

Please see the following pinned topic which has information on how to get help with this: Available Assistance for Possibly Infected Computers

Thank you

[charlestek]

I just reset chrome browser setting, it did not help.   For what it is worth, it appears that after shutting down chrome and restarting it, I might be able to send one https request, then suddenly they start getting blocked.

[charlestek]

Those policies were there before I had this issue.   I do not believe that is the problem.  Those policies exist on my laptop as well which is not affected.

[charlestek]

This issue started after I had both MBAM and Kis 2014 installed.  If they were doing their job the probability that malware is causing this is less likely.

[charlestek]

Just tried uninstalling HitmanPro.Alert  Things look ok for a moment, but this problem is notorious for suddenly disappearing then reappearing for hours or a day.

There is no detailed info on how to completely uninstall HitmaPro.Alert or how the vaccination or protection works along the lines of whether it could have been blocking https.

But I never saw any alerts given by HitmanPro.Alert .   Just posted to the Wilders security forum for HitmanPro.

[charlestek]

I spoke too soon.  With HitmanPro.Alert uninstalled https just started acting up, primarily google and https://www.malwarebytes and https://forums.malwarebytes oddly https://www.donationcoder works in chrome.

Firefox seems unaffected.

[charlestek]

Appear to have found the issue.  After weeks of combing the internet with google, when https://www.google.com was working, I seem to have found the issue.  I turns out that when I had Kaspersky Internet Security Installed and MalwareBytes at the same time, I also experimented with installing Comodo Programs Manager:  http://www.comodo.com/home/support-maintenance/programs-manager.php

which gave me several blue screens because of a Comodo Driver.   In addition, I have an older version of Comodo Dragon installed.

 

Sometime after having the Comodo Programs Manager uninstalled, I began to have the strange https problem where connections would work for awhile, then stop. Then suddenly work a day later or something terribly unpredictable.

 

This author, Jonas Lieb describes the problem almost exactly as I have been experiencing it:  http://www.jonas-lieb.de/blog/2013/12/13/fixing-chrome-ssl-connection-error-caused-by-comodo-products/, in his case caused by a faulty Comodo Dragon installation.

 

 

 

DEC 13TH, 2013

A couple of months ago, I lost my precious Google Chrome browser (running on Windows 7, 64bit): All of the sudden (not so much as I will find out later), Chrome was not able to establish secure connections anymore.

Problem description

The symptoms where a little bit unclear: When I would start the browser, I was able to reach secure sites (with the https:// prefix, port 443) for about 30 seconds. Afterwards, it would always get stuck in the “Establishing secure connection” stage for new connections, until ERR_CONNECTION_TIMED_OUT. The connections that were established in these first moments seemed to work for the rest of the session and usual http traffic (TCP port 80) was not affected.

Researching solutions on the internet yielded a lot of open questions and problems, including obvious solutions as checking firewall settings, reinstalling Chrome, clearing the ssl cache or disabling TLS 1.2 (which is not possible in anymore in current Chrome versions). All of these solutions did nothing for me.

Finding and Resolving the Issue

So, I monitored my network connections with packet capture software (Wireshark). First everything went as expected. But even when the secure connections started to fail, I could clearly see that the handshake completed (SSL Client Hello, Server Hello, Certificate, Client Key Exchange, New Session Ticket), but there was silence after the handshake until Chrome finished and reset the connection 20 seconds later (TCP FIN followed by RST flag). Comparing that behavior to Firefox (which still worked; for comparison, I also enabled TLS 1.2), it was clear that it was Chrome’s turn to send data.

The fact that the connections which were established in the first seconds worked for an entire session indicated that some kind of data would be cached, probably certificates. Additionally, because the amount of websites that I could load was not limited by a certain number, but a certain time period, it was quite obvious that my connections were victims of a race condition. So I fired up Sysinternals Process Monitor, filtering only events from the chrome.exe application. After a few tries, the experiment was set up and ready to capture Chrome’s faulty behavior. I started Chrome and navigated to a lot off different web pages, pinpointing the exact time of failure. Using Wireshark and Process Monitor, I found out that at the time of the failure, Chrome just finished reading a lot of certificate files (having to do with different Certificate Authorities and revocation lists). There were especially a lot of accesses to the certificate stores issuers.sst and subjects.sst (located at ... \AppData\LocalLow\COMODO\CertSentry).

Research on the internet showed that these files were remnants of an old COMODO Dragon installation that I got tricked into earlier this year and that had not finished correctly. If one tries to delete them, they are recreated moments after by the DLL certsentry.dll (located at C:\Windows\system32 and C:\Windows\SysWOW64). Using regsvr32 -u certsentry.dll and Unlocker, I was able to unregister and delete the files making a deletion of the certificate stores permanent. After a couple of reboots, Chrome worked again as intended.

But I did not stop here. To further investigate the issue, I kept copies of the DLL files and the certificate lists. Using Dependency Walker, I was able to confirm that there were dependencies on crypt32.dll, cryptnet.dll and cryptui.dll. The certificate stores could be opened with certmgr and included certificates which I had used during my tests (e.g. Google, LastPass, AdBlockPlus, akamai [facebook]). They were still valid though.

Explanation and Conclusion

Earlier this year, I had to manually cancel a COMODO setup procedure and remove all of its remnants. During that procedure, I missed the DLL files certsentry.dll in my system folder which were still being hooked by Microsoft Windows cryptography modules, creating the files issuers.sst and subjects.sst in my user data folder. When Google Chrome is started, the user can immediately start browsing while the certificate stores are loaded. This leads to a race condition. Once all files have finished loading, new SSL connections also fail after completing the handshake. There are a couple things that Chrome and COMODO could learn from these situations: First of all, the asynchronous loading of security files could also be very dangerous since the user does not seem to be protected by the COMODO mechanism in the first seconds. Secondly, there should be a reasonable error message informing the user of SSL errors instead of a time out exception.

For me, I am very satisfied with the result, especially since I have a game jam coming up where I wanted to make use of HTML5 technology, which is faster and more stable in Chrome than it is in Firefox.

Posted by Jonas Lieb

Dec 13th, 2013

 

[charlestek]

Comodo Dragon Certsentry.dll is described here: http://help.comodo.com/topic-120-1-279-4652-.html

 

Mick in this Comodo forum post descibes similar SSL issues in other Win apps from Dragon's installation:  http://forums.comodo.com/firewall-help-cis/cis-62-and-redundant-crl-certificate-revocation-list-requests-t96843.0.html;msg725002#msg725002

 

I posted in the Comodo forum, with somewhat of a rant about Comodo not warning what Dragon does to SSL revocation effects to other non Comodo apps and the fact that the Dragon unistaller doesn't even delete this "feature":

 

http://forums.comodo.com/news-announcements-feedback-cd/cd-unistaller-does-not-remove-certsentrydll-t104751.0.html;msg760980#msg760980

 

I feel on a rant after the amount of time it has taken to get to the bottom of this.....