SSL web sites do not open

[Using 1]

The used configuration is Windows XP SP3, NOD32 AV 7.x latest available version.

Firefox 17.010 ESR

Protocol Filtering is enabled

"Enable application protocoll content filtering" is checked

SSL protocol filtering mode is set to "Ask about non-visited sites..."

Automatic export of ESET... root ceriticate to Firefox succeeded

support.mozilla.org certificate is listed on the trusted cert. - nod32 av

 

By some reason Firefox is automatically redirecting some http urls to https -

just for information, not an objective of this thread.

 

Problem occurs with

support.mozilla.org

forum.eset.com

Problem does not occure with

www.google.com

 

After had the non-https url invoked in address bar and the Firefox's automatic redirection

to https url the browser opens following error page

Secure Connection Failed
An error occurred during a connection to support.mozilla.org.
Cannot communicate securely with peer: no common encryption algorithm(s).
(Error code: ssl_error_no_cypher_overlap)
  The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
  Please contact the website owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site.

 

To get those urls working following is necessary

- put Firefox on the list of excluede applications on nod32 side, or

- uncheck "Enable application protocoll content filtering", or

- change to do not scan ssl protocol

 

Following does not help to get these urls working

- add the url to the list of url excluded from filtering

- to add the url to the list of allowed addrresses

 

What is the reason?

Why is https://www.google.com not affected?

How to solve the prob, (to disable ssl protocol filtering is not the real solution)?

[User 13]

See also this thread.

 

I have the same problem.
ESET knows about this problem: KB Solution ID: SOLN3126, but there is no bugfix until now.

Edited November 16, 2013 by User

[Using 1]

Thanks so much!

 

I wish I had more knowledge about how the system looks when ssl filtering is enabled.

I could then better decide which workaround to apply.

As for now, I understand that with ssl filtering enabled the nod32 av emerges as

peer on the side of client machine and communicates with service on another end-point

- the ssl communication based on service certificate.

Than it forwards the traffic to real client using own certificate, the firefox in this case.

Is this working this way in the fact?

[User 13]

I have the same problem.

ESET knows about this problem: KB Solution ID: SOLN3126, but there is no bugfix until now.

 

 

 

The problem is solved for me with Internet protection module 1092, look here.

Edited December 5, 2013 by User

[Using 1]

Thanks for information.

Pre-Release udpates had been enabled temporarily in order to perform the

Internet protection update to 1092.

Following that "check for for product update" button was pushed.

No reaction.

Only pushing the virus data base update button resulted in huge update, about 40MB.

1. I wonder why the component update is included in db update instead of

in program update.

First trial using virus signature update didn't result in update of Internet

protection component to 1092. I had to repeat this in order to initiate a second

update (signatures) exact big as the first one. Not until the second trial was

completed the Internet Protection module showed 1092.

2. I wonder where does this behavior come from.

Now I can open https://forum.eset.com by following a link from to this discussion\

[Marcos 5,074]

1, We haven't included any PCU (program component update) in a standard signature and module update for v7 yet. For program updates, there's a separate update option in the program update section. When you switch between normal and pre-release updates, the engine as well as all modules are downloaded from pre-release or release servers which is about 40-50 MB.

2, It's not clear to me what you were referring to.