Wellicht omdat een virusscanner - een die niet averechts werkt - je HTTPS verkeer NIET zal scannen. En dus ook niet zal blokkeren.

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.

Dank het meedenken!

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:
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.

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.

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

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 :-)

Ah thanks! Ik zal nog eens goed kijken of daar sprake van is bij de door mij genoemde sites, maar ik vermoed van niet.

Zie geen HSTS.
Gebruik je eigenlijk wel een fatsoenlijke browser?

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.