Google Chrome krijgt ander icoon in plaats van slotje voor https-websites

Google geeft zijn browser Chrome een ander icoon in plaats van het slotje voor https-websites. Omdat https op websites nu de standaard is, is het slotje niet meer nodig volgens de zoekgigant. Een icoon voor website-instellingen ligt dan meer voor de hand, redeneert het bedrijf.

Chrome blijft http-sites markeren als onveilig, zegt Google. Het nieuwe icoon maakt gebruikers duidelijk dat er instellingen zijn die gebruikers kunnen aanpassen en impliceert bovendien niet langer dat de site te vertrouwen is. Ook https-sites kunnen malafide content bevatten, al is de verbinding beveiligd, zo redeneert het bedrijf.

Het vervangen van het icoontje wordt onderdeel van een grotere refresh van het design van de browser. Die komt live in Chrome 117, die in september moet uitkomen. Met een flag is die al te activeren. Op Android krijgt Chrome hetzelfde icoon rond hetzelfde moment. Op iOS is het icoon niet te klikken, dus daar haalt Google het icoon helemaal weg.

Het oude lock-icoon (links) en het nieuwe

Reacties (114)

[Madcat]

Waar het naar toe moet gaan is dat de URL minder prominent in beeld moet zijn in de browser en dat de identitieit van het certificaat juist meer in beeld zou moeten zijn.

Dus in geval van dit bericht dat er ipv tweakers.net /nieuws/209320/ in de URL iets van {certificaat identiteit}nieuws/209320/ moet komen.
Op dit manier zie je duidelijker dat je op een verkeerde website bent beland

[Reactie gewijzigd door Madcat op 23 juli 2024 08:17]

[GertMenkel]

Apple doet (deed?) dit geloof ik in Safari. Helaas kun je een bedrijf oprichten met een soortgelijke naam in een ander land en daarvoor een certificaat aanvragen, dus veilig is het niet bepaald. Dit is één van de redenen dat browsers de extra perks van de EV-kartel af hebben gepakt.

Ga naar nissan.com en je komt op de website van een bedrijf genaamd Nissan uit, maar als dat bedrijf je auto's verkoopt doe je iets goed verkeerd. Desondanks is het bedrijf niks minder echt, vertrouwd en legaal dan de Nissan die jij en ik wellicht kennen.

Browsers hebben nu al een tijdje het domein in een veel dikkere kleur dan de rest van de URL juist om de bron van de pagina te identificeren. Google heeft ook de https:// prefix laten vallen om het domein zo ver mogelijk naar links te halen.

[deadinspace]

Dus in geval van dit bericht dat er ipv tweakers.net /nieuws/209320/ in de URL iets van {certificaat identiteit}nieuws/209320/ moet komen.

Maar de "certificaat identiteit" (CN veld) in het Tweakers certificaat is "tweakers.net". Dan verandert er dus niks. Kijk maar in de details van het certificaat.

Dat is het hele idee van Domain-Validated certificaten: ze verifieren de verbinding met het domein, en meer niet.

Alleen EV/OV certificaten doen meer dan dat, maar die worden maar door heel weinig sites gebruikt.

[Reactie gewijzigd door deadinspace op 23 juli 2024 08:17]

[closefuture]

> Maar de "certificaat identiteit" (CN veld)

Het CN veld is voor dat gebruik overigens ook uitgefaseerd. Chrome kijkt enkel naar de SAN's (subject alternative name) in het certificaat.

Daar ontstaat dan ook meteen een probleem want een certificaat kan velen SAN's hebben.

[deadinspace]

Het CN veld is voor dat gebruik overigens ook uitgefaseerd.

Klopt, maar het is wel hetgeen het dichtst bij een "certificaat identiteit" in de buurt komt in een DV certificaat. Iets anders (a la "Tweakers.net B.V.") staat er niet in namelijk. Het verandert dus niet veel aan mijn antwoord.

[Blokker_1999]

Jarenlang leer je mensen aan dat ze naar dat slotje moeten kijken. Heeft Google enig idee hoeveel hoofdpijn ze mensen gaan be zorgen van al die vragen die we gaan krijgen van bezorgde mensen die nu gaan denken dat er iets mis is?

[Finraziel]

Maar zoals Google in de bron uitlegt zegt het slotje niet dat de website veilig is. Malafide websites gebruiken ook gewoon https. Dus mensen die dat gebruiken om te zien of een website veilig is die moeten ook eens vragen gaan stellen want het is niet meer genoeg om alleen naar dat slotje te kijken. Het geeft een vals gevoel van veiligheid dus goed dat ze het weghalen.

[IStealYourGun]

Klopt, maar toch gebruik ik dat nog steeds als check en als het om een website gaat voor betalingen dan check ik snel wie het certificaat heeft uitgeschreven. Een Let's Encrypt is dan wel een rode vlag omdat daar geen verificatie nodig is.

[Joolee]

Let's encrypt voert net zoveel verificatie uit als de meeste partijen. Sterker nog; de verificatie die het uitvoert is een vaste procedure waar iedereen zich aan moet houden. Waar je bij andere certificaatproviders nog wel eens ziet dat als je maar groot genoeg bent, je steeds makkelijker aan certificaten kunt komen.

Er is echt niets mis met let's encrypt. Sinds browsers zijn gestopt met het extra duidelijk weergeven van "extended validation" certificaten is ook waarde daarvan nu nihil.

[gooos]

Eens, en de certificaten van Let's encrypt zijn ook nog eens korter geldig (3 mnd), wat het eigenlijk een betere setup maakt in mijn beleving dan certificaten die goed 2 jaar geldig zijn.

[stefan52a]

Eens. De MITM preventie is toch altijd afhankelijk van de zwakste schakel in je commuincatiokanaal. Denk, in ultimo, bijv. aan de communicatie tussen je analoge brein en je toetsenbord. Ok dat is plaatselijk, denk je, en een minder gevoelige attack vector, maar toch.
Maar wat ik me afvraag wat de risico's op dit moment zijn in elk stukje van die communicatie.
Bijv. ik heb net een site opgezet die nog niet met TLS beveiligd is, is het gvaar dan groot dat er dan al bijv. bots zijn ,die het net afscannen naar onveilige ports, die meeluisteren?

[Joolee]

Meeluisteren kun je in principe alleen maar als je in de datastroom zelf zit; een man in the middle positie. Een willekeurige bot kan niets met jouw http website op poort 80 dat hij niet ook kan op jouw https website op poort 443.

Als je je zorgen maakt om mitm aanvallen dan zou je eens kunnen bedenken waarom er zoveel partijen zijn die je vpn verbindingen aan proberen te smeren (alle verkeer loopt dan via hun servers!) En hoe slecht de backbone van internet in elkaar zit (bgp hijacking)

[.oisyn]

Een willekeurige bot kan niets met jouw http website op poort 80 dat hij niet ook kan op jouw https website op poort 443.

Dat is wat kort door de bocht. Elk apparaat op hetzelfde wifi-netwerk kan bijvoorbeeld al doodleuk meeluisteren. Dat is niet per se een mitm positie (al is de stap daarnaartoe op zo'n moment al niet groot meer).

[Joolee]

Dat is gelukkig alleen het geval met onversleutelde wifi netwerken. Het is uiteraard wel zo dat ook bij een versleuteld netwerk de eigenaar van dat netwerk alle (onversleuteld, http) verkeer in kan zien op de router. Het is echt niet zo dat je als deelnemer van een modern versleuteld wifi netwerk het verkeer van alle andere clients in kan zien, die tijd zijn we gelukkig al ver voorbij.

[.oisyn]

Dat is gelukkig alleen het geval met onversleutelde wifi netwerken

Vziw is dat het geval op alle wifi netwerken waarvan je het wachtwoord weet.

Ah, ik zat ernaast, met WPA heb je wel versleutelde sessies. Al lijkt het in de praktijk niet heel lastig om alsnog af te luisteren, dus het gaat wat ver om je dan beschermd te noemen.

[Reactie gewijzigd door .oisyn op 23 juli 2024 08:17]

[Joolee]

Al sinds de overstap van wep naar wpa wordt er gebruik gemaakt van sleutels die voor elke cliënt (een elke x pakketten) uniek zijn. Dat wil niet zeggen dat er geen andere problemen met, vooral de oudere, versies van wpa zijn maar het afluisteren van verkeer vanaf een enkele cliënt hoef je tegenwoordig niet bang meer voor te zijn.

[.oisyn]

Even f5'en

[deadinspace]

Meeluisteren kun je in principe alleen maar als je in de datastroom zelf zit; een man in the middle positie.

Ook dan niet, tenzij er meer mis gaat. TLS-verkeer is versleuteld en ondertekend dmv (de private key horende bij) het certificaat. Zie voor meer details mijn reactie verderop.

[Joolee]

Stefan had het dan ook over onversleuteld http verkeer

[Waswat]

Let's Encrypt heeft wel degelijk een verificatie nodig. Namelijk dat je de eigenaar bent van het domein of in ieder geval controle hebt over de dns er van. Of dat je website waar je domein naar verwijst een token bevat op een specifieke locatie (gegenereerd door let's encrypt).

https://letsencrypt.org/docs/challenge-types/

[Reactie gewijzigd door Waswat op 23 juli 2024 08:17]

[lenwar]

Namelijk dat je de eigenaar bent van het domein of in ieder geval controle hebt over de dns er van.

Nou ja... Alleen controle hebt op de DNS (of webserver) Het zegt niets over de eigenaar.

Edit: blijkbaar suggereerde ik dat LE-certificaten minder ‘goed’ zijn. Dat was zeker niet mijn intentie.
Ter aanvulling op bovenstaande:
En dat is natuurlijk helemaal prima. De meeste CA’s doen niets meer dan dat, alleen LE doet het gratis en je kan het heel makkelijk volledig automatiseren.

Certificaten bieden dan ook geen garantie dat je op de gewenste plaats bent uitgekomen. Alleen dat de verbinding versleuteld is en dat de dns-records/webserver in controle zijn van de certificaat-aanvrager.

(( je kan prima op een site met een certificaat op tweakers.nl (ipv .net) uitgekomen zijn. Daar beschermen de certificaten niet tegen. Daar zijn ze ook niet voor bedoeld ))

[Reactie gewijzigd door lenwar op 23 juli 2024 08:17]

[djiwie]

Bijna alle betaalde certificaten checken ook alleen op DNS (tenzij je een duurder cert neemt, wat bijna niemand meer doet). En Let's Encrypt checkt minstens elke 3 maanden ipv 1 jaar dus vaker dan gemiddeld.

[lenwar]

Klopt helemaal!
En omdat het volledig geautomatiseerd kan, is dat wel echt heel fijn.

[pennywiser]

Dat geldt voor tig andere merken certificaten ook. EV certificaten komen maar weinig voor. Je bent niet helemaal goed geïnformeerd.

[lenwar]

Ja, dat klopt.
Ik suggereer toch nergens dat het bij andere CA’s anders is?

Ik reageerde alleen op het feit dat je niet de eigenaar van het domein hoeft te zijn. Het enige dat een (niet-EV) certificaat ‘aantoont’ is dat je controle hebt over de DNS-records. Niets meer of minder dan dat.

Ik kan prima eigenaar van een domein zijn en iemand anders de certificaten laten regelen, door hen toegang te geven tot de DNS ofzo.

Nou ik er aan denk had ik vroeger een certificaat en daar moest ik controle hebben over een specifiek e-mail adres. Weet even niet meer precies hoe dat zat.
Uit m’n hoofd kreeg ik de ‘opdracht’ om een bepaald e-mail adres aan te maken waar zijn dan een code naartoe stuurde ofzo. Of misschien was het dan iets van [e-mail] ofzo. Er was wel nog een extra iets daar voordat ze m’n csr in behandeling nemen.

[pennywiser]

Maar je noemt dat alleen bij LE dat een probleem is. Het challenge mechanisme dat zij gebruiken, bestond voor LE al jaren. En toen was het geen probleem kennelijk.

Er zijn per certificaat meerdere challenges mogelijk vaak.

[lenwar]

Kan je me daarvan citeren? Ik zie het niet staan? Ik zeg toch ook nergens dat het een probleem is?

Ik reageer op het feit dat iemand zegt dat LE eigenaar moet zijn of in elk geval DNS-controle nodig heeft.

Ik corrigeer dat naar het feit dat er geen eigenaarschap nodig is. Ik plak er toch geen waardeoordeel aan?

[pennywiser]

Spraakverwarring denk ik, ik had het idee dat je met de eerste opmerking "LE is een rode vlag" meeging. Excuus.

[lenwar]

Ah. Vandaar
Ik zal m’n reactie aanpassen. Er zijn blijkbaar ook andere mensen die die conclusie trokken.

[Ies Korpershoek]

grappig, tweakers.net gebruikt ook let's Encrypt althans volgens certificaat info achter het 'slotje'

[IStealYourGun]

Maar tweakers is dan ook een nieuwswebsite en de betaling gebeuren niet op hun website.

Desondanks heb ik dat altijd vreemd gevonden. Volgens mij hebben alle websites van dpg gewoon een professioneel certificaat.

[FlyingDutchMen]

De betalingen van Tweakers gear gaan wel via https://tweakersgear.net. En de ze hebben ook ene Let's Encrypt certificaat. Al maakt het al met al verdacht weinig uit. Want er zijn nog maar weinig shops waar de betaling zelf nog via de website gaat. Nagenoeg alle shops gebruiken Bijv. Mollie voor ideal en creditcard en paypal. Je komt dan toch echt de website van deze uit om te betalen en als je hebt betaald redirecten ze je terug naar de webshop. Of ze hebben dit alles via een IFrame gedaan.

Ik denk ook dat de vraag een beetje is waarom is Let's Encrypt zo slecht? omdat er makkelijk aan te komen is? Koop een random domein bij strato en voor twee tientjes heb je een domein en SSL certificaat. Dus als dat de gedachte gang is, vraag ik me af of dit wel perse logisch is.

[IStealYourGun]

Ik heb nooit beweerd dat Let's Encrypt slecht is, het is zelfs een hele goede tool die je gerust kan gebruiken op een blog of een nieuwssite. Maar zodra je gevoelige gegevens moet inbrengen, hoop ik dat je als eigenaar de moeite doet om een je certificaat te laten uitschrijven door een partij met de nodige audits en support.

[.oisyn]

Ik heb nooit beweerd dat Let's Encrypt slecht is

Je zegt dat het een rode vlag is, en daarmee impliceer je dat het slechter is dan een certificaat van een andere (niet gratis) partij. En daarna spreek je ook nog eens van een "professioneel certificaat".

Er is niets onprofessioneel aan Let's Encrypt of vergelijkbare partijen. Ze volgen exact dezelfde procedures als de partijen die jij als professional beschouwt. En het feit dat je voor die andere partijen moet betalen legt een scammer echt geen stroobreed in de weg.

[deadinspace]

Maar zodra je gevoelige gegevens moet inbrengen, hoop ik dat je als eigenaar de moeite doet om een je certificaat te laten uitschrijven door een partij met de nodige audits en support.

Let's Encrypt heeft ook webtrust audits, dit zijn verplichte audits voor alle CAs. Je vindt de meest recente rapporten van Let's Encrypt hier.

Er is geen bezwaar om Let's Encrypt certificaten te gebruiken voor sites die gevoelige gegevens verwerken. Het is ook niet alsof een Let's Encrypt certificaat resulteert in een onveilige verbinding, zelfs als Let's Encrypt intern iets fout doet. De private key die bij het certificaat hoort en de feitelijke versleuteling doet, gaat immers nooit naar Let's Encrypt maar blijft 100% in handen van de site-beheerder.

[Eagle Creek]

Kun je aangeven waarom een partij als let's encrypt niet professioneel is volgens jou? En waarom een commerciële boer dit wel zou zijn? Omdat gratis per definitie rommelt?

De Symantec's en Diginotars van deze wereld hebben ook niet bepaald hun best gedaan het imago hoog te houden. En met name eerstgenoemde had toch wel een flinke naam in beveiligingsland.

Let's encrypt voert als CA dezelfde controles uit als alle andere CA's, zoals vastgelegd in de browserforumstandaarden.

Daarnaast geeft ze aan dat je het slotje als extra controle gebruikt. Maar wat als ik nu zeg dat het de standaard is dat alle sites beveiligd zijn en de controle er inzit dat je geen waarschuwing ontvangt? Daar bovenop kun je nog steeds handmatig op het icoontje klikken om het certificaat op te vragen.

[Reactie gewijzigd door Eagle Creek op 23 juli 2024 08:17]

[IStealYourGun]

Let's encrypt is nog steeds een service as-is zonder enige garantie, sla of support. Ik ga ervan uit dat je als betalingsinstelling daar toch moeite mee hebt en daarvoor kiest voor een andere partij. Dus neen, ik vind let's encrypt niet professioneel en dat is oké voor veel websites, maar niet voor alle.

Edit: Plus, tot op heden heb ik nog geen phishing site tegengekomen die gebruik maakt van een duur certificaat. Dat soort aanvallers doen niet de moeite om dat allemaal aan te vragen als ze sneller en goedkoper gewoon een website kunnen opzetten met let's encrypt.

Op die manier heb ik in het verleden trouwens al een succesvolle aanval kunnen voorkomen. Ik zat op een phishing site met een let's encrypt, goed wetende dat het echte bedrijf daar vermoedelijk geen gebruik van zou maken en een check op de echte website gaf me gelijk. Dus voor mij is een let's encrypt certificaat een rood vlagje als ik gevoelige data moet ingeven.

[Reactie gewijzigd door IStealYourGun op 23 juli 2024 08:17]

[svane]

en de betaling gebeuren niet op hun website.

Betalingen gaan inderdaad vaak via een Payment provider. Een van de grootsten daarvan is Adyen, met klanten als Uber/microsoft/Booking.com/KLM etc.

Enig idee wat voor certificaat er op Adyen.com zit? Juist, Letsencrypt

Het is oké dat jij letsencrypt zelf als red-flag ziet, maar het is slecht advies om dit aan anderen aan te raden.
https://www.vanmoof.com/nl-NL (ook letsencrypt) gebruikt zelf ook Adyen en dus letsencrypt tot de betaalpagina aan toe. Als klant zie je dus volop letsencrypt, en ik heb nou niet het idee dat dat nou ook maar iets zegt over de veiligheid van de betalingen.

[deadinspace]

Klopt, maar toch gebruik ik dat nog steeds als check en als het om een website gaat voor betalingen dan check ik snel wie het certificaat heeft uitgeschreven. Een Let's Encrypt is dan wel een rode vlag omdat daar geen verificatie nodig is.

Let's Encrypt vereist exact evenveel verificatie als andere CA's doen voor DV-certificaten, namelijk: je moet aantonen dat je het domein in kwestie beheert voordat je een certificaat krijgt.

Zo werkt het overal; je moet (al dan niet geautomatiseerd) laten zien dat je een code kunt ontvangen op [e-mail], of dat je een code kunt weergeven op domein.nl/verificatie, of dat je een DNS-record genaamd code.domein.nl kunt aanmaken. De verificatie hiervoor is bij Let's Encrypt niet beter of slechter dan andere CAs.

Waar wel extra verificatie gebeurt is bij EV certificaten; EV staat zelfs voor Extended Validation. Maar deze certificaten zijn veel duurder en worden maar door heel weinig websites gebruikt. Banken hebben ze doorgaans wel, maar webshops niet. (ze zijn ook maar beperkt nuttig en verdwijnen waarschijnlijk op termijn.)

Voor meer informatie is dit uitgebreide antwoord op webmasters.stackexchange.com goed leesvoer.

[Blokker_1999]

En ook dat is door toedoen van Google zelf.

Met een EV certificaat, het type certificaat dat vele instellingen vroeger gebruikten en vandaag ook nog altijd, is het wel degelijk mogelijk om na te gaan of de server malafide is, danwel toebehoord aan de firma van wie je de site bezoekt. En vroeger gaven Browsers de naam in het EV certificaat ook gewoon netjes weer naast het slotje. Totdat Google besloot dat het volgens hen geen toegevoegde waarde had.

Maar vandaag is dat slotje nog altijd een indicator dat de verbinding tussen jouw PC en de server beveiligd is op een vertrouwde manier. En hoewel het omkeren van die logica, door een waarschuwing te tonen wanneer er geen encryptie is, inderdaad hetzelfde doel bekomt, is het probleem hier dat we gedurende 20 jaar heel veel mensen hebben aangeleerd dat wanneer ze bijvoorbeeld naar de website van hun bank gaan, dat ze zeker moeten zijn dat dat slotje er staat.

Ik herinner mij ong het verhaal van een kennis die op een callcenter werkte van een ISP. Op een dag had hij een klant aan de lijn en die vroeg aan hem waarom ze het internet hadden veranderd. Nu had hij moeite om het internet terug te vinden op zijn computer. Wat was hier aan de hand? Heel eenvoudig. De beste gebruiker kon zijn Internet Explorer niet meer terugvinden omdat Microsoft na al die jaren besloten had om eindelijk IE6 te upgraden naar IE7. En zoals dit voorbeeld zijn er enorm veel mensen. Zij kennen niets van technologie, niets van het internet. We leren hen aan hoe er mee te werken en geven advies aan hoe men zich zo veilig mogelijk moet gedragen op het internet dat hen continue probeert te bestelen en te belazeren. 1 van de dingen die vele van ons hier op Tweakers al decennia zeggen is: er moet een slotje staan.

Haal nu dat slotje weg, en wat gaat er gebeuren denk je? En waarom? Waarom kan het slotje niet gewoon blijven staan? Die toggles die men wil toevoegen kan men er evengoed bijzetten in dat pop-up menu als er een slotje blijft staan.

[Jeoh]

Extended Validation zei in 2019 al helemaal niets meer: https://www.troyhunt.com/...s-are-really-really-dead/

[Blokker_1999]

Maar niet omdat het niet nuttig is, net omdat Google daar net hetzelfde gedaan heeft, het tonen van de EV informatie weggehaald uit de adresbalk. Dan mag je wel zeggen dat het dood is, maar plaats er dan ook direct de context bij. Het is niet alsof EV ineens slecht of onbetrouwbaar was geworden.

[d3burt]

Ehhh... Troy Hunt is één van de security bobo's die al jaren daarvoor riepen dat EV certificaten meer kwaad doen dan goed. Een ding is zeker: het is voor het geboefte nu makkelijker dan tien jaar geleden om aan certificaten op maat te komen, door de integratie met ransomware gangs. Kijk alleen maar hoe vaak exploits van zero day vulnerabilities gewoon een geldige driver signature hebben.

Het is ooit een grote fout geweest om te roepen dat een slotje betekent dat een website veilig is. En ik weet zeker dat ik mijn pa aan de lijn ga krijgen als er weer eens iets verandert in de browser, dus ik heb ook een enorme hekel aan dit soort wijzigingen... Maar goed, de browsers gaan collectief in die richting dus we zullen wel mee moeten.

[Jeoh]

Lees de rest van het artikel anders even

[Verwijderd]

Door Blokker_1999:

Met een EV certificaat, het type certificaat dat vele instellingen vroeger gebruikten en vandaag ook nog altijd, is het wel degelijk mogelijk om na te gaan of de server malafide is, danwel toebehoord aan de firma van wie je de site bezoekt.

Aan de hand van een https servercertificaat kun je niet nagaan of een website gehacked is of niet. Het énige doel van zo'n certificaat is authenticatie van de webserver.

Bij een DV (Domain Validated) certificaat weet je niet méér dan de domeinnaam van de webserver. Het probleem daarbij is dat je, als internetter, kennelijk moet ruiken of zo van welke organisatie een gegeven domeinnaam is (microsoft-sso.net, circle-ci.com en ga zo maar door). Precies daardoor trappen zoveel mensen in nepwebsites.

Vooral omdat ze gratis zijn (geen "money-trail"), niemand vragen stelt en je ze in een oogwenk verkrijgt, gebruiken nagenoeg alle nepwebsites DV-certificaten.

Bij een OV (Organization Validated) en EV (Extended Validation) certificaat kun je met enige zekerheid nagaan van welke organisatie een website is, en dat kan enorm helpen om een phishing website van een echte website te onderscheiden.

Ik vind het een slechte zaak dat webbrowsers niet ééns laten zien welke soort certificaat (DV, OV, EV of QWAC) een website gebruikt, wat er ook toe leidt dat steeds meer websites DV-certs gaan gebruiken. Daarmee kun je als bezoeker op geen enkele manier meer vaststellen van welke organisatie een website is (omdat je hooguit de domeinnaam ziet). Dit werkt steeds meer phishing in de hand.

Omdat je op iPhone en iPad standaard geen TLS-certificaten kunt bekijken, heb ik (belangeloos) een Nederlandse vertaling gemaakt voor de gratis app TLS Inspector (de maker, Ian Spence, ontvangt graag donaties en er bestaat ook een betaalde pro-versie van). De app met NL vertaling staat sinds afgelopen weekend in de Apple App Store (de app werkt ook prima op iPhone).

De NL vertaling is nog niet perfect, maar "you get the idea" waarschijnlijk. Met TLS Inspector kun je TLS-certificaten bekijken, waaronder https server-certificaten. Dat kan vanuit de app zelf, maar je kunt ook in jouw webbrowser op de knop "delen" drukken (lijkt op [^]) en dan onderaan op "Show Certificate" drukken (dat is dus nog niet vertaald). Met de app kun je ook http headerregels (kopregels) bekijken, zoals settings voor HSTS en CSP.

Ik hoop hierover binnenkort een uitgebreide writeup op security.nl te publiceren.

Deze "TLS Inspector" app is overigens open source.

@Jeoh in deze reactie: met alle respect voor Troy Hunt, maar dit heeft hij hartstikke fout. "Dankzij" DV-certificaten stikt het op internet van de phishing-sites - waar niet alleen suffe ouwe knarren intrappen.

Aanvulling 14:14: meer info over de app toegevoegd.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 08:17]

[Finraziel]

Om jouw hele verhaal samen te vatten, je hebt geen zin om lastig gevallen te worden door digibeten die je een trucje geleerd hebt ook al helpt dat trucje hun nu helemaal niet meer?

Dingen hetzelfde houden alleen om oude users die het niet snappen gerust te stellen terwijl iets helemaal geen nut meer heeft is wat mij betreft compleet zinloos. Ik heb helaas geen andere magic tip waarmee een digibeet altijd weet of een website veilig is of niet, maar naar dat slotje kijken is gewoon zinloos nu. Als het slotje er niet was krijg je ook al een tijd een niet te missen waarschuwing waar je expliciet in meerdere stappen moet aangeven toch door te willen gaan.

[tom.cx]

Google zorgt er inderdaad voor dat het zinloos is om daar naar te kijken. Google is ook begonnen met het weglaten van https:// omdat ze het zinloos vinden. Google lijkt nu dus te bepalen wat 'handig is. Het feit dat je aangeeft dat het alleen om oude users gaat is echt helemaal fout. Ik maak dagelijks op mijn werk mee hoe digibeet jonge collega's zijn. Het is dus zeker van alle generaties. Plus wat is er nu erg aan om twee icoontjes te laten zien? Een voor de veilige verbinding en een voor opties. Dit werkt in Firefox al jaren zo.

Het probleem is nu vooral dat Google aan het bepalen is wat goed zou zijn voor haar gebruikers met Chrome en dit is de marktleider. Ik vraag me daarom sowieso af of Google niet aangepakt moet worden zoals Microsoft toen is aangepakt met Internet Explorer. Ze krijgen in mijn ogen een te grote macht over het gebruik van internet. Ik ken zelfs genoeg personen die denken dat ze moeten internetten via Chrome.

[Kevinp]

Verkeerde samenvatting.

Als je aanpassingen gaat maken zorg er dan voor dat de normale gebruikers (want de meeste weten echt niet wat ze aan het doen zijn). Ook nog er mee overweg kunnen.

Bijvoorbeeld door beide te tonen. Daarna één kleiner te maken en daarna weg te halen.

Een harde overgang is gewoon niet slim. En ja de wereld gaat snel, maar Chrome heeft dit zoals al aangegeven is zelf grotendeels gedaan. Door erg veel weg te halen want dat was toch niet interessant.

[Blokker_1999]

Ik ben helemaal niet met dat trucje afgekomen. Kijk eens rond op het internet, zowel op websites die informatie vergaren voor digibeten, maar ook vaak op websites van vele gerenomeerde instellingen. Allemaal geven ze aan dat je naar dat slotje moet kijken om na te gaan of het veilig is.

Dat dat slotje een vals gevoel van veiligheid geeft doet er op dat moment zelfs niet meer toe. Als digibeten vanuit alle kanten horen dat ze naar dat slotje moeten kijken, dan doen ze dat ook.

En als je mensen jarenlang iets laat doen, leer ze het dan maar weer eens af. Je ziet hier toch ook voldoende op Tweakers hoeveel weerwerk mensen bieden als er ook maar iets veranderd, hoe slecht dat dat is.

En wees nu eens eerlijk, wat is de meerwaarde van dat slotje te vervangen door een ander, nietszeggend icoon?

[cobaco]

"Dingen hetzelfde houden alleen om oude users die het niet snappen gerust te stellen terwijl iets helemaal geen nut meer heeft is wat mij betreft compleet zinloos

"

Je eerste zin geeft het nut, niet onderschatten hoeveel verschil dat in praktijk maakt

[gooos]

Precies, het tonen van de naam van een gevalideerde organisatie had echt toegevoegde waarde. Eeuwig zonde dat ze dat eruit hebben gehaald in "hun wijsheid".
Moet wel zeggen dat het me in die tijd wel verbaasde dat onze overheid nergens die hogere certificaten gebruikte, ook niet bij de Belastingdienst. De banken hadden het over het algemeen wel netjes voor elkaar.

[Korben]

Dat had helemaal geen toegevoegde waarde. Het maakte dingen juist gevaarlijk, omdat het impliceerde dat dingen veilig waren, terwijl dat niet zo was. Wie zegt dat ‘Rabo Services B.V.’ wel iets te maken heeft met de Rabobank? Terwijl ze wellicht prima de domeinnaam rabobnak.nl zouden kunnen bezitten. Een ander voorbeeld is dat de naam van een legitiem bedrijf geen enkele relatie hoeft te hebben met de domeinnaam. Een voorbeeld dat inmiddels niet meer van toepassing is, is mp3shop.nl. De bedrijfsnaam zou Coolblue B.V. zijn, wat een aantal jaar geleden niemand wat zei.

[gooos]

Daar heb je wel een punt. Maar als bijv Rabobank gewoon Rabobank erin zou hebben staan en dat naar de klanten communiceert, dan zou het wel toegevoegde waarde hebben.

[lenwar]

En vroeger gaven Browsers de naam in het EV certificaat ook gewoon netjes weer naast het slotje. Totdat Google besloot dat het volgens hen geen toegevoegde waarde had.

(Apple deed het als eerste met Safari, maar van de veelgebruikte browsers waren het inderdaad Chrome en Firefox)

Had dat niet voornamelijk te maken met dat bedrijven uit andere landen/staten hetzelfde konden aanvragen of zo? En dat er weliswaar een landcode/staatcode staat, maar dat dat toch voor verwarring kan zorgen?

Het kon natuurlijk op andere manier ook voor verwarring zorgen. Je gaat naar steampowered.com en je zie Valve als bedrijf.
Je gaat naar philips-hue.com en je ziet Signify als bedrijf.
Of je ziet in eens buitenlandse bedrijfssoorten Google LLC, der spiegel GmbH, enz. Dit kan allemaal voor verwarring zorgen.

[Reactie gewijzigd door lenwar op 23 juli 2024 08:17]

[deadinspace]

Met een EV certificaat, het type certificaat dat vele instellingen vroeger gebruikten en vandaag ook nog altijd, is het wel degelijk mogelijk om na te gaan of de server malafide is, danwel toebehoord aan de firma van wie je de site bezoekt.

Een EV certificaat zegt niks over of de server malafide is, het geeft alleen meer informatie over aan wie het certificaat toebehoort. Misschien bedoel je dat ook, maar het is wel een belangrijk onderscheid. jebank.nl kan nog zo'n mooi EV certificaat hebben, maar als hun server gehackt is dan zie je dat niet aan het certificaat.

... Wat was hier aan de hand? Heel eenvoudig. De beste gebruiker kon zijn Internet Explorer niet meer terugvinden omdat Microsoft na al die jaren besloten had om eindelijk IE6 te upgraden naar IE7.

En ik snap dat dat lastig is voor zulke gebruikers. Maar wat is het alternatief? Niks meer verbeteren?

Hadden we omwille van deze beste man maar moeten zeggen "Ok jongens, het is klaar. De wereld blijft bij IE6, voortaan geen ontwikkelingen meer aan browsers"? Natuurlijk niet. We blijven ontwikkelen en verbeteren, en ja, dat is soms wennen voor gebruikers.

Zo ook in dit geval. Geen slotje meer, maar een melding als de verbinding niet beveiligd is. Weer iets minder om op te letten, dus uiteindelijk alleen maar makkelijker. Maar even wennen ja.

[dasiro]

google kan op geen enkele manier garanderen dat een website al dan niet malafide is, daarom moeten ze dit niet weghalen. Het gaat om een visuele indicatie van een technische specificatie en dat idee wordt hiermee onderuit gehaald.

[Eagle Creek]

Daarom moeten ze het niet weghalen.

Ik vind dat nogal dik aangezet. Het argument is niet dat ze de veilige verbinding niet willen tonen maar dat het anno 2023 de defacto standaard is. En als het ervan afwijkt, je een waarschuwing krijgt.

Vergelijk het in een auto waarin constant allerlei groene lampjes branden voor alle systemen die wél werken. Stuurbekrachtiging, ABS, handrem uitgeschakeld, géén versleten remblokken,een vólle tank sproeier vloeistof, een juiste watertemperatuur, geen motorstoring.

Je mag ervan uitgaan dat al die dingen gewoon werken, 99% van de tijd. Pas als er een afwijking optreedt, dan wil je een waarschuwing.

En dat is precies de modus waar Google nu voor gekozen heeft.

Voorheen was https iets bijzonders. Kom je nog uit de tijd van IE4/5? Dan kreeg je bij elke https- site een popup dat de verbinding beveiligd werd, die je dan weg moest klikken. Kun je je dat nog voorstellen? De popup is verdwenen en werd het slotje. En het slotje gaat nu ook door naar de volgende iteratie.

[Reactie gewijzigd door Eagle Creek op 23 juli 2024 08:17]

[flexity]

Bij mij zou de reden zijn als ik personeel wil uitleggen hun cookies te wissen door op het slotje te klikken in de browser. Nu moet ik een ander "friebeltje" uitleggen en het personeel is al niet digitaal vaardig. Slotje is wat herkenbaarder om te zien dan wat er nu gaat komen.

[Verwijderd]

Hee bedankt, dat op slotje klikken om cookies te wissen kende ik nog niet

[Reactie gewijzigd door Verwijderd op 23 juli 2024 08:17]

[Jenk-Han]

En dát geeft precies aan hoe onlogisch het is om daar een icoon van een slotje te laten staan

[uiltje]

Inderdaad, maar ik hoop niet dat ze er een koekjesblik van maken, want dan snappen mensen het echt niet meer

[gimbal]

Het is helaas nog geen wijsheid om niet zomaar dingen te veranderen die iedereen kent. Het klinkt zo nietig, we veranderen even het icoontje. Ja. Een icoontje wat in duizenden handleidingen staat.

[GertMenkel]

De technische indicatie is "deze verbinding is privé". Om iemand van Twitter te quoten: je kunt een privégesprek hebben met de duivel. Dat je buren je niet kunnen afluisteren betekent niet dat je verbinding te vertrouwen is.

Dat een website een EV gebruikt betekent overigens ook niet dat een verbinding te vertrouwen is, daarom zijn die groene vinkjes dsn ook weggehaald.

Qua technische specificatie klopt het slotje wel. Aan de andere kant is de situatie al een tijdje andersom: HTTPS is de norm, andere protocollen krijgen expliciet "niet veilig" in de adresbalk. Dan voegt een slotje ook maar weinig toe natuurlijk.

[CH4OS]

Bij een man-in-the-middle attack zie je óók dat de verbinding "veilig" is en tóch heb je luistervinken. Ook al praat je met de duivel, dus nee, omdat er een slotje staat maakt het zelfs niet dat de verbinding écht privé is. Het zegt alleen dat er versleuteling is (die bij unsigned certificaten óók werkt) en dat er een derde partij achter het uitgegeven certificaat staat. Meer is het niet. Met diensten zoals Let's Encrypt hebben TLS en HTTPS echt enorm aan populariteit gewonnen en dat is goed, maar is enkel een stap. Helemaal 100% veilig wordt het nooit.

[GertMenkel]

Bij een man in the middle waarbij de server of het domein gehackt is, kunnen je buren, je ISP en het sleepnet van de AIVD nog steeds niet zien wat jij allemaal naar de phisher stuurt. Je blijft een privégesprek houden, in dat geval dus met de duivel.

Een MitM uitvoeren is nagenoeg onmogelijk gelukkig zonder dat wel of geen HTTPS toch niet meer uitmaakt.

Unsigned certificaten met Chrome laten werken is wel heel moeilijk. Ja, je kan doorklikken op het superenge waarschuwingsscherm, tenzij HSTS is ingesteld (dan moet je "thisisunsafe" intypen in dat scherm dat geen tekstinvoer heeft) maar in de praktijk is dat niet iets wat je zomaar doet. Ja okee, malware kan een malafide CA installeren, maar malware kan ook Chrome vervangen door een versie die een kopie van alles doorstuurt naar hun server, als je cerficaatopslag kan worden geïnfecteerd ben je sowieso de pineut.

100% veilig wordt het nooit, daarom is aannemen dat een geldige HTTPS-sessie goed is en waarschuwen bij afwijkingen juist genoeg.

[CH4OS]

Dat privé gesprek gaat echter tot aan the man in the middle, wat er daarna gebeurd weet je niet.

[GertMenkel]

Dat klopt. Maar HTTPS functioneert dus gewoon zoals ontworpen. Veel websites die je over een veilige verbinding bezoekt, verkopen de informatie die je de geeft ook aan data brokers en adverteerders.

Je dokter of doktersassistent kan ook een kopie van je hele gesprek naar de pers doorsturen. Of je gesprek op dat moment privé is of niet, zegt niets over wat er verder met die informatie gebeurt.

[Reactie gewijzigd door GertMenkel op 23 juli 2024 08:17]

[gooos]

"Unsigned certificaten met Chrome laten werken is wel heel moeilijk."

Klopt. Zou echter wel graag een makkelijkere manier zien om localhost / 127.0.0.1 / 192.168.* / 10.* met https, zonder irritante meldingen tussendoor, te kunnen gebruiken. Gewoon voor tijdens testen binnen de lokale omgeving.

[GertMenkel]

Local Localhost is al een secure origin dus voor dev werk hoef je daar weinig aan te doen.

Voor het lokale netwerk zul je een eigen CA moeten opzetten (is goed te doen maar handmatig certificaten vernieuwen is vervelend) of bijvoorbeeld een wildcard van Let's Encrypt gebruiken met een los apparaat dat de boel proxiet. Ik gebruik thuis een combinatie van eigen CA en LE wildcards en dat werkt wel redelijk eigenlijk, alleen op niet-browsers op Android en programma's die hun eigen cert store bijhouden om domme redenen (kuch Electron kuch) heb ik last.

Met IPv6 zou elk apparaat in theorie gewoon met Let's Encrypt kunnen werken, maar dan moet je wel regelmatig tijdelijk (via UPnP bijvoorbeeld) poort 80 bereikbaar moeten maken. Helaas zijn er maar weinig services en apparaten die van die mogelijkheid gebruik maken.

[svane]

Geen idee of je er wat aan hebt, maar zelf gebruik ik puma-dev

Plaats een bestandje in ~/.puma-dev/ met een poortnummer, en je hebt meteen een localhost website met https. Bijv:

`echo 3000 > ~/.puma-dev/foo`
en nu zie je op https://foo.test de data van http://localhost:3000

voor windows zou je misschien dit kunnen proberen, maar heb ik geen ervaring mee.

[gooos]

Ik ga er vanavond eens naar kijken. Thanks.

[lenwar]

Totdat je transparant door een lokale proxy gerouteerd wordt waar je alle controle een duidelijke zichtbaarheid kwijt bent.

Allicht een optie die voor één sessie mogelijk is op een ingewikkelde manier, maar het kan wel een groot gat zijn.

Er is in principe geen reden om in je eigen LAN geen https met geldige certificaten te gebruiken. Je kan op relatief makkelijke manieren gratis Lets Encrypt certificaten zetten. (Toegegeven. Op iets als een printer kan het gedoe zijn, maar daar zijn (althans in mijn ervaring) niet interfaces die je 10x per week gebruikt als er eenmaal is, dus dan is het even doorklikken van de fout best oké te doen.

[Reactie gewijzigd door lenwar op 23 juli 2024 08:17]

[deadinspace]

Bij een man-in-the-middle attack zie je óók dat de verbinding "veilig" is en tóch heb je luistervinken.

Nee, dat heb je niet. Dat is nou precies wat TLS + certificaat voorkomt.

Bij TLS + certificaat wordt aan de serverkant een bericht versleuteld en ondertekend met behulp van de private key. Deze private key is onlosmakelijk verbonden met de public key in het certificaat. De ontvanger (jij) controleert die digitale handtekening aan de hand van het certificaat. Het certificaat zelf is weer ondertekend door iemand anders (de CA) en alleen geldig voor het juiste domein.

• Een mitm-aanvaller kan het verkeer niet lezen want het is versleuteld.
• Een mitm-aanvaller kan het verkeer niet aanpassen want dan faalt de controle van ondertekening.
• Een mitm-aanvaller kan het certificaat niet aanpassen want dan faalt de ondertekening daarvan.
• Een mitm-aanvaller kan het verkeer niet opnieuw versleutelen met zijn eigen certificaat want dan komt het domein op het certificaat niet overeen.

Er zijn wel dingen mogelijk, maar alleen als protocollen geschonden worden, bv:

• De aanvaller weet een vals certificaat te bemachtigen (zoals bv bij DigiNotar het geval was).
• De aanvaller overtuigt jou de foutmelding over een fout certificaat weg te klikken.
• De aanvaller overtuigt jou zijn certificaat te installeren op je computer.

Maar onder normale omstandigheden kan dit dus niet.

[lenwar]

Tldr:De publieke sleutel versleuteld, de private sleutel ontsleutelt en ondertekend. (Iedereen moet een beruchte kunnen sturen en initiëren naar de server toe)

In het lang:
De browser genereert on the fly een private sleutel en publieke sleutel. Daarna wordt er een key-Exchange gedaan, op basis van bijvoorbeeld modulaire rekenkunde .
Vervolgens genereren beide kanten dezelfde sleutel die uniek is voor de sessie die beide kanten kunnen ontsleutelen.

Het hele traject wordt goed uitgelegd in deze YouTube playlist:
https://yewtu.be/playlist?list=PLB4D701646DAF0817

De technieken zijn uiteraard gemoderniseerd sinds het maken van deze serie, maar het concept is nog hetzelfde.

[CH4OS]

Als ik via-via een TLS-certificaat voor domein X kan verkrijgen en op de PC van mijn slachtoffer het netwerk of de client zover kan krijgen, dat het naar mijn server gaat in plaats van de juiste, zal de computer van het slechtoffer toch echt denken dat het certificaat valide is. DigiNotar vergeten? Gelukkig is het sindsdien niet meer voorgekomen, maar betekend niet dat het niet meer gebeuren kan of zal.

[deadinspace]

Dat zeg ik ook letterlijk in mijn comment. Ik benoem DigiNotar zelfs expliciet.

Waar het mij om ging is dat jouw bericht de indruk wekte dat TLS-verkeer normaalgesproken af te luisteren is door alleen een MITM-aanval. Mijn punt is dat er naast een MITM-aanval nog meer nodig is.

[lenwar]

Ik snap je sentiment, maar ik heb niet het idee dat er in de praktijk (veel) naar gekeken werd. Er staat nu heel groot dat de website niet versleuteld is als het niet https is.

Ik blijf zelf wel een voorstander van speciaal gemarkeerde sites voor financiële instellingen, payment providers, overheden, winkels, enz.

(Edit, winkels lijkt een beetje een vreemde suggestie bij nader inzicht)

[Reactie gewijzigd door lenwar op 23 juli 2024 08:17]

[The Zep Man]

Ik blijf zelf wel een voorstander van speciaal gemarkeerde sites voor financiële instellingen, payment providers, overheden, winkels, enz.

En met extended validation (EV) wordt juist niet veel meer gedaan vanuit browsers. Verder zitten winkels ook niet te wachten op de additionele eisen daaraan. TLS is ondertussen een vinkje geworden, waarbij certificaten automatisch verlengd worden (en zelfs gratis, als men dat wil). Dat draagt bij aan de brede adoptie ervan.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:17]

[lenwar]

Ik weet ook niet precies over hoe en wat hoor. Ik heb het ook niet specifiek over extended validation, al zal dat er wel bijkomen natuurlijk .

Ik bedoel meer dat bijvoorbeeld financiële instellingen (banken, verzekeraars, paypal-achtige bedrijven) een bepaalde markering krijgen, maar ook payment providers (Mollie, enz) weer een andere, zodat iemand makkelijker kan zien dat ie wel of niet bij een 'geregistreerde payment provider' z'n creditcardgegevens aan het invullen is. Overheden weer een eigen, enz, enz, enz. Allicht is er geen goede reden voor 'winkels' te bedenken hoor, ik gaf ook maar een paar losse voorbeelden.

[The Zep Man]

Ik bedoel meer dat bijvoorbeeld financiële instellingen (banken, verzekeraars, paypal-achtige bedrijven) een bepaalde markering krijgen, maar ook payment providers (Mollie, enz) weer een andere, zodat iemand makkelijker kan zien dat ie wel of niet bij een 'geregistreerde payment provider' z'n creditcardgegevens aan het invullen is. Overheden weer een eigen, enz, enz, enz. Allicht is er geen goede reden voor 'winkels' te bedenken hoor, ik gaf ook maar een paar losse voorbeelden.

Een specifieke markering komt er juist niet, want dan moet je een onderscheid gaan maken. Dat kost meer moeite aan de kant van de aanvragers, certificaatautoriteiten, en browserbakkers. Ook kost het meer moeite aan de kant van de gebruiker omdat verwacht wordt dat die het verifieert. Dit terwijl beveiligingsonderzoekers het ondertussen er wel over eens zijn dat de tijd en aandacht van gebruikers te kostbaar en beperkt is om hieraan te besteden. Ik noem EV juist als een voorbeeld van hoe dit niet werkte, en daarom is men daar grotendeels vanaf gestapt.

Gezien hoe traag de ontwikkelingen gaan op TLS-gebied, gaat het niet gebeuren.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:17]

[lenwar]

Dat snap ik, maar mij lijkt het handig als er specifieke markeringen komen voor bepaalde type bedrijven/organisaties. Ik snap uiteraard dat dat gedoe gaat opleveren voor degenen die er bij betrokken zijn (browsermakers, CAs, enz, maar ik denk wel dat dit potentieel iets toevoegt.

Een browser/password manager kan detecteren dat je creditcarddata invult (zit een bepaalde checksum op). Als je dan bij een niet-paymentprovider bent, dat je dan een waarschuwing krijgt (ik verzin maar wat).

Misschien voegt het in de praktijk allemaal niks toe hoor, of dat de registratie ervan dusdanig complex is, dat het nooit betrouwbaar wordt (dus dat je dan zoveel valse fouten krijgt dat iedereen ze gaat negeren), maar mij lijkt het op zich wel een interessante. Specifiek voor bepaalde type bedrijven.

[The Zep Man]

Dat snap ik, maar mij lijkt het handig als er specifieke markeringen komen voor bepaalde type bedrijven/organisaties.

Handig voor wie? Niemand zit erop te wachten, behalve een kleine groep mensen die iets meer affiniteit met beveiliging heeft, die denkt dat het iets qua beveiliging toedoet (wat het niet doet, want het is afhankelijk van de gebruiker).

Een browser/password manager kan detecteren dat je creditcarddata invult (zit een bepaalde checksum op). Als je dan bij een niet-paymentprovider bent, dat je dan een waarschuwing krijgt (ik verzin maar wat).

Dan hoeft het toch niet in webstandaarden te zitten? Maak een browser add-on.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:17]

[lenwar]

Ik denk dat het kan bijdragen voor phishing-zaken. Of men er op zit te wachten weet ik niet. Ik wil in elk geval. Dus in elk geval niet niemand.

Mogelijk zit ik er naast hoor, maar gevoelsmatig kan transparantie bijdragen aan veiligheid.

Het kan inderdaad ook met een plug-in waar bekende payment providers in geregistreerd zijn. Maar wie beheert die lijst. Dat moet een officiële controleerbare instantie zijn.

[gooos]

Voor financiële instellingen, payment providers en overheden zou ik het zeker kunnen waarderen. Denk dat je dan winkels niet zou moeten doen zodat ze bij de echt relevante sites er beter uitspringen.

[lenwar]

Dat denk ik nu ook. Ik noemde maar wat dingetjes. Winkels is allicht geen goed idee
Er zijn vast nog een wel een paar categorieën te bedenken die ook een toegevoegde waarde leveren, naast die drie.

[SMGGM]

Tijden veranderen, het slotje geeft een vals gevoel van veiligheid. Ik snap Google wel dat ze het doen. Vroeger waren die certificaten duur en stond het bijna garant voor een veilige site. Tegenwoordig is het gratis en hebben misleidende websites zo’n slotje. Wat is het dan nog waard om het überhaupt nog uit te leggen.
Probeer je iets in te vullen op een niet https website krijg je tegenwoordig waarschuwingen dat de data niet versleuteld zal worden verzonden.

[AlRoke]

Certificaten waren inderdaad duur, maar phishing sites betaalde gewoon de prijs... dus "bijna garant voor een veilige site" was nooit waar. Je had (en hebt) een extra dure variant die de naam van je bedrijf checkt... en heb persoonlijk nooit die versie gezien op een phishing sites, maar normale certificaten waren altijd een slechte indicatie van 'site veiligheid'. Vroeger en nu was het altijd een teken van 'beveiligde communicatie' en niets meer en niks minder.

[TijsZonderH]

Jarenlang leer je mensen aan dat ze naar dat slotje moeten kijken

Van de andere kant is dat advies al lang niet meer echt zo relevant als vroeger. Nu de norm is dat vrijwel iedere belangrijke site gewoon goede https heeft is kijkt niemand meer naar dat slotje en hoeft dat ook niet echt (mits je dan natuurlijk wel andere waarschuwingen geeft bij http)

[Vexxon]

Nee dat hebben ze niet. Als ik naar de laatste jaren van Google kijk zijn ze maar weinig succesvol. Als de advertenties niet zo belachelijk veel geld had opgebracht waren ze allang failliet gegaan.
Ze poepen het ene product of service na de andere uit, maar vaak hebben die overlap met een andere service die ze dan vervolgens weer de nek omdraaien of gaan samenvoegen met een andere service.
En als ze dan een keer goud in handen hebben, zie Stadia, gaat het niet snel genoeg voor ze en begraven ze het weer. Ondertussen is hun reputatie op het gebied van betrouwbaarheid tanende.

[GertMenkel]

Het slotje was altijd al een slechte aanpak. Het slotje zei vanaf dag één helemaal niks behalve "er is versleuteling".

In de vroege tijden van HTTPS was er lange tijd een bug in Firefox waarmee je met je eigen websitecertificaat voor tweakers.net andere certificaten (rabobank.nl) kon ondertekenen, inclusief slotje. Dat is zo ongeveer waar we begonnen zijn.

"Kijk naar het slotje" is gebruikt om mensen te ontzien van "check het domein", omdat je dan mensen moet gaan uitleggen wat het verschil uw tussen tweakers.net en tweakers.info en dat was opgegeven voor iemand er een serieuze poging toe deed. Óf internetters zijn te dom om domeinen te snappen óf de mensen die met dat slotjesverhaal komen denken alleen dat internetters daar te dom voor zijn. Hoe dan ook, met "check het slotje" red je niemand.

We zijn al jaren van "groene adresbalk" naar "waarschuwing bij problemen" aan het afbouwen, om goede redenen. Als je er vragen over krijgt, kun je mensen vertellen op dezelfde plek te klikken als waar het slotje stond. "Het handtasje heeft een nieuw plaatje gekregen" lijkt me toch niet zo'n probleem?

[Cuverclub]

"sommigen" letten nergens op.
Mocht je een smartphone gebruiker zijn dan wordt Chrome ook wel eens aanbevolen om de browser te openen, alle voorwaarden vaak ongelezen akkoord geklikt. Zo ook synchronisatie etc.
Ik ken genoeg mensen die ik al heel vaak heb verteld dat ze moeten letten op de url en liever geen links klikken in de mails ik zal denk ik geen hoofdpijn krijgen van de vragen juist hierom. ;-)
Zelf hou ik me bij add-ons / extincties in Firefox, Vivaldi, Opera en zelfs in Edge maar voor de echte digibeet is dat zelfs onvoldoende.
Zoeken naar een website waar je de url ook van weet bijvoorbeeld www.toeslagen doorgelinkt naar BD terwijl zoeken ook naar een site kan leiden die "helpt" tegen betaling bij het aanvragen.
En er zijn nog veel meer https voorbeelden die niet als kwaadaardig worden gezien.

[dunpealhunter]

yup, ik voorzie dat ook ja "ik mis mijn slotje op mijn computer! Ben ik nu gehackt?!" Je wilt niet weten hoeveel mensen ik op de klantenservice gesproken heb (ik werk voor klantenservice van een grote internet provider) die als ik vraag of ze de computer aan kunnen zetten meteen beginnen met "oh, ik weet niet of ik dat kan, ik ben niet technisch...."

[Yzord]

Niemand die valt over de location en microfoon toggles? Ik word er persoonlijk niet goed van dat websites mijn lokatie willen weten en of zelfs willen horen wat ik te zeggen heb.

En om nog maar niet te spreken van deze aktie. Waarom moet Google zo nodig weer de boel omgooien? Wat was er specifiek mis met een slotje? De reden dat https ook niet veilig zouden kunnen zijn doet niet af aan het feit dat de verbinding wel of niet veilig is. Het gaat om de man of the middle attack en niet zozeer of de webmaster van de website wel te vertrouwen is. Dus het heeft totaal geen enkel nut om het slotje nu te gaan veranderen in een kleuterig icoontje.

[bwerg]

Het gaat om de man of the middle attack en niet zozeer of de webmaster van de website wel te vertrouwen is.

Laat de doelgroep van dat slotje nou net geen flauw idee hebben van wat je hier gezegd hebt...

Groen slotje = goed. Dat is wat mensen eruit halen. En groen slotje is niet altijd goed. Groen slotje is soms ook een oplichtersbende die drie euro heeft uitgegeven bij letsencrypt.

Degenen die het verschil snappen tussen een beveiligde verbinding en een geverifieerde beheerder hebben vijf minuten nodig om te wennen aan de nieuwe situatie. Want ook in de nieuwe situatie zie je precies hetzelfde onderscheid, alleen anders weergegeven.

[Reactie gewijzigd door bwerg op 23 juli 2024 08:17]

[Yzord]

3 euro uitgeven bij LE? Is dat tegenwoordig betaald?

[bwerg]

Oh, zelfs dat niet schijnbaar. Geen idee.

[dasiro]

Niemand die valt over de location en microfoon toggles? Ik word er persoonlijk niet goed van dat websites mijn lokatie willen weten en of zelfs willen horen wat ik te zeggen heb.

daarom dat de vraag telkens gesteld wordt als je op een site terecht komt die dit soort info wil krijgen. Voor het zoeken van een winkel in de buurt of een chatbox zijn dit features die handig zijn, maar voor andere sites kan je kiezen om die toestemming niet te geven.

[Sinester]

Niemand die valt over de location en microfoon toggles? Ik word er persoonlijk niet goed van dat websites mijn lokatie willen weten en of zelfs willen horen wat ik te zeggen heb.

Waarom zou ik daar over vallen? als ik op sites zitten die mijn microfoon gebruiken (Skype bijvoorbeeld) of een site die mijn locatie kan gebruiken (Thuisbezorg) dat is het vrij logisch dat ze dit nodig hebben toch?

Je staat vrij om ze die toegang niet te verlenen, met deze toggles kan je dit juist mooi doen en zien.. dus ik snap dit probleem niet zo

[GertMenkel]

Locatie en microfoon worden constant gebruikt. Google Maps gebruikt je locatie, Google Meet/Jitsi/Teams gebruikt je microfoon en ook nog eens je webcam. De tool om de Stadia-controller naar Bluetoothmodus om te zetten gebruikt zelfs WebUSB. Dit zit al jaren in je browser, die toggles zijn al lang onderdeel van je browser. Als je die functies niet wil gebruiken, klik dan op "blokkeren" zodra hierom gevraagd wordt, of ga naar de instellingen van je browser en zet de default op "weigeren" zodat je niet eens gevraagd wordt om je locatie.

Waarom Google de boel omgooit kun je lezen in de reeks blogposts die ze geschreven hebben. HTTPS is de norm, HTTP krijgt expliciet "onveilig" in de adresbalk, dan is het slotje (of zoals gebruikers het noemen, "handtasje") niet meer zo heel nuttig.

Weinig mensen checken de uitgever van een certificaat maar dat menu doet veel meer dan alleen laten zien dat Super Secure Ltd EV je website heeft ondertekend; het bepaald ook of je meldingen krijgt en of je webcam wordt doorgegeven. Dat lijkt me veel belangrijker, dus waarom ook niet?

[Reactie gewijzigd door GertMenkel op 23 juli 2024 08:17]

[SinergyX]

Ik weet niet hoe dit in Chrome als 'default' staat, maar Edge heeft dezelfde menu opties (en een berg meer), waar bijna alles op 'Ask (default)' staat, uit met vraag.

[Dyon_R]

Zal wel fijn zijn als er wel een rood open slotje zou komen wanneer er toch geen gebruik verbinding wordt gemaakt naar een https-website, of dat er net als bij malafide websites een rood waarschuwingsscherm komt.
Misschien is iets van dit al het geval, maar ben niet in de situatie om dit te testen.

Edit: zoals hieronder werd gezegd heb ik er gewoon vol overheen gekeken. HTTP blijft gewoon gemarkeerd worden als onveilig

[Reactie gewijzigd door Dyon_R op 23 juli 2024 08:17]

[mschol]

het zou fijn zijn als die hele slotjesbende (en bij behorende zaken) gewoon industrie gestandaardiseerd zou zijn en vast zou liggen en niet dat 1 project/bedrijf het als een soort hobbyprojectje ziet en zowat bij elke iterate wel een wijziging aanbrengt

[Reactie gewijzigd door mschol op 23 juli 2024 08:17]

[crazyboy01]

Zit ook wel een keerzijde aan hoor. Niet dat ik er tegen ben, ik ben voor, maar de stempel onveilig geeft soms ook een foute indruk. Het wordt nu al duidelijk aangegeven, maar wanneer geen data verzonden wordt (bijvoorbeeld op een website die enkel plain informatie verstrekt of wanneer verzonden info niet gevoelig is), is https soms overbodig gedoe. Bij kleine projecten die niet op zo'n standaard webhostingpakket staan, maar ook bij bijvoorbeeld servers zonder domeinnaam en lokale webservers. Zijn allemaal mogelijkheden voor, maar die zijn gewoon omslachtig en dat moet dan allemaal puur om dat open slotje niet te hoeven uitleggen nadat het wantrouwen al is opgewekt. Bij kleine projecten die je opzet voor een kleine club mensen heb je dat dus eigenlijk niet altijd nodig, maar roept het meteen vragen op als je dat niet voor elkaar hebt.

Maarja, better safe than sorry natuurlijk. Sowieso zijn dit ook vrij specifieke situaties, op een echte website die bedoelt is voor het web en een breed publiek wil je natuurlijk altijd een slotje en heb je die ook zo bemachtigd - veel mensen gebruiken ook gewoon zo'n hostingpakket en dat zit daar dan al standaard bij.

[JKP]

In het artikel staat letterlijk:

Chrome blijft http-sites markeren als onveilig, zegt Google.

Mijn inschatting is dat deze verandering dan ook weinig tot geen problemen zal geven.

Bij een onveilige verbinding zal het blijven zoals het nu is: https://i.pcmag.com/image...1152x559.v_1569470588.png

[Dyon_R]

Nah, heb ik daar nou echt overheen gekeken. Ik geef het maar de schuld dat het ochtend is

[elmuerte]

Wat krijg je dan te zien bij een http verbinding?

[JKP]

Bij een http verbinding staat er links naast de adresbalk heel duidelijk in beeld: 'Onveilige verbinding'. Voorbeeld van hoe dat eruitziet: https://i.pcmag.com/image...1152x559.v_1569470588.png

[Reactie gewijzigd door JKP op 23 juli 2024 08:17]

[Not Pingu]

Anno 2023 krijg ik nog steeds wel eens een bezorgde collega aan m'n bureau met de vraag waarom het slotje op ons platform niet groen is. Het besef van de doorsnee internetter verandert een stuk langzamer dan Google misschien zou willen. Google zou beter meer informatie kunnen verstrekken over de al-dan-niet veiligheid van een website ipv meer vragen op te roepen.

Voor websites die echt malware bevatten of malafide zijn, is nu al een blocklist die in Chrome een knalrode waarschuwingspagina oplevert.

[matdriks41]

https wilt niet zeggen dat het secure is...

[crazyboy01]

Dat wil het in brede zin wel, de S staat letterlijk voor secure. Maar dat gaat puur over de verbinding.

Het misverstand zit hem, zoals ook in het artikel staat, dat mensen automatisch denken dat de website daarmee ook direct legitiem is. Zelfs als iemand op dit-is-echt-de-ing-bank-hoor.nl zit met een slotje, ipv ing.nl. Daarmee is https nog steeds secure, maar de content op de website hoeft dat niet te zijn. Dat blijft ook altijd een verhaal van gezond verstand.

[_sepulnation_]

Is het niet eenvoudiger en veiliger als Google haar zoekresultaten beperkt tot https-websites met een opt-in voor http-websites?

[TweakerCarlo]

Mocht je je afvragen welke flag:

chrome://flags/#chrome-refresh-2023

[pennywiser]

Volgens mij is het best een goede browser, alleen wordt ie zo opgedrongen. Als je hem opent krijg je zo'n enorme portal met popups, etc. Volgens mij als ze dat beter stroomlijnen wordt de adoptie ook beter. Je opent hem, van ellende klik je hem weer dicht zeg maar. Maar als je doorbijt en het goed instelt is het een prima browser. Maar dat doen niet veel gewone gebruikers.