Privacy
- Wat niemand over je mag weten
Google's dubbele agenda
Sinds zondag 2014-12-14 hebben 23 bezoekers hun mening gegeven onder het artikel Schmidt: Google veiligste plek om gegevens op te slaan (https://www.security.nl/posting/411861/Schmidt%3A+Google+veiligste+plek+om+gegevens+op+te+slaan). Zoals te verwachten waren de meeste reacties afwijzend, en niet allemaal even goed onderbouwd. Ik heb daar zelf ook dapper aan meegedaan.
Een Google fan?
Afwijkend en interessant is de reactie van "Peter", uit https://www.security.nl/posting/411861/#posting411888:
Kan zijn, maar Google is niet het heilige boontje die ze claimen te zijn.
Bewijs dat Google er een dubbele agenda op nahoudt
Laat ik dan nu maar een wel onderbouwd voorbeeld geven waarom ik denk dat Google een gigantische slang is met een gespleten tong. De ene kant van het bedrijf weet niet wat wat de andere doet (en als ze dat wel weten, zijn ze het er niet per definitie mee eens).
HSTS
Google is 1 van de bedenkers en en promotors van RFC 6797 voor HSTS (HTTP Strict Transport Security), zie https://tools.ietf.org/html/rfc6797 (auteur A.Barth is van Google). Het ligt dus in de lijn der verwachting dat alle Google sites HSTS gebruiken. Hmm...
All your search data are belong to us - but only us
Uit http://googleonlinesecurity.blogspot.com/2014/08/https-as-ranking-signal_6.html:
Wait... all your search data are belong to us - and to anyone else who cares
Heel sneu voor onder andere Adam Langley, mr. encrypt-the-web himself, is dat Google Search niet gegarandeerd via https plaatsvindt. Uit http://www.theregister.co.uk/2014/11/20/gotcha_google_caught_stripping_ssl_search_from_bt_wifi_users_searches/:
WTF?!
Wat is daar precies aan de hand? British Telecom heeft, net als o.a. Ziggo in NL, public WiFi routers uitgerold (volgens http://business.bt.com/broadband-and-internet/wi-fi/ gaat het om 5 miljoen hotspots in de UK). Vanzelfsprekend levert BT ook de benodigde DNS services, en kunnen er dus voor kiezen om bij een DNS lookup voor google.co.uk, een ander IP-adres terug te geven dan bijvoorbeeld Google's eigen DNS servers doen.
IP-adres(sen) van google.co.uk
Voorbeeld, vraag aan de Google DNS server met IP-adres 8.8.8.8 wat het IP-adres is van google.co.uk:Om de belasting van Google servers te verdelen, kun je andere antwoorden tegenkomen (soms als je de vraag simpelweg herhaalt). Andere adressen die je kunt tegenkomen zijn 173.194.125.55, 173.194.125.56 en 173.194.125.63. Allemaal prima.
Surfen naar https://google.co.uk/ - watskeburt?!
Wat er normaal gesproken gebeurt als je, als URL, https://google.co.uk/ intikt, is het volgende:
1) DNS lookup van google.co.uk. Dit levert ofwel een IP-adres van een echte Google server op, of van een fake server.
2) Jouw browser maakt verbinding met het betreffende IP adres op poort 443 (https).
3) De remote server zal moeten antwoorden met een certificaat, anders geeft de browser een foutmelding.
4) De browser zal het certificaat controleren, maar ook of de domeinnnaam in de URL-balk overeenkomt wat in het certificaat als "CN" (Common Name), of onder de lijst met Alternate DNS names, is opgenomen. Als het certificaat niet is uitgegeven voor "google.co.uk", zal de browser een foutmelding geven.
Vet cool: https beschermt je tegen DNS manipulatie!
Of niet altijd?
Een aanvaller (o.a. een ISP zoals BT) die DNS responses manipuleert, kan daar niets mee in het geval van een https site, tenzij:
- De aanvaller op illegale wijze aan een certificaat voor "google.co.uk" kan komen (echter, daarvan is hier geen sprake);
- De site zelf (Google), na server-authenticatie en opzetten van de https verbinding, de browser doorstuurt naar een http site.
En dat laatste is dus het geval... Kortom, Google zelf ondersteunt, min of meer stiekem, plain-text zoekopdrachten. En dat is 100% in tegenstrijd met de eerste blog-post die ik aanhaal. En, in potentie, een fikse bedreiging - want veel internetters gebruiken Google search als hun startpagina en vullen het zoekveld in (in plaats van dat ze een URL in de URL balk intikken).
Waarom, en hoe kan dat dan?
Er zijn bedrijven en scholen die willen big-brotheren, bijv. om te verhinderen dat er naar pr0n, films, muziek en "gratis" software wordt gegoogled. Er zijn verschillende manieren om dat te doen. Je kunt bijv. een "SSL-inspection" device tussen de organisatie en internet plaatsen. Maar dat kost geld, en je moet een root certificaat distribueren om foutmeldingen in webbrowsers te voorkomen.
Google biedt zelf enkele alternatieve oplossingen aan, waaronder "SafeSearch" (zie https://support.google.com/websearch/answer/510 en/of https://en.wikipedia.org/wiki/SafeSearch). Maar de basisversie daarvan is een dienst waar je, als beheerder, zelf geen invloed op hebt, laat staan dat je (lekker?) kunt meekijken (of, desgewenst, beïnvloeden).
nsslsearch
Google heeft al veel langer een "handiger" oplossing voor beheerders en ISP's die graag hun invloed laten gelden, en hoewel Google al een tijd aangeeft deze dienst op te zullen heffen, werkt ze nog steeds. Naar verluidt (https://support.google.com/websearch/answer/186669?hl=en, zie optie 3: SafeSearch VIP (Virtual IP)) is de bedoeling hiervan "Inhoud voor volwassenen blokkeren op uw school" (vermoedelijk niet te interpreteren als dat kinderen alles mogen zien, en volwassenen niet). Echter: ook "kwaderwillenden" dan scholen kunnen misbruik maken van deze "dienst".
Het gaat hierbij in elk geval om de servers met URLs https://nosslsearch.google.com/ (216.239.32.20) en https://forcesafesearch.google.com/ (216.239.38.120). Huh?
1. Dat zijn https URLs, en
2. Niemand tikt vrijwillig een URL in die begint met nosslsearch of forcesafesearch, en
3. Als je die pagina's opent krijg je een 404 error...
DNS + nosslsearch (of DNS + forcesafesearch)
Die eerstgenoemde server, nosslsearch.google.com, is zo "opgevoed" dat als je daar naar toe surft terwijl je daarbij aangeeft: ik wil eigenlijk naar google.co.uk, dat dan een onversleutelde http verbinding zal worden opgezet met -schijnbaar- google.co.uk. Nb. forcesafesearch.google.com (216.239.38.120) heb ik niet inderzocht, ik verwacht vergelijkbaar gedrag.
Hoe werkt dat precies? Als beheerder laat je de DNS server, bij de vraag om het IP-adres van google.co.uk, niet het gebruikelijke adres, maar 216.239.32.20 teruggeven (het IP-adres van nosslsearch.google.com).
Surfen naar https://google.co.uk/ met IP = 216.239.32.20: watskeburt?!
Wat er normaal gesproken gebeurt als je, als URL, https://google.co.uk/ intikt, is het volgende:
1) DNS lookup van google.co.uk. Als antwoord kijgt jouw browser: 216.239.32.20
2) Jouw browser maakt verbinding met 216.239.32.20 op poort 443 (https) en stuurt meteen, volgens het SNI protocol (Server Name Indication), de naam van de server mee waar de browser feitelijk mee wil communiceren.
3) De remote server antwoordt met het gevraagde certificaat (immers het is een server van Google, dus dat kan die server).
4) De browser zal het certificaat controleren, maar ook of de domeinnnaam in de URL-balk overeenkomt met wat in het certificaat als "CN" (Common Name), of onder de lijst met Alternate DNS names, is opgenomen. Alles klopt natuurlijk.
En dan volgt de truc: de remote server (virtueel google.co.uk met echt IP-adres 216.239.32.20) toont, via de https verbinding, geen zoekpagina. In plaats daarvan geeft de server de browser de instructie om http://google.co.uk/ te openen (dus dezelfde site, alleen via http).
Jouw browser doet mogelijk opnieuw een DNS lookup (als deze het vorige antwoord niet gecached heeft), de vraag is ongewijzigd "google.co.uk" en het antwoord is weer "216.239.32.20".
Ten slotte maakt jouw browser nogmaals verbinding met 216.239.32.20, echter nu op poort 80 (http), en wordt de zoekpagina getoond. Mensen die niet opletten (of niet beter weten) zal dit niet opvallen. Immers, browsers slaan by default geen alarm als je van https naar http gaat (dat kun je vaak wel aanzetten, maar dat levert, op het huidige internet, -helaas- zoveel meldingen op dat de meeste gebruikers deze waarschuwingen snel weer uit zullen zetten).
En voila: BT, jouw werkgever, school, MacDonalds, en alles op het netwerk onderweg (dus ook de NSA en AIVD), kunnen desgewenst jouw zoekopdrachten afluisteren (en, als ze dat willen, de antwoorden manipuleren of informatie toevoegen).
Nogmaals HSTS
HSTS helpt dit soort https->http degradaties te voorkomen, maar natuurlijk uitsluitend indien de browser het ondersteunt (MSIE t/m versie 11 doet dat niet). Helaas: google.co.uk heeft geen HSTS header (want dan zou de BT afluistertruc niet werken in fatsoenlijke browsers). En, for that matter, ook https://google.nl/ ondersteunt geen HSTS. Erger, zelfs https://encrypted.google.com/ ondersteunt geen HSTS...
Zelf testen
Nu kun je denken: die Erik roept maar wat. Wel, je kunt het eenvoudig zelf testen. Voeg de volgende regels toe aan je hosts file:
Sluit je browser(s), open een commandprompt venster (cmd.exe) en geef het commando:
Beide acties kunnen nodig zijn om te zorgen dat de browser gebruik zal maken van de nieuwe info in de hosts file.
Open https://google.co.uk/, https://google.nl/ en https://google.com/. Als ik dat in Firefox doe, worden dat allemaal http verbindingen (https://google.com/ wordt http://www.google.nl/ met meuk erachter).
Opmerkelijk, met MSIE 11: https://google.co.uk/ wordt http://www.google.co.uk/?gws_rd=ssl (http dus), maar zowel https://google.com/ als https://google.nl/ blijven https! Ik heb geen idee waarom Google dit verschil tussen webbrowsers maakt. Ik stel het op prijs als jullie hieronder melden hoe Chrome, Chromium, Opera en Safari reageren met bovenstaande hosts file uitbreidingen!
Ook valt op dat https://encrypted.google.com/ en https://maps.google.nl/, met bovenstaande hosts instellingen, https blijven (zowel in Firefox als in MSIE).
Echter, er is NIETS dat Google, vandaag of morgen, belet om instellingen op de server met IP-adres 216.239.32.20 zodanig te wijzigen dat alle verbindingen naar http worden overgezet, al dan niet afhankelijk van de gebruikte webbrowser.
Conclusie
Het feit dat de Google search pagina's geen HSTS gebruiken is, gezien Google's schijnbare commitment voor https, absurd. Dat maakt sslstrip aanvallen, bijv. op open WiFi hotspots, een koud kunstje. Met alle gevolgen van dien.
Erger, Google biedt zelf een mogelijkheid waarbij een "big brother" slechts DNS hoeft te kunnen manipuleren (full-fledged MitM-access is dus niet nodig) om mee te kunnen kijken en/of gegevens on the fly te wijzigen.
DNS manipulatie gevolgd door misbruik maken van Google's "nosslsearch" kwam al eerder voor: in oktober 2013 werd gemeld dat Iraanse gebruikers Google search via http kregen aangeboden (en als de Iraanse overheid het kan, kunnen de NSA en de AIVD dit natuurlijk ook). In https://twitter.com/agl__/status/387695114719473664 schreef Adam Langley toen:
Nee Adam, dat gebeurt pas als Eric Schmidt (en zijn adviseurs, de Google aandeelhouders en wie weet welke "dienst" nog meer) er geen business case meer in zien.
Een Google fan?
Afwijkend en interessant is de reactie van "Peter", uit https://www.security.nl/posting/411861/#posting411888:
14-12-2014 21:54 door Anoniem (Peter): Men vergeet een belangrijk ding als met het heeft over Google als Amerikaans bedrijf. Google heeft grote vestigingen in o.a. Zwitserland waar veel ontwikkelt wordt. Daar vindt ook veel van de monitoring plaats van de interne systemen. Het meerendeel van die mensen is geen Amerikaan, maar bijvoorbeeld Russisch, Zwitsers, Duits of Chinees. Als die merken dat de NSA kopien trekt van servers van Google merken die dat en zullen ze dat zeker niet stil houden.
Kan zijn, maar Google is niet het heilige boontje die ze claimen te zijn.
Bewijs dat Google er een dubbele agenda op nahoudt
Laat ik dan nu maar een wel onderbouwd voorbeeld geven waarom ik denk dat Google een gigantische slang is met een gespleten tong. De ene kant van het bedrijf weet niet wat wat de andere doet (en als ze dat wel weten, zijn ze het er niet per definitie mee eens).
HSTS
Google is 1 van de bedenkers en en promotors van RFC 6797 voor HSTS (HTTP Strict Transport Security), zie https://tools.ietf.org/html/rfc6797 (auteur A.Barth is van Google). Het ligt dus in de lijn der verwachting dat alle Google sites HSTS gebruiken. Hmm...
All your search data are belong to us - but only us
Uit http://googleonlinesecurity.blogspot.com/2014/08/https-as-ranking-signal_6.html:
Posted: Wednesday, August 6, 2014, by Online Security Blog: HTTPS as a ranking signal
Security is a top priority for Google. We invest a lot in making sure that our services use industry-leading security, like strong HTTPS encryption by default. That means that people using Search, Gmail and Drive, for example, automatically have a secure connection to Google.
Security is a top priority for Google. We invest a lot in making sure that our services use industry-leading security, like strong HTTPS encryption by default. That means that people using Search, Gmail and Drive, for example, automatically have a secure connection to Google.
Wait... all your search data are belong to us - and to anyone else who cares
Heel sneu voor onder andere Adam Langley, mr. encrypt-the-web himself, is dat Google Search niet gegarandeerd via https plaatsvindt. Uit http://www.theregister.co.uk/2014/11/20/gotcha_google_caught_stripping_ssl_search_from_bt_wifi_users_searches/:
20 Nov 2014 at 03:29, Darren Pauli:: Google's "encryption everywhere" claim has been undermined by Mountain View stripping secure search functions for BT WiFi subscribers piggy-backing off wireless connections, sysadmin Alex Forbes has found.
[...]
Google engineer and security bod Adam Langley in a forum comment confirmed the SSL strip and said it would be removed 'soon'.
"At the moment, yes, no nosslsearch VIP will do this. However we're getting rid of it soon and replacing it with one that enables SafeSearch, but still over HTTPS," Langley said.
"However, if you want an encrypted search option, 'https://encrypted.google.com' is always encrypted and isn't affected by these methods."
[...]
[...]
Google engineer and security bod Adam Langley in a forum comment confirmed the SSL strip and said it would be removed 'soon'.
"At the moment, yes, no nosslsearch VIP will do this. However we're getting rid of it soon and replacing it with one that enables SafeSearch, but still over HTTPS," Langley said.
"However, if you want an encrypted search option, 'https://encrypted.google.com' is always encrypted and isn't affected by these methods."
[...]
WTF?!
Wat is daar precies aan de hand? British Telecom heeft, net als o.a. Ziggo in NL, public WiFi routers uitgerold (volgens http://business.bt.com/broadband-and-internet/wi-fi/ gaat het om 5 miljoen hotspots in de UK). Vanzelfsprekend levert BT ook de benodigde DNS services, en kunnen er dus voor kiezen om bij een DNS lookup voor google.co.uk, een ander IP-adres terug te geven dan bijvoorbeeld Google's eigen DNS servers doen.
IP-adres(sen) van google.co.uk
Voorbeeld, vraag aan de Google DNS server met IP-adres 8.8.8.8 wat het IP-adres is van google.co.uk:
D:\>nslookup -querytpe=A google.co.uk 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
Name: google.co.uk
Address: 173.194.65.94
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
Name: google.co.uk
Address: 173.194.65.94
Surfen naar https://google.co.uk/ - watskeburt?!
Wat er normaal gesproken gebeurt als je, als URL, https://google.co.uk/ intikt, is het volgende:
1) DNS lookup van google.co.uk. Dit levert ofwel een IP-adres van een echte Google server op, of van een fake server.
2) Jouw browser maakt verbinding met het betreffende IP adres op poort 443 (https).
3) De remote server zal moeten antwoorden met een certificaat, anders geeft de browser een foutmelding.
4) De browser zal het certificaat controleren, maar ook of de domeinnnaam in de URL-balk overeenkomt wat in het certificaat als "CN" (Common Name), of onder de lijst met Alternate DNS names, is opgenomen. Als het certificaat niet is uitgegeven voor "google.co.uk", zal de browser een foutmelding geven.
Vet cool: https beschermt je tegen DNS manipulatie!
Of niet altijd?
Een aanvaller (o.a. een ISP zoals BT) die DNS responses manipuleert, kan daar niets mee in het geval van een https site, tenzij:
- De aanvaller op illegale wijze aan een certificaat voor "google.co.uk" kan komen (echter, daarvan is hier geen sprake);
- De site zelf (Google), na server-authenticatie en opzetten van de https verbinding, de browser doorstuurt naar een http site.
En dat laatste is dus het geval... Kortom, Google zelf ondersteunt, min of meer stiekem, plain-text zoekopdrachten. En dat is 100% in tegenstrijd met de eerste blog-post die ik aanhaal. En, in potentie, een fikse bedreiging - want veel internetters gebruiken Google search als hun startpagina en vullen het zoekveld in (in plaats van dat ze een URL in de URL balk intikken).
Waarom, en hoe kan dat dan?
Er zijn bedrijven en scholen die willen big-brotheren, bijv. om te verhinderen dat er naar pr0n, films, muziek en "gratis" software wordt gegoogled. Er zijn verschillende manieren om dat te doen. Je kunt bijv. een "SSL-inspection" device tussen de organisatie en internet plaatsen. Maar dat kost geld, en je moet een root certificaat distribueren om foutmeldingen in webbrowsers te voorkomen.
Sidenote: daar komt bij dat veel van dat soort oplossingen zelf, in de praktijk, verre van veilig blijken te zijn (zie bijv. https://www.security.nl/posting/37732/Sleutelblunder+in+systeem+kritieke+infrastructuur, maar ook de Kaspersky desktop software ondersteunt SSL-inspection maar patcht niet bijtijds, Duitstalig: http://www.heise.de/security/meldung/Kaspersky-Schutzsoftware-senkt-Sicherheit-von-SSL-Verbindungen-2482344.html).
Google biedt zelf enkele alternatieve oplossingen aan, waaronder "SafeSearch" (zie https://support.google.com/websearch/answer/510 en/of https://en.wikipedia.org/wiki/SafeSearch). Maar de basisversie daarvan is een dienst waar je, als beheerder, zelf geen invloed op hebt, laat staan dat je (lekker?) kunt meekijken (of, desgewenst, beïnvloeden).
nsslsearch
Google heeft al veel langer een "handiger" oplossing voor beheerders en ISP's die graag hun invloed laten gelden, en hoewel Google al een tijd aangeeft deze dienst op te zullen heffen, werkt ze nog steeds. Naar verluidt (https://support.google.com/websearch/answer/186669?hl=en, zie optie 3: SafeSearch VIP (Virtual IP)) is de bedoeling hiervan "Inhoud voor volwassenen blokkeren op uw school" (vermoedelijk niet te interpreteren als dat kinderen alles mogen zien, en volwassenen niet). Echter: ook "kwaderwillenden" dan scholen kunnen misbruik maken van deze "dienst".
Het gaat hierbij in elk geval om de servers met URLs https://nosslsearch.google.com/ (216.239.32.20) en https://forcesafesearch.google.com/ (216.239.38.120). Huh?
1. Dat zijn https URLs, en
2. Niemand tikt vrijwillig een URL in die begint met nosslsearch of forcesafesearch, en
3. Als je die pagina's opent krijg je een 404 error...
DNS + nosslsearch (of DNS + forcesafesearch)
Die eerstgenoemde server, nosslsearch.google.com, is zo "opgevoed" dat als je daar naar toe surft terwijl je daarbij aangeeft: ik wil eigenlijk naar google.co.uk, dat dan een onversleutelde http verbinding zal worden opgezet met -schijnbaar- google.co.uk. Nb. forcesafesearch.google.com (216.239.38.120) heb ik niet inderzocht, ik verwacht vergelijkbaar gedrag.
Hoe werkt dat precies? Als beheerder laat je de DNS server, bij de vraag om het IP-adres van google.co.uk, niet het gebruikelijke adres, maar 216.239.32.20 teruggeven (het IP-adres van nosslsearch.google.com).
Surfen naar https://google.co.uk/ met IP = 216.239.32.20: watskeburt?!
Wat er normaal gesproken gebeurt als je, als URL, https://google.co.uk/ intikt, is het volgende:
1) DNS lookup van google.co.uk. Als antwoord kijgt jouw browser: 216.239.32.20
2) Jouw browser maakt verbinding met 216.239.32.20 op poort 443 (https) en stuurt meteen, volgens het SNI protocol (Server Name Indication), de naam van de server mee waar de browser feitelijk mee wil communiceren.
3) De remote server antwoordt met het gevraagde certificaat (immers het is een server van Google, dus dat kan die server).
4) De browser zal het certificaat controleren, maar ook of de domeinnnaam in de URL-balk overeenkomt met wat in het certificaat als "CN" (Common Name), of onder de lijst met Alternate DNS names, is opgenomen. Alles klopt natuurlijk.
En dan volgt de truc: de remote server (virtueel google.co.uk met echt IP-adres 216.239.32.20) toont, via de https verbinding, geen zoekpagina. In plaats daarvan geeft de server de browser de instructie om http://google.co.uk/ te openen (dus dezelfde site, alleen via http).
Jouw browser doet mogelijk opnieuw een DNS lookup (als deze het vorige antwoord niet gecached heeft), de vraag is ongewijzigd "google.co.uk" en het antwoord is weer "216.239.32.20".
Ten slotte maakt jouw browser nogmaals verbinding met 216.239.32.20, echter nu op poort 80 (http), en wordt de zoekpagina getoond. Mensen die niet opletten (of niet beter weten) zal dit niet opvallen. Immers, browsers slaan by default geen alarm als je van https naar http gaat (dat kun je vaak wel aanzetten, maar dat levert, op het huidige internet, -helaas- zoveel meldingen op dat de meeste gebruikers deze waarschuwingen snel weer uit zullen zetten).
En voila: BT, jouw werkgever, school, MacDonalds, en alles op het netwerk onderweg (dus ook de NSA en AIVD), kunnen desgewenst jouw zoekopdrachten afluisteren (en, als ze dat willen, de antwoorden manipuleren of informatie toevoegen).
Nogmaals HSTS
HSTS helpt dit soort https->http degradaties te voorkomen, maar natuurlijk uitsluitend indien de browser het ondersteunt (MSIE t/m versie 11 doet dat niet). Helaas: google.co.uk heeft geen HSTS header (want dan zou de BT afluistertruc niet werken in fatsoenlijke browsers). En, for that matter, ook https://google.nl/ ondersteunt geen HSTS. Erger, zelfs https://encrypted.google.com/ ondersteunt geen HSTS...
Zelf testen
Nu kun je denken: die Erik roept maar wat. Wel, je kunt het eenvoudig zelf testen. Voeg de volgende regels toe aan je hosts file:
216.239.32.20 www.google.nl google.nl maps.google.nl
216.239.32.20 www.google.co.uk google.co.uk
216.239.32.20 www.google.com google.com
216.239.32.20 encrypted.google.com
216.239.32.20 www.google.co.uk google.co.uk
216.239.32.20 www.google.com google.com
216.239.32.20 encrypted.google.com
Sluit je browser(s), open een commandprompt venster (cmd.exe) en geef het commando:
ipconfig /flushdns
Open https://google.co.uk/, https://google.nl/ en https://google.com/. Als ik dat in Firefox doe, worden dat allemaal http verbindingen (https://google.com/ wordt http://www.google.nl/ met meuk erachter).
Opmerkelijk, met MSIE 11: https://google.co.uk/ wordt http://www.google.co.uk/?gws_rd=ssl (http dus), maar zowel https://google.com/ als https://google.nl/ blijven https! Ik heb geen idee waarom Google dit verschil tussen webbrowsers maakt. Ik stel het op prijs als jullie hieronder melden hoe Chrome, Chromium, Opera en Safari reageren met bovenstaande hosts file uitbreidingen!
Ook valt op dat https://encrypted.google.com/ en https://maps.google.nl/, met bovenstaande hosts instellingen, https blijven (zowel in Firefox als in MSIE).
Echter, er is NIETS dat Google, vandaag of morgen, belet om instellingen op de server met IP-adres 216.239.32.20 zodanig te wijzigen dat alle verbindingen naar http worden overgezet, al dan niet afhankelijk van de gebruikte webbrowser.
Conclusie
Het feit dat de Google search pagina's geen HSTS gebruiken is, gezien Google's schijnbare commitment voor https, absurd. Dat maakt sslstrip aanvallen, bijv. op open WiFi hotspots, een koud kunstje. Met alle gevolgen van dien.
Erger, Google biedt zelf een mogelijkheid waarbij een "big brother" slechts DNS hoeft te kunnen manipuleren (full-fledged MitM-access is dus niet nodig) om mee te kunnen kijken en/of gegevens on the fly te wijzigen.
DNS manipulatie gevolgd door misbruik maken van Google's "nosslsearch" kwam al eerder voor: in oktober 2013 werd gemeld dat Iraanse gebruikers Google search via http kregen aangeboden (en als de Iraanse overheid het kan, kunnen de NSA en de AIVD dit natuurlijk ook). In https://twitter.com/agl__/status/387695114719473664 schreef Adam Langley toen:
If you find that this is being done on a large scale, please let me know. We can do things to address it.
Nee Adam, dat gebeurt pas als Eric Schmidt (en zijn adviseurs, de Google aandeelhouders en wie weet welke "dienst" nog meer) er geen business case meer in zien.
Reacties (12)
Het meerendeel van die mensen is geen Amerikaan, maar bijvoorbeeld Russisch, Zwitsers, Duits of Chinees. Als die merken dat de NSA kopien trekt van servers van Google merken die dat en zullen ze dat zeker niet stil houden.
Een onzinnig argument, verder staat al lang vast dat Google op grote schaal informatie deelt met de NSA. Dus deze poging om dat te ontkennen is reeds achterhaald. Verder kan je er op rekenen dat men werkt met een need-to-know principe.
Er zal geen mailing gaan naar alle 55.000 personeelsleden om hen op de hoogte te houden van samenwerking met de NSA, of met eventuele andere opsporings- en inlichtingendiensten.
Het idee dat ieder willekeurig (Russisch, Zwitsers, Duits of Chinees) personeelslid weet heeft van dit soort zaken (buiten wat ze erover lezen in de media) is redelijk voorbarig.
16-12-2014, 10:44 door
Mysterio
Dat Google geen brave Hendrik is was al duidelijk. Ik vraag me alleen af of je met dit stuk nou zo kunt stellen dat Google en dubbele agenda heeft en de slang met gespleten tong. Ik zal het proberen uit te leggen.
Google zet in op veiligheid na de ophef die ontstaan is naar aanleiding van PRISM. Of Google wist wat er aan de hand was/is laat ik in het midden, wat duidelijk was is dat Google de gebruikers tegemoet moest komen. Dat doen ze door een visie te ontwikkelen die inzet op meer veiligheid en afscherming. Dit is nog lang niet klaar, laat staan volledig geïmplementeerd. Dat heeft te maken met Google zelf, want ze moeten natuurlijk wel hun werk kunnen blijven doen, maar heeft ook te maken met alle wetgeving in de landen waarin te opereren.
Het is niet de taak van Google om te waken over de veiligheid van de internetters. Vergelijk het met een auto. Als je geeft om privacy zou je kunnen stellen dat je enkel en alleen met geblindeerde ramen over straat wilt. Iedere fabrikant kan zo'n auto maken, maar bij wet is het in Nederland verboden om met zo'n auto over straat te gaan. Als dan een fabrikant zo'n auto niet aanbiedt, wiens schuld is dat dan?
98% van de data van PRISM komt bij Google, Yahoo en Microsoft vandaan. De overheid van de VS heeft al aangegeven zich hard te willen maken om toegang tot die gegevens te willen houden. Joost mag weten wat een overheid kan afdwingen bij Google. Google wil graag opereren in Iran (en de CIA wil dat ook graag) maar de overheid aldaar kan daar wel enige invloed op uitoefenen. Kijk alleen al naar het gedoe tussen de EU en Google.
Ik alleen maar gissen wat dat kan betekenen voor de voortgang van de implementatie van bijvoorbeeld HTTPS en DNS manipulatie.
Google zet in op veiligheid na de ophef die ontstaan is naar aanleiding van PRISM. Of Google wist wat er aan de hand was/is laat ik in het midden, wat duidelijk was is dat Google de gebruikers tegemoet moest komen. Dat doen ze door een visie te ontwikkelen die inzet op meer veiligheid en afscherming. Dit is nog lang niet klaar, laat staan volledig geïmplementeerd. Dat heeft te maken met Google zelf, want ze moeten natuurlijk wel hun werk kunnen blijven doen, maar heeft ook te maken met alle wetgeving in de landen waarin te opereren.
Het is niet de taak van Google om te waken over de veiligheid van de internetters. Vergelijk het met een auto. Als je geeft om privacy zou je kunnen stellen dat je enkel en alleen met geblindeerde ramen over straat wilt. Iedere fabrikant kan zo'n auto maken, maar bij wet is het in Nederland verboden om met zo'n auto over straat te gaan. Als dan een fabrikant zo'n auto niet aanbiedt, wiens schuld is dat dan?
98% van de data van PRISM komt bij Google, Yahoo en Microsoft vandaan. De overheid van de VS heeft al aangegeven zich hard te willen maken om toegang tot die gegevens te willen houden. Joost mag weten wat een overheid kan afdwingen bij Google. Google wil graag opereren in Iran (en de CIA wil dat ook graag) maar de overheid aldaar kan daar wel enige invloed op uitoefenen. Kijk alleen al naar het gedoe tussen de EU en Google.
Ik alleen maar gissen wat dat kan betekenen voor de voortgang van de implementatie van bijvoorbeeld HTTPS en DNS manipulatie.
Ten slotte maakt jouw browser nogmaals verbinding met 216.239.32.20, echter nu op poort 80 (http)
Was daar niet HTTPS-Everywhere voor uitgevonden? (https://www.eff.org/https-everywhere)Toegegeven de niet-zo-security-minded-internetters zullen dit waarschijnlijk niet kennen.
/edit: internetexplorer-users ook niet.
Laat ik dan nu maar een wel onderbouwd voorbeeld geven waarom ik denk dat Google een gigantische slang is met een gespleten tong.
Heeft Google een gespleten tong, of zijn gebruikers moedwillig Oost-Indisch doof ? Wat ik frappant vind is dat we allemaal deze diensten blijven gebruiken, ook al weten we sinds jaar en dag wat het business model is van Google. Hetzelfde is natuurlijk van toepassing op diensten van bedrijven als Facebook.
De nieuwswaarde van het feit dat deze bedrijven onze privacy schenden is zolangzamerhand wel weg; iedereen weet dit, maar de meeste mensen steken hun kop in het zand, aangezien ze graag de diensten van deze bedrijven willen blijven gebruiken (of ze maken een afweging, en besluiten dat het hen meer voor- dan nadelen oplevert).
Wat raar dat Google niet volledig privacy-vriendelijk is. Misschien heeft dit wel te maken met hun bedrijfsactiviteit?
Wait... all your search data are belong to us - and to anyone else who cares
Yep, als consument maak ik me hier heel veel zorgen om. Wat nou als een aanvaller uitvindt dat ik het telefoonnummer van domino's pizza opzoek? Gisteravond nog slecht geslapen omdat ik bang ben dat de AIVD mijn zoekopdracht manipuleert zodat ik het nummer van New York pizza krijg. Het zou je maar gebeuren.
Nee zonder gekheid, dit is belachelijk. Het is echt een reëel gevaar, ik Google namelijk elke dag op mijn BSN-nummer, wachtwoorden voor mijn internetbankieren, en bedrijfsgeheime gegevens.
Ik weet zeker dat ik hierin niet de enige ben </sarcasme>
Wat betreft die HSTS, dat is een afweging van Google. Jammer, ik vindt het mooi spul, maar ik kan niet zeggen dat in mijn organisatie ook alle plannen worden uitgevoerd.
Verder wil ik toevoegen dat nergens op de Google pagina staat dat ze je garanderen een versleutelde reactie te versturen. Het is volgens mij ook algemeen bekend dat je voor Google niet moet zijn bij de privacy kant.
nsslsearch
Ik wordt zo moe van deze redeneringen.
Ok. Het is duidelijk. Je houdt niet van Google. Wat probeer je nou duidelijk te maken Erik? Zelfs de non-security mensen weten dat Google niet privacyvriendelijk is. Je kan het illustreren met allerlei technieken en bewijslast, maar volgens mij is het een algemeen bekend feit. Het is en blijft een commercieel bedrijf wat leeft op data.
Ik zie in mijn ogen ook geen probleem. Als jij niet van Google houdt, ga dan lekker naar DuckDuckGo. Niemand wordt geforceerd om Google te gebruiken. Veel mensen (waaronder ik) doen het gewoon graag omdat we het een fijne zoekmachine vinden. Mijn data mogen ze hebben, I don't care.
Security mensen blijven altijd zo paranoia. Schmidt geeft in het artikel aan de beste keuze te zijn voor dataopslag, net als Toyota, Volkswagen, Audi en Mercedes aangeven de beste auto van 2015 te hebben. Het klopt niet, maar niemand interesseert het wat als de automerken het doen, maar als het om beveiliging gaat schreeuwt iedereen moord en brand.
Om een bedrijf tot slang met gespleten tong te dopen om de filosofie van een topman gaat mij een beetje ver. Hij is volgens mij niet eens meer de CEO, dus wat zegt zijn filosofie nou?
Als Google bovenstaande punten allemaal zou dichten zou jij gewoon nieuwe inconsistenties vinden. Plaats het eens in perspectief. Wat doet Bing bijvoorbeeld?
Wait... all your search data are belong to us - and to anyone else who cares
Yep, als consument maak ik me hier heel veel zorgen om. Wat nou als een aanvaller uitvindt dat ik het telefoonnummer van domino's pizza opzoek? Gisteravond nog slecht geslapen omdat ik bang ben dat de AIVD mijn zoekopdracht manipuleert zodat ik het nummer van New York pizza krijg. Het zou je maar gebeuren.
Nee zonder gekheid, dit is belachelijk. Het is echt een reëel gevaar, ik Google namelijk elke dag op mijn BSN-nummer, wachtwoorden voor mijn internetbankieren, en bedrijfsgeheime gegevens.
Ik weet zeker dat ik hierin niet de enige ben </sarcasme>
Wat betreft die HSTS, dat is een afweging van Google. Jammer, ik vindt het mooi spul, maar ik kan niet zeggen dat in mijn organisatie ook alle plannen worden uitgevoerd.
Verder wil ik toevoegen dat nergens op de Google pagina staat dat ze je garanderen een versleutelde reactie te versturen. Het is volgens mij ook algemeen bekend dat je voor Google niet moet zijn bij de privacy kant.
nsslsearch
Echter: ook "kwaderwillenden" dan scholen kunnen misbruik maken van deze "dienst".
Here we go again. Een keukenmes is bedoeld voor in de keuken, als ik er iemand mee neersteek, is de fabricant dan ook verantwoordelijk? Ik wordt zo moe van deze redeneringen.
Conclusie
Het feit dat de Google search pagina's geen HSTS gebruiken is, gezien Google's schijnbare commitment voor https, absurd. Dat maakt sslstrip aanvallen, bijv. op open WiFi hotspots, een koud kunstje. Met alle gevolgen van dien.
Erger, Google biedt zelf een mogelijkheid waarbij een "big brother" slechts DNS hoeft te kunnen manipuleren (full-fledged MitM-access is dus niet nodig) om mee te kunnen kijken en/of gegevens on the fly te wijzigen.
DNS manipulatie gevolgd door misbruik maken van Google's "nosslsearch" kwam al eerder voor: in oktober 2013 werd gemeld dat Iraanse gebruikers Google search via http kregen aangeboden (en als de Iraanse overheid het kan, kunnen de NSA en de AIVD dit natuurlijk ook). In https://twitter.com/agl__/status/387695114719473664 schreef Adam Langley toen:
If you find that this is being done on a large scale, please let me know. We can do things to address it.
Nee Adam, dat gebeurt pas als Eric Schmidt (en zijn adviseurs, de Google aandeelhouders en wie weet welke "dienst" nog meer) er geen business case meer in zien.
Het feit dat de Google search pagina's geen HSTS gebruiken is, gezien Google's schijnbare commitment voor https, absurd. Dat maakt sslstrip aanvallen, bijv. op open WiFi hotspots, een koud kunstje. Met alle gevolgen van dien.
Erger, Google biedt zelf een mogelijkheid waarbij een "big brother" slechts DNS hoeft te kunnen manipuleren (full-fledged MitM-access is dus niet nodig) om mee te kunnen kijken en/of gegevens on the fly te wijzigen.
DNS manipulatie gevolgd door misbruik maken van Google's "nosslsearch" kwam al eerder voor: in oktober 2013 werd gemeld dat Iraanse gebruikers Google search via http kregen aangeboden (en als de Iraanse overheid het kan, kunnen de NSA en de AIVD dit natuurlijk ook). In https://twitter.com/agl__/status/387695114719473664 schreef Adam Langley toen:
If you find that this is being done on a large scale, please let me know. We can do things to address it.
Nee Adam, dat gebeurt pas als Eric Schmidt (en zijn adviseurs, de Google aandeelhouders en wie weet welke "dienst" nog meer) er geen business case meer in zien.
Ok. Het is duidelijk. Je houdt niet van Google. Wat probeer je nou duidelijk te maken Erik? Zelfs de non-security mensen weten dat Google niet privacyvriendelijk is. Je kan het illustreren met allerlei technieken en bewijslast, maar volgens mij is het een algemeen bekend feit. Het is en blijft een commercieel bedrijf wat leeft op data.
Ik zie in mijn ogen ook geen probleem. Als jij niet van Google houdt, ga dan lekker naar DuckDuckGo. Niemand wordt geforceerd om Google te gebruiken. Veel mensen (waaronder ik) doen het gewoon graag omdat we het een fijne zoekmachine vinden. Mijn data mogen ze hebben, I don't care.
Security mensen blijven altijd zo paranoia. Schmidt geeft in het artikel aan de beste keuze te zijn voor dataopslag, net als Toyota, Volkswagen, Audi en Mercedes aangeven de beste auto van 2015 te hebben. Het klopt niet, maar niemand interesseert het wat als de automerken het doen, maar als het om beveiliging gaat schreeuwt iedereen moord en brand.
Om een bedrijf tot slang met gespleten tong te dopen om de filosofie van een topman gaat mij een beetje ver. Hij is volgens mij niet eens meer de CEO, dus wat zegt zijn filosofie nou?
Als Google bovenstaande punten allemaal zou dichten zou jij gewoon nieuwe inconsistenties vinden. Plaats het eens in perspectief. Wat doet Bing bijvoorbeeld?
16-12-2014, 11:52 door
Erik van Straten
16-12-2014, 10:44 door Mysterio: Het is niet de taak van Google om te waken over de veiligheid van de internetters.
Dank voor jouw reactie! En met dat laatste statement ben ik het eens.Echter, Google presenteert zich wel degelijk als wereldverbeteraar [1], eerder onder meer door certificate pinning in te voeren (waardoor onthuld werd dat Diginotar was gehacked), SHA1 versneld af te bouwen en gisteren nog met haar plan om in Chrome http als onveiliger dan https te gaan bestempelen.
In dat licht vind ik het onbegrijpelijk dat, na het Iraanse incident in oktober 2013 en tot op de dag van vandaag, ruim 3 weken na de BT affaire, Google nog steeds bypass-diensten biedt voor big brothers...
M.b.t. http als onveilig bestempelen: op zich ben ik daar niet tegen, maar zoals gebruikelijk wordt de zaak weer totaal verkeerd voorgesteld en zullen gebruikers opnieuw op het verkeerde been worden gezet. Bovenaan, in https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure, lees ik namelijk:
The goal of this proposal is to more clearly display to users that HTTP provides no data security
Zucht. Zo'n blunder, namelijk de suggestie dat https en bepaalde X.509 certificaten, wel "data security" betekenen, verdient het om te worden vertaald in "Google wil de veiligheid van websites kunnen garanderen" (https://www.max.nl/blog/onveilige-websites-google-chrome/).
Helaas is de werkelijkheid dat zelfs de Redactie van security.nl in deze val trapt, uit https://www.security.nl/posting/411982/:
15-12-2014, 15:12 door Redactie: Als het aan Google ligt zullen straks alle internetgebruikers die een website bezoeken die over HTTP wordt aangeboden te zien krijgen dat deze website niet veilig is.
NEE! PLEASE! https i.p.v. http zegt NIETS over de veiligheid van een website! Het X.509 certificaat dient uitsluitend ter authenticatie van de server (het zegt NIETS over de inhoud van de site)!
Beveiligers en media maken, keer op keer, die fout, waarna scammers daar weer handig misbruik van (kunnen) maken. Ja, er bestaan stomme gebruikers die niks snappen (lost case anyway). Maar er zijn zat gebruikers waarvan je mag verwachten dat ze zich enigszins in de materie gaan verdiepen om veilig te kunnen internetten.
Google: hou alsjeblieft op met oversimplificeren, en Redactie: denk even na!
Overigens vind ik het een uitstekende ontwikkeling dat steeds meer security.nl lezers inzien wat de zegeningen, maar ook de tekortkomingen, van https en digitale X.509 certificaten zijn. Server-authenticatie en de aanvullende versleuteling gaan nooit perfect worden, maar noem in elk geval het beestje bij de naam!
[1] M.b.t. wereldverbeteraars: net als veel Google medewerkers is ook mijn belangrijkste "drive" een veiliger internet. Daarnaast schrijf ik stukken als hierboven om ervan te leren, en ten slotte om een stukje naamsbekendheid te kweken. Die, trouwens, niet altijd even positief zal uitpakken; er is mij al eens eerder verweten recalcitrant en querulant te zijn. Echter, zachte heelmeesters maken stinkende wonden...
16-12-2014, 16:12 door Anoniem: Ok. Het is duidelijk. Je houdt niet van Google. Wat probeer je nou duidelijk te maken Erik?
Ik heb een haat/liefde verhouding met Google. Ik probeer mijzelf er zo bewust mogelijk van te zijn dat Google veel van mij weet, en probeer tegelijkertijd mijn infoflow naar Google zoveel mogelijk te beperken. Maar ik zou "een dief van mijn eigen portemonnee" zijn als ik hun zoekdienst en Google Maps niet zou gebruiken. Het is vergelijkbaar met de (oneindige) Windows/Linux discussie: ja, mijn geweten zegt dat ik geen Windows en geen Google moet gebruiken, maar dan kan ik veel minder efficiënt mijn werk en hobby uitvoeren. Dus kies ik meestal voor die laatste twee, maar timmer zaken dan wel zoveel mogelijk dicht.Wat ik probeer duidelijk te maken (naast dat Google verdient aan onze gegevens, "All your search data are belong to us - but only us"), is vooral dat Google ook een achterdeur in stand houdt waarmee derden doodsimpel onze zoekopdrachten kunnen meelezen (en zelfs antwoorden manipuleren). Duidelijk is dat niet iedereen bij Google het eens is met dit beleid. En dat beleid wordt goedgekeurd door Eric Schmidt, Executive Chairman (niet CEO), van Google.
En diezelfde Eric Schmidt liegt dus als hij in http://www.usnews.com/news/articles/2014/12/12/eric-schmidt-says-using-google-now-best-way-to-evade-nsa (bron: https://www.security.nl/posting/411861/) stelt:
But, he also said, Google's services should now be a destination for people looking to avoid surreptitious National Security Agency snooping.
Want als er iets te snoopen (passief afluisteren) valt, is het wel http verkeer.
Correctie 16-12-2014 13:17: Eric Schmidt is geen CEO maar Executive Chairman (https://www.google.com/about/company/facts/management/), met dank aan Anoniem van 16-12-2014 12:15 hieronder.
Security mensen blijven altijd zo paranoia. Schmidt geeft in het artikel aan de beste keuze te zijn voor dataopslag, net als Toyota, Volkswagen, Audi en Mercedes aangeven de beste auto van 2015 te hebben. Het klopt niet, maar niemand interesseert het wat als de automerken het doen, maar als het om beveiliging gaat schreeuwt iedereen moord en brand.
Tja, professionals in de auto branche zullen waarschijnlijk ook wel hun gedachten hebben over de vraag wie de beste of de meest veilige auto fabriceert. Mij boeit dat niet; het is niet mijn vakgebied, en het heeft ook niet mijn interesse. Overigens is er wel een wereld van verschil tussen beroepsmatige interesse en paranoia.
Om een bedrijf tot slang met gespleten tong te dopen om de filosofie van een topman gaat mij een beetje ver. Hij is volgens mij niet eens meer de CEO, dus wat zegt zijn filosofie nou?
Ben ik geheel met je eens. Al is dat de uitspraak van een individu, en niet van ''Security mensen'' in het algemeen. Omtrent de vraag wat zijn filosofie zegt; ik denk vrij veel, ook al is Larry Page nu de CEO. Ik neem aan dat de executive Chairman, Eric Schmidt, toch nog altijd heel veel invloed heeft op de koers van Google.
Ok. Het is duidelijk. Je houdt niet van Google. Wat probeer je nou duidelijk te maken Erik? Zelfs de non-security mensen weten dat Google niet privacyvriendelijk is. Je kan het illustreren met allerlei technieken en bewijslast, maar volgens mij is het een algemeen bekend feit.
Dat is inderdaad sinds jaar en dag bekend. En weinig verbazingwekkend, gezien hun business model. Volgens sommigen moeten bedrijven als Google waarschijnlijk vrijwilligerswerk doen, alsof het niets kost om al deze diensten te maken en te exploiteren.
Ik zie in mijn ogen ook geen probleem. Als jij niet van Google houdt, ga dan lekker naar DuckDuckGo.
Lijkt mij een goed advies. Ofwel gebruik Google, en accepteer hun business model, of ga op zoek naar een alternatief. De tijd dat we niet wisten dat deze bedrijven leven van onze informatie ligt ver achter ons.
Even heel kort door de bocht, zou het volgende dus gelden, op basis van het HTTP/HTTPS criteria ?
[Onveilig]
Een website met een aankondiging van een kerstmarkt, waar je verder geen informatie achter laat, via HTTP
[Veilig]
Een botnet command & control server, waarnaartoe je vertrouwelijke data wordt geexfiltreerd via HTTPS
[Onveilig]
Een website met een aankondiging van een kerstmarkt, waar je verder geen informatie achter laat, via HTTP
[Veilig]
Een botnet command & control server, waarnaartoe je vertrouwelijke data wordt geexfiltreerd via HTTPS
16-12-2014, 13:31 door
Erik van Straten
16-12-2014, 12:17 door Anoniem: Een website met een aankondiging van een kerstmarkt, waar je verder geen informatie achter laat, via HTTP
Ik heb nog nooit een website gezien waarop je geen informatie achterlaat (niet alleen op die website zelf, maar zeer vaak ook op allerlei ander sites die je niet in de URL balk van je webbrowser ziet, maar die actief op zoek zijn naar informatie over jou en jouw surfgedrag).Ik begrijp het niet. Als Gamma en Karwei camerabeelden met "die griezels" van de politie willen delen, schreeuwen jullie moord en brand (in https://www.security.nl/posting/412011/Gamma+en+Karwei+zien+af+van+cameraproject+politie), maar als je kersintkopen doet bij bol.com vinden jullie het niet erg dat er tig servers elke handeling (toets, muisklik en wellicht muisbewegingen) loggen die jullie daar verrichten? En jullie, cross-internet, op vele sites tracken, en zo een compleet profiel van jullie opbouwen? Waarom denk je dat dergelijke data niet met de politie gedeeld zou kunnen worden? Bizar.
16-12-2014, 17:49 door
[Account Verwijderd]
-
Bijgewerkt: 16-12-2014, 17:50
[Verwijderd]
16-12-2014, 18:57 door
mcb
Door Erik van Straten:Ik begrijp het niet. Als Gamma en Karwei camerabeelden met "die griezels" van de politie willen delen, schreeuwen jullie moord en brand (in https://www.security.nl/posting/412011/Gamma+en+Karwei+zien+af+van+cameraproject+politie), maar als je kersintkopen doet bij bol.com vinden jullie het niet erg dat er tig servers elke handeling (toets, muisklik en wellicht muisbewegingen) loggen die jullie daar verrichten?
Ik denk dat dat deels komt omdat:- Een politiebezoek iets indringender overkomt dat een "bezoekje" van een adverteerder.
- De meesten hier adblockplus/noscript/ghostery e.d. gebruiken en zo de meeste trackers/adverteerders buiten de deur houden. Een politieblocker op mijn pc of zelfs mijn voordeur zal iets minder effectief blijken.
- Er wordt al jaren geschreeuwd over trackers e.d. en daar zijn ook oplossingen voor (zie vorig punt).
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
