Chrome verwijdert aanduiding 'veilig' in adresbalk bij https-sites

Websites die gebruikmaken van een https-verbinding zullen vanaf september in Chrome-versie 69 niet meer worden aangeduid met de term 'veilig'. In de adresbalk verdwijnt dan het groene woord 'veilig' of 'secure'.

Google meldt dat de aanduiding 'veilig' wordt weggehaald, omdat gebruikers van websites die een https-verbinding ondersteunen, mogen verwachten dat deze standaard veilig is. Als er een beveiligingsprobleem zou zijn, worden gebruikers gewaarschuwd.

Websites die nog geen gebruikmaken van https, worden vanaf oktober in Chrome 70 in de adresbalk aangeduid met de rode tekst 'not secure'. Dit heeft Google eerder nog niet gedaan, omdat http volgens het bedrijf tot nu toe nog teveel werd gebruikt.

Google is al jaren bezig om websites te bewegen over te stappen op beveiligde https-verbindingen. Al in 2014 maakte het bedrijf het plan bekend om niet-https-verbindingen als 'onveilig' te markeren.

De wijze waarop websites die gebruikmaken van http in Chrome 70 worden aangeduid.

Reacties (125)

[TRON]

Ik zou liever zien dat men afstapt van de term 'secure'. Het suggereert dat de website veilig is, terwijl men bedoelt dat het verkeer van en naar de website versleuteld is. Veilig betekent voor mij iets anders. Als ik nu een malafide website zou opzetten met een SSL-certificaat, dan vindt men dat een 'secure' website.

Een non-SSL-site is dan straks ook niet insecure, maar 'not encrypted'. Men moet de gebruikers leren dat daar een groot verschil in zit. Dat scheelt heel wat reparatiewerk in de hersenen op het moment dat de toekomst wat complexer wordt

[Jerie]

Yup, maar dat probleem zit hem voornamelijk in het feit dat we teveel vertrouwen hebben in CAs (certification authorities).

[Superstoned]

Allemaal waar, maar het probleem is dat gebruikers niet goed omgaan met complexiteit. Het resulteert vaak in het omgekeerde van wat je probeert te bereiken... Vergeet niet dat we aan veel gebruikers nog uit moeten leggen wat 'encryption' is. Dus 'veilig' is geen gekke term, al weten techies dat er veel meer bij komt kijken.

[CJ_Latitude]

Benieuwd hoe de communicatie vanuit banken etc. gaat veranderen hierdoor. Nu hebben ze meestal staan "Let op het groene slotje". Als dat (alleen) in Chrome straks wegvalt, zal de uitleg wel anders (complexer?) moeten worden.

[WhatsappHack]

Banken gebruiken over het algemeen EV-certificaten. Die blijven wel de groene balk met bedrijfsnaam erin tonen lijkt me. En het slotje verdwijnt ook nog niet, enkel de tekst.


-edit- aangepast voor duidelijkheid

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 20:42]

[.oisyn]

En het slotje verdwijnt ook niet, enkel de tekst

Het idee is dat het slotje op termijn gewoon verdwijnt, zoals je in het plaatje kunt zien bij "eventually". Maar goed, tegen die tijd is het ook de standaard, en zie je "not secure" als er gewoon HTTP wordt gebruikt.

[Reactie gewijzigd door .oisyn op 22 juli 2024 20:42]

[GekkePrutser]

Maar op zich heeft de bedrijfsnaam (zoals getoond bij EV certificaten) wel een flinke toegevoegde waarde. Want daar zie je dat het, naast dat het een veilige verbinding is, ook dat het gevalideerd is met wie je daadwerkelijk communiceert.

Ik hoop ook dat ze hier een uitzondering voor maken, want EV certificaten die banken gebruiken zijn toch wel een aparte klasse met een eigen usecase.

[PhoenixT]

Veiligheidsonderzoekers willen juist het liefst van EV certificaten af! De reden is dat EV certificaten zaken als phishing juist makkelijker maken. Zo zijn er voorbeelden van mensen die een bedrijfsnaam registreerden in een andere staat dan waar het echte bedrijf geregisteerd staat. Sommige browsers (zoals Safari in iOS) verbergen bij een EV certificaat de URL en laten dan vrolijk "Facebook, Inc" zien terwijl het om een nepbedrijf gaat.

Ook zijn er voorbeelden van onderzoekers die een EV certificaat kregen voor "bedrijfsnamen" als "Identity Verified" of "Secure Connection". Nogal handig als dat groot met groene tekst in je adresbalk staat bij een phishing website

Je kunt vervolgens wel zeggen dat certificate authorities bij EV certificaten dan maar betere controle moeten toepassen, maar willen we echt dat een groepje bedrijven de poortwachters van het internet worden? HTTPS moet betekenen dat de verbinding niet afgeluisterd/beinvloed kan worden, maar of de site zelf veilig is, is een heel andere zaak, en dat moeten we gebruikers aanleren. HTTPS != veilig/legitiem.

[GekkePrutser]

Maar een certificaat is juist de beste manier om te verifieren of een site wel daadwerkelijk afkomstig is van de juiste bron. De PKI techniek erachter maakt dit mogelijk. TLS voorziet zowel in encryptie (tegen afluisteren) als signing (verifieren van de bron).

We kunnen gebruikers niet blijven aanleren dat een site wellicht niet veilig is, je moet gebruikers niet gebruiken om gaten in je proces of techniek op te vangen. Zij hebben de kennis niet om te kunnen beoordelen of de site veilig is of niet. Er moet een techniek komen om dit te bewijzen. EV certificaten zouden een mooie manier zijn, mits het bijvoorbeeld heel moeilijk is om deze te krijgen. Bijvoorbeeld een wereldwijd geregistreerde tenaamstelling die maar door een entiteit afgegeven mag worden.

Het is sowieso al verbazend dat deze situatie algemeen geaccepteerd wordt. Het zou wat zijn als je een auto koopt en er een briefje bij krijgt: "Deze auto gebruikt Euro 95 brandstof. Sommige officieel als Euro 95 verkochte brandstof is zeer schadelijk voor deze auto, we hebben helaas geen manier waarop u dit kunt beoordelen. Veel succes.".

Dat een groepje bedrijven nu de sleutels heeft is inderdaad een van de problemen van het huidige PKI systeem dat gebruikt wordt voor TLS. Het grootste probleem met TLS is niet de techniek, het is het hele gedonder met het certificaatbeheer. Dat moet sowieso op de schop.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 20:42]

[PhoenixT]

Je moet gebruikers inderdaad niet gebruiken om gaten in je proces of techniek op te vangen. Maar dat doen we nu juist wel door van de gebruiker te verlangen dat hij/zij het certificaat eventjes nakijkt! Is dat EV-certificaat nu van Facebook, Inc uit de VS of van Facebook, Inc uit een ander land of een andere staat van de VS? Tja...

Daarnaast leren we mensen nu aan naar het groene slotje te kijken, maar daarmee toon je totaal niet aan dat een site veilig is, enkel dat de verbinding encrypted is. Het "secure" in de adresbalk is nogal misleidend.

Nog iets anders: veel bedrijven hebben een andere naam dan de domeinnaam van een van hun dochterondernemingen of producten. Dan ga je dus naar een website met EV certificaat en dan staat er een heel andere bedrijfsnaam in de adresbalk dan de domeinnaam zelf. Gaan we dan van de gebruiker verlangen dat die wel weet dat bedrijf X de echte eigenaar is van het domein, en niet bedrijf Y?

Doe anders eens de volgende test: vraag aan iemand uit z'n hoofd op te zeggen wat je in de adresbalk zou moeten zien als je naar rabobank.nl gaat. Die persoon zou volgens conventionele wijsheid dan het volgende moeten zeggen:
- Er moet een groen slotje staan
- De URL moet met https beginnen
- De naam van de eigenaar van rabobank.nl moet in de adresbalk staan, namelijk Cooperatieve Rabobank U.A. [NL], omdat het een EV certificaat is en geen DV certificaat. Rabobank is bovendien een Nederlands bedrijf.

Hoeveel mensen gaan dit goed hebben en zouden dus als ze een DV certificaat aantreffen op rabobank.nl direct weten dat het foute boel is? 0 natuurlijk. Dus wat voegt EV dan toe?

En nog een mooie afsluiter: in Edge van Microsoft is het "groene slotje" helemaal niet groen, maar grijs (Voor alle DV certificaten). Succes

[GekkePrutser]

Dat is waar, maar het zou niet per se een bedrijfsnaam hoeven zijn. De bank kan dan zelf in hun communicatie aangeven dat alleen "Rabobank" de geaccepteerde tag is voor hun sites. Als er 1 instantie is die die tags wereldwijd uitgeeft, ben je er al.

Maargoed het hele TLS PKI verhaal is inderdaad een zooitje, dat is waar. Het moet hoe dan ook herzien worden om dit mogelijk te maken.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 20:42]

[PhoenixT]

Als er letterlijk 1 enkele certificate authority is dan zou dat kunnen, maar ik denk niet dat je zoveel vertrouwen in 1 enkele organisatie wilt leggen. Nu is er direct en indirect juist een flink grote hoeveelheid (intermediate) authorities.

Daarnaast, als zo'n authority echt bij iedere aanvraag een flink onderzoek zou opzetten dan zou een certificaat onbetaalbaar worden. Zeg maar dag tegen Let's Encrypt dan.

[GekkePrutser]

Ja maar we hadden het over EV. Let's Encrypt doet dat ook niet, immers. Een onderzoek is met EV altijd al vereist.

En een enkele organisatie zou ook een NGO kunnen zijn. Denk aan iets als ICANN of de ITU (die de telefoon landcodes toewijzen).

Ik snap dat er wat moet veranderen, maar het idee van een EV certificaat was juist dat er naar meer gekeken werd dan encryptie.

[PhoenixT]

We hadden het inderdaad over EV, maar het is niet zeer nuttig om DV en EV naast elkaar te laten bestaan. Als een site een EV certificaat zou moeten hebben maar plotseling een DV certificaat heeft dan is er iets aan de hand (een gehackte CA heeft bijvoorbeeld een vals certificaat gegenereerd), maar welke gebruiker gaat denken "Goh, zou hier niet een bedrijfsnaam moeten staan"? Die ziet een groen slotje en denkt het is goed.

[fastedje]

Het slotje geeft inderdaad alleen maar aan dat de verbinding naar de server veilig is, niet dat de site zelf veilig is. Het probleem is ook wel dat Google Chrome aanpast aan het niveau van de gemiddelde internetgebruiker en dit niveau is niet al te hoog. Als je b.v. het certificaat en de cipher wil bekijken moet je de developer tools raadplegen.

[Elefant]

Ik denk dat je hier de kern raakt. De waarheid is simpelweg dat het voor de gemiddelde mens veel te moeilijk is en dat je heel veel kennis nodig hebt om alle valkuilen te onderscheiden. Dat gaat een gewone man, zelfs veel specialisten gewoon niet lukken. Het ontbreken van grondige kennis maakt mensen ook weer gemakkelijk slachtoffer van social engineering.

De simpele waarheid is dat onze systemen onveilig zijn voor gebruikers. Dat Google zich steeds opwerpt als een hoeder van onze veiligheid zie ik vooral als een knap staaltje imago-building en marketing. Want Google is zelf het de nummer een in kwalijke social engineering die mensen grootschalig hun privégegevens weet te ontfustselen. Zoals men vroeger wel zei: "Als de vos de passie preekt, boer pas op je kippen".

[.oisyn]

Uiteraard, ik reageerde vooral op WhatsappHacks laatste opmerking, dat het slotje niet verdwijnt. Op termijn verdwijnt die dus ook. Maar idd, voor EV certificaten zul je het bedrijfsnaam waarschijnlijk gewoon blijven zien (als dat ook weggaat dan is de toegevoegde waarde van een EV cert ook verdwenen)

[WhatsappHack]

Klopt, heb het aangepast

[svenslootweg]

Dat is hoe het theoretisch zou moeten werken, maar de praktijk is helaas anders (1, 2).

Ik kan dan ook niet meer anders beargumenteren dan dat EV niet heeft gewerkt, en het geen zin heeft om het nog in stand te houden - sterker nog, het kan juist gevaarlijker zijn om het wel in stand te houden.

[Reactie gewijzigd door svenslootweg op 22 juli 2024 20:42]

[MarcoC]

Is dat zo? Een slotje betekent dat er encryptie plaatsvindt, dat is een feitelijk gegeven. Of iets "veilig" of "niet veilig" is, is subjectief, waardoor ik me kan voorstellen dat Google hier anders mee omgaat.

[Boermansjo]

Wel beetje stom om direct HTTP als "not secure" te zetten... Wat als ik gewoon een landing page maak ? Zonder formulier of forms... Dan gaan de mensen direct de melding "not secure" krijgen en in paniek zo snel mogelijk de site verlaten... Of gaan ze ervoor zorgen dat https gratis word zodat je geen 100 sites moet onderhouden (of iedere hosting zou dit dan gratis standaard moeten ondersteunen)

[bbob]

Waarom zou een EV certificaat wel groene balkje krijgen. Uit de tekst kan ik dat nergens opmaken. Er staat alleen dat mensen bij https kunnen verwachten dat het veilig is.

Wat ik nog wel eens tegenkom is dat sommige sites wel https zijn maar deel van de ingeladen informatie komt dan niet van https, dit wordt nu aangeven zonder groen balkje met een i en rondje. Druk je er op staat er dat niet alles volledig veilig is.

Krijgen die sites dan straks ook rood als het niet volledig veilig is ondanks dat het dus wel met https begint.

[WhatsappHack]

Omdat dat het punt is van EV-certificaten. Als dat verdwijnt kan je heel dat certificaattype wel schrappen. Ik denk niet dat dat wenselijk is.

Geen idee wat ze met mixed-content gaan doen eigenlijk, maar je kan externe insecure content altijd proxyen natuurlijk.

[InjecTioN]

Het nieuwsbericht geeft echter wel aan dat het slotje uiteindelijk wèl verdwijnt.

Ik vind het een goede ontwikkeling. Zonder TLS wel een terechte melding. Met TLS, géén melding meer. Uiteindelijk zorgt zoiets alleen maar voor onnodige informatie waar je als klant toch niets mee hoeft te doen.

Als er nou ook nog eens de ciphers en DNSSEC aangepakt worden, dan zijn we helemaal blij!

[Jace / TBL]

Slotje gaat nog niet weg. Ik neem aan dat het nu eerst wordt:

SSL EV: slotje + bedrijfsnaam
SSL: slotje
geen SSL (dus http ipv https): "not secure"

[bbob]

Dan is er nog de vorm wel https maar niet alles is veilig. wordt dat dan rood ?

[Jace / TBL]

https betekent toch sowieso nooit "alles is veilig" ?

Het betekent alleen dat er geen middle man kan eavesdroppen, mits je zeker bent van je DNS.

En in theorie weet je bij een EV certificaat ook dat als er bedrijf X bij dat slotje staat, dat je dan met bedrijf X te schaften hebt (ik zeg in theorie want die check stelt in de praktijk geen reet voor).

[Marzman]

Nog niet inderdaad, op termijn gaat het dus wel weg.

[Frituurbaas]

Inderdaad, verwarring alom bij de minder digitale klanten. Gelukkig is het wel zo dat >75% v/d bankier-sessies via mobile native apps gaan waar dit probleem niet speelt.

[SMGGM]

Maar het zijn juist de mensen die het meest vallen in valse mails die geen van die apps gebruiken.

[nsacrawler]

Vrijwel zeker dat ze een Extended Validation certificaat aan zullen blijven geven met het welbekende 'groene slotje', en dat dit alleen voor normale https certificaten geldt.

[ace6717]

Bron?

[nsacrawler]

De bron van dit artikel heeft het er continu over dat de 'secure' tekst gaat verdwijnen (en uiteindelijk het bijbehorende slotje), en dat staat er niet bij een EV certificaat, daar staat de bedrijfsnaam in de balk. Er is op dit moment een verschil hoe Chrome EV en normale https certificaten behandeld, en het is ook logisch dat dat blijft.

[lallasjip]

Uitleg kan dan vrij simpel: ‘ziet u een rode waarschuwing met de tekst ‘Not secure’ of ‘Niet veilig’? Stop dan onmiddellijk.

Waar ik eerder een probleem zie is hoe alle andere browsers het gaan implementeren. Wat gaan Safari, Edge etc. in de toekomst dien. Als zij allemaal een andere melding gaan geven wordt het wel erg onduidelijk. Wat dat betreft werkt het slotje nu redelijk universeel.

[primanocte]

slotje zal wel blijven denk ik. Alleen de tekst verdwijnt

[SuperflipNL]

Slotje verdwijnt ook 'uiteindelijk' (Eventually, zie onderste tekstbalk in het plaatje).

[faim]

Tegen die tijd wordt HTTP waarschijnlijk helemaal niet meer toegelaten.

[.oisyn]

Dat is gewoon praktisch onmogelijk. Wat voor certificaat moet je router interface bijvoorbeeld aan gaan bieden, die doorgaans louter op een ip-adres bereikbaar is?

[Reactie gewijzigd door .oisyn op 22 juli 2024 20:42]

[Casmow]

Een self-signed certificaat.
Zal het wel HTTPS zijn, alleen niet vertrouwd voor public en zal je deze dus eerst zelf moeten accepteren.

[GekkePrutser]

En wie gaat er nieuwe apparatuur kopen voor al die mensen met spullen die het nu niet ondersteunen?

Een Self-signed certificaat is trouwens juist iets waar meer over gewaarschuwd wordt door de browser dan een onbeveiligde verbinding. Want dat kan ook op een MITM aanval wijzen.

[Bastiaan V]

Welke apparatuur, waarmee je websites bezoekt, heeft geen ondersteuning voor https?

Een self-signed certificaat is prima voor een router, je kan het fysieke apparat (incl verbinding) zelf zien tijdens de eerste installatie. Op dat moment accepteer je het bewuste certificaat, zodat je een volgende keer ook remote kan inloggen zonder dat je je zorgen hoeft te maken of je met het juiste apparaat verbonden bent.

De vraag is dan wat vertrouw jij meer, jouw eigen ogen of een externe toko als digicert/comodo/diginotar ;-)

[GekkePrutser]

Ik bedoel de routers zelf. De meesten ondersteunen helemaal geen https op hun admin interface. Veel andere apparatuur ook niet (printers, ip cams, ip telefoons enz).

Er is bijna geen enkel apparaat hier in huis dat het heeft. Vind ik ook niet handig, maar ik ga niet alles nieuw kopen

En ik bedoel het niet voor mezelf, maar voor n00bs. Want als je dit soort types sites bezoekt:

- HTTP: In chrome een rood vakje "Not secure" maar de site laadt wel gewoon
- HTTPS met self signed: "W00000T deze site is onveilig, absoluut niet doorgaan!!", waarna je op "advanced" moet drukken en dan "load anyway".

Als dat alleen nog maar op de HTTPS manier kan, krijgen een heleboel Tweakers straks hun oma's aan de telefoon omdat ze denken dat hun router/printer enz gehackt zijn. Of, en dat is eigenlijk nog erger, de gebruikers worden geconditioneerd om altijd maar op 'load anyway' te drukken. Want, zo denken ze, het is toch nooit iets ernstigs.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 20:42]

[Engineer]

Ook niet erg gebruikersvriendelijk als ieder persoon op de wereld die “This website is unsecure” blokkade moet doorworstelen.

In mijn ogen gaat het wat onzinnig ver om HTTP uit willen te faseren. Dat is net zoiets als bij elk adres aan iedere straat in het land, luchthaven security te plaatsen met xray en metaaldetector. Je stropt het hele systeem ermee tot het gewoon niet meer functioneerd.

[Reactie gewijzigd door Engineer op 22 juli 2024 20:42]

[faim]

Private IP-ranges zullen dan gewoon worden toegelaten (10.x.x.x, 172.16.x.x, 192.168.x.x) en ook lokale top-level domains zoals .local en .lan.

Praktisch helemaal niet onmogelijk en ook helemaal niet ondenkbaar.

[the_stickie]

En hoe gaat men bepalen of een tld lokaal is? Er is geen zinvolle manier om dat te doen; uiteindelijk kies je die tld gewoon zelf. Ook .lan is bijvoorbeeld niet "reserved" thuisgebruiker met Homegroups gebruiken .home...
Bovendien is er niks dat je tegenhoudt om een in een lokaal netwerk publieke adressen te gebruiken (buiten de geaccepteerde best practices en het feit dat je jezelf het leven lastiger maakt) of anderzijds zelf bijvoorbeeld een .com zone authoratief te hosten op je dns server.

Ik ben het eens met .oisyn dat dit niet iets waar Google aan zal willen beginnen.

[faim]

Ja dat bepaal je zelf, maar als je zelf de verkeerde gebruikt waarvoor het niet bedoeld is, ben je zelf natuurlijk fout en loop je inderdaad tegen problemen aan.

15 jaar geleden was SMTP op poort 25 ook de standaard, dat is nu inmiddels ook bijna uitgefaseerd en vervangen door beveiligde poorten 587 of 465. Waarom zou het zo ondenkbaar zijn dat HTTP (80) wordt uitgefaseerd voor HTTPS (443)?

[the_stickie]

Je gaat voorbij aan het punt: dat er geen enkele manier is om vast te stellen of een tld al dan niet lokaal is, danwel een ip in een vertrouwd lan zit. Dus http browserside alleen "lokaal" toestaan levert gegarandeerd een hoop issues waar google geen enkele baat bij heeft.

SMTP werkt overigens nog gewoon op poort 25, al is dat ook een slecht idee (omdat iedereen "onderweg" je emails in plain text ziet "voorbijkomen")
En de reden dat http (nog) minder snel zal verwijnen is heel eenvoudig: er zijn gewoon véél meer toepassingen. Google doet nu al heel hard zijn best https te promoten. Maar http simpelweg "verbieden" is ten eerste niet hun taak, en is, ten tweede, een manier om problemen te veroorzaken bij eindgebruikers (die dan gewoon een andere browser zullen gebruiken). Dat zal Google dus niet gaan doen

En ik zie niet in wie dat wél zou (kunnen) doen.

[fastedje]

Smtp op poort 25 kan prima veilig met STARTTLS. Ik zou ook graag zien dat dit verplicht gaat worden, nu zegt de verouderde RFC dat je STARTTLS niet mag afdwingen.

[faim]

Je gaat voorbij aan het punt: dat er geen enkele manier is om vast te stellen of een tld al dan niet lokaal is, danwel een ip in een vertrouwd lan zit. Dus http browserside alleen "lokaal" toestaan levert gegarandeerd een hoop issues waar google geen enkele baat bij heeft.

Jawel, daar zijn gereserveerd IP-adressen en TLD's voor, die zijn er dus wel.

SMTP werkt overigens nog gewoon op poort 25, al is dat ook een slecht idee (omdat iedereen "onderweg" je emails in plain text ziet "voorbijkomen")
En de reden dat http (nog) minder snel zal verwijnen is heel eenvoudig: er zijn gewoon véél meer toepassingen. Google doet nu al heel hard zijn best https te promoten. Maar http simpelweg "verbieden" is ten eerste niet hun taak, en is, ten tweede, een manier om problemen te veroorzaken bij eindgebruikers (die dan gewoon een andere browser zullen gebruiken).

Hoewel SMTP nog steeds op poort 25 werkt, wordt het al door verschillende providers geblokkeerd. Ook bij hosting providers kom ik regelmatig tegen dat poort 25 standaard dichtstaat.

Dat zal Google dus niet gaan doen
En ik zie niet in wie dat wél zou (kunnen) doen.

Zoals wel vaker, als Google ergens mee begint, volgen er vaak velen. Om de privacy en beveiliging op het web weer een stukje beter te maken, is dit helemaal niet zo ondenkbaar. Toen Google HTTP websites als onveilig ging aanmerken en anders behandelen in zoekopdrachten, schreeuwde iedereen moord en brand. Inmiddels zijn we twee jaar verder en heeft alleen Let's Encrypt al 50x meer certificaten uitgegeven. Tevens forceert Google inmiddels HTTPS bij haar top-level domains. Ik zeg niet dat dit binnen nu en twee jaar gebeurd, maar er komt straks een keer dat bijvoorbeeld Chrome geen HTTP websites meer gaat serveren en dan duurt het echt niet lang voordat Firefox en andere browsers volgen.

[the_stickie]

Er zijn geresrveerde ip ranges voor privaat gebruik, klopt.
Ik had overigens zelf de rfc's mbt tld's gezocht, noch in rfc2606 noch in rfc6761 staat .lan of .home... waar jij naar verwijst is een (expired) draft. Gelukkig hoeven we niet met elke rfc-draft rekening te houden.

Providers blocken poorten om gebruikers (vnl met dynamische ip's) te "beschermen" (bijvoorbeeld telenet). Gelukkig doet "al de rest" nog altijd wat ze willen...

[Dorank]

Een certificaat waar de CN het ipadres is!

[walteij]

Nee, HTTP wordt dan weergegeven als NOT-Secure

[mschol]

Nee, HTTP wordt dan weergegeven als NOT-Secure

en voor de niet technische en/of minder handige personen zijn op dat moment https EN http niet veilig, want in beide gevallen wordt er niks weer gegeven over wat WEL veilig is.

hele, hele slechte zaak, google kan in zijn eentje op deze manier (en dat doen ze al) gewoon bepalen wat internet moet doen.

https is leuk, maar niet heilig of zaligmakend en zo laat google het wel overkomen nu vind ik.

[Reactie gewijzigd door mschol op 22 juli 2024 20:42]

[Bastiaan V]

[...]


en voor de niet technische en/of minder handige personen zijn op dat moment https EN http niet veilig, want in beide gevallen wordt er niks weer gegeven over wat WEL veilig is.

hele, hele slechte zaak, google kan in zijn eentje op deze manier (en dat doen ze al) gewoon bepalen wat internet moet doen.

https is leuk, maar niet heilig of zaligmakend en zo laat google het wel overkomen nu vind ik.

Er wordt straks juist nergens gezegd dat https secure is, wat op dit moment wel het geval is. Jouw laatste zin onderschrijft juist datgene waar google naartoe aan het werken is, en toch bashen?

[lallasjip]

Slotje gaat ‘eventually’ ook weg; zie screenshot.

[MikeyMan]

Vraag die bij mij opkomt is wel; is het echt nodig om voor alle sites een ‘veilige verbinding’ te hebben? Moet alles via https lopen om geen gevaar te lopen op van alles?

[Rannasha]

De toegevoegde waarde van HTTPS verschilt per website. Op een website waar je passief content consumeert, zonder accounts of dergelijke zaken, zal HTTPS minder bijdragen dan op de website van je bank. Maar ook in dat eerste geval heeft HTTPS nut. Zo blijft je privacy gewaarborgd, want alleen jij en de website weten wat je precies leest. Andere partijen kunnen wel zien welke website je bezoekt, maar niet welke pagina je precies hebt geopend. Zo kan men zien dat je Tweakers hebt bezocht, maar niet welk artikel of post je gelezen hebt. Daar komt nog bij dat met een HTTP verbinding, een aanvaller die zich tussen jou en de website bevindt, de content kan wijzigen. Zo kan deze een phishing link, malware of ads toevoegen. Met HTTPS blokkeer je dit omdat alle content versleuteld over de lijn gaat.

Tegenwoordig is het zo eenvoudig en goedkoop om een simpel certificaatje aan te maken en je website HTTPS-compatible te maken, dat er voor websites eigenlijk geen reden is om het niet te doen. En het levert altijd wat op, soms wat meer, soms wat minder.

[krosis]

>Tegenwoordig is het zo eenvoudig en goedkoop om een simpel certificaatje aan te maken en je website HTTPS-compatible te maken, dat er voor websites eigenlijk geen reden is om het niet te doen.

True. Ik heb op al mijn websites, zelfs gekke side-projects, simpelweg LetsEncrypt aangezet. Kost vrijwel geen moeite.

[DigitalExorcist]

Https is geen beveiliging tegen 'van alles'. Het is een bepaalde mate van garantie dat jij praat met wie je denkt te praten. De site in kwestie kan nog steeds malafide zijn.

[Blokker_1999]

Het is zelfs geen garantie dat jij praat met wie jij denkt te praten. Het is een garantie dat niemand anders kan meelezen en je verbinding kan onderscheppen om ineens een ander antwoord te geven dat wat de server je wenste te geven. Maar als iemand in staat is om de initiële verbinding te onderscheppen en te redirecten naar een andere server dan kan je nog altijd met een ander aan het praten gaan.

[Terrestrial]

Je spreekt jezelf nu een klein beetje tegen. De enige garantie is dat de verbinding versleuteld is tussen punt a (jezelf) en punt b, verder niks. Je weet niet of punt b de punt b is die jij in gedachte hebt en je weet ook niet of het verkeer meegelezen kan worden, je hoopt van niet.

[MikeyMan]

Dat was ook een beetje de strekking van mijn vraag. Enerzijds; hoeveel veiligheid biedt het en anderzijds hoe onveilig is het zonder?

[Anoniem: 288526]

https garandeert niets, behalve dat de verbinding van A naar B versleuteld is en er zeer geringe kans is op een MITM attack. Wie er aan de andere kant van het touwtje zit ( B ) is zeker bij Domein Validatie zeer onzeker, elke crimineel kan een Let's Encrypt certificaatje installeren. Bij Organisatie Validatie is het al iets zekerder met wie je te doen hebt maar nog steeds geen garantie. Zelfs bij een EV (Uitgebreide Validatie en de bekende groene bedrijfsnaam label in de adresbalk) is er geen 100% garantie dat je te maken hebt met wie je denkt te maken te hebben, hoewel de kans dat een ABN met een EV certificaat malafide is best klein is.

[Reactie gewijzigd door Anoniem: 288526 op 22 juli 2024 20:42]

[Blokker_1999]

Voor een veilige verbinding? Ja. Dat is net het doel van een standaard https verbinding. De communicatie tussen je browser en de webserver beveiligen. Is dat een garantie? Niet noodzakelijk. Zegt het iets over de identiteit van de eigenaar? Neen, tenzij er een EV cert gebruikt wordt. Betekend het dat de website zelf veilig en vrij van malware is? Absoluut niet.

[WhatsappHack]

Sowieso als er formulieren zijn. (En de target van het formulier moet ook https zijn). Voor de rest is het strict gezien niet perse nodig, maar het verhoogt wel je veiligheid en privacy - wel zo prettig, dus sterk aan te raden en beter om het gewoon te doen. Ik zou graag standaard encryptie zien, waarbij selfsigned certificaatjes worden gezien als wat http:// nu is (onveilig), maar de browser daar niet over bitched tenzij het certificaat is gewijzigd. Uiteraard alsnog (ev-)ssl certificaten om een groen slotje/balkje te krijgen. En nog liever dat zaken als LetsEncrypt meer worden omarmd, maar veel hosting providers proberen nog altijd mensen uit te zuigen voor SSL Certificaten ipv mee te helpen het internet veiliger te maken. Sommige blokkeren zelfs poort 443 tenzij je bij hen een peperduur certificaat koopt. Snel overstappen naar een andere host in dat geval.

Het is altijd zo geweest dat je bij een selfsigned certificaat een mega-waarschuwing krijgt, maar als er helemaal geen encryptie is krijg je geen waarschuwing. Met het oog op authenticatie is dat heel logisch en terecht, maar eigenlijk is het ook heel krom; want een beveiligde verbinding met zelfondertekend of verlopen certificaat is nog altijd veiliger dan een plain-text verbinding natuurlijk. Recent zijn browsers wel “onveilig” icoontjes gaan tonen op onversleutelde formulieren - en terecht. Heeft jaren te lang geduurd...

En SSL zegt enkel iets over de veiligheid van de verbinding he. Het zegt niets over de veiligheid van de site. Toch is een beveiligde verbinding eigenlijk altijd te prefereren over een onversleutelde verbinding.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 20:42]

[ssmeding]

Er is eigenlijk geen argument waarom je voor http zou kiezen in plaats van https.
Zelfs op een simpele website met maar een paar statische html-pagina's heeft https als voordeel dat je surfgedrag niet (of in elk geval lastiger) te onderscheppen is.

De noodzaak voor https ligt wel iets genuanceerd. De implementatie van de melding 'Not secure', getoond in de animated gif bij dit artikel, is hiervan wel een mooie vertaling. Zo lang je alleen een pagina bezoekt staat bij de melding een (i)-icoon (melding is informatief), zodra je een formulier gaat invullen (en dus gegevens onversleuteld over het internet gaat versturen) wordt dit vervangen door een rood uitroepteken.

Met name voor websites met formulieren is het blijven werken met http een onveilige keuze.

Goed dat Google er nu voor kiest om de melding 'veilig' op basis van het hebben van een https-verbinding weg te halen, want dit is natuurlijk maar één aspect van de beveiliging van een website. Https != geen gevaar.

[Steynno]

Iemand die hier een duidelijke maar controversiële mening over heeft is Bryan Lunduke.
Erg interessant om ook de beweegredenen te horen om niet voor iedere passieve website SSL te activeren, je hoort vaak alleen de voordelen maar er zijn ook argumenten te bedenken waarom je het niet zou willen.

https://www.youtube.com/watch?v=wNPvIk3jQ-M

[gop1]

Wat is nou de waarde van zo'n slotje? Kan zoiets niet gewoon gefaked worden?

[Anoniem: 498327]

Als je een groen slotje als favicon toevoegt heeft 80% het niet eens door denk ik.

[gop1]

Lees net dat dat inmiddels ook niet meer kan (althans, in Firefox dan): nieuws: Firefox schrapt favicon uit url-balk vanwege beveiliging

[Martijntj]

Google maakt gebruik van non-HTTPS op heel veel manieren onaantrekkelijker. Ranking in de zoekmachine, maar ook op deze wijze wordt gebruik door websites gepromoot. Denk dat Google veel bedrijven drijft naar een veiliger internet.

[svennd]

https vs http maakt enkel de communicatie tussen server en gebruiker veiliger. Genoeg https websites die even onveilig zijn als 10 jaar terug toen ze in dienst kwamen.

[DigitalExorcist]

Precies. HTTPS garandeert in hoge mate alleen dat je praat met wie je dénkt te praten. Dat je ondertussen met een malafide organisatie praat kan nog steeds. Het garandeert niks, alleen beschermt het tegen 'meeluisteren' door derden..

[Grrrrrene]

Nu doe je net alsof dat niet fijn is om te weten, dat er niet meegeluisterd wordt? Het is een van de vele manieren om internet veiliger te maken, niet de enige.

[Neko Koneko]

Nee, het punt is alleen dat je nog steeds niet weet of je daadwerkelijk veilig bent. Tussen jou en de tweede partij kan niemand meeluisteren, maar wat als er aan de kant van de tweede partij iets niet goed is (bv. malware op de server). Er is gewoon een risico dat mensen denken dat ze met HTTPS klaar zijn, maar de site moet zelf ook veilig met de gegevens omgaan (en niet bv. wachtwoorden onversleuteld opslaan oid).

[Grrrrrene]

Dat klopt, maar het deel dat je zelf kunt controleren is dan in ieder geval veilig. Want hoe toon jij aan dat de site zelf veilig is? Je hebt een veilige verbinding met je bank, maar wie zegt jou dat jouw bank veilig is? En waar nu "bank" staat, mag je natuurlijk ook "webwinkel", "social media website", etc lezen.

Mijn punt is: het feit dat dit niet het enige is wat je kunt doen, wil niet zeggen dat het niet bijdraagt aan een veiliger internet. Iets met de zwakste schakel...

[reneflo]

Dat is dus eigenlijk precies een argument vóór deze actie van Chrome/Google. Op dit moment geeft Chrome heel duidelijk 'secure' of veilig als je een HTTPS verbinding hebt, maar dat is dus eigenlijk geen zekerheid.

Als een website alleen HTTP gebruikt weet je eigenlijk sowieso dat die niet veilig is, want je wordt dan afhankelijk van het hele netwerk tussen jou en de website en als dat netwerk ergens niet veilig is (een zeer grote kans op het internet) kan er dus malafide content worden toegevoegd aan de site. Dus bij HTTPS niets meer tonen (eerst alleen nog een slotje) en bij HTTP dat het niet veilig is. HTTPS is geen garantie voor een veilige site, maar wel een vereiste.

[Dorank]

HTTPS garandeert in hoge mate alleen dat je praat met wie je dénkt te praten

Hoe kan ik aan het lets encrypt certificaat van Tweakers achterhalen dat ik daadwerkelijk met de enige echte Tweakers machines communiceer? Het enige wat ik nu weet is dat iemand met de controle over DNS een certificaat heeft kunnen genereren. En aangezien tweakers geen DNSSEC gebruikt is dat relatief simpel te regelen.

Het garandeert niks, alleen beschermt het tegen 'meeluisteren' door derden..

Dit is HET doel van een secure transport layer. Dat staat in principe los van het hele fiasco genaamd Certificate Authorities, die ongecontroleerd certificaten kunnen uitleveren die zomaar trusted zijn door alle browsers.
Gelukkig spreek je jezelf tegen.

[DigitalExorcist]

Dat kun je inderdaad niet achterhalen. Maar 'for the sake of argument': laten we er even van uitgaan dat iemand die de certificaten bij Tweakers beheerd, inderdaad betrouwbaar is en dit daadwerkelijk Tweakers.net is zoals dat ooit bedoeld is.

Vervolgens slaat Tweakers al je wachtwoorden in plaintext op in een .htaccess file op de server zelf. Ik noem maar een gekke dwarsstraat, je hoort wel vreemdere verhalen tegenwoordig. Dan kan je verbinding nóg zo veilig zijn maar de site zelf onbetrouwbaar blijken.

Nee, in die zin garandeert https inderdaad niks over de veiligheid van de site, maar wél een bepaalde mate van veiligheid voor de verbinding daar naartoe. Ook dát is wat genuanceerder: een SSL-verbinding zónder certificaat is nog steeds encrypted en dus veilig, alleen is het op geen enkele wijze gevalideerd door een CA.

[MadEgg]

HTTPS garandeert ook niet dat je praat met wie je denkt te praten. Het garandeert dat je praat met iemand die zeggenschap heeft over de domeinnaam die je bezoekt. Dat is alles. Als daar rab0bank.nl staat in plaats van rabobank.nl denk je (als je niet al te goed oplet) nog steeds dat je met de Rabobank praat.

Terecht dus dat 'veilig' daar weggehaald wordt - het is niet veilig. Het geeft hoogstens een indicatie dat het onwaarschijnlijk is dat het verkeer onderweg van jouw client naar de server waar je mee praat wordt afgeluisterd.

[Anoniem: 1073059]

Wel zou ik willen dat hier meer nuance in komt. Sommige websites hebben geen versleuteling nodig. Bijvoorbeeld de hobbyisten die een read-only website hebben (HTML / CSS) en waarvan de website dus geen mogelijkheid heeft om data te schrijven. Google kan dat onderscheid vast maken, en ik vind het gemeen vinden om deze websites te "straffen" omdat de eigenaren best wel complexe processen niet begrijpen.

Dat zie je inmiddels ook aan de resultaten terug: websites van de vaardige hobbyist vind je niet meer omdat zij niet mee kunnen doen met contentdieven die niks geven om de hobby en alleen maar advertenties willen tonen. Ik mis dat organische wel een beetje van vroeger. Nu is alles zo geoptimaliseerd dat het artificieel is geworden. Google is vooral een afspiegeling geworden van ongeïnteresseerde IT'ers. Andere vaardigheden en daadwerkelijke inhoud worden niet meegewogen.

[Anoniem: 159174]

Google is vooral een afspiegeling geworden van ongeïnteresseerde IT'ers.

Ik zou het eerder een bedrijf noemen dat nogal monomaan in een bepaalde richting kijkt. Dat zie je bij deze actie ook terug. Er is in de UX van de browser een slotje gemeengoed geworden. Staat ook in alle handleidingen. Nu wordt dit UX element verwijderd, waardoor de ene browser het wel weergeeft, de andere niet. Veel succes, handleidingenmaker...

In zekere zin heeft Chrome/google gelijk, een slotje is nog wat anders dan secure. Maar voor zover ik weet is in het leven niets zeker.

En alhoewel het hier los van staat, de "wisdom of the crowds" is omgeslagen naar "wisdom of the SEO expert". Het komt steeds vaker voor dat ik via directe links in fora de informatie moet vinden, omdat google het bedolven heeft in lege verkooppraatpagina's.

[Hardwareseller]

Ik ben echt benieuwd hoe dat gaat worden met een wildcard (dus waar de naam van het bedrijf bovenin bij de zoekbalk in staat). Het heeft namelijk dan niet veel nut meer om 130€/jaar uit te geven aan zo’n dure ssl, kan iedereen beter meteen overstappen naar letsencrypt

[RobinF]

Bij wildcards staat de naam niet in de balk. Bij EV staat dat er alleen, en die zal wel blijven vermoed ik.

[Casmow]

Tevens kan je wildcards gebruiken met letsencrypt

[Blokker_1999]

Een wildcard certificaat is een certificaat dat voor meerdere (sub-)domeinen geldig is. De term die jij zoekt is een EV-certificaat. En die zullen behandeld worden zoals vandaag: groen slotje, met naam van de firma erbij om aan te geven dat de identiteit gecontroleerd werd.

[ace6717]

Ik heb dat nu al meerdere keren gelezen in de comments, maar ik kan nergens terugvinden waar staat dat bij een EV het slotje en de naam blijven staan. Heb jij een bron?

[pim]

Enigsinds off topic, maar ik heb een server met Centos en directadmin, met een schone installatie.
Heb iemand ingehuurd om https geïnstalleerd te krijgen, die persoon kreeg het niet voor elkaar.
Iemand anders ingehuurd om https werkend te krijgen, die kreeg het ook niet voor mekaar.
Toen een derde persoon ingehuurd die het wel voor elkaar krerg, maar na een paar maanden stopte het met werken, en als resultaat ging mijn website down. Iets fout gegaan met automatische verlenging.
Hij repareerde het..
Vervolgens voegde ik een nieuw domein toe via directadmin, bam, weer https wat stopte met werken bij dat domein.

Ik wou dat ssl makkelijk te installeren was, maar tot zover is het voor mij een absolute nachtmerrie geweest.

[Anoniem: 167912]

Vreemd verhaal, de meeste (goede) hosters bieden dit tegenwoordig standaard aan en meestal zelfs gratis, met een eenvoudig vinkje in het controlepaneel is alles tot in de eeuwigheid in orde.

[pim]

Ik gebruik transip.

En om daar nog aan toe te voegen.
Transip raadde me aan om php te updaten, met een simpel commando. Vervolgens vlogen er een half uur lang update commando's over het scherm(putty), en vervolgens was de gehele server down. (ook dit betrof een "verse" centos installatie).
Het zou zo makkelijk moeten zijn, maar ik ben als de dood om wijzigingen te maken in de server configuratie.

[Reactie gewijzigd door pim op 22 juli 2024 20:42]

[WhatsappHack]

Op een vps/dedicated server wordt je geacht het zelf te kunnen. Je kan dan zelf iets opzetten als LetsEncrypt bijvoorbeeld. Als je geen idee hebt hoe de server werkt dan moet je daar iemand voor inhuren.

[Demonitzu]

Was dit recentelijk? Ondersteuning voor https via Lets Encrypt zit helemaal ingebakken en vereist normaliter alleen een aantal muiskliks

[pim]

Ja, dit was allemaal in het afgelopen jaar.

[Primuszoon]

Wat met lokale devices zoals een nas/printer bij thuisgebruik? Ik moet nu overal de self-signed certificates gaan installeren, of elke keer 2 -3 beveiliginswaarschuwingen wegklikken.

[RobinF]

Gewoon doorklikken, toevoegen aan uitzonderen, zelf een geldig certificaat aan hangen, de waarschuwing "onveilig" negeren

[Blokker_1999]

Daar veranderd op zich niets aan. Het is enkel de weergave in de adresbalk die zal veranderen.

[dakathefox]

Ik vind dit toch een stap terug. Misschien niet de hele tekst tonen, maar een rood driehoekje of een groen slotje is qua usability toch wel aan te bevelen.

[Anonymoussaurus]

Mwoah, ik weet het niet. Ik heb het idee alsof mensen denken "oh, een groen slotje. Mij kan helemaal niets gebeuren. M'n pc is dus veilig" terwijl dat er geen drol mee te maken heeft natuurlijk . Punt is dat de gemiddelde gebruiker dat dus niet weet.

[daantjeboez]

Wat mij opvalt is dat zodra ik met Safari (built-in browser macOS) probeer in te loggen op een site die nog met http werkt, ik al een rode melding krijg in de url-balk "Not Secure". Zodra ik ben ingelogd verdwijnt de melding. Blijkbaar willen ze bij Apple alvast waarschuwen.

[calvinturbo]

Heeft ermee te maken dat je wachtwoord kan worden onderschept als je inlogt via HTTP.