Chanklish 1 Posted April 13, 2021 Author Share Posted April 13, 2021 26 minutes ago, itman said: Do what @Marcos instructed and we'll proceed from there. It appears your client devices having this issue are all Win 7 based? Yes Link to comment Share on other sites More sharing options...
itman 1,655 Posted April 13, 2021 Share Posted April 13, 2021 (edited) I disabled Eset protocol filtering. This means Eset Web Access and Phishing protection were fully disabled. I tried to access this web site in IE11 with the same result; blank web page displayed. As far as I am concerned, this web site issue has nothing to do with Eset protections. Why access to the web site works on devices w/o Eset installed must be related to something else. Edited April 13, 2021 by itman Link to comment Share on other sites More sharing options...
itman 1,655 Posted April 13, 2021 Share Posted April 13, 2021 I did some further analysis. I found the AAA Services root cert. in FireFox. It's listed under the name of "Comodo AAA Services root." It also matches that for the same cert. in the Win root CA store. So we can rule out a certificate issue here. I next thought that perhaps it was a TLS downgrade issue since this web site supports downgrade to TLS 1.0 and 1.1. Note Microsoft browsers now only support TLS 1.2 connections. But Firefox shows a TLS 1.2 connection. So we can rule out this one out also. Now here is where it gets really weird. In both IE11 and Edge, I inspected the code for the shown blank web page for the site's logon web page. The code is all there! It's just not being executed it appears. I did notice most of the scripts are angularJS based. Perhaps there is an issue with its use by IE11 and Edge? Also the logon web page does take a long time to render in FireFox. Link to comment Share on other sites More sharing options...
Chanklish 1 Posted April 13, 2021 Author Share Posted April 13, 2021 58 minutes ago, itman said: I did some further analysis. I found the AAA Services root cert. in FireFox. It's listed under the name of "Comodo AAA Services root." It also matches that for the same cert. in the Win root CA store. So we can rule out a certificate issue here. I next thought that perhaps it was a TLS downgrade issue since this web site supports downgrade to TLS 1.0 and 1.1. Note Microsoft browsers now only support TLS 1.2 connections. But Firefox shows a TLS 1.2 connection. So we can rule out this one out also. Now here is where it gets really weird. In both IE11 and Edge, I inspected the code for the shown blank web page for the site's logon web page. The code is all there! It's just not being executed it appears. I did notice most of the scripts are angularJS based. Perhaps there is an issue with its use by IE11 and Edge? Also the logon web page does take a long time to render in FireFox. What about chrome? BCE yold me chrome is the chosen browser Link to comment Share on other sites More sharing options...
itman 1,655 Posted April 13, 2021 Share Posted April 13, 2021 (edited) 1 hour ago, Chanklish said: What about chrome? BCE yold me chrome is the chosen browser I don't have Chrome installed, so I can' test with it. Try using Chrome on your end ,and see if the web site use is OK. Edited April 13, 2021 by itman Link to comment Share on other sites More sharing options...
itman 1,655 Posted April 14, 2021 Share Posted April 14, 2021 16 hours ago, itman said: I found the AAA Services root cert. in FireFox. It's listed under the name of "Comodo AAA Services root." It also matches that for the same cert. in the Win root CA store. I need to revise what I posted above. The FireFox AAA Services root cert. is not the same as that one present in the Win root CA store. The FireFox AAA Services root cert. contains both SHA-1 and SHA-256 thumbprints whereas the Win root CA store cert. only contains a SHA-1 thumbprint. This is why the web site web site is fully accessible via FireFox and not so in Microsoft browsers. Note that Microsoft browsers use the Win root CA store exclusively for web site cert. chain validation processing. Referring back to what I posted previously, it appears OSCP servers used in web site cert. validation processing are using the same AAA Services root cert. that FireFox uses. Also and because SHA-1 encryption is now deprecated, only the SHA-256 thumbprint is being used for verification purposes by the OCSP servers. You need to contact BCE and have them contact Sertigo, aka Comodo. Sertigo needs to contact Microsoft in regards to updating their existing Win root CA store AAA Services root cert. to include a SHA-256 thumbprint. Link to comment Share on other sites More sharing options...
Chanklish 1 Posted April 14, 2021 Author Share Posted April 14, 2021 34 minutes ago, itman said: I need to revise what I posted above. The FireFox AAA Services root cert. is not the same as that one present in the Win root CA store. The FireFox AAA Services root cert. contains both SHA-1 and SHA-256 thumbprints whereas the Win root CA store cert. only contains a SHA-1 thumbprint. This is why the web site web site is fully accessible via FireFox and not so in Microsoft browsers. Note that Microsoft browsers use the Win root CA store exclusively for web site cert. chain validation processing. Referring back to what I posted previously, it appears OSCP servers used in web site cert. validation processing are using the same AAA Services root cert. that FireFox uses. Also and because SHA-1 encryption is now deprecated, only the SHA-256 thumbprint is being used for verification purposes by the OCSP servers. You need to contact BCE and have them contact Sertigo, aka Comodo. Sertigo needs to contact Microsoft in regards to updating their existing Win root CA store AAA Services root cert. to include a SHA-256 thumbprint. but why does it work normally on pc without eset ? Link to comment Share on other sites More sharing options...
itman 1,655 Posted April 14, 2021 Share Posted April 14, 2021 12 minutes ago, Chanklish said: but why does it work normally on pc without eset ? I really don't have an answer for that. As I posted on my Win 10 installation, the same non-web page rendering occurred both in IE11 and Edge with Eset Protocol Filtering disabled. So as far as Win 10 operation goes, this issue is not Eset related. However, I am using Eset Internet Security running on Win 10 Home and you are using Eset Endpoint Security running on a Win 7 version. Note that Win 7 is an unsupported OS and I don't know the what updates from it have been applied. It may very well be that IE11; or is it IE10 on your device, is allowing SHA-1 root certificates verification. Link to comment Share on other sites More sharing options...
itman 1,655 Posted April 14, 2021 Share Posted April 14, 2021 (edited) I will also state this. Eset should perform a detailed analysis on what this web site: https://tvs.bce.lt/ is doing. BTW - the web site provider is located in Lithuania which "speaks volumes" as to its status. As a test, I did a global URL Allow List exclusion on it. When accessing the web site in IE11, I proceeded to receive 95 connection alerts; most related to AngularJS scripts running on the site's web server. Then the alerts stopped with a blank web page being rendered. This implies that something within IE11 prevented the web page from rendering. Only a Process Monitor session will fully detail on what the IE11 issue is with this web site. Edited April 14, 2021 by itman Link to comment Share on other sites More sharing options...
Chanklish 1 Posted April 14, 2021 Author Share Posted April 14, 2021 11 minutes ago, itman said: I will also state this. Eset should perform a detailed analysis on what this web site: https://tvs.bce.lt/ is doing. BTW - the web site provider is located in Lithuania which "speaks volumes" as to its status. As a test, I did a global URL Allow List exclusion on it. When accessing the web site in IE11, I proceeded to receive 95 connection alerts; most related to AngularJS scripts running on the site's web server. Then the alerts stopped with a blank web page being rendered. This implies that something within IE11 prevented the web page from rendering. Only a Process Monitor session will fully detail on what the IE11 issue is with this web site. how you did : URL Allow List exclusion ? Link to comment Share on other sites More sharing options...
itman 1,655 Posted April 14, 2021 Share Posted April 14, 2021 4 minutes ago, Chanklish said: URL Allow List exclusion ? Yes. Add https://tvs.bce.lt/* Link to comment Share on other sites More sharing options...
Chanklish 1 Posted April 14, 2021 Author Share Posted April 14, 2021 1 minute ago, itman said: Yes. Add https://tvs.bce.lt/* where?! Link to comment Share on other sites More sharing options...
itman 1,655 Posted April 14, 2021 Share Posted April 14, 2021 2 minutes ago, Chanklish said: where?! Link to comment Share on other sites More sharing options...
itman 1,655 Posted April 14, 2021 Share Posted April 14, 2021 (edited) Below is a screen shot of what is the problem in IE11. The website certificate chain validation appears to be borked. Also I have excluded the web site from Eset SSL/TLS protocol scanning. Otherwise, you would see Eset's root certificate at the top of the certificate chain. Therefore and again, Eset SSL/TLS protocol scanning is not the source of this problem. Note that the top of the chain root certificate shows a Sertigo CA root certificate. However in reality, it is a UserTrust CA root certificate. It really appears to me that IE is not correctly processing the additional download of the UserTrust CA root certificate and properly chaining it to the Sertigo CA root certificate. It also appears that IE11 is the only browser that is performing this alternate certificate chain processing. It is not being performed in FireFox. This leads me to believe that IE use in regards to this web site is highly suspect. Or taking it a step further, use of this web site is highly suspect. Edited April 14, 2021 by itman Link to comment Share on other sites More sharing options...
Solution itman 1,655 Posted April 15, 2021 Solution Share Posted April 15, 2021 (edited) My final posting in this thread is that I found the source of the problem and it is the web site provider. Let's get into the "nitty gritty" detail. First, read this Sertigo article in its entirety: https://sectigo.com/knowledge-base/detail/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020/kA03l00000117LT . Most important note the following: Quote As of April 30, 2020: For business processes that depend on very old systems, Sectigo has made available (by default in the certificate bundles) a new legacy root for cross-signing, the “AAA Certificate Services” root. However, please use extreme caution about any process that depends on very old legacy systems. Systems that have not received the updates necessary to support newer roots such as Sectigo’s COMODO root will inevitably be missing other essential security updates and should be considered insecure. If you would still like to cross-sign to the AAA Certificate Services root, please contact Sectigo directly. What does Sertigo mean by "very old systems?: Quote The cross-certificates with AAA Certificate Services provide compatibility to older versions: Apple iOS 3. Apple macOS 10.4. Google Android 2.3. Mozilla Firefox 1. Oracle Java JRE 1.5.0_08. AAA Certificate Services self-signed root [expiring 2028] - https://crt.sh/?id=331986 Putting all the above together. The web site should not be using the alternate certificate chain validation path that includes use of the AAA Services root cert. for IE certificate validation purposes. As to the final question as to why this web site renders OK w/o Eset installed, it is most likely linked to Eset Network Protection processing. In order for Eset to scan encrypted network traffic, it does so by intercepting network packet traffic via interfacing with the Windows Filtering Platform. It appears this is done regardless of whether Eset protocol filtering is enabled or not or if a particular web site is excluded from it. This is most likely because at this point, Eset Web Access protection has yet to be deployed. Once the browser in use receives this network traffic and if no Eset protocol filtering is being deployed, Eset re-encrypts the network traffic prior to the web page network traffic being processed by the browser. Because of this Sertigo certificate path issue, Eset is not properly re-encrypting the network traffic resulting in the browser failing to display the web page properly. Edited April 15, 2021 by itman Link to comment Share on other sites More sharing options...
Chanklish 1 Posted April 15, 2021 Author Share Posted April 15, 2021 i was about to post this , i ended up adding the intermediate certificates to the intermediate certificate store in windows works like a charm Link to comment Share on other sites More sharing options...
Recommended Posts