Vraag ik me meteen af, blokkeren die AVs die genoemd gaan worden hier dan ook meteen andere manieren om zeker te weten dat je met de juiste site communiceert, zoals DNSSEC/DANE?


Mocht je de AV ook geïnstalleerd hebben en een DNS provider hebben die aan DNSSEC doet en een browser met plugin hebben die TLSA checkt, ga dan even naar http://www.dnssec-failed.org (DNSSEC check) en https://bad-sig.dane.verisignlabs.com (TLSA check) en test het meteen even uit.

Bij Eset staat de SSL-controle standaard uit en is er dus geen eigen Eset-certificaat geinstalleerd: https://device5.co.uk/blog/do-not-use-eset-ssl-protocol-filtering.html

Ik had altijd het idee dat in Windows the SSL routines in het systeem zaten en dat zo'n virusscanner het verkeer
aftapte op de API tussen de applicatie en de OS routines dmv een speciaal door Windows aangeboden functionaliteit.
(net zoals deze onvercijferd verkeer en disk accesses kunnen onderscheppen om te scannen)

Werkt het dan niet op die manier?

Het primaire doel van SSL-MitM door sommige virusscanners is het voorkomen van malware infecties op je PC, en dat is helemaal niet slecht - maar er kleven ook nadelen aan. Kwestie van de voor- en die nadelen tegen elkaar afwegen.

Windows bevat API's (Application Programming Interface) om o.a. firewall functionaliteit te kunnen realiseren. Ik vermoed dat op die plek wordt ingegrepen. Als "SSL/TLS-achtige" versleuteling wordt gedetecteerd (https, SMTPS, etc) wordt het betreffende verkeer door de "SSL/TLS proxy" van de virusscanner geleid.

Topic starter is het ook te doen om de bewust wording en de achtergrond kennis die daarbij hoort zodat als het aan de hand is, de gebruiker een goede afweging kan maken.


Wat zijn dan precies de voordelen en vooral: wat zijn de nadelen en gevaren?

Op het ethische gebied had ik al een voorzetje gegeven (vertrouw je je AV leverancier wel voldoende om op deze manier in te grijpen? Is vertrouwen wel genoeg? Is er reden je AV volledig te vertrouwen?).
Wat betreft het technisch inhoudelijke voor- en nadeel laat ik dat graag over aan diegenen die er meer verstand van hebben dan ik.

T.s. nodigt jou en anderen hierbij dan ook van harte uit om als je over de voordeel en nadeel kennis/inzichten beschikt die te delen/inhoudelijk toe te lichten.

In de hoop een wat vollediger beeld te krijgen zodat iedereen (Windows/Linux/OS X) nog bewustere keuzes kan maken bij een AV security product en de manier waarop je de security voorkeuren instelt; wel of geen MitM tussenkomst van je AV, of/en in in welke gevallen wel of niet (en waarom..)!

Mvg
TS Anoniem

Bitdefender Antivrus Plus 2015 en "uitgebreidere" versies hebben een BitDefender Certificaat in the Trested Root CA staan.
Deze optie is uit te zetten maar dan geen AV/Malware scanning op SSL verbindingen, natuurlijk :)

Voordelen: de virusscanner kan, in elk geval een deel, van versleuteld inkomend- en uitgaand verkeer scannen op tekenen van malware. Met "een deel van" bedoel ik die, op certificaten gebaseerde, protocollen die de virusscanner ondersteunt. Naast https kunnen dit bijv. smtps, imaps en pop3s zijn.

In een deel van deze gevallen bieden sommige virusscanners alternatieve functionaliteit door applicatie-specifieke plugins. Bijv. Kasperksy heeft een Outlook plugin. Van een oudere Kaspersky scanner herinner ik mij een Firefox plugin die niet werkte in op dat moment recente versies van Firefox. Deze plugins zijn dus geen garantie op succes, scannen door "SSL MitM" is applicatie-onafhankelijk en kan betrouwbaarder zijn. Aan de andere kant maakt webbased drive-by-malware vaak gebruik van obfuscated Javascript; als zo'n webbrowser plugin toegang zou hebben (ik heb geen idee of dat in de praktijk zo is) tot Javascript acties tijdens de uitvoering zou dat weer een voordeel kunnen hebben.

Er zijn echter veel meer applicaties dan webbrowsers die https verbindingen kunnen opzetten, waar lang niet allemaal plugins voor bestaan.

Een nadeel van AV SSL-MitM kan zijn dat de gebruikte engine (lokale proxy) minder up-to-date is dan de gebruikte browser. Voorbeeld: als de AV proxy nog SSLv3 ondersteunt, en jouw webbrowser niet meer, loop je risico's met die proxy. Zoals ik eerder schreef op deze site, dat kun je testen op https://www.ssllabs.com/ssltest/viewMyClient.html.

Maar het bovenstaande kan ook een voordeel zijn als je gedwongen bent om een oude webbrowser te gebruiken (door je werkgever bijv. omdat er sprake is van een oude bedrijfsapplicatie en andere webbrowsers niet worden getolereerd). Dan zou de AV SSL client wel eens veiliger kunnen zijn dan die van de gebruikte webbrowser.

Andere nadelen van AV SSL-MitM kunnen zijn:

- Naast een extra rootcertificaat in de Trusted Certificate Store staat de bijbehorende private key natuurlijk ook ergens op jouw systeem. Een enorm risico loop je als blijkt dat jouw AV boer (net als andere Komodia meuk zoals gebruikt in Superfish) op elk systeem dezelfde private key gebruikt. Als op jouw systeem een uniek keypair is gegenereerd kan de ongemerkte diefstal van de private key door een doortastende aanvaller ook flinke consequenties hebben, maar om die private key te kunnen kopiëren moet de aanvaller minstens code onder jouw account kunnen laten draaien (en kan dan ook meteen al veel meer).

- Als het goed is worden certificaat-foutmeldingen tussen proxy-client en server goed aan de applicatie (meestal webbrowser) doorgegeven. Als je een site met een self-signed certificate bezoekt en geen foutmelding krijgt, weet je genoeg. Er zijn echter meer aspecten van certificaten die gecheckt horen te worden, o.a. de ingangs- en verloopdatum alsmede revocation checks. Onder browserfabrikanten is er geen consensus over hoe je met revocation checks moet omgaan. De vraag is hoe dat in die AV proxy is geconfigureerd en of je de bijbehorende instellingen kunt wijzigen.

- AV-boeren zouden informatie vergaard uit opgengebroken versleutelde verbindingen "naar huis" kunnen sturen voor analyse, en daar zou zeer gevoelige informatie bij kunnen zitten (waaronder wachtwoorden). Aangezien AV software al volledige systeemtoegang heeft kun je niet anders dan je AV boer vertouwen op dit punt. Datzelfde geldt voor het delen van informatie met derde partijen.

- Het scannen van netwerkpakketjes kan minder effectief zijn dan van complete bestanden, en bovendien vertragend werken. Bijv. een PDF file kan zo zijn opgebouwd dat er tijdens download al content getoond kan worden. Als de virusscanner eerst alle netwerkpakketjes tot een bestand samengevoegd moet hebben om dit goed te kunnen scannen, vertraagt jouw download. Om dat te voorkomen zou de scanner alleen op patronen in losse pakketjes kunnen scannen, en daarmee minder effectief worden.

- De effectieviteit van patroongebaseerde scanning is sowieso niet zo groot. Anderzijds, als malware via SSL jouw computer binnenkomt en nooit naar schijf geschreven wordt, zijn virusscanners ook veel minder effectief, en had je wellicht gered kunnen worden door de SSL-MitM.

Dit is wat ik er even over kan bedenken. Persoonlijk denk ik dat je, op een fatsoenlijk systeem, beter je webbrowser en plugins up-to-date kunt houden (en bij 0days plugins uitschakelen/andere browser gebruiken) dan AV versleutelde verbindingen te laten openbreken, vooral als jouw e-mails op andere wijze (op de server bijvoorbeeld) worden gescand. Een uitzondering hierop is als je met verouderde software moet werken (bijv. XP met MSIE 6 t/m 8).

Hartelijk dank voor de uitgebreide inzichtelijker makende toelichting Erik.

Het eventueel toestaan van de MitM tussenkomst om malware die in het geheugen wil gaan zitten voortijdig te ontdekken, vind ik op zich een heel plausibele reden om te overwegen dit van je scanner toe te staan.
Dan is er nog wel een aanmerkelijk verschil tussen toestaan voor webbrowser verkeer en dat van je mailprogramma (!), voor je mailprogramma zijn namelijk ook wel andere simpele oplossingen denkbaar (firewall poortbeheer = blokkeren van ophaalmogelijkheid van externe (html) content).

Echter, als je die AV MitM tussenkomst een vervelend idee vindt, ben ik het met Erik eens; "denk ik dat je, op een fatsoenlijk systeem, beter je webbrowser en plugins up-to-date kunt houden.." .
In aanvulling opgemerkt, met de juiste browser instellingen en de nodige nuttige browser extensies, kom je denk ik qua protectie ook al heel ver; denk maar aan javascripts beheer en bijvoorbeeld het managen (blokkeren) van reclame via iFrames met gebruik van flash (.swf) functionaliteit.

Wat betreft de mogelijkheid van het delen van informatie over jouw bestanden met je AV leverancier, daar ben je zelf bij.
Het hebben van veel rechten hoeft nog niet te betekenen dat het AV product ook de baas is over jouw systeem (!).
Je kan ervoor kiezen om bijvoorbeeld alleen inkomend verkeer toe te staan voor je AV scanner, voor het updaten van de malware-virusdefinities (tenminste, een mogelijkheid in het geval van sommige niet-cloud gebaseerde AV producten.).
Zo wordt er niets persoonlijks (behalve dan de metadata over je update frequentie) gedeeld met wie dan ook als je dat niet wil.

Maar goed, ..
Wat zou jij kiezen?
En waarom zo?

Mvg
TS Anoniem


P.s.
Ik zag overigens zojuist op eerder genoemde Mac site een reactie van een reageerder die lezers erop attent maakte dat ook Avast instellingen heeft om de MitM protectie uit te schakelen waar dat gewenst is.
Screenshot op https://i.imgur.com/NKXfVc8.png

Uit http://www.networkworld.com/article/2889693/some-bitdefender-products-break-https-certificate-revocation.html
(bron: http://www.theregister.co.uk/2015/03/01/bitdefender_bit_trip_slaps_valid_on_revoked_certs/):

Het artikel noemt verder dat je middels https://revoked.grc.com/ kunt testen of revocation checks goed werken, want het openen van die site moet een foutmelding opleveren in je webbrowser - ook als er sprake is van een proxy (waaronder een virusscanner die SSL/TLS "openbreekt" om onversleuteld verkeer te kunnen scannen).

Slechte zaak, temeer daar revoked.grc.com netjes OCSP-stapling informatie meestuurt.

Dat doet natuurlijk bijna niemand.

Voor de volledigheid de argumenten van Adam Langley, Google Security Engineer: https://www.imperialviolet.org/2014/04/29/revocationagain.html.