Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
https voorkeur Google?
Als ik Google naar eicar krijg ik bovenaan 2 links die beginnen met http://www.eicar.org/ terwijl die site ook bereikbaar is via https (https://www.eicar.org/).
Toelichting
"EICAR", om precies te zijn "eicar.com", kun je downloaden vanaf die site. Het is een 16bits programma (niet uitvoerbaar dus op moderne 64bit systemen, want die voeren nog slechts 32bit en 64bit code uit) bedoeld als testbestand om te controleren of je antimalware oplossing werkt. Het echte eicar.com bestand toont, indien uitgevoerd op een systeem dat 16bits code ondersteunt, de volgende tekst:
Het bijzonder aan dit bestand is dat het bestaat uit uitsluitend "printbare" 8bit ASCII karakters waardoor je het ook als leesbare tekstfile (in notepad/kladblok) kunt openen en daarvandaan opslaan zonder de functionaliteit ervan te wijzigen.
Het idee ervan is dat op het moment dat je dit bestand op jouw systeem opslaat, jouw antimalware oplossing alarm hoort te slaan - waarmee je kunt testenof jouw antimalware goed werkt zonder echt kwaadaardige code te hoeven aanbieden. Nb. denkbaar is ook dat jouw antimalware oplossing pas alarm slaat op het moment dat het bestand geopend wordt voor lezen, bijvoorbeeld omdat je het probeert uit te voeren of te openen in notepad/kladblok. De oorspronkelijke eicar.com is niet kwaadaardig, maar een variant daarvan die wel kwaardaadig is, behoort natuurlijk tot de mogelijkheden. Daarom is het belangrijk dat je zeker weet dat zo'n bestand vanaf de echte eicar.org website wordt gedownload, en niet vanaf een website die zich weet voor te doen als de bedoelde website.
Als je ermee gaat testen, adviseer ik om altijd de variant te downloaden met de .txt extensie. Mocht je een bestand downloaden dat toch kwaadaardig blijkt te zijn (bijv. doordat iemand de website heeft weten te hacken en het bestand heeft weten te vervangen door een kwaadaardig exemplaar), dan is de kans minimaal dat het op jouw PC daadwerkelijk wordt gestart. Deze verse kun je downloaden via de volgende link: https://www.eicar.org/download/eicar.com.txt. Denkbaar is evenwel dat jouw antimalware oplossing geen .txt bestanden scant omdat ook deze ervan uitgaat dat die niet uitvoerbaar zijn.
Waarom de eicar.org website standaard geen redirect doet naar https is me een raadsel, want iets dat lijkt op malware zou je niet moeten willen downloaden via een http link (bijv. http://www.eicar.org/download/eicar.com te vinden in http://www.eicar.org/85-0-Download.html).
Bedoeling van mijn vraag
Waar het mij om gaat: ik meen gelezen te hebben dat Google de voorkeur zou geven aan https links, waarom zie ik dan http links naar die site in de Google zoekresultaten?
Of ligt het aan mijn "zoekverleden" en/of instellingen; krijgt iemand van jullie wel https links te zien naar die site in de Google zoekresultaten?
Toelichting
"EICAR", om precies te zijn "eicar.com", kun je downloaden vanaf die site. Het is een 16bits programma (niet uitvoerbaar dus op moderne 64bit systemen, want die voeren nog slechts 32bit en 64bit code uit) bedoeld als testbestand om te controleren of je antimalware oplossing werkt. Het echte eicar.com bestand toont, indien uitgevoerd op een systeem dat 16bits code ondersteunt, de volgende tekst:
EICAR-STANDARD-ANTIVIRUS-TEST-FILE!
Het bijzonder aan dit bestand is dat het bestaat uit uitsluitend "printbare" 8bit ASCII karakters waardoor je het ook als leesbare tekstfile (in notepad/kladblok) kunt openen en daarvandaan opslaan zonder de functionaliteit ervan te wijzigen.
Het idee ervan is dat op het moment dat je dit bestand op jouw systeem opslaat, jouw antimalware oplossing alarm hoort te slaan - waarmee je kunt testenof jouw antimalware goed werkt zonder echt kwaadaardige code te hoeven aanbieden. Nb. denkbaar is ook dat jouw antimalware oplossing pas alarm slaat op het moment dat het bestand geopend wordt voor lezen, bijvoorbeeld omdat je het probeert uit te voeren of te openen in notepad/kladblok. De oorspronkelijke eicar.com is niet kwaadaardig, maar een variant daarvan die wel kwaardaadig is, behoort natuurlijk tot de mogelijkheden. Daarom is het belangrijk dat je zeker weet dat zo'n bestand vanaf de echte eicar.org website wordt gedownload, en niet vanaf een website die zich weet voor te doen als de bedoelde website.
Als je ermee gaat testen, adviseer ik om altijd de variant te downloaden met de .txt extensie. Mocht je een bestand downloaden dat toch kwaadaardig blijkt te zijn (bijv. doordat iemand de website heeft weten te hacken en het bestand heeft weten te vervangen door een kwaadaardig exemplaar), dan is de kans minimaal dat het op jouw PC daadwerkelijk wordt gestart. Deze verse kun je downloaden via de volgende link: https://www.eicar.org/download/eicar.com.txt. Denkbaar is evenwel dat jouw antimalware oplossing geen .txt bestanden scant omdat ook deze ervan uitgaat dat die niet uitvoerbaar zijn.
Waarom de eicar.org website standaard geen redirect doet naar https is me een raadsel, want iets dat lijkt op malware zou je niet moeten willen downloaden via een http link (bijv. http://www.eicar.org/download/eicar.com te vinden in http://www.eicar.org/85-0-Download.html).
Bedoeling van mijn vraag
Waar het mij om gaat: ik meen gelezen te hebben dat Google de voorkeur zou geven aan https links, waarom zie ik dan http links naar die site in de Google zoekresultaten?
Of ligt het aan mijn "zoekverleden" en/of instellingen; krijgt iemand van jullie wel https links te zien naar die site in de Google zoekresultaten?
Reacties (12)
02-07-2017, 19:55 door
Vixen
Wellicht omdat een virusscanner - een die niet averechts werkt - je HTTPS verkeer NIET zal scannen. En dus ook niet zal blokkeren.
02-07-2017, 20:30 door
Lexib0y
Een virusscanner zal denk ik sowieso niet het verkeer scannen maar wel de file die tijdens de download wordt geschreven.
02-07-2017, 21:29 door
Vixen
Door Lexib0y: Een virusscanner zal denk ik sowieso niet het verkeer scannen maar wel de file die tijdens de download wordt geschreven.
Mijn antivirus scanner scant wel mijn webverkeer, maar alleen plain text HTTP verkeer. HTTPS laat ik niet mitm'en door mijn antivirus, maar inderdaad, bij het schrijven/openen/uitvoeren van het bestand word het direct geblokkeerd.
02-07-2017, 23:19 door
Bitwiper
Dank het meedenken!
Ander voorbeeld gezocht... (hmm www.ikea.com is alleen http, inloggen wel via https://secure.ikea.com/, maar ik heb niet gekeken wat er gebeurt als je "verder gaat winkelen" na inloggen - want ik heb geen account - anyway da's off topic).
Tap tap tap aha, als ik Google naar:
Als ik vervolgens handmatig http in https wijzig, werkt dit gewoon: https://www.vvv.nl/nl - met een certificaat uitgegeven op 25 augustus 2016; vermoedelijk bestaat de https variant dus niet pas sinds vorige week of zo. Waarom zou Google dan de http link i.p.v. de https link vermelden? Voor deze site kan ik geen enkel voordeel daarvoor bedenken.
Maar maak ik correct op uit jouw antwoord dat ook jij http links in Google gepresenteerd krijgt voor eicar, en wat zie je bij de VVV site?
Door Vixen: Wellicht omdat een virusscanner - een die niet averechts werkt - je HTTPS verkeer NIET zal scannen. En dus ook niet zal blokkeren.
Eerlijk gezegd geloof ik niet dat Google zo slim is dat ze precies voor deze site een uitzondering maakt...Ander voorbeeld gezocht... (hmm www.ikea.com is alleen http, inloggen wel via https://secure.ikea.com/, maar ik heb niet gekeken wat er gebeurt als je "verder gaat winkelen" na inloggen - want ik heb geen account - anyway da's off topic).
Tap tap tap aha, als ik Google naar:
vvv nederland
zie ik (op plaats 3) "Welkom bij VVV.nl" met een link naar http://www.vvv.nl/. Als ik daarop klik kom ik uit op http://www.vvv.nl/nl (dus wel een redirect maar niet naar https).Als ik vervolgens handmatig http in https wijzig, werkt dit gewoon: https://www.vvv.nl/nl - met een certificaat uitgegeven op 25 augustus 2016; vermoedelijk bestaat de https variant dus niet pas sinds vorige week of zo. Waarom zou Google dan de http link i.p.v. de https link vermelden? Voor deze site kan ik geen enkel voordeel daarvoor bedenken.
Maar maak ik correct op uit jouw antwoord dat ook jij http links in Google gepresenteerd krijgt voor eicar, en wat zie je bij de VVV site?
eicar.com staat in ieder geval nog niet op het lijstje van EFF's https-everywhere.
Dat helpt in ieder geval ook niet erg als andere zoekmachines ook eerst de http versie tonen.
Dat helpt in ieder geval ook niet erg als andere zoekmachines ook eerst de http versie tonen.
03-07-2017, 00:09 door
Vixen
Als ik vervolgens handmatig http in https wijzig, werkt dit gewoon: https://www.vvv.nl/nl - met een certificaat uitgegeven op 25 augustus 2016; vermoedelijk bestaat de https variant dus niet pas sinds vorige week of zo.
Ik kan je geen ongelijk geven , maar het laatste acht ik zeer onwaarschijnlijk, omdat een certificaat vaak vernieuwd word. Mijn eigen website waar dit alles geautomatiseerd is krijgt bijvoorbeeld elke 2 maanden een nieuw certificaat.
Mijn eigen website waar dit alles geautomatiseerd is krijgt bijvoorbeeld elke 2 maanden een nieuw certificaat.
Waarom? Ik heb altijd gevonden dat lange termijn certificaten beter zijn in de identificatie van web sites in het geval van sites waar je vaker dan eens komt. Het is iets te makkelijk om een certificaat te krijgen onder andermans naam.
Kort antwoord:
https resultaten terugzien is een actiepunt voor de webmasters: zelf aangeven of ze https voor alle content willen serveren (zie onderaan voor technische details)
Respectvolle zoekmachines/bots zorgen er vervolgens voor dat ze niet onnodig een minder optimale webserver plat crawlen.
Langere achtergrond info voor jan en alleman: wantrouwend, licht paranoïde en kort door de bocht kan gedacht worden:
- https (encryptie) kost meer tijd/rekenkracht voor zowel webserver als de (mobiele) computer van de bezoeker. Nauwelijks merkbaar, ook voor puur informatieve websites betere privacy voor én vertrouwen door je bezoekers.
- https is niet synoniem aan veilig (ondanks media onlangs pretendeerde) want:
1. het verkeer is hooguit langzamer te ontcijferen.
2. versleuteling staat los van de inhoud. Deze kan als nog (onbewust) onveilig zijn door zender en/of ontvanger. Sommige suites voor webservers herkennen eicar.com niet eens als virus.
3. geheel los staat het hoeveel Companies er daarna ook inzage in zullen hebben .....
- https wordt door sommige instanties nagenoeg realtime ontcijfert en meegelezen. Vaak veel eenvoudiger: vervangen met een ander, legitiem certificaat ondertekend door bijv. 'Staat der Nederlanden' en de andere reeds vertrouwde namen in je Root Certificate Store. Op welk kantoor is thuisbankieren nog wel privé? Waarom is DNS voorafgaand aan https niet versleuteld? Op welke andere tapbare lagen van het OSI model heb je ook geen versleuteling? Op welke lagen vindt er geen integriteitscontrole plaats?
- https is niet veilig. Wel ietsje veiliger. Nog correcter is: data wordt op minder onveilige wijze uitgewisseld.
Toch vinden wij brave burgers en informatie/productverkopers de voordelen van https vaak gevoelsmatig groter:
- https (compressie) zorgt vaak voor minder dataverbruik, ondanks initiële overhead. Op oude systemen wordt https zelfs als sneller ervaren want https wordt niet opgeslagen in tragere diskcache).
- persoonlijke gegevens (NAW, bestellingen, financiële transacties, zoekvoorkeuren, etc.) zijn toch vrij lastig te onderscheppen & vooral niet te vergeten: te modificeren door derden.
- applicaties downloaden we ook liever zonder toenemende toegevoegde Ransomware. Optimist: Lastiger te injecteren in https, Realist: kan als nog op een geïnfecteerde https server zelf. Ook gedoogde tapware (simpelste zet enkele standaard bestandsdeel poorten open) via honderden (!) gekaapte switches toe te voegen. Pessimist: Hoeveel andere switches zijn er nog met nog te ontdekken zero-days te kapen?
- als je vervolgens aan duizenden bezoekers/klanten kwalitatieve informatie/producten biedt nodigt dat (indirect) uit tot meer gebruik van https websites t.o.v. concurrentie. Peer pressure?
- zeker een iets duurder EV certificaat want bedrijf wordt geverifieerd (vaak een vrij eenvoudig telefonisch vraaggesprek). Zo'n certificaat met bedrijfsnaam in de groene balk zorgt voor een nog sneller gevoel van vertrouwen bij de webwinkels.
- dat er nog veel meer te verbeteren is (lekken dichten, versleuteling aanscherpen) wordt de laatste tijd gelukkig steeds sneller doorgevoerd dan we als burger merken kunnen.
Terugkomende op de hoofdvraag en de techniek achter de websites:
At Google we'll typically choose to index the HTTPS URL if:
- It doesn’t contain insecure dependencies.
- It isn’t blocked from crawling by robots.txt.
- It doesn’t redirect users to or through an insecure HTTP page.
- It doesn’t have a rel="canonical" link to the HTTP page.
- It doesn’t contain a noindex robots meta tag.
- It doesn’t have on-host outlinks to HTTP URLs.
- The sitemaps lists the HTTPS URL, or doesn’t list the HTTP version of the URL
- The server has a valid TLS certificate.
bron: https://webmasters.googleblog.com/2015/12/indexing-https-pages-by-default.html
https resultaten terugzien is een actiepunt voor de webmasters: zelf aangeven of ze https voor alle content willen serveren (zie onderaan voor technische details)
Respectvolle zoekmachines/bots zorgen er vervolgens voor dat ze niet onnodig een minder optimale webserver plat crawlen.
Langere achtergrond info voor jan en alleman: wantrouwend, licht paranoïde en kort door de bocht kan gedacht worden:
- https (encryptie) kost meer tijd/rekenkracht voor zowel webserver als de (mobiele) computer van de bezoeker. Nauwelijks merkbaar, ook voor puur informatieve websites betere privacy voor én vertrouwen door je bezoekers.
- https is niet synoniem aan veilig (ondanks media onlangs pretendeerde) want:
1. het verkeer is hooguit langzamer te ontcijferen.
2. versleuteling staat los van de inhoud. Deze kan als nog (onbewust) onveilig zijn door zender en/of ontvanger. Sommige suites voor webservers herkennen eicar.com niet eens als virus.
3. geheel los staat het hoeveel Companies er daarna ook inzage in zullen hebben .....
- https wordt door sommige instanties nagenoeg realtime ontcijfert en meegelezen. Vaak veel eenvoudiger: vervangen met een ander, legitiem certificaat ondertekend door bijv. 'Staat der Nederlanden' en de andere reeds vertrouwde namen in je Root Certificate Store. Op welk kantoor is thuisbankieren nog wel privé? Waarom is DNS voorafgaand aan https niet versleuteld? Op welke andere tapbare lagen van het OSI model heb je ook geen versleuteling? Op welke lagen vindt er geen integriteitscontrole plaats?
- https is niet veilig. Wel ietsje veiliger. Nog correcter is: data wordt op minder onveilige wijze uitgewisseld.
Toch vinden wij brave burgers en informatie/productverkopers de voordelen van https vaak gevoelsmatig groter:
- https (compressie) zorgt vaak voor minder dataverbruik, ondanks initiële overhead. Op oude systemen wordt https zelfs als sneller ervaren want https wordt niet opgeslagen in tragere diskcache).
- persoonlijke gegevens (NAW, bestellingen, financiële transacties, zoekvoorkeuren, etc.) zijn toch vrij lastig te onderscheppen & vooral niet te vergeten: te modificeren door derden.
- applicaties downloaden we ook liever zonder toenemende toegevoegde Ransomware. Optimist: Lastiger te injecteren in https, Realist: kan als nog op een geïnfecteerde https server zelf. Ook gedoogde tapware (simpelste zet enkele standaard bestandsdeel poorten open) via honderden (!) gekaapte switches toe te voegen. Pessimist: Hoeveel andere switches zijn er nog met nog te ontdekken zero-days te kapen?
- als je vervolgens aan duizenden bezoekers/klanten kwalitatieve informatie/producten biedt nodigt dat (indirect) uit tot meer gebruik van https websites t.o.v. concurrentie. Peer pressure?
- zeker een iets duurder EV certificaat want bedrijf wordt geverifieerd (vaak een vrij eenvoudig telefonisch vraaggesprek). Zo'n certificaat met bedrijfsnaam in de groene balk zorgt voor een nog sneller gevoel van vertrouwen bij de webwinkels.
- dat er nog veel meer te verbeteren is (lekken dichten, versleuteling aanscherpen) wordt de laatste tijd gelukkig steeds sneller doorgevoerd dan we als burger merken kunnen.
Terugkomende op de hoofdvraag en de techniek achter de websites:
At Google we'll typically choose to index the HTTPS URL if:
- It doesn’t contain insecure dependencies.
- It isn’t blocked from crawling by robots.txt.
- It doesn’t redirect users to or through an insecure HTTP page.
- It doesn’t have a rel="canonical" link to the HTTP page.
- It doesn’t contain a noindex robots meta tag.
- It doesn’t have on-host outlinks to HTTP URLs.
- The sitemaps lists the HTTPS URL, or doesn’t list the HTTP version of the URL
- The server has a valid TLS certificate.
bron: https://webmasters.googleblog.com/2015/12/indexing-https-pages-by-default.html
08-07-2017, 12:42 door
Bitwiper
Door Anoniem: Kort antwoord: ...
Niet op mijn vraag en zeker niet kort, maar op dat laatste mag ik geen kritiek hebben omdat ik met erzelf ook vaak schuldig aan maak :-)Door Anoniem: Terugkomende op de hoofdvraag en de techniek achter de websites:
At Google we'll typically choose to index the HTTPS URL if:
- It doesn’t contain insecure dependencies.
- It isn’t blocked from crawling by robots.txt.
- It doesn’t redirect users to or through an insecure HTTP page.
- It doesn’t have a rel="canonical" link to the HTTP page.
- It doesn’t contain a noindex robots meta tag.
- It doesn’t have on-host outlinks to HTTP URLs.
- The sitemaps lists the HTTPS URL, or doesn’t list the HTTP version of the URL
- The server has a valid TLS certificate.
bron: https://webmasters.googleblog.com/2015/12/indexing-https-pages-by-default.html
Ah thanks! Ik zal nog eens goed kijken of daar sprake van is bij de door mij genoemde sites, maar ik vermoed van niet.At Google we'll typically choose to index the HTTPS URL if:
- It doesn’t contain insecure dependencies.
- It isn’t blocked from crawling by robots.txt.
- It doesn’t redirect users to or through an insecure HTTP page.
- It doesn’t have a rel="canonical" link to the HTTP page.
- It doesn’t contain a noindex robots meta tag.
- It doesn’t have on-host outlinks to HTTP URLs.
- The sitemaps lists the HTTPS URL, or doesn’t list the HTTP version of the URL
- The server has a valid TLS certificate.
bron: https://webmasters.googleblog.com/2015/12/indexing-https-pages-by-default.html
09-07-2017, 12:28 door
Bitwiper
Door Anoniem: Zie geen HSTS.
Ben je een "ik angsthaas" en bedoel je te zeggen "Ik zie geen HSTS"?Bijv. in Firefox, met https://www.security.nl/ open:
1) Druk F12
2) Open de Netwerk tab
3) Druk Ctrl-F5 voor een forced refresh
4) Selecteer links de bovenste regel
5) Constateer dat rechts o.a. staat: Strict-Transport-Security: max-age=31536000
Als je dat NIET ziet, zit er iets of iemand tussen security.nl (feitelijk Cloudflare) en jouw webbrowser dat deze informatie weghaalt. Dat betekent dat er sprake is van een MitM aanval. Of dat gebeurt door een virusscanner op jouw PC of iets een beetje verderop richting Cloudflare, weet ik niet.
In elk geval heb ik kennelijk niet te maken met een MitM die deze informatie weghaalt, terwijl het mij heel sterk lijkt dat ik juist wel met een MitM te maken zou hebben die deze informatie toevoegt...
Beste Bitwiper, bedankt voor het alert maken omtrent dit issue.
Je kunt hiervoor chrome toevoegen en een query maken: chrome://net-internals/#hsts
Voorbeeld van query response:
static_sts_domain:
static_upgrade_mode: UNKNOWN
static_sts_include_subdomains:
static_sts_observed:
static_pkp_domain:
static_pkp_include_subdomains:
static_pkp_observed:
static_spki_hashes:
dynamic_sts_domain: https://forum.XXXX.XX/index.php
dynamic_upgrade_mode: STRICT
dynamic_sts_include_subdomains: false
dynamic_sts_observed: 1499604675.150495
dynamic_pkp_domain:
dynamic_pkp_include_subdomains:
dynamic_pkp_observed:
dynamic_spki_hashes:
groetjes,
lauferek.
Je kunt hiervoor chrome toevoegen en een query maken: chrome://net-internals/#hsts
Voorbeeld van query response:
static_sts_domain:
static_upgrade_mode: UNKNOWN
static_sts_include_subdomains:
static_sts_observed:
static_pkp_domain:
static_pkp_include_subdomains:
static_pkp_observed:
static_spki_hashes:
dynamic_sts_domain: https://forum.XXXX.XX/index.php
dynamic_upgrade_mode: STRICT
dynamic_sts_include_subdomains: false
dynamic_sts_observed: 1499604675.150495
dynamic_pkp_domain:
dynamic_pkp_include_subdomains:
dynamic_pkp_observed:
dynamic_spki_hashes:
groetjes,
lauferek.
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.
