"ESET stelt dat het de namen van deze landen niet zal noemen, om te voorkomen dat mensen gevaar zullen lopen."

Dat begrijp ik niet helemaal. Andersom toch??

Redelijk snel te achterhalen door de MD5 te checken van je downloads.

Jammer dat er niet bij staat welke landen en providers het zijn.

Juist door de landen NIET te noemen brengt ESET levens in gevaar.

Peter

Worden er bytes toegevoegd ?, of gebruiken ze lege plekken in de .exe file ?
Anders kan het handig zijn als fabrikant om het exact aantal bytes van de geinstalleerde software te melden ( maarja dat filteren ze er ook weer uit natuurlijk ).

Wie kan je nog vertrouwen ?, alles gaat achter je rug om, je kan er beter vanuitgaan dat je altijd gehackt bent.

Maar als je HTTPS zou gebruiken om te downloaden, dan kan je ISP er toch niets inzetten.
Tenzij, ze de SSL cert hebben van de site, waarvan je download.

Veronderstellen dat er een of meer organisaties het initiatief hebben genomen lijkt me veilig. Als het een organisatie is en ESET noemt het juiste aantal landen dan weet die organisatie al genoeg om aan te nemen dat ze waarschijnlijk ontdekt zijn. Als ze dat niet al eerder door hadden. Om iemand in gevaar te brengen is het publiceren mogelijk al voldoende en toch neemt ESET dat risico? De mensen die gevaar lopen mogen hopen van niet.

Als ze IoCs als hashes en urls publiek maken dan weet de kwade genius die het heeft opgezet al genoeg. De namen van de landen dan niet noemen om mensen niet in gevaar te brengen is dan een vrij onwaarschijnlijk excuus.

Als je dan een hash algoritme wilt vertrouwen, zou ik dan weer niet kiezen voor MD5....

Dat "?" in het plaatje geeft aan dat ze niet zeker weten of het wel door de ISP gedaan wort.

Ik verwacht in elk geval dat de USA dit zal doen, en mogelijk rusland, of china.

Gaan we hier niet voorbij aan een *VEEL* groter probleem dan de ISP's? Dat bijvoorbeeld het inmiddels veel geplaagde Avast niet in staat is om zijn eigen installerte beschermen en te zien dat er executables zijn toegevoegd en/of veranderd en andere wijzigingen zijn gemaakt? Als de zelf-bescherming in orde is, dan is het hele verhaal gelijk onmogelijk!

Het verbaast me niet dat dat weer Avast wordt gebruikt. Het is gratis en dus (netzo als Piriform) populair, maar je ziet waar er dan op bezuinigd wordt.

Denk niet dat de ISP's zomaar "Nee" kunnen zeggen tegen de oerheid, zeker niet in landen zoals China, Rusland, ed.

Dan moet je wel een onafhankelijke manier hebben om die MD5 checksum te controleren. Je kan hem niet op internet opzoeken want dat wordt onderschept en gemanipuleerd.

Een overheid die het eigen volk bespioneert.. ik moet opeens weer aan dat gedicht van van Randwijk denken..

Wat dacht je van hun eigen mensen niet in gevaar brengen?

Schreeuw dit niet te luid. Als iedereen dit zou zeggen krijgen we straks duizenden drones boven onze hoofd die over heel de wereld verspreid.

Je moet de recente movie "the circle" maar eens bekijken.
http://www.imdb.com/title/tt4287320/

Inderdaad sci-ficion, maar wil maar zeggen dat dit niet aangemoedigd hoeft te worden.

Het gaat niet om de ISP die je thuislijn aanbiedt, maar de ISP die de hosting doet voor de aanbieders van software. In plaats van dat deze jou de legietieme installer aanbied en laat downloaden, wordt er zonder dat jij het merkt een geinfecteerde versie van het installer bestand aangeboden.

Aan het SSL certificaat is niets geheim. Sterker, elke https webserver stuurt haar certificaat ongevraagd naar jouw webbrowser zodra je daar een https verbinding mee opzet.

Geheim is de private key behorende bij de public key in het certificaat. Die hoort de server nooit te verlaten (hooguit in een versleutelde en/of fysiek beveiligde back-up). De kans dat die private key in handen van een ISP valt is daardoor niet zo groot.

De kans is groter dat zo'n ISP een intermediate certificaat in handen krijgt waarmee zijn (onrechtmatig) zelf certificaten kan uitgeven voor sites niet in hun bezit (en jou daarnaartoe routeren i.p.v. naar de echte site). Nog lastiger is het als de ISP en jij je in een land bevinden waarin je gedwongen wordt om een overheidsrootcertificaat in jouw webbrowser te installeren.

Een wellicht groter probleem voor meer democratische landen is dat veel downloadsites ook (of slechts) http ondersteunen en mensen niet eens https proberen.

Hoewel niet heel eenvoudig, is het mogelijk om een bestand zodanig te wijzigen dat het dezelfde MD5 hash oplevert. In mindere mate geldt dat ook voor SHA-1. Niet meer gebruiken dus om vast te stellen of een bestand ongewijzigd is!

Zelf-bescherming wordt jaarlijks getest door AV-TEST:https://www.av-test.org/en/news/news-single-view/32-products-put-to-the-test-how-good-is-antivirus-software-at-protecting-itself/. Daar staat Avast redelijk laag.


Tja. Men zegt dan dat en niet mag klagen over een gratis product, maar als zij zelf zeggen dat ze goed zijn... (wij van wc-eend bevelen aan...)

ESET gratis online scanner,scan duurde ruim een uur,niets gevonden,over 104.000 bestanden,prima dan.

In de eerste plaats gaat het om targeted attacks van state actors. Hoe kan je je daar als gewoon gebruiker druk over hoeven maken? Ze hebben het immers niet op jouw technische data voorzien. Het geheel was een prelude op technologische bedrijfsspionage, gezien de targets als samsung Breda en andere grote technologie bedrijven, die de C2 server op de korrel had.

De rest wordt netjes uitvergroot en uitgespeeld tegen o.a. avast, die een flinke portie van de av markt beheert. De een zijn nood is de ander zijn brood.

Beter is hier lering uit te trekken en analyseren hoe zulke staatshackers te werk gingen en welke server hosters hen hand en spandiensten verleenden, soms waarbij bepaalde overheden een oogje dichtknepen of zelfs mee hielpen faciliteren (zie FinFisher, whatsapp compromitatie enz.).

De positie van de eindgebruiker wordt steeds onbeduidender.

hoe lang duurt het voordat de NSA ESeT van extra payload voorziet die een schil vormt tegen detectie?
en heeft dit ook te maken met het zwart maken van kaspersky die ongetwijfelt ookbdeze software detecteerde?

Nou dat denk ik niet hoor, want die overheden die deze code willen toevoegen willen dat natuurlijk doen bij de gebruikers
in hun eigen land die deze software downloaden van een computer in waarschijnlijk een ander land. De lokale ISPs
(van de gebruikers) hebben ze onder controle, maar de hosters van de aanbieders niet.

HTTPS voegt weinig toe want de man-in-the-middle kan op DNS gedaan worden (daar zou je DNSSEC voor moeten hebben
maar dat heeft vrijwel niemand thuis geconfigureerd) en een certificaat kunnen ze zo genereren want zowat iedere
overheid heeft wel een trusted root certificaat.

Kun je niet met de ingebouwde developer tools van je browser zien wanneer een http 307 redirect plaatsvindt?
Of anders met Firebug. (addon voor Firefox browser)

1.Installeer FireBug
2.Open firebug
3. ga naar de "net" tab
4. Klik op "persist" optie
5. vul daar de url in die je wilt bezoeken.
Let vervolgens op de veranderende URL-lijst waar je een entry met "http 307 redirect" of iets dergelijks langs ziet komen.

https://superuser.com/questions/242138/how-to-track-url-redirects-in-the-browser

Nee, dat is *niet* mogelijk .
Ik heb al vaker het verschil tussen first pre-image, second pre-image en collision attacks uitgelegd.

Zoek dat op, en zoek op welke hoort bij het maken van een bestand met dezelfde hash als het originele programma, en zoek dan op welke zwakheden wel en welke niet bekend zijn bij MD5 en SHA-1 .

en welke end user kan dat ? doe normaal.

Dit is schokkend!!! Nu kan je ook al je eigen ISP niet meer vertrouwen. (zover dat al kon natuurlijk)
De roverheid al helemaal al niet meer met de nieuwe wet die er aan zit te komen.
Terug naar de het briefpapier en de postduif. ;-)

Het zal voor de gewone burger wel meevallen, iedereen komt niet onder een targeted attack te liggen.
Algemene surveillance en sleepnetten wordt wel verder uitgerold en dat is verontrustend genoeg.

Het belangrijkste bij al deze ellende is, dat je eigenlijk niemand en echt niemand meer ten gronde kan vertrouwen in digitale zin. Wat hebben we er met zijn allen een zootje van gemaakt, aangestuurd vooral vanuit het Anglo-Amerikaanse Imperium vooral en de rest moet daar in mee.

Ik ben ervan overtuigd dat Nederland 1 van deze landen is en dat UPC/Ziggo daaraan meewerkt.Ook Frankrijk is 1 van de landen die deze praktijken toepassen. Het zijn echt Control Freak-nations waar naast deze gemene spionage en sabotage activiteiten ook organised gangstalking deel van uitmaakt. Deze gangstalking groepen hwbben informatie nodig over hun targets, in het bijzonder over die hun internet-gedrag,contacten etc. En dat die informatie krijgen ze van de AIVD en de Nationale Politie die zelf target ook in de gaten houden. Ik weet al heel lang dat ik online en trouwens ook offline wordt bespioneert alleen werdt er vrijwel nooit wat door mijn internetsecurity gedetecteerd en ik heb McAfee,Norton,Kaspersky en Bitdefender gebruikt enndaarnaast nog Malwarebytes,HitmanPro en diverse online virusscanners. Ook Detekt een tool om overheidsspyware te ontdekken vondt niks. Maar ik weet dat ze zowel de (r)overheid alsook de groepstalkers meegluren tot op de dag van vandaag. Dat is de harde realiteit als je doelwit bent vd (r) overheid en aanverwante organised gangstalking groepen. Ik ben ervan overtuigd dat er IT tech bedrijven en IT deskundigen zijn die van dit soort overheidspraktijken weten maar die mogen of willen (uit angst) niks zeggen laat staan iets doen om het doelwit te helpen. Ik vindt het al moedig van Eset dat ze toch voorzichtig een tip vd sluier op lichten jammer dat ze de namen vd betrokken landen niet durven noemen. Ik als doelwit/slachtoffer zou daar nl.wel baat bij hebben om bijv.juridische aktie te kunnen ondernemen en aangifte te kunnen doen tegen de betrokken landen,staatsorganen zoals bijv. de AIVD.Er is hiet m.i.. namelijk sprake van schending vd mensenrechten in dit geval ook van mijn mensenrechten en daarmee gaan de staat,de AIVD en de politie te ver. Dat MOET STOPPEN! Dus bij deze roep ik Eset en andere internetsecurity firma's op on open kaart te spelen en de namen te noemen can landen en overheidsdiensten en internet en mobiele telefoonproviders te noemen die hierbij betrokken zijn. Zodat wij als burgers hier juridische, politieke en andere actie op kunnen ondernemen denk aan boycot betrokken providers,schadeclaims etc.

Grapje : "Ben je nu helemaal ge-lenovo'd?". Met een transparante redirect die by design niet door een browser in de adresbalk gerapporteerd wordt Tijd voor een goede web-proxy? Of helpt dat niet, net als VPN?

De rommel wordt gemaakt in Duitsland en het Verenigd Koninkrijk. Wie zijn hun afnemers?
EU niet transparant en ondemocratisch by design. $.html met niet te vertrouwen input, test uw reg expr.

Op de mac heel simpel.
- Open de terminal.
- type "md5 "
- sleep de file op het terminal window en geen een return

Het zal onder windows wel net zo simpel gaan.

Dag Bitwiper (iemand die in ieder geval heeft getuigt van enige kennis),
Je zou MD5 én SHA1 hashes kunnen controleren, samen met de bestandsgrootte. (aantal bytes)

Wat ik trouwens niet helemaal zeker weet, is of die redirect 307 ook met https werkt.
Ik denk van wel, want bijv. de whatsapp website heeft https. Wat denk jij?

De aanval is me ook niet helemaal duidelijk hoe deze nu precies werkt.
Wordt de browser nu geïnformeerd over de 307 redirect of niet?
Er zijn berichten dat de browser simpel naar een ander IP-adres wordt gestuurd met de geïnfecteerde versie met behulp van die redirect (307). Dat zou de browser dus moeten merken.
Maar uit het plaatje van ESET blijkt dat de redirect geheel buiten de browser om gaat, en volledig bij de ISP gebeurt met behulp van een ManInTheMiddle. Dat zou kunnen betekenen dat wanneer een slachtoffer op de download knop drukt om het gewenste bestand te downloaden, de browser niet het IP-adres gebruikt van de website met de geïnfecteerde versie, maar nog steeds het IP-adres van de juiste (niet geïnfecteerd) website.
Maar vanwege de MITM dus toch de geïnfecteerde versie krijgt.
HTTPS, DNSSEC e.d zal hier niet helpen, als daarmee deze redirect ook gewoon mogelijk is.

Het plaatje laat zien dat je eerst keurig naar de juiste website gaat, dus certificaat is okee.
Pas als je op de downloadknop drukt om het bestand te downloaden, treedt blijkbaar de MITM in werking.
Je ziet dan niet in de url van de browser dat het domein (waar de download wordt opgehaald) verandert.
Het certificaat zou wel moeten veranderen, maar dat zie je dan niet meer.
Het downloaden gebeurt immers op de achtergrond, en het certificaat is dan niet meer zichtbaar.
Je kan dan dus ook het certificaat niet meer controleren.
En als de browser verder ook niet meer over het gewijzigde certificaat bij de download valt, dan is men de pineut.

De vraag is dan ten slotte of browsers in zo'n situatie bij de daadwerkelijke download over https nog eens een keer extra het certicaat verifiëren of niet.
Het komt veel vaker voor dat een download niet van dezelfde website wordt opgehaald als waar men hem aanvraagt,
dus dan zou waarschuwen alleen maar een hoop gemekker in beeld geven. Maar dan blijft het IP-adres meestal niet gelijk.
Controleren browsers nog eens het certificaat als ze van hetzelfde IP-adres en https-domein downloaden?
Blijkbaar niet, anders was men er niet zo snel ingetrapt.

Als ik gelijk heb, dan zouden browsers dus voortaan moeten kunnen controleren (instelling?) of bij gelijkblijvend domein en IP-adres het certificaat opeens verandert als je gaat downloaden...

1) Bij een te goeder trouw gemaakt bestand heb je waarschijnlijk gelijk. Voor zover ik weet is nog niet gepubliceerd hoe je dit kunt doen. Echter MD5 en SHA1 zijn dusdanig minder sterk gebleken (dan ontworpen) dat de kans dat dit binnen afzienbare tijd, of nu al, kan steeds aannemelijker wordt. Bovendien, als ik (kansloos maar stel dat) zou ontdekken hoe dit moet, zou ik dat niet publiceren. Want terwijl cryptografen massaal afraden om MD5 en SHA1 te gebruiken om aan te tonen dat een reeks bytes (binnendeel van een certificaat of elk willekeurig bestand), sinds een eerdere check, ongewijzigd is, zijn er helaas nog steeds veel te veel te veel idioten die stellen dat dit risico niet bestaat. Waardoor MD5 en SHA1 nog steeds niet zijn uitgeroeid voor dit doel.

2) Collision attacks zijn wel gepubliceerd en vormen ook een risico. Een softwareleverancier zou gedwongen kunnen worden (NSA? BundesTrojaner?) om versies en updates zodanig te manipuleren dat een collision wel eenvoudig te maken is. Vervolgens zouden ISP's die daartoe gedwongen worden, een backdoored versie naar specifieke of alle klanten kunnen sturen (precies waar dit artikel over gaat). De schone en backdoored versie hebben dan een identieke cryptografische hash (MD5 of SHA1) of zelfs een identiek code signing certificaat.

M.b.t. tot punt 2: gelukkig gebruikt VirusTotal SHA256 in URL's en niet MD5, anders zou je die versies niet uit elkaar kunnen houden. Zorgelijk vind ik wel dat de Microsoft Windows certificate store (deze bevindt zich in het register) certificaten "uniek" identificeert op basis van hun SHA1 hash - ook hier kunnen collisions niet worden uitgesloten.

Hele kwalijke zaak dit. En mag ESET misschien de namen niet noemen? Vroeg of laat komt dit toch wel naar buiten.

Maar hoeveel pedo´s en terroristen gaan ze hier nu mee pakken? Waarschijnlijk 0. Maar wel lekker de burger besmetten met spyware want die heeft toch niks te verbergen zogenaamd. En wie weet als je pech hebt (klokkenluider oid) plaatsen ze erna nog even wat kinderporno op je pc of wat darkweb gerelateerde zaken. Uitleveren aan usa en hoppa je bent klaar. Misschien schets ik het nu iets te makkelijk maar ik vrees dat we deze kant op gaan. Vertrouw iig maar niet op je isp/overheid met al hun bevoegdheden en nieuwe wetten die ze doordrukken.

Stel hackers (laten we als voorbeeld rusland nemen, die doet het altijd goed in kranten koppen) weten de command en control server van finfisher te hacken oid. Kun je dan de ISP/overheid aansprakelijk stellen? Hun hebben jou als 1e geinfecteerd namelijk. Je zal wel geen poot hebben om op te staan waarschijnlijk.


Eigenlijk zouden ze in de politiek toetsen moeten maken of ze wel bekwaam zijn om uitspraken te doen of wetten door te drukken op dat gebied. Ben je gezakt dan heb je geen enkele stem in te brengen op dat onderdeel de rest van het jaar. Nou dan zouden een hoop mensen stil moeten zijn. Zo een ivo opstelten bijvoorbeeld die wist zelf de helft van de tijd niet wat hij allemaal liep te mompelen. Duidelijk verhaal van een puppet die zich dingen in laat fluisteren.


(Natuurlijk zou dit niet werken want de hele politiek is 1 corrupt zakken vullend zooitje dat je niet kan vertrouwen.) De overheid controlleert de burger maar niemand controlleert de overheid.

Ja, als die informatie allemaal (door een betrouwbare bron) gepubliceerd wordt. Ik zie echter zelden zowel MD5 als SHA1 genoemd worden, en in de situaties dat dit gebeurt, staat SHA256 er meestal ook bij. Waarom moeilijk doen dan?

Kort antwoord: nee.

Lang antwoord:

Bij het correct opzetten van een https verbinding met, bijvoorbeeld, www.example.com gebeurt ongeveer het volgende:

1) Ervan uitgaande dat jouw PC (of willekeurig welk device aan jouw netwerk) via DHCP een IP adres krijgt, krijgt jouw PC ook via DHCP het IP-adres van jouw lokale router en van 1 of meer DNS servers meegedeeld. Die informatie kan worden vervalst, bijv. als jouw router gehacked is of er zich een ander kwaadaardig device aan jouw lokale netwerk is gekoppeld. Als alles goed gaat krijg je correcte gegevens, en als DNS server(s) jouw eigen router en/of DNS server(s) van jouw ISP. Die instelling kun je natuurlijk overrulen met bijv. 8.8.8.8, maar UDP verkeer met die server verloopt onversleuteld via jouw ISP en kan dus eenvoudig gemanipuleerd worden;

2) Op jouw lokale netwerk zou zich een kwaadaardig device kunnen bevinden dat netwerkverkeer tussen jouw device en router probeert te kapen, bijv. middels ARP attacks, ICMP redirects en/of ICMP Router Advertisement Messages. Ook kan zij eventuele WPAD requests vanuit jouw PC met valse gegevens beantwoorden, waardoor jouw PC denkt dat deze voor http en https van een proxy server gebruik moet maken;

3) Ervan uitgaande dat de client (bijv. webbrowser) op jouw netwerk geen gebruik maakt van een proxy (ingesteld via bijv. WPAD) zal deze een DNS lookup van www.example.com en een IP-adres terugkrijgen, bijv. 192.0.2.1. Dat kan het echte IP adres van www.example.com zijn, maar het kan ook vervalst zijn (bijv. door de ISP of bijv. door een aanvaller die onrechtmatig schrijftoegang heeft gekregen tot de authoritative DNS server voor www.example.com);

4) Ervan uitgaande dat het geretourneerde IP-adres zich niet in jouw lokale subnet bevindt, zal jouw PC via ARP, dus op basis van het IP-adres van jouw router, om het Ethernet-adres van jouw router vragen. Een kwaadaardig device aan jouw netwerk kan dan zijn Ethernetadres retourneren waarna jouw PC denkt dat het kwaadaardige device jouw router is en daarmee gaat communiceren;

5) Ervan uitgaande dat er geen kwaadaardig device aan jouw netwerk hangt, zal jouw PC ethernetpakketjes uitwisselen met jouw router, met het verzoek verbinding te maken met IP-adres 192.0.2.1. Dat gaat daarna via jouw ISP en allerlei netwerkproviders "onderweg", die jouw IP pakketjes naar elke door hen gewenste server kunnen routeren;

6) Ervan uitgaande dat alle ISP's onderweg betrouwbaar zijn, zou IP-adres 192.0.2.1 best van een CDN (Content Delivery Network) provider kunnen zijn. De praktijk is dan dat 1 of meer server(s) van die CDN provider het https (TLS) endpoint vormen en je geen idee hebt of en hoe met servers van de bedoelde organisatie wordt gecommuniceerd;

7) Ervan uitgaande dat geen sprake is van een CDN en 192.0.2.1 "up" is, zal jouw client een TLS handshake beginnen met IP-adres 192.0.2.1. Moderne clients geven daarbij vaak aan dat ze feitelijk een verbinding willen met www.example.com (zodat er meerdere https servers op 1 IP-adres kunnen draaien), maar noodzakelijk is dit niet. In grote lijnen (vereenvoudigd en mogelijk is de volgorde niet precies zo) bestaat die handhake uit de volgende stappen:

8) De webserver stuurt haar certificaat naar jouw client (meestal samen met alle benodigde intermediate certificaten);

9) De client checkt of de domainname waar verbinding mee gezocht is (www.example.com) overeenkomt met een van de diomainnames genoemd in het certificaat onder "Subject Alternate Names". Als dat niet het geval is, wordt een certificaatfoutmelding gegeven, en stopt de communicatie;

10) De client checkt ook of het certificaat niet verlopen is en, via een keten aan eventuele intermediate certificaten tot en met een root certificaat dat in het besturingssysteem (of de client zelf), wordt vertrouwd; zo niet dan volgt een certificaatwaarschuwing. De client checkt meestal ook of geen van de betrokken certificaten is ingetrokken. Gebruikelijk hierbij is dat, als antwoorden hierop te lang uitblijven, de client er gemakshalve vanuit gaat dat het wel goed zit hiermee;

11) De client en de server wisselen informatie uit over welke symmetrische versleutelingsprotocollen zij ondersteunen, waarna de beste gemeenschappelijke wordt gekozen, bijv. AES128;

12) Jouw client en de server voeren een Diffie-Hellman key agreement uit, waarbij beide partijen (via een nog niet versleutelde en server-geauthenticeerde verbinding) een onvoorspelbare symmetrische sleutel voor symmetrische encryptie overeenkomen - zonder dat die sleutel zelf wordt uitgewisseld (dat is de charme van DH). Let op: jouw client heeft nog geen enkele zekerheid over de identiteit van de server waar die sleutel mee is overeengekomen, dat zou best een MitM (Man in the Middle) aanvaller kunnen zijn die zich via 1 van bovenstaande aanvallen voordoet als de server. Vanaf dit moment wordt alle uitgewisselde informatie versleuteld;

Correctie 26-09-2017 22:20, bij de tegenwoordig gebruikelijke DHE_RSA key agreement vindt authenticatie van de server op een andere manier plaats dan ik eerder schreef achter de punten 13 en 14 (ik laat de oude tekst in onderstaande box staan):

13) (gecorrigeerd) Eerder, aan het begin van de handshake, heeft de client een random nummer gegenereerd en naar de server gestuurd (stap 7) en de server heeft ook een random nummer gegenereerd en dat in stap 8 naar de client gestuurd. De server genereert nu een digitale handtekening over een mix van beide random nummers en de door de server gegenereerde Diffie-Hellman parameters genoemd in stap 12, door over die mix een SHA256 hash te berekenen en die te versleutelen met de private key (behorende bij de public key in het certificaat), en stuurt ook deze "handtekening" naar de client;

14) (gecorrigeerd) De client berekent, op exact dezelfde wijze als de server in stap 13, de SHA256 hash over de mix van de uitgewisselde random nummers en de door de server opgestuurde Diffie-Hellman parameters. Ook ontsleutelt de client de signature uit stap 13 met de public key uit het servercertificaat, wat uitsluitend dezelfde SHA256 waarde kan opleveren als de server over de private key beschikt, behorende bij de public key in het certificaat. Daarmee is de identiteit van de server aangetoond en weet de client zeker dat er met een server wordt gecommuniceerd waarvan de domainname voorkomt in het certificaat (einde correctie);

15) Pas hierna wordt http informatie (HTML, CSS, Javascript maar ook evt. redirects) via de (versleutelde en server-geauthenticeerde) TLS verbinding uitgewisseld.

Aanvulling 26-09-2017, 22:20: stap 7 t/m 15 worden goed en veel uitgebreider toegelicht in https://tlseminar.github.io/first-few-milliseconds/. Ter verduidelijking, onderaan de paragraaf die begint met ServerKeyExchange in die webpagina staat:
Met its private key wordt niet de net daarvoor genoemde random (DH) private key bedoeld, maar de vaste RSA private key behorende bij de public key in het servercertificaat. Die RSA private key wordt gebruikt voor signing in stap 13. (Einde aanvulling).

De kracht van https is dat verschillende soorten (met name MitM) aanvallen uitgesloten kunnen worden als je geen certificaatwaarschuwing krijgt. Daarmee beschermt https jou tegen ARP, DNS, routering en MitM aanvallen.

De overblijvende risico's zijn hoofdzakelijk:
A) Onbetrouwbare software op jouw PC;
B) Dat je niet de exacte domeinnaam kent (of je laat foppen) van de organisatie waar je verbinding mee wilt maken;
C) Dat een (door jouw OS of client vertrouwde) certificaatverstrekker een servercertificaat (of intermediate certificaat) voor de bedoelde domeinnaam heeft afgegeven aan een kwaadwillende derde (of zelf is gehacked), door niet op betrouwbare wijze vast te stellen dat die aanvrager geautoriseerd is om een certificaat voor die domeinnaam aan te vragen;
D) Het in verkeerde handen vallen van private keys. Dit probleem is veel groter dan vaak gedacht omdat steeds meer CDN's worden ingezet met endpoints bij lokale ISP's;
E) Zwakke cryptografie;
F) Niet of niet tijdig geïnformeerd worden dat een certificaat is ingetrokken.

Het fraaie van https is dat alle aanvallen van het type MitM, DNS, IP routering, lokale ARP en proxy, maar ook op niveau van http redirect onmogelijk zijn, maar helaas blijven bovenstaande risico's wel bestaan.

Ook is het -helaas- zo, dat als jouw OS of client certificaatleveranciers vertrouwt die DV certificaten verstrekken, veel van die afhankelijkheden weer worden geïntroduceerd - d.w.z. op het moment dat de certificaatverstrekker controleert of een aanvrager van een certificaat geautoriseerd is om dat te doen voor een specifieke domeinnaam.

Elke ISP die een MitM aanval (hoeft maar heel even te duren) tussen een server en een DV certificaatverstrekker (zoals Let's Encrypt) kan uitvoeren, kan een geldig certificaat verkrijgen voor die server. Kansloos voor Russen met een server en letsencrypt in de USA zul je zeggen. Maar er zijn wel regelmatig BGP hijacks die nauwelijks aan configuratiefouten kunnen worden toegeschreven, zoals afgelopen april toen de Russische ISP RosTelecom claimde dat IP verkeer naar "MasterCard,Visa, Fortis,Alfa-Bank,card complete Service Bank and more" (bron: [1]) naar haar netwerk moest worden gerouteerd.

[1] https://bgpmon.net/bgpstream-and-the-curious-case-of-as12389/

In een https verbinding kan een MitM aanvaller geen redirectverzoek injecteren tenzij die aanvaller over een certificaat beschikt dat jouw browser accepteert voor de betreffende server.

Veel feitelijke downloads gebeuren echter nog steeds via http (of soms ftp). En hoewel veel binaries gesigneerd zijn, is het een koud kunstje om die signature te verwijderen of te vervangen door een andere (met een naam die lijkt op de oorspronkelijke ondertekenaar).

Het is dus zaak dat http wordt vervangen door https en dat we ons realiseren dat CDN's een groot risico kunnen vormen, en dat https met een DV certificaat nauwelijks meerwaarde biedt boven http.

In Nederland, en veel andere Westerse landen niet anders. ISPs hebben zich immers te houden aan wetgeving, en kunnen gerechtelijke bevelen en dergelijke niet zomaar naast zich neerleggen. Medewerking van ISP's is niet iets wat gebeurt op vrijwillige basis, maar wat wordt afgedwongen.

Wijzelf controleren de overheid. En brengen steeds weer partijen aan de macht waar we met zijn allen dag in, dag uit kritiek op hebben. Grappig hoe mensen altijd de verantwoordelijkheid ontkennen voor de burger, m.b.t. de vraag wie we hebben als politici. Als we de huidige politici niet vertrouwen, dan moeten we ook niet op hen stemmen. Ze hebben immers ons mandaat, om ons land te besturen.

Hoe vaak heb jij al last gehad van een besmetting met finfisher ? En waar haal je vandaan dat men burgers, anders dan pedo's terroristen en criminelen, zou willen besmetten met finfisher ? Het klinkt allemaal aardig paranoia. Heb je wel eens een risk assessment gemaakt omtrent de vraag of jij doelwit bent van dit soort malware ? De kans is immers zo ongeveer 0.00%.

@ anoniem van 10:40

De vraag hier is niet hoe vaak gebruikers getroffen worden door zogenaamde geavanceerde gerichte aanvallen.
Behalve voor industriële en technologische spionage vrijwel geen.

De vraag moet meer zijn, hoe onnoemelijk veel gewone gebruikers slachtoffer worden van de "collateral damage", die optreedt door het moedwillig verzwakken van de algemene veiligheid van de globale infrastructuur om dit soort acties überhaupt mogelijk te kunnen maken. Bovendien wordt het door toezichthouders gedoogd of moet het opgelegd worden gedoogd.

De grootste aanstichters van zo'n toestand op de infrastructuur is het protectionistische machtsbelang van de Grote Commerciële Spelers, we kennen er allemaal wel een aantal. Daarnaast de geconcentreerde acties van het Surveillance Imperium bij uitstek. Ook hiervan kennen we de drie letter en vier letter namen.

Als deze toestand zo blijft of met opzet in stand gehouden wordt, is het bereiken van echt vertrouwen in de infrastructuur en echte veiligheid een farce. Verzwakte encryptie, verborgen niet publiek verkeer, ingebouwde zero-days en achterdeurtjes vanaf de eerste dag in gesloten software, onveilige protocollen. Toezicht dat een lachtertje blijkt keer op keer, boetes, die ook graag zo uit de achterzak worden betaald. En dan moet je daar dan nog iets van zien te maken als een developer keer op keer weer kiest voor een "pact met de duivel of adware-leverancier" vanwege het brood dat op de plank moet komen.

Kortom "borked" blijft "borked" en een "rigged" systeem blijft "rigged". "Resistance is futile, you will be assimilated".

Toch blijf ik en met mij misschien nog een goede 20% in de juiste traditie staan voor veiligheid en, gaan we voor betrouwbaarheid en voor onverdachte zuiverheid. Waarom? Simpel, omdat ik de andere optie geen optie vind.

Dus die het anders zien, doen maar...

luntrus

Dat lijkt me duidelijk. Wanneer je bijvoorbeeld "HashMyFiles gebruikt".
http://www.nirsoft.net/utils/hash_my_files.html
Die genereert alleen maar SHA1 en MD5 (en CRC) hashes.
Anders moet je er weer een andere tool bijslepen. Niet echt nodig.

Ik ben iemand anders die antwoord geeft.
Als je met deze surveillance/overheidsmalware wordt besmet, dan merk jij daar waarschijnlijk helemaal niets van.
Tenzij je een specialist bent, dan weet je waarschijnlijk waar je allemaal op moet letten.
Verder is het tot nu toe zo, dat er eerst toestemming moet komen voor een malwarebesmetting bij iemand.
Dat wordt als de nieuwe wet ingaat veel gemakkelijker. Om terroristen en pedo's en criminelen te vinden moeten ze
iedereen eerst onderzoeken. Dus moet je niet gek kijken als de AIVD na 1 januari als die wet er komt bij bosjes
alle adressen en mobiels gaan monitoren. Aan de buitenkant immers meestal niet te zien of iemand rottigheid uithaalt.

Wat je dan krijgt is een bijvangst van mensen die om één of andere reden verdacht lijken vanwege de communicatie
die ze plegen, maar die er bijv. alleen maar wat galgenhumor op na houden en niet werkelijk van plan zijn om te doen wat ze zeggen. "Kom, zullen we vanavond even New York onveilig maken?" is een klassieker, en helemaal niet serieus bedoeld. Het is een Nederlandse uitdrukking en betekent niet veel meer als een tocht maken door New York o.i.d..
Maar deze groep jongens werd dus afgeluisterd in de V.S. en onmiddellijk opgepakt, alleen maar omdat ze in de V.S. deze uitdrukking niet kennen en zoiets letterlijk gaan opvatten. Je wordt in eerste instantie onmiddelijk als terroristen behandeld, en dat kan een behoorlijk impact hebben. Je weet niet wat je overkomt. Misschien heb je er later nog nachtmerries van.
Dat is mijn voornaamste argument tegen sleepnetten waarmee niet-verdachte mensen ook worden onderzocht.
Daarbij is het raar dat alle onverdachte burgers van Nederland zomaar kunnen worden bespioneerd, en dat niet is
bewezen dat dit gaat helpen. Het bevredigt alleen de inlichtingendiensten (waar geloof ik een oud-generaal aan het roer staat) die Nederland nu al behandelen alsof het volop oorlog is, en de aanslagen, bommen en granaten niet van de lucht zijn.

Het hele punt is dat je dat niet weet als je onder toezicht staat omdat alles eromheen geheim is. Bovendien zijn dit geen script kiddies die sporen achter laten.

En hoe weet je of iemand een terrorist, crimineel of pedo is als je diegene niet in de gaten houdt?
Ze slepen een sleepnet over het internet en dan zien ze wel wat ze allemaal vangen. En als jij daar toevallig als brave burger met wat pech tussen zit dan ga je hier ook geen bericht van krijgen. Je privacy is dan al wel aangetast en de vraag is wat ze met jou info doen. Alleen zullen ze jou niet gaan informeren dat ze je per ongeluk in de gaten hielden. Want geheim.

Hoi mensen - ESET zegt wel alles over anderen maar wat te denken van het feit dat ESET Security , het aanmaken
van een registersleutel in HKEY - USERS , toestaat , genaamd "national. exe ?
De waarschuwing ging snel voorbij en kon maar enkele gegevens noteren terwijl de logs niet laten zien.
HKEY-USERS en een lange codering S-1.15-18 en meer is alles wat ik kon noteren.
Ik denk dat dit ook niet deugt en er toegnag wordt verleend aan derden.
Verder ziet dit secutiy programma er heel goed uit en onderschept aardig wat rotzooi , zoals een trjojaan die
via een Tor-bestand werd mgedownl;oad.

Bey

Vraagje aan de deskundigen hier.

Als je metasploit in de browser of voodooshield op de laptop gebruikt moet je dat toch kunnen zien, of niet?
Dan scannen er ineens aardig wat scanners mee. Een VT scan zou er ook niet over moeten liegen.

Als je VT en Google in deze niet meer kan vertrouwen, waar blijf je dan? Dan staat alles, echt alles, op losse schroeven.

Tijd voor een nieuwe Kaspersky conferentie tot volle ergenis van Anglo-Amerikaanse diensten als NSA e.d,,
die dit circus hebben opgestart en in stand houden.

luntrus