Chrome gaat gebruikers vaker waarschuwen bij http-sites

Google heeft een aantal veranderingen in de Chrome-browser aangekondigd. Zo moeten er vanaf versie 62 aanvullende waarschuwingen worden getoond op http-sites, bijvoorbeeld in de incognitomodus en bij het invullen van gegevens.

Bij de aankondiging maakt Google bekend dat de wijzigingen in oktober van kracht moeten worden. De zoekgigant schrijft dat in principe alle gegevens die gebruikers op een website invullen ontoegankelijk voor derden zouden moeten zijn. Daarom waarschuwt Chrome vanaf versie 62 dat de gebruiker zich op een onveilige website bevindt als er gegevens op een http-pagina ingevuld worden. Daarbij maakt het niet uit om wat voor gegevens het gaat.

De tweede verandering is dat er ook op incognitotabbladen de melding 'not secure' wordt getoond als een Chrome-gebruiker zich op een http-pagina bevindt. Google motiveert deze keuze door te stellen dat gebruikers die de incognitomodus activeren, verwachten dat hun privacy beter is beschermd. Op een http-pagina is het netwerkverkeer echter inzichtelijk voor personen die zich op hetzelfde netwerk bevinden, redeneert het bedrijf.

Google is al langer bezig met het aanpassen van de manier waarop de Chrome-browser met http-pagina's omgaat. In september van vorig jaar kondigde het bedrijf aan dat de inmiddels uitgekomen versie 56 van Chrome websites die wachtwoorden en betalingsgegevens doorsturen als onveilig zou gaan aanduiden als deze geen https gebruiken. Google zegt nu dat er sinds deze wijziging 23 procent minder naar http-sites met invulvelden voor wachtwoorden of betalingsgegevens genavigeerd wordt. In januari begon ook Firefox met het waarschuwen voor http-pagina's met inlogformulieren.

   Illustratie van de wijzigingen door Google

Reacties (67)

En wat gebeurt er dan zo speciaal met een website die met https begint ? Kan die site je niet gewoon doorverwijzen naar een gewone site en toch https in de adresbalk laten staan ?

Het speciale aan een https site is dat
a) er een certificaat keten is die garandeert dat de data die je ziet inderdaad van die site komt, en niet door een man in the middle is geïnjecteerd.
b) al het verkeer tussen je browser en de site is geëncrypt, zodat het niet mogelijk is te sniffen wat jij allemaal voor gegevens doorgeeft.

En ja, het is mogelijk om een https site te hebben waarbij (het grootste deel van) de content via http wordt opgehaald. Alleen weet de browser dat, en kan dat doorgeven. Ik zie met firefox wel eens een insecure icoontje op een https site, en als je dan dieper gaat kijken blijken de plaatjes met http opgehaald te worden, of zo.

Dit laatste heet mixed-content

Mixed content is niet aanbevolen. Als je gebruik maakt van https en er is ook maar 1 verbinding die connectie maakt via http dan geeft de browser al een waarschuwing dat de verbinding niet veilig is. Alle resources, dus ook images, scripts en bv css bestanden moeten via de beveiligigde verbinding lopen anders heb je er nog niet zoveel aan

Dus geen vervelende popups / meldingen, dat komt gwn in de balk te staan?

Gelukkig want er zijn superveel websites die geen https gebruiken.

Dat aantal zal langzamerhand wel gaan dalen door deze actie van Chrome. Ik hoop ook dat alle browsers hieraan mee gaan doen

Mozilla wel: https://blog.mozilla.org/...recating-non-secure-http/

Onvoorstelbaar, ik kom ze ook nog geregeld tegen bijv sites van de lokale cateraar waar je gewoon al je gegevens in moet vullen en dan geen https, dat snap je toch niet. Van mij mogen de waarschuwingen nog indringender zijn. Kijk een site met statische content waar je enkel iets kunt downloaden ok, maar waar je gegevens invult pfff kom op.

Ik snap het wel. Als je niks van websites snapt, maar wel een website wilt, dan zegt "http" vs "https" je niet heel veel. "Hij werkt toch?"

Dan moet je ook niet een website hosten. Zodra er persoongegevens bij te pas komen moet je gewoon weten waar je mee bezig bent.

Ideale situatie natuurlijk, maar niet hoe het werkt helaas.

Zodra browsers forceren dat HTTPS gebruikt word, merken deze mensen snel genoeg dat hun website geen traffic meer genereert. Dus, moeten ze er wel iemand bij halen die verstand van zaken heeft

Dit moet natuurlijk wel mooi gefaseerd gaan (naar mijn mening doet Google dit ook goed), zodra websites niet ineens kapot gaan door deze nieuwe maatregelingen, en dat onwetende mensen de tijd krijgen om hun websites beter te beveiligen.

Er is al een beveiligingsplicht bij het verwerken van persoonsgegevens. En daaruit is heel goed te beargumenteren dat je een inlogpagina over HTTPS dient aan te bieden.

Wat mij betreft hoe lomper de waarschuwing, hoe beter. Laat MS, Google en Mozilla maar keihard doordrukken en HTTPS afdwingen.

Het implementeren van HTTPS op een site is triviaal werk, als je site ordentelijk gebouwd is. 301 instellen die alles naar de HTTPS versie verwijst is ook geen onmogelijke taak.

Die mensen zouden altijd advies moeten krijgen van de hoster vind ik... Daar mogen best regels voor opgesteld worden

Voor het verwerken van persoonsgegevens zijn al regels. Binnenkort gaat de GDPR er over. Voor inloggen etc met niet persoonsgegevens is het natuurlijk aan de gebruiker

[Reactie gewijzigd door RobinF op 28 april 2017 20:07]

Ook dan is er geen reden om niet even een LetsEncrypt er tegenaan te gooien.

LetsEncrypt vereist iets meer moeite voor de leek dan een SSL certificaat aanvragen en eens in de 1/2 jaar vernieuwen. Gelukkig zit het al als plugin in bijv, Plesk ingebakken, maar webhostingbedrijven gaan toch liever hun eigen SSL aansmeren en dat kost centjes.

Let's Encrypt is eenvoudiger dan een certificaat kopen... enige nadeel is dat ze beperkt zijn kwa verificatie ...

Lets encrypt is voor jou als eind gebruiker misschien makkelijk. Maar vanaf de beheerderskant is lets encrypt (zonder die plesk/DA/Cpanel software) toch even wat meer werk dan een simpel certificaatje vernieuwen met de hand.

https://www.svennd.be/lets-encrypt-article-overview/

Absoluut niet. Een cron iedere week lopen en vergeten.

[Reactie gewijzigd door svennd op 29 april 2017 18:12]

ik heb het zelf ook geinstalleerd, maar dan is linken naar je eigen site voor ad inkomsten niet nodig. Link dan op z'n minst even naar de officiele guides...

zoals dan bijvoorbeeld certbot gebruiken

Maar dat is juist weer inherent aan het automatiseren. Het automatiseren van OV en EV certificaten is vele malen moeilijker tot onmogelijk.

Bij Versio zit het gewoon in DirectAdmin ingebakken. Simpel één druk op de knop en hij vernieuwt het ook automatisch. Maw. geen omkijken naar.

Er staat een gids online om met een paar oneliners een zelfvernieuwend certificaat op te zetten. Die checkt via cron af en toe of het gaat verlopen. Iedereen die al ver genoeg is dat ie DNS records aanmaakt, kan ook wel wat regeltjes copypasten via ssh.

Handmatig eens in het jaar vernieuwen is meer moeite.

[Reactie gewijzigd door ItsNotRudy op 28 april 2017 20:31]

Yop, zelf vraag ik nieuwe certs aan met een Ansible playbook die ook een renew cronjob toevoegt.

Maar genoeg ouderwetsere ITers.

maar webhostingbedrijven gaan toch liever hun eigen SSL aansmeren en dat kost centjes.

Ik weet niet bij welk hostingbedrijf jij zit, maar PCextreme biedt standaard gratis LetsEncrypt die automatisch vernieuwd worden

Of je gebruikt cloudflare free, heb je ook gratis ssl

Maar het ding met CloudFlare is dat alle verbindingen van de client naar CloudFlare wel beveiligd zijn, maar de verbinding van CloudFlare naar de server/host niet.

Dus dan heb je juist een gevaarlijkere situatie waar het er uit ziet alsof je informatie veilig is, maar het gaat nog steeds gedeeltelijk ongecodeerd over het internet.

Het vervelende van deze meldingen is dat gebruikers moeten weten wat nodig is in welke situatie. Een nieuws site, blog enz zonder formulieren hebben in principe geen https nodig. Een MItM aanval is dan wel mogelijk maar de gevolgen zijn beperkt.

Het wordt een stuk vervelender als iemand een certificaat voor https://www.1ng.nl krijgt en vervolgens een ING website aanmaakt. Chrome zal dan terecht "secure" melden terwijl er nog steeds een probleem aanwezig is.
Gelukkig hebben de meeste browsers de punycode aanvalsvector al opgelost.

Als een pagina een formulier bevat (en vraagt om gevoelige informatie) dan is HTTPS wel nodig. Waar ik bang voor ben is dat de gebruiker misschien naar de secure melding kijkt bij het laden maar zeer waarschijnlijk niet blijft controleren. Hierdoor zal de gebruiker de "not secure - when entering data" gemakkelijk missen.
M.i. is deze foutmelding niet opvallend genoeg

Het vervelende van deze meldingen is dat gebruikers moeten weten wat nodig is in welke situatie. Een nieuws site, blog enz zonder formulieren hebben in principe geen https nodig.

Oneens. Elke onbeveiligde verbinding is er één te veel. De reden: men kan niet alleen afluisteren, maar ook injecteren. Met een fake 'gratis' AP wordt het dan wel heel makkelijk om een computer bloot te stellen aan zero-days, malware, reclame en andere narigheid.

[Reactie gewijzigd door The Zep Man op 29 april 2017 13:49]

Het vervelende van deze meldingen is dat gebruikers moeten weten wat nodig is in welke situatie. Een nieuws site, blog enz zonder formulieren hebben in principe geen https nodig. Een MItM aanval is dan wel mogelijk maar de gevolgen zijn beperkt.

Oneens omdat partijen hierbij zelf content kunnen invoegen en kunnen welke specifieke pagina jij op een website bekijkt.
Zie ook deze reactie: The Zep Man in 'nieuws: Chrome gaat gebruikers vaker waarschuwen bij http-sites'

Het wordt een stuk vervelender als iemand een certificaat voor https://www.1ng.nl krijgt en vervolgens een ING website aanmaakt. Chrome zal dan terecht "secure" melden terwijl er nog steeds een probleem aanwezig is.

Chrome meldt dat de verbinding secure is. Veel mensen denken dat alles met "een slotje" goed is maar dat is totaal verkeerd. Het gaat er om dat de hostname overeenkomt met de server met wie je praat. Als dan 1ng.nl of ing.nl.nieting.nl is dan kan dat maar dan is het aan de gebruiker om dit te controleren.

Waar ik bang voor ben is dat de gebruiker misschien naar de secure melding kijkt bij het laden maar zeer waarschijnlijk niet blijft controleren. Hierdoor zal de gebruiker de "not secure - when entering data" gemakkelijk missen.
M.i. is deze foutmelding niet opvallend genoeg

Een EV certificaat is ontworpen om dit duidelijk te maken. Als je bijvoorbeeld in het beveiligde gedeelte van de rabobank komt zal er netjes de handelsnaam weergeven worden: "Cooperatieve Rabobank". ING doet dit overigens ook.
Let's Encrypt heeft overigens een mooi verhaal over: https://letsencrypt.org/2015/10/29/phishing-and-malware.html

[Reactie gewijzigd door RobinF op 28 april 2017 20:17]

Gaan de providers nu ook al hun routers bij de gebruikers thuis van certificaten voorzien? Nu is het nog een waarschuwing bij het inloggen, later moet je eerst naar about://flags om het weer mogelijk te maken, en nog later werkt het in het geheel niet meer.

Ze kunnen altijd LAN adressen erbuiten laten, of in ieder geval de .1 of .254.

Alleen jammer dat zowat elke browser gaat klagen over self-signed certificates op lokale ip adressen. Dit werkt het gebruik van http over lokale netwerken alleen maar in de hand.

Exact, self-signed zijn imho even veilig lijkt me als de echte. Nu krijg je een vuile waarschuwing waar niemand beter van word.

Even veilig is niet zo. Qua encryptie zal het praktisch hetzelfde zijn maar qua authenticatie zit er wel een verschil tenzij jij natuurlijk heel netjes met je root certificaat omgaat.

Iets dergelijks heb ik eerder ook eens onder een nieuwsbericht geplaatst. Gelukkig weet ik nu beter
Goede encryptie is goede encryptie inderdaad, daar doet een self-signed certificate niets aan af. Wat je echter niet weet is met wie je een encrypted gesprek voert. Een MITM aanval zul je met een self signed certificaat waarschijnlijk niet uitvinden. Zowel jij als je server voert een encrypted 'gesprek'. Dat jullie dat gesprek niet met elkaar hebben maar met een tussenpersoon heb je geen weet van.

De enige manier om een MITM te ontdekken bij gebruik van een self-signed certificate is door als gebruiker te weten met welk certificaat je zou moeten zij verbonden en ook daadwerkelijk te controleren dat dat zo is. In een privésituatie is dat haalbaar maar als je meerdere gebruikers kent wordt dat al een stuk lastiger.

[Reactie gewijzigd door Joolee op 29 april 2017 16:24]

Met self signed weet je idd niet met wie je praat maar je bent volgens mij afdoende beschermt om te weten dat niemand tussenin kan meelezen.

Als ik een webservice dus ken, (niet eerste maal) en ik aanvaarde het self-signed, dan zou in theorie mijn verbinding te vertrouwen zijn lijkt me, maar bon, met let's encrypt is alles een stuk makkelijker/goedkoper.

Certificaten zijn niet (meer) aan te vragen voor private classes, zoals de ranges die men thuis gebruikt. Chrome kan deze ranges makkelijk uitzonderen.

Dat is niet helemaal waar. Volgens het CA/Browser Forum mag dit niet meer maar het staat je altijd vrij om intern een CA te maken om certificaten voor RFC1918 IPs uit te geven.

Eventueel kan je die CA zelf vertrouwen. Alleen de grotere partijen zoals Mozilla zullen je CA niet vertrouwen.

Daarnaast kan je gewoon je eigen domeinnaam aan een RFC1918 IP koppelen en daar een certificaat voor aanvragen.

[Reactie gewijzigd door RobinF op 28 april 2017 20:29]

Een zelfbeheerde (c.q. interne) CA valt buiten hetgeen ik beschrijf. Een eigen CA kun je namelijk altijd volledig volgens je eigen regels inzetten. Ik heb het ook over het aanvragen van certificaten en daarmee doel ik dus op de commerciële CA's. Als het je eigen CA is stelt een "aanvraag" ook niet veel voor.

Daarnaast: als je er een domeinnaam voor aanvraagt is het geen IP-adres in de private classes waar je een certificaat voor aanvraagt. Het is in dat geval een publiek geregistreerde domeinnaam. Dat je die vervolgens doorverwijst naar een intern IP-adres doet daar niets aan af.

[Reactie gewijzigd door Eagle Creek op 29 april 2017 16:38]

Ook leuk, als web developer draai ik vaak op een lokale development server (localhost, dus geen https mogelijk). Dit gaat nog leuk worden in de toekomst.

Voeg je self signed certificate toe als betrouwbare uitgever van certs. in je besturingssysteem

Https is mogelijk op localhost, alleen kun je geen geldig certificaat hierop krijgen. Een flag in chrome maakt het mogelijk geen waarschuwing te geven bij ongeldige certificaten op localhost

De vraag is, wat is geldig? Je kan namelijk gewoon zelf een certifcaat uitgeven voor localhost en jouw root certificaat als vertrouwd toevoegen aan je computer.
Dat is het mooie van het trusted third-party systeem.

[Reactie gewijzigd door RobinF op 28 april 2017 20:30]

Gaan de providers nu ook al hun routers bij de gebruikers thuis van certificaten voorzien?

All-in-one (modem + router) van providers weet ik niet, maar de meeste grote router-fabrikanten doen dat reeds. Uiteraard is dat wel een self-signed certificaat, want per definitie geen internet, maar intranet domein. Maar als je dat als trusted importeerd/aanmerkt op je computer/telefoon/etc kun je gewoon met HTTPS inloggen.

(En doe je die import niet kan het ook maar moet je eerst een rode balk wegklikken.)

Maar goed, als je HTTPS nodig hebt over je eigen WiFi intranet, is er natuurlijk wel wat anders mis lijkt mij aangezien WPA2 al afscheiding van individuele gebruikers biedt.

Gaan de providers nu ook al hun routers bij de gebruikers thuis van certificaten voorzien?

All-in-one (modem + router) van providers weet ik niet, maar de meeste grote router-fabrikanten doen dat reeds. Uiteraard is dat wel een self-signed certificaat, want per definitie geen internet, maar intranet domein. Maar als je dat als trusted importeerd/aanmerkt op je computer/telefoon/etc kun je gewoon met HTTPS inloggen.

Asus firmware heeft alleen een heel irritant probleem waar het certificaat bij elke firmware update opnieuw gegenereerd wordt op zo'n manier dat er een mismatch ontstaat met de versie die je eerder lokaal geimporteerd had als trusted.

Omdat ze tegelijkertijd ook van application cache gebruik maken, krijg je als eindgebuiker op dat moment enkel nog een nietszeggende offline pagina te zien met de boodschap:

Settings have been updated. Web page will now refresh.
Changes have been made to the IP address or port number. You will now be disconnected from <ROUTER MODEL>.
To access the settings of <ROUTER MODEL>, reconnect to the wireless network and use the updated IP address and port number.

Zelf tegengekomen bij iemand. Was toen echt wel even graven voordat ik er achter was wat daar nou aan de hand was. Gelukkig kun je bij Firefox per domein permissies instellen en app-cache gewoon niet toestaan voor het router domein.

[Reactie gewijzigd door R4gnax op 29 april 2017 12:59]

Ik snap 1 ding niet: hoe kun je de veiligheid verhogen met gratis certificaten (zoals de genoemde let's encrypt)?

Als het certificaat een garantie van betrouwbaarheid moet zijn, dan moeten er controles uitgevoerd worden om jouw betrouwbaarheid, en daarmee je site te valideren. Zoals kost tijd, mankracht. Dat kan m.i. niet gratis gedaan worden.

Daarnaast: een certificaat kan nog steeds naar een https website verwijzen, die op zich zelf verwerpelijke of zelfs schadelijke content kan aanbieden. Dat https is niet meer dat je verbinding versleuteld is. Het zegt alleen iets dat de aanbieder van de website moeite gedaan heeft om zijn backend van een (trusted) certificaat te voorzien. Daardoor wordt data veiliger uitgewisseld dan met plain, niet-versleuteld http. Meer niet. Ook via een https verbinding kun je een virus oid oplopen.

Het adagium dat hierboven door een aantal gehanteerd lijkt te worden (https is veilig) behoeft op z'n minst enige nuancering.

Klopt wat je zegt. LetsEncrypt bied geen betrouwbaarheid maar probeert dit ook niet te bereiken. Hier voor wil je een EV certificaat waarbij jouw organisatie naam in de URL balk komt te staan. Hier komen inderdaad controles zeker voor.

Maar hoe zorg ik dan dat lokale 'websites' van programma's zoals Sabnzbd, Sonarr en Plex dat regelen? Draaien nu op 192.168.1.x of 10.0.0.x maar ik kan daardoor ook geen certificaat daarvoor aanmaken in Windows.

Gaat volgens mij wel met een Let's Encrypt certificaat, afhankelijk van hoe je de website benadert.
Dat werkt niet op 192.168.1.x maar als je hem
1. aan een domeinnaam kunt koppelen
én
2. de nodige aanpassingen doet in je DNS zodat de FQDN naar je interne IP resolvt, dan zou het wel moeten werken als je hem via http://jouw-FQDN benadert.

We hebben hier op het werkt hetzelfde probleem met
* de webinterface voro de tijdverantwoording, vakantieaanvragen e.d.
* interne registratiewebsite voor materiaalgebruik
* ...

Ik ben bezig met LE certificaten te regelen. Ik ben er nog niet helemaal uit, maar het theoretische plaatje klopt volgens mij al.

Als de eerder vermelde in order zijn is het wellicht gemakkelijk om dat ook voor een aantal diensten te doen waar ik nog niet over nagedacht heb, en die niet zó belangrijk zijn omdat gewone users er niet bij moeten kunnen.
* de webinterface voor de zonnepanelen
* vSphere Web UI
* switch management

[Reactie gewijzigd door tc-t op 28 april 2017 18:57]

Als je een officiële domein of hostnaam hebt dan kan je idd een ssl cert hiervoor aanvragen. Bij letsencrypt moet je server om het certificaat aan te vragen wel berihkbaar zijn vanaf buiten op poort 443. Vervolgens kan je op jeinterne netwerk een eigen DNS gebruiken of op alle machines de hosts file aanpassen zodat je hostnaam die bij het sslcert hoort wordt doorgestuurd naar je lan adres van je server.

Tja, ik vind dit dus totaal niet werken. LE is leuk voor openbare sites.

Maar voor interne sites werkt het niet, want die gooi je gelijk open voor internet vanwege de validatie en dan moet je opeens je beveiliging op orde hebben.

Waarbij ik geen garanties durf af te geven op de beveiliging van tijdsregistratie tooltjes en vakantieaanvragen etc.

Niet waar. Je moet ACME gebruiken om je domein te verifieren maar dit mag met TLS-SNI-01, HTTP-01 en DNS-01. Je kan het dus ook heel makkelijk doen met DNS

Lokaal DNS records aanmaken voor je server en een certificaat toepassen is een optie.

Draaien nu op 192.168.1.x of 10.0.0.x maar ik kan daardoor ook geen certificaat daarvoor aanmaken in Windows.

De vraag is of voor thuis-gebruik intranet het nodig is natuurlijk. Maar ook daar kan het. Je kunt dan een self-signed certifciaat aanmaken, en dit gebruiken met een intranet hostname. Uiteraard werkt dat alleen als de webserver in dat apparaat ook HTTPS kan serveren. Indien dat zo is, is er echter al soms reeds een self-signed certifciaat ingebakken, en is het een kwestie van als 'trusted' aanmerken op je PC/telefoon.

Alleen draai ik zelf geen eigen webserver. Dat doen de programma's (Plex en Sabnzbd), is het dan alsnog mogelijk?

Daar refereede ik naar: "Uiteraard werkt dat alleen als de webserver in dat apparaat ook HTTPS kan serveren. Indien dat zo is, is er echter al soms reeds een self-signed certifciaat ingebakken, en is het een kwestie van als 'trusted' aanmerken op je PC/telefoon. "

Kan het apparaat het wel, maar is er geen certifciaat ingebakken wordt het meestal toch al hackwerk waar ik niet aan zou beginnen.

Sabnzbd heeft het trouwens wel. Alleen op de een of andere manier ook al voeg ik het in Windows als trusted toe, toch geeft Chrome dan aan dat het niet veilig is.

Chrome dan aan dat het niet veilig is.

Wat als je Edge or IE start? Als die het ook niet accepteren, is het als trusted toewijzen niet gelukt. Hier een voorbeeld om IE te gebruiken.

Ikzelf gebruik geen Chrome, maar wellicht dat dit helpt?

Ik gebruik inoreader als feedreader, maar niet met https, want dan werkt de previewfunctie niet en moet ik steeds de feed in een nieuwe tab openen. Dat wil ik dus niet.

Maar is dat dan het probleem van https? Eerder van inoreader lijkt me

Weet ik. Dat melden ze ook. Ik gebruik ook liever https, maar in dit geval dus niet.

In Firefox heb ik dit soort meuk maar uitgezet, erg irritant op lokaal netwerk

Een beetje of topic maar er schiet mij ineens een vraag naar boven. In incognito modus kunnen google en je provider toch wel jou data inzien?