Ik zou absoluut niet willen dat mijn TLS verbindingen worden gebroken, goede bedoelingen ten spijt. Geen MitM, geen MitB.

Meestal zijn er meer nadelen dan voordelen.

Een veelvoorkomend probleem is dat de TLS client van het antiviruspakket qua ondersteunde protocollen (of juist niet meer ondersteunde zwakke broeders) achterloopt op up-to-date besturingssystemen en browsers. Bezoek in elk geval https://www.ssllabs.com/ssltest/viewMyClient.html om te kijken of de AV TLS client bekende kwetsbaarheden heeft en de laatste protocollen en cipher-suites ondersteunt.

Ook is het de vraag of de client goed naar ingetrokken certificaten kijkt (revoked certificates); ook die functionaliteit wil wel eens tekort schieten. Check https://revoked.grc.com/ - dat moet een foutmelding opleveren.

Een ander nadeel is dat je geen EV-certificaten meer ziet van sites die wel zo'n certificaat sturen (tenzij de AV-boer daar wat op gevonden heeft).

De effectiviteit is vaak ook nogal beperkt. Effectieve malware gebruikt obfuscatie of versleuteling van de overgedragen scripts en dergelijke. De kans dat een scanner die rommel "in transit" detecteert is relatief klein.

Een risico is dat je een rootcertificaat "aan boord" hebt waarvan de private key op jouw computer staat. Veel AV boeren gaan hier uitermate slordig mee om. Als een aanvaller die private key in handen krijgt, kan hij malware digitaal ondertekenen en jou (of jouw systeem) overhalen deze met admin of SYSTEM rechten laten uitvoeren (game over) en/of versleutelde verbindingen "verderop" openbreken.

Het komt regelmatig voor dat producten met een niet-uniek sleutelpaar worden uitgeleverd (zie de recente issues met de Dell rootcertificaten "eDellRoot" en "DSDTestProvider", maar eerder ook bij professionele appliances die SSL verkeer scannen: https://www.security.nl/posting/37180/Fortinet+SSL+DPI+ook+lek+%28net+als+Cyberoam%29%3F). Dan is het voor een aanvaller een koud kunstje om zo'n private key in handen te krijgen. Ik hoop dat dit niet het geval is bij de nieuwste versie van ESET NOD32, maar je weet maar nooit.

Als je besluit de SSL/TLS-inspectie niet langer te gebruiken, raad ik je aan het rootcertificaat te kopiëren naar de "untrusted" tak van de certificate store (zowel in Windows als van webbrowsers met eigen certificate store, waaronder Firefox). Reden: vaak blijft dit certificaat gewoon staan en kun je (of een aanvaller) de private key gewoon terugvinden op de schijf.

Erik, bedankt voor je uitgebreide reactie. Voordat ik jouw post las heb ik al besloten SSL scanning uit te zetten in NOD32. Vervolgens heb ik in mijn browsers Firefox, Opera en IE het Eset certificaat verwijderd...

Was dat wel een goede actie? Wat raad je me nu aan als vervolg stap, of kan ik het zo laten?

En waar vind ik de certificaten store van Windows op mijn systeem (kan ik kiken of Eset certificaat daar nog in staat)?

Het lijkt mij vanuit beveiligingsoptiek nou juist wel handig om dit te doen, zodat je het verkeer kan scannen op malicious traffic. Waarom zou je jezelf blind willen maken voor malware via HTTPS ? Het is net zo onverstandig als het niet scannen van ander verkeer.

MSIE en recente versies van Opera gebruiken de Windows certificate store (dat geldt overigens ook voor Chrome en Chromium).

Jazeker, als je geen SSL/TLS inspection gebruikt zijn er geen voordelen om die certificaten "trusted" te laten - integendeel, je loopt er risico's door.

Ik heb geen idee hoe NOD32 werkt, maar ik zie Kaspersky KES10, tijdens installatie, zo'n certificaat toevoegen aan de Windows certificate store, ook als je geen SSL/TLS inspectie gebruikt (of zelfs maar ergens aan kunt zetten). De vraag is of er ook andere omstandigheden zijn waarbij NOD32 dat certificaat weer toevoegt (reboot, bepaalde updates, aanzetten SSL/TLS inspectie etc).

Garanties biedt het niet: je kunt een kopie van het certificaat toevoegen aan de untrusted "tak" van de certificate store. Mocht NOD32 het certificaat later (ongemerkt) toevoegen aan de trusted tak van de certificate store, en daarbij de kopie in de untrusted certificate store niet verwijderen, dan ben je nog steeds beschermd.


Feitelijk heeft Windows meerdere certificate stores:
- Een systeembrede (te vinden in het register onder HKLM\SOFTWARE\Microsoft\SystemCertificates\)
- Per gebruiker een aanvullende (idem maar dan beginnend met HKCU).

Gebruikelijk is dat rootcertificaten "systeembreed" worden geïnstalleerd. In elk geval is het zo dat als je een kopie van een certificaat in de untrusted tak van de system certificate store installeert, dat certificaat (indien aangeboden door een webserver of gebruikt bij code-signing) voor iedereen ongeldig is.

Om systeemcertificaten te beheren (dit werkt op Win 7; ik heb geen idee of dit bij andere versies ook zo werkt):

(1) Start als admin (account dat lid is van de groep Administrators): C:\Windows\System32\mmc.exe
(2) Druk Ctrl-M (er hoort een dialoogbox "Add or Remove Snap-ins" of NL equivalent daarvan te verschijnen)
(3) Dubbel-klik op Certificates: als er nu geen dialoogbox verschijnt heb je geen adminrechten (verdergaan is zinloos)
(4) Kies "Computer account", druk op "Next" en in de dialoogbox erna op "Finish"
(5) Klik "OK" om de "Add or Remove Snap-ins" dialoogbox te sluiten

Persoonlijk zou ik deze nieuwe configuratie opslaan (via File | Save as) als C:\Windows\System32\SysCerts.msc zodat je bovenstaande handelingen niet steeds opnieuw hoeft uit te voeren; in plaats daarvan kun je voortaan gewoon C:\Windows\System32\SysCerts.msc starten.

Als het NOD32 certificaat vóórkomt in de "tak" met "Trusted Root Certification Authorities/Certificates" kun je het slepen naar "Untrusted Certificates/Certificates" (als je, tijdens slepen, de Control toets ingedrukt houdt, wordt er een kopie gemaakt).