Posolsvetla
-
Posts
40 -
Joined
-
Last visited
-
Days Won
3
Posts posted by Posolsvetla
-
-
On 7/18/2023 at 6:22 AM, cibersecyritycare said:
For example I want that the communication happens only with TLS_AES_256_GCM_SHA384.
This must be configured in the application doing the connection, in some cases directly in Windows.
For example, in Firefox it's quite easy:
Enter about:config and search for security.ssl3 and security.tls13. Set false for all that you don't want to be used. Please note that such change might trigger serious issues when connecting to the servers which don't support any of the remaining enabled ciphers. -
On 3/19/2022 at 10:21 PM, itman said:
Eset should have added it the first time you ran chrome.exe.
Since Internet protection module 1436 applications are no longer automatically added to the list. If an application is not present in the list, Scan action Auto is assumed.
On 3/20/2022 at 12:10 AM, itman said:Brave's .exe Scan action setting needs to be manually set from Auto to Scan for SSL/TLS protocol scanning to work.
Since Internet protection module 1436 TLS scanning is enabled for Brave browser also when set to Auto Scan action.
-
Hi
1 hour ago, itman said:I have created no exception for ssllabs.com web site.
Well, you did, as you mentioned at Thursday at 10:17 PM (edited): "If I overrode that warning, the web site displayed a page noting I had been exploited."
Firefox remembers that exception and when further attempt to access the site in question is made, no warning is issued by Firefox.1 hour ago, itman said:At this point, you have already been exploited. Immediately open Win Event logs and open the Warning log section. You will observe that an Audit_CVE log entry created relating to this activity noting an exploit attempt was made.
No, you haven't. As stated in the Event log, "an attempt to exploit" has been made, but that does not mean it was successful. We perform the check for this vulnerability only after we call the Windows API function which causes the log to be created. That's the reason the log is present. AFAIK Chrome does this in the same order, so the log would be present as well. Unfortunately I cannot verify this myself atm. Firefox don't call that particular Windows API function, therefore the log is not present.
1 hour ago, itman said:Next, note that the error code on the above screen shot shows "SEC_ERROR_UNKNOWN_ISSUER." This is a result of Eset's root CA certificate being used to decrypt and re-encrypt the network connection and doing so erroneously. Eset never detected the exploit attempt and the connection to the exploit web site only failed due to a glitch in Eset HTTPS scanning activities.
The shown error code is not the result of a glitch. It's the result of the exploit detected by us. In this particular case we use the same technique as for some other cases, e.g. when we detect the server certificate is selfsigned.
1 hour ago, itman said:Firefox shows that a secure connection attempted failed completely.
I would agree here, that we should probably block the connection altogether, the same way as we do when a server certificate is revoked, so an user won't be able to create an exception in a browser (as you did) and proceed. We might do that in the future.
-
19 hours ago, itman said:
immediately stop certificate validation processing in regards to Firefox. It is the only browser past or present that performed certificate validation processing properly.
We cannot stop validating certificates.
We don't do it because some browser might do certificate validation incorrectly. We do it because if TLS scanning is active for a particular web site, a browser cannot validate the original certificate of that site. (Note: As already discussed previously, we validate certificates also in several cases when TLS scanning is not active for a web page in question.)
What would happen if we stopped validating certificates can be simulated like this:
As per https://help.eset.com/eis/15/en-US/?idh_config_epfw_ssl_known.html add the certificate for https://untrusted-root.badssl.com/ and set the Access action to Allow. This way, the server's certificate will be considered valid by our product with the same effect as if we didn't validate it. (Note: As already mentioned, the revoked certificates won't be considered valid even if configured so.) Then try to open that web site. It will succeed.I managed to find a few links which might be helpful for anybody reading this forum:
https://medium.com/@ethicalevil/how-http-proxies-read-tls-traffic-from-browsers-f15364e91226
https://security.stackexchange.com/questions/133254/how-does-ssl-proxy-server-in-company-work
https://docs.mitmproxy.org/stable/concepts-howmitmproxyworks/#transparent-https
https://en.wikipedia.org/wiki/TLS_termination_proxy
According to Wikipedia, we use "TLS termination proxy" of "TLS Bridging" type in order to be able to do TLS scanning.- TJP, New_Style_xd and Peter Randziak
-
3
-
I would like to address several other points, not directly related to the original topic.
On 2/9/2022 at 5:11 PM, itman said:In any case, Eset is monitoring this Firefox certificate update activity;
As far as I know, we don't monitor this in any special way, just as any other download.
On 2/9/2022 at 10:36 PM, itman said:The problem is when Win cert. data is loaded in Eset Service memory out of sequence, the normal handshake process between Firefox and Eset for removal doesn't occur.
There is no such thing implemented in our product which would be described as "the normal handshake process between Firefox and Eset for removal" of a certificate data loaded in the memory of our process. As has been mentioned already, it's not possible to force the memory flush; see: "The Windows operating system does not support manual or programmatic flushing of the CRL cache." (ref.: https://social.technet.microsoft.com/wiki/contents/articles/4954.windows-xp-certificate-status-and-revocation-checking.aspx )
On 2/10/2022 at 1:00 AM, itman said:Eset will query via OSCP the issuing CA server. It then proceeds to download all these revoked certs.
If OCSP takes place when checking of a particular certificate, there is no CRL downloaded for it.
On 2/10/2022 at 8:07 PM, itman said:Eset did not detect the two expired cert. tests. However, at least Firefox detected the expired certs..
We indeed detect expired certificates, however we don't act on it in any special way. Instead, we keep this expired date in the certificate the browser sees, so the browser can detect it itself.
On 2/10/2022 at 8:07 PM, itman said:The above leads to the conclusion Eset SSL/TLS protocol scanning has an issue with expired cert. detection.
See the comment above.
On 2/16/2022 at 3:59 PM, itman said:add Intermediate cert. revocation checking bypass exclusion capability.
That would introduce a possibility for a security hole caused by a misconfiguration. It's not possible to configure such exclusions in browsers (AFAIK), so it's not possible to do so in our product.
On 2/16/2022 at 3:59 PM, itman said:Eset needs to allow for disabling of its certificate revocation checking processing. Note this will have no effect on web sites that Eset performs SSL/TLS protocol scanning on since it chains the web site cert. directly to its own root cert..
Partially answered above.
The web site certificate is chained to our root certificate only because it's safe to do so, i.e. the certificate checks, including the revocation check, already passed.On 2/16/2022 at 5:15 PM, itman said:Because Eset has directly chained the web site cert. to its root cert. eliminating the troublesome DigiCert Intermediate CA cert.. and is using its own cert. for CRL checking.
Partially answered above.
Neither our product nor a browser do any revocation checking for the certificate chained to our root certificate. There is no point doing so, it's not possible that exact certificate is ever revoked.On 2/16/2022 at 8:29 PM, itman said:on-the-fly downloading of altered cert. chain path processing that browsers are invoking to get around the SHA1 CRT signing issue.
I'm not familiar with "SHA1 CRT signing issue". However, see the answer below.
On 2/16/2022 at 8:43 PM, itman said:disable its certificate revocation checking processing for all non-SSL/TLS protocol scanned web sites until they can accommodate this downloading of altered cert. chain path processing that browsers are invoking.
We had an issue, when a server was sending the wrong intermediate certificate, already fixed. Now we look also for the alternate one, but it must be already present in the certificate store on Windows. We don't download it ourselves. This is a subject for future improvements as already mentioned.
On 2/16/2022 at 11:19 PM, New_Style_xd said:My concern and when is it said that there will be a correction in the future, rather than the future? Next year 2023, in ESET version 16?
The year 2023 is quite optimistic IMHO, though not impossible...
On 2/17/2022 at 1:21 AM, itman said:The correct way to perform cert. chain validation is when a web site is accessed the thumbprint of the terminating; i.e. top of the chain root cert. is extracted. Then an identical web site access is made via a secured server and the same process is repeated. If the two accessed thumbprints match, the chain is valid
This would be "root certificate pinning". We cannot do that. While it would work most of the time, it would immediately cause connection issues to the servers at the moment they changed CA for their server certificates.
21 hours ago, itman said:Eset needs to "bow out" of CRL checking and let the browser handle it.
As already mentioned, browsers do not do any revocation checking in the case TLS filtering is in effect. So we have to do it ourselves.
17 hours ago, itman said:These Intermediate CA certs. in Firefox's Authorities store function as an "override" to the Intermediate cert. downloaded, if needed, by the browser from the web site server. Since browsers use the Intermediate cert. for chain validation purposes, Firefox uses the DigiCert SHA2 Secure Server CA cert. in its Authorities store and bypasses the Intermediate CA cert. download from the web site.
As I have mentioned, we fixed this, so now we look for the alternate intermediate certificate.
-
Hi, no, unfortunately there is nothing new.
-
9 minutes ago, me myself and i said:
what are the next steps?
Will you inform me when the problem is solved?We will take care of the issue, but please note it might take some time as there might be more urgent work to be done.
I will sent you a PM when it's released for business users. Please do not expect it to be soon, e.g. the usual release workflow (in cases like this) lasts several weeks.
-
24 minutes ago, me myself and i said:
is there a browser where it works?
if I understand correctly, this does not work anywhere?
The source code of only Chrome and Firefox was checked. The majority, if not all, of the browsers are expected to behave similarly.
24 minutes ago, me myself and i said:are we the only company using ESET and a proxy?
Probably not. But as it's been like this for several years already, you are the 1st (AFAIK) to actually care enough to report the issue.
-
This is intended behavior of both Chrome and Firefox.
We serve the blocking page with HTTP/1.0 403 Blocked by ESET Security, as the immediate response to CONNECT blocked.domain.com:443 HTTP/1.1
Such response is blocked by browsers, and therefore not shown, in the case of https for security reasons, see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=137891In order to make the browsers show the page we would need to proceed with the tunnel establishment and serve the blocking page only in there. Currently there is no ETA when this change will be done. It would be implemented in Internet protection module and therefore the clients would receive the update automatically.
-
If you mean customized messages, than no, it's not possible to setup multiple, each one for different scenario.
-
In most cases only domain is sent, but the whole URL can be sent as well. The URL part after ? or # is not sent.
Currently the URL can be quite easily read from the request, however these days we are in the process of releasing a new functionality for the encryption of these requests. The process should be finished in November if no blocking issues emerge.
The URLs are not kept at our servers at all.
-
We are already investigating an issue with the same symptoms, so it might be the same issue in fact.
Does the certificate used on the server have CRL Distribution Point X509 extension?
If so, is the URL in there accessible on the affected local machine?The certificate is verified using the functionality OS provides. As a part of that process, the URL mentioned above is accessed.
-
I wasn't able to reproduce it with the version 1388.4
The version 1398 was released only for a few days and than replaced with 1388.4
The issue is only present in the version 1398 and will be fixed in 1399
-
I was able to reproduce this issue with Internet protection module 1398.
Do you have the same version? -
Unfortunately we are not able to provide any update on this issue yet.
-
According to our testing of www.rahvastikuregister.ee, the issue is on the server side. We recommend you to contact the server administrator.
In the meantime, we recommend to add the server certificate of www.rahvastikuregister.ee into the List of known certificates (https://help.eset.com/eav/13/en-US/?idh_config_epfw_ssl.html) and set Scan action to Ignore.
The technical details discovered during the testing which might be useful:
The issue is present when there is TLS version 1.3 advertised in the Client Hello, but there is not advertised x25519 group in the Supported Groups Client Hello extension. It seems that the server requires the presence of x25519 group despite it's not mandatory, according to the https://tools.ietf.org/html/rfc8446#section-9.1
As can be seen on https://www.ssllabs.com/ssltest/analyze.html?d=www.rahvastikuregister.ee, Java 11.0.3 or Java 12.0.1 as a client has the same issue. -
-
13 hours ago, hardwired said:
This is what happens to me, Firefox isn't filtering at all on a new install/new Windows install. Other browsers did but not Firefox.
This is very likely the issue we are already aware of. It manifests itself only on a fresh install of our product.
It will be addressed by the Internet protection module update. -
CVE-2020-0601 is related to ECC, not SHA1. Only Win10 were affected.
We have implemented the detection of the attack shortly after is was published, so our users are protected (to be precise, this applies only to the TLS connections scanned by Web access protection, not the complete protection of the whole OS) even if they don't have the Win patch installed. -
We already tried to solve this issue. Unfortunately, there is no general solution which would work out-of-the-box.
Currently it's put on-hold and there is no progress being made on this. -
-
Not sure if this is important and would make any difference, but there is missing charset=utf-8 in the content-type header sent by the server.
-
I checked the provided logs for GET /6.board-5991e97616a5fcf95475.js (as indicated by the screenshot) and there is no garbage at the end in the data passed to the browser. The data have length of 18682 bytes.
Wireshark capture is sometimes needed in order to diagnose some kinds of issues. This is not the case.
-
Only a few selected browsers are supported by default in regards to TLS filtering (https).
If you want the communication by Brave browser to be scanned, it must be explicitly setup to Scan, please refer to https://help.eset.com/eav/13/en-US/idh_config_epfw_ssl_app.html
In addition, if after this change there are errors in Brave browser related to certificates, it's likely it does not use the Windows OS to verify web servers certificates. In this case, please refer to Root certificate at https://help.eset.com/eav/13/en-US/idh_config_epfw_ssl.html
New EES Firewall / Consider every network as untrusted
in ESET Endpoint Products
Posted
Yes.