Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Chrome duidt sites aan als onveilig als ze geen https toepassen

Google brengt dinsdag Chrome 68 uit. Als een http-site wordt bezocht, duidt Googles browser deze site expliciet als 'onveilig' aan. Tot nu toe gaf Chrome geen waarschuwende tekst weer bij dit soort pagina's. In de toekomst moet ook de 'beveiligd'-mededeling bij https-sites verdwijnen.

Google kondigde deze verandering al in februari aan, maar toen was de exacte releasedatum van Chrome 68 nog niet bekend. De gedachtegang achter deze wijziging is dat er voldoende progressie is geboekt naar de adoptie van https op het web. Chrome waarschuwde al wel bij inlogpagina's die niet gebruikmaken van een beveiligde https-verbinding.

Er staan meer van dit soort wijzigingen op stapel voor volgende versies van Googles webbrowser. Zo zullen websites die gebruikmaken van een https-verbinding in Chrome 69 niet meer worden aangeduid met het woord 'veilig'. Dat verdwijnt, omdat Google vindt dat gebruikers mogen verwachten dat 'het web standaard veilig is' en dat ze een waarschuwing krijgen als dat niet zo is. Daarnaast speelt mee dat een aanwezig certificaat niets zegt over de veiligheid van een site.

Chrome 69 komt in september uit. Websites met invulvelden die nog geen gebruik maken van https, worden vanaf oktober in Chrome 70 in de adresbalk aangeduid met de rode tekst 'not secure'.

De huidige wijziging in Chrome 68 met betrekking tot http-sites

De volgende stap in Chrome 69 met betrekking tot de 'veilig'-aanduiding bij https-sites

Door Joris Jansen

Nieuwsredacteur

24-07-2018 • 13:53

173 Linkedin Google+

Reacties (173)

Wijzig sortering
Aan de ene kant snap ik dat wel, maar op een site waar alleen info wordt aangeboden (bv de site van de bakker op de hoek die geen webshop/bestel functionaliteit heeft) is dat natuurlijk redelijk overbodig.
Ja het is tegenwoordig makkelijk (en zelfs gratis met LetsEncrypt) in te regelen, maar toch...
Voor een site waar form/userdata gebruikt wordt in welke vorm dan ook is het wat mij betreft noodzakelijk, maar zelfs dan is https lang niet heilig.


Edit:
niet gedacht aan data/packet injection. Zeker over een onbeveiligde verbinding (leuk die gratis wifi netwerken overal) is dat natuurlijk een zwaar risico. Zo zie je maar weer, niemand is oud genoeg om stomme dingen te roeptoeteren :)

[Reactie gewijzigd door derx666 op 24 juli 2018 14:18]

Het gaat niet alleen om het beveiligen van de content van de website, maar ook om het beveiligen van de gebruikers van de website.

Zie dit artikel waar uitgelegd wordt waarom dit zo belangrijk is: https://www.troyhunt.com/...atic-website-needs-https/
Tuurlijk kan verkeer intercepted worden, maar wat is daarbij dan het doel als het om de website van de bakker betreft waar hoofdzakelijk de winkeltijden staan neergeplempt?

Het gaat niet alleen om de site, maar ook of het een interessant doelwit is. En dat is het in veel gevallen nog steeds niet.

Verder vind ik het nogal naïef om te denken dat elke website makkelijk op HTTPS gezet kan worden. Niet iedereen gebruikt handige software om zijn blogje te beheren. En niet iedereen heeft een fancy domeinboer die dat makkelijk maakt.

[Reactie gewijzigd door Martinspire op 24 juli 2018 14:10]

omdat je daar als aanvaller ook doodleuk een facebook login kan neerplempen of een flash update popup als je dan toch al een intercept aan het doen bent, dat is letterlijk een kwestie van een paar knopjes indrukken en klaar. daar zijn hele frameworks voor ontworpen.

niet elke site is makkelijk om te zetten naar HTTPS, maar dat is geen geldig excuus meer.

Je hebt geen fancy domeinboer nodig daarvoor, root toegang is het enige wat je nodig hebt om een script te draaien met wat simpel copy paste werk. als je het zelf niet kan vraag je het je handige neef maar.
En volgens mij draagt al dat "handige neef" c.q. buurjongen / zoon van de baas nu juist bij aan al die halfbakken implementaties, onderhiudsproblemen en beveiligsrisico's...
Uiteraard, maar als iemand het zelf niet kan en weigert iemand in te huren om het goed te doen is het beter dan niks.
Ik wilde juist afstappen van HTTPS voor mijn site omdat geen enkele meerwaarde heeft voor mijn site.
Dat is precies waarom google dit doet, voor je site zelf heeft het misschien geen meerwaarde maar voor de bezoekers wel.
Dat iemand mijn CV bekijkt?
SSL is alleen maar gedoe als je het niet nodig hebt.
dit is geen SSL, dit is TLS. SSL is zwaar outdated. en jou CV kan opeens een heel mooi reactieveld hebben waarbij je kunt inloggen met google, facebook, je bank etc om een reactie achter te laten. je kan dingen injecteren, wat net zo gevaarlijk is als dingen onderscheppen.
Nooit gehoord van MITM? Men kan gewoon leuk een andere (aangepaste of nagemaakte) versie van je cv aanbieden aan gebruikers op het moment dat een gebruiker een request doet om je cv op te vragen. Daarnaast is het aanbieden van HTTPS goed voor je (iig google) SEO.

[Reactie gewijzigd door jozuf op 24 juli 2018 16:24]

Jawel, maar ik heb geen formulieren, en ik had alleen niet bedacht dat er ook een scenario mogelijk is zoals beschreven door @mjz2cool ergens hieronder.
formulieren kun je inderdaad ook gemakkelijk plaatsen, een bezoeker heeft in de meeste gevallen niet door dat er normaal geen formulier is.
Het maakt geen zak uit of het 'read only' is of niet, je hebt 0 cryptografische bescherming om 'read only' (wat dat ook mag zijn in deze context) duidelijk te maken aan de eindgebruiker waardoor een tussenpersoon kan doen met de website wat die wil en dat voorschotelt aan de bezoeker. TLS garandeerd niet alleen dat de antwoorden niet gelezen kunnen worden door een derde, maar ook dat de antwoorden niet aangepast kunnen worden door een derde. opeens is het antwoord van

laad pagina MrMonkEhenCV.nl

niet meer de echte MrMonkEhenCV.nl maar MrMonkEhenCVmetfbcomments.nl alleen staat in de adresbalk nogsteeds MrMonkEhenCV.nl dat is waar TLS tegen beschermd.

[Reactie gewijzigd door t link op 24 juli 2018 14:56]

Ja, je hebt gelijk.
Hoewel dit bij mij vrij irellevant is zal dit zeker niet voor alle read-only sites gelden.
Dat is volgens mij exact het punt, zonder ssl kan iemand random meuk in een respons van jouw site injecteren en dat veld aanmaken om zo gebruikers te phishen.

Ja, SSL (TLS) heeft meerwaarde.
nee, het is read only.
Op een onbeveiligde verbinding is niets read-only. Als je dat niet snapt, moet je misschien je mening over het al dan niet toepassen van TLS ook eens matigen. Je hebt dan duidelijk niet de kennis in huis om daar juist over te oordelen.

[Reactie gewijzigd door R4gnax op 25 juli 2018 08:30]

We zijn er gisteren al uitgekomen hoor.
injecteren schrijft ook niks, je injecteerd alleen maar iets.
Ik heb het een keer ingesteld met certbot, en heb er verder geen omkijken meer naar.

(en het opzetten zelf is ook heel eenvoudig)
Totdat er een nieuwe versie van ACME uit is dan werkt het niet meer. Wel in de gaten houden dus!
20 dagen voordat je certificaat verloopt verstuurd LetsEncrypt nog een e-mail, dus als er iets niet meer werkt, wordt je op de hoogte gesteld.
Als je de ACME versie in de gaten moet houden, moet je ook je OS up to date houden...Acme updaten is dan net even 2 minuten meer werk. Als je al niet de moeite wilt, kunt, durft te nemen om dit te doen dan hoor je gewoonweg geen server of VPS te hebben maar gewoon een hostingaccount af te nemen.

Dan wordt dit alles voor je gedaan zonder dat je überhaupt ergens naar hoeft om te kijken als je de SSL (via Let's Encrypt) eenmalig ingesteld hebt.

Overigens één van mijn hobby servers heeft nog gewoon een vrij oude Acme draaien, geen probleem zolang er in de backend niets veranderd en dat is dan dus ook niet eens het geval. Voor de wildcard certificaten is zelfs een totaal nieuwe backend in gebruik genomen waarbij beide naast elkaar werken. Het is dus zeker niet zo dat je iedere maand een nieuwe acme-update "moet" installeren.
Maar complexer dan niet doen.
Dat gaat natuurlijk voor alles op.

Laat je je website toch lekker SSL-loos, gezien 60% van het web browsen nu via Chrome gebeurd, success er mee. Mensen zijn vaak snel bang als ze meldingen van hun OS of browser krijgen dat er iets niet aan de haak is.

5-10min werk om dit uit te voeren, verhoogd je kansen op de arbeidsmarkt enorm, zal wel IT gerelateerd zijn vermoed ik. Je steekt er wat van op en de complexiteit valt omlaag.

Dus, waarom niet? Complexiteit of luiheid mag geen excuus zijn. Gezien je account een jaar of 10 oud is, we zijn toch Tweakers?
Ik denk dat het er aan ligt voor wie je CV toegankelijk moet zijn.

Persoonlijk zou ik als jij in de IT (serveronderhoud, webdesign etc.) actief bent, jou niet in dienst nemen daar je misschien weinig kaas gegeten hebt van website beveiliging, bescherming van data, laksheid of luiheid. Als je het voor je eigen zaken deze moeite al niet neemt, wie zou mij dan zeggen dat je het wel voor mij als werkgever zou doen ?!

Als werkgever zou ik dan wellicht vragen kunnen gaan stellen maar dat kost tijd, moeite en dus geld.... of te wel, volgende CV en potentiële kandidaat.

Nu kan je C.V. misschien wel geen persoonlijke gegevens (adres, dob etc. bevatten maar dan nog).
SSL is alleen maar gedoe als je het niet nodig hebt.
Als je die 3-5 minuten al een heel gedoe vind, is het wellicht zelfs verstandiger die hele site offline te halen en je C.V. gewoon ergens online te dumpen.

[Reactie gewijzigd door DarkForce op 24 juli 2018 15:20]

Helemaal correct. Is ook 1 van de eerste dingen die ik in orde bracht bij mijn persoonlijke site ter ondersteuning van mijn CV. Het staat gewoon veel beter als je die kleine moeite neemt.
nee, dat iemand dingen injecteerd op je website waardoor data van bezoekers wordt verzameld, zoals facebook accounts en dergelijke.
Als je met dat CV solliciteert op een baan in de IT en het nog niet eens voor elkaar kunt krijgen een gratis letsencrypt certificaat op je site te krijgen (hoezo gedoe? het is een eenmalige setup) geef ik je niet veel kans om door te gaan naar de volgende ronde. Het ontbreken van SSL op je site zal bij een echte IT’er meer aandacht trekken dan wat dan ook uit je CV :+
Ik heb gewoon https hoor.
Zag alleen de aanvalsvector zoals @mjz2cool beschreef niet zo 1-2-3.
Je hebt geen fancy domeinboer nodig daarvoor, root toegang is het enige wat je nodig hebt om een script te draaien met wat simpel copy paste werk.
Volgens mij overschat je de hoeveelheid servers die root toegang geven. Als je een simpel servertje ergens hebt gehuurd met 1 of andere oude admin erop, dan heb je alleen een plek om je bestanden heen te sturen en misschien een MySQL database aan te maken, maar meer niet hoor? Genoeg MKB bedrijven die daar niet veel aan hebben gedaan de laatste jaren. En sommigen zitten gewoon met een gehuurd Wordpress domein.

Ik snap je punt maar tenzij je echt eigenaar bent van de server, krijg je in andere gevallen vrijwel nooit genoeg toegang om zo'n script uit te voeren. Laat staan dat het in alle gevallen werkt.

En dan ga je nog voorbij aan het feit dat het waarschijnlijk makkelijker is om maar meteen de server over te nemen dan als man-in-the-middle te gaan werken.

[Reactie gewijzigd door Martinspire op 24 juli 2018 16:40]

[...]
Volgens mij overschat je de hoeveelheid servers die root toegang geven. Als je een simpel servertje ergens hebt gehuurd met 1 of andere oude admin erop, dan heb je alleen een plek om je bestanden heen te sturen en misschien een MySQL database aan te maken, maar meer niet hoor? Genoeg MKB bedrijven die daar niet veel aan hebben gedaan de laatste jaren. En sommigen zitten gewoon met een gehuurd Wordpress domein.
Klopt. Het word ook eens tijd dat het MKB vragen gaat stellen aan hun hosting partijen. Simpele SSL / TLS opties zijn al meer dan 10 jaar aanwezig in de meest gangbare CMS systemen

Het grootste probleem is volgens mij het feit dat veel bedrijfjes zichzelf verkopen als one stop shop voor websites en voor het gemak even vergeten dat webservers beheren iets anders is dan beetje HTML/JavaScript/CSS typen
Net als dat sommige bedrijven die webservers beheren denken dat het maken van websites niet meer is dan een beetje HTML/JavaScript/CSS typen ;)
De -complexere- website is een frontend, als je hier meer doet dan een beetje HTML/JS/CSS meuk gebruiken, doe je wat verkeerd denk ik?

Alle complexe zut voer je doorgaans uit op een backend waar die frontend zijn info uit trekt.
De -complexere- website is een frontend, als je hier meer doet dan een beetje HTML/JS/CSS meuk gebruiken, doe je wat verkeerd denk ik?

Alle complexe zut voer je doorgaans uit op een backend waar die frontend zijn info uit trekt.
Verdiep je eens in wat moderne techniek. Er gebeurt tegenwoordig veel, en veel meer aan de front-end kant dan wat 'meuk'. Complexe 'zut' aan de backend komt in 90% van de gevallen neer op varianten van "trek data uit database/webservice; plemp door template heen" terwijl je aan de frontend kant bezig bent met complexe gebruikersinteracties afhandelen.
Ik ben full-stack developer en heb zowel ruime front- als backend ervaring.

IMHO is de frontend honderd maal complexer dan de backend.

De backend: Je schrijft een request handler, verzamelt wat request parameters/headers, doet een DB/API call of wat, berekent nog iets, genereert een JSON response en done. Er zijn hier honderden frameworks voor maar je kiest er een en zo lang de response hetzelfde is merkt de client niks.

De frontend: Je moet drie kolommen van gelijke hoogte maken -> bent 2 weken tutorials over CSS aan het lezen. En dan werkt het alsnog niet in Edge of Opera of whatever. Alles moet werken op piepkleine tot zeer grote schermen (responsive) op alle browsers (cross-browser), voor blinden etc. Je hebt soms maar hele beperkte bronnen tot je beschikking. Je hebt alle UX problemen die je op moet lossen etc etc.

En als je dan een pagina bekijkt die 10 jaar geleden aan alle voorwaarden voldeed dan is diezelfde pagina nu in de meeste gevallen een goed voorbeeld geworden van hoe het niet moet.

* OddesE herinnert zich nog schrijven van XSLT stylesheets voor XHTML Strict webpages....

EDIT:
als je hier meer doet dan een beetje HTML/JS/CSS meuk gebruiken, doe je wat verkeerd denk ik?
Behalve Flash/Silverlight is er verder überhaupt niet zoveel. Je kunt net zo goed schrijven 'een beetje code gebruiken'. Precies hetzelfde kun je over de backend zeggen. Echter op de backend kies je zelf je talen. Op de frontend zit je vast aan HTML/CSS. En Javascript is gewoon een full-blown programmeertaal waarmee je zo'n beetje alles kunt coden wat je maar wilt.

Ondertussen zie je dat we met microservices en serverless / managed oplossingen steeds minder aan de backend hoeven te doen. Tegelijkerijd is de front-end een fat client geworden die zoveel mogelijk lokaal doet. De frontend voelt hierdoor veel sneller en soepeler aan (omdat je niet die trage klik .... laad... klik .... laad request response cyclus meer hebt) maar tegelijkertijd is dit een van de onderdelen die hierdoor juist veel complexer is geworden de afgelopen jaren.

Ik zou zeggen ga eens wat React en/of Angular development doen en vertel me dan dat het wat simpele HTML/CSS/JS meuk is....

[Reactie gewijzigd door OddesE op 24 juli 2018 19:18]

* OddesE herinnert zich nog schrijven van XSLT stylesheets voor XHTML Strict webpages....
Dat ging in mijn herinnering toch ook gewoon met CSS hoor.... xslt is om de ene XML structuur in de andere om te zetten, niet om webpagina’s te stylen.
Ja precies iedereen z'n vak!
Nee hoor, het is feitelijk niet veel meer dan dat.
een man in the middle is echt kinderspel. je hebt gewoon kant en klare producten die het voor je doen met de druk op een knop. (zie wifipineapple). je gaat geen bedraad verkeer makkelijk kunnen af tappen op een groot netwerk nee, maar een wifi hotspot overnemen is kinderlijk makkelijk met simpele arp poisoning.
Als je geen handige software gebruikt die het makkelijk maakt, dan zijn er oplossingen zoals Cloudflare, die een reverse proxy voor je site zetten en waarbij je gratis https krijgt, en daar bovenop krijg je gratis dingen als caching en DDoS protection.

Nog steeds geldt: er is geen excuus om geen https te hebben.
Dat maakt de verbinding tussen jou en Cloudflare als HTTPS maar geeft geen garantie van de verbinding tussen Cloudflare en de server. Daar kan nog steeds iemand tussen zitten volgens mij
Dat is afhankelijk van hoe je het instelt. Cloudflare genereert voor jou een certificaat en dat kun je gewoon op jouw server neerzetten zodat de encryptie wel end-to-end is. Echter dan ben je wel weer terug op het punt dat je HTTPS voor je server moet configureren. Wil je dat niet, dan kun je edge-encryptie gebruiken.

En ja, de verbinding tussen Cloudflare en jouw server zijn dan niet beveiligd, maar dat is in de meeste (realistische) scenario's niet erg. Tenzij je bang bent voor beveiligingsdiensten of zo. Want de echte praktische bedreiging zijn open Wifi punten op stations etc. die eigenlijk van een hacker zijn en die MitM attacks op populaire sites doen. En dat soort aanvallen weer je ook met edge encryptie prima af.
Volgens mij is het aantal bots wat servers probeert te kraken toch echt groter dan het aantal wat MITM aanvallen op wifi hotspots doet.
Je kunt Cloudflare e.d. zelfs zo configureren dat jouw origin server 'verstopt' is en dat alleen Cloudflare hem kan bereiken.
Klopt.... Veel bedrijven zorgen dan ook dat zulk verkeer via een private netwerk gaat. Bedrijven zoals COLT kunnen je daarbij helpen en het echt niet heel ingewikkeld
Het is natuurlijk ook mogelijk om alleen verkeer toe te staan vanaf cloudflare-IP's (ik werk zelf met AWS Cloudfront bijvoorbeeld, daar kan je dat ook netjes instellen).

Je staat alleen verkeer toe náár je reverse proxy(/CDN) en staat geen direct verkeer van bezoeker naar de host toe. Dan heb je dit probleem niet.

Dat maakt het niet minder gemakkelijk om een SSL certificaat (evt. met let's encrypt) of self-signed toe te voegen, maar goed!
Jawel, als je veel content hebt van externe bronnen dan is het wel een excuus.
Het gaat er niet om of de website van de bakker een target is. Het gaat erom dat degenen die de website bezoeken targets zijn.

En het gaat de aanvallers niet om welke website je bezoekt, ze maken gebruik van elke onbeveiligde website die je bezoekt, die ze automatisch injecteren.
Crap ja, niet gedacht aan data-injection. Oftewel, iedereen aan de https :) Let's Encrypt gaat het nog druk krijgen.
Let's Encrypt kan dat makkelijk aan hoor. Zo heel heftig is een certificaat aanvraag ook weer niet.
Belangrijker wordt het voor webhosting partijen dat ze zelf SSL gaan promoten. Dit kan al door een LetsEncrypt certificaat gratis aan te bieden bij het hosting packet (er zijn er die dit al doen).

Ook wordt het steeds belangrijker dat de shared-hosting platformen letsencrypt beter gaan ondersteunen. Je hebt tenslotte toch een cryptobot nodig die op de betreffende server de certificaten aanvraagt. Er zijn helaas nog steeds veel shared-hosting platformen die dit niet ondersteunen.
Ook voor websites met statische content is https aan te raden. Troy Hunt heeft hier een blogpost over gemaakt: https://www.troyhunt.com/...atic-website-needs-https/

Troy heeft ook een website opgezet met de grootste HTTPS 'overtreders', ook op land:
https://whynohttps.com/country/nl

[Reactie gewijzigd door Cerenas op 24 juli 2018 14:09]

Dan mag Troy de lijst wel eens updaten. GeenStijl en Dumpert hebben HTTPS.
Het is een automatisch gegenereerde lijst. Als je (handmatig) naar http://www.dumpert.nl gaat, word je niet naar https gestuurd en dat is waarschijnlijk waarom dumpert er ook tussen staat.
Bij dumpert inderdaad geen doorsturen naar https, bij geenstijl wel (zojuist even beiden getest).
Dus de lijst is niet helemaal in orde.
Bij Dumpert wordt https niet afgedwongen - zie http://www.dumpert.nl
Ik krijg wel een redirect naar HTTPS als ik naar http://dumpert.nl ga (zoals in de lijst staat). Dumpert is dus niet goed bezig ...

[Reactie gewijzigd door Zidane007nl op 24 juli 2018 16:18]

Dumpert lijkt per browser te bepalen welke het doorstuurt.

FF krijgt netjes https.
Edge en IE blijven op http hangen.
Vivaldi blijft op http hangen.
Xxx tracker en ero advertising :D in de top 10.
Nee voor de bakker op de hoek is het niet overbodig. het gevaar is niet alleen maar data stelen die word ingevoerd zoals log in gegevens.

Ik kan ook doodleuk een popup geven dat je flash moet updaten om vervolgens een rat installer die praktisch niet te onderscheiden is van een echte flash update te pushen als je op update drukt. dat is waarom ALLES https moet zijn tegenwoordig. er is geen enkele reden om een website niet in https te runnen, het is gratis, en het is zo simpel dat mijn moeder het zou kunnen.

Of wat dacht je van doodleuk wel een inloggen met facebook scherm te laten zien als iemand toch naar de website van die bakker gaat? om bijvoorbeeld een reactie achter te laten, vast wel iemand die erin trapt die al op de gratis wifi van diezelfde bakker zit. dan had de site misschien oorspronkelijk niks om inloggegevens van te jatten, na een simpele MITM heeft die dat wel.

[Reactie gewijzigd door t link op 24 juli 2018 14:12]

Ook in een https site kun je de popup maken dat je flash moet updaten.
Het gaat erom wie dat kan doen en wanneer het gebeurd. Https is een transport beveiliging. Het zegt dus niks over de inhoud van de website, maar wel dat de inhoud onderweg niet is aangepast.
maar dan moet je inbreken op de server. of je moet het als eigenaar doen, maargoed, daar kan niks tegen beschermen. als de server goed beveiligd is en je accounts ook, dan is dat moeilijker dan een injectie op een http verbinding
tuurlijk kan dat, alleen is het veelvoudig keer moeilijker. het kan niet meer met een simpele MITM omdat je nu ook de TLS keys nodig hebt of toegang tot de DNS registrar. (als ik me niet vergis)

[Reactie gewijzigd door t link op 24 juli 2018 14:24]

Dit is 1 van de redenen dat Letsencrypt juist zo goed is. Een certificaat dat na 90 dagen expired ( en waarschijnlijk in de toekomst nog sneller! ) is veel moeilijker stoute dingen mee te doen. Breekt iemand in op je server en jat hij de keys / cert chain; dan heeft ie een maximum van 90 dagen als je het NET hebt aangevraagd om het te exploiten. Hierdoor is de kans dat het dus fout gaat aanzienlijk lager, ook zullen in veel gevallen er veel minder dagen over zijn.

Letsencrypt, of iig, certbot genereert een nieuwe key bij elke renewal, dus dat zit ook helemaal goed. Het enige wat letsencrypt lastiger maakt is Certificate pinning goed opzetten.

HTTPS all the things!
als het 1000x keer eenvoudiger is om een website te hacken heb je zeker "wachtwoord" als wachtwoord. als je ssl/tls gebruikt kan iemand van buitenaf niks aanpassen, wat vrij simpel kan door alle http verbindingen te injecteren die je tegenkomt, wat dus zeker een goede reden is om http verbindingen als niet veilig te markeren. het heeft niks met hacken te maken, wat met een goede beveiliging moeilijk genoeg is.
Statistisch gezien klopt het waarschijnlijk wel wat hij zegt. Als je de drie populairste web frameworks bekijkt hebben die samen al bijna de helft van alle websites of zo. Dan even zoeken naar security leaks in (oude) versies en voor je het weet heb je een crack waarmee je duizenden of zelfs miljoenen sites zou kunnen besmetten.

Een MitM is praktisch heel moeilijk tenzij je ergens een AP neerzet, maar dat is dan weer heel localized en zul je geen miljoenen slachtoffers mee maken.
ja een simpele MITM, die hoeft ook niet op grote schaal uitgevoerd te worden. simpelweg op het station een gratis wifi netwerk aanbieden en op alle niet HTTPS websites dingen injecteren is al genoeg om schaden te kunnen maken. daarmee kan je als je een enkel doelwit hebt makkelijk zeer gericht iemands pc binnendringen. gewoon ethercap downloaden op een apparaat met een wifi chip en je hebt al alles wat je nodig hebt. of een pineapple kopen als je al helemaal lui bent. Dat je er nou zelf een arbitraire voorwaarden aan hangt maakt het niet opeens moeilijk.

[Reactie gewijzigd door t link op 24 juli 2018 15:28]

Het is nog een reden om Chrome te droppen met dit soort namaak security redenen.
Dan kan je maar beter gaan stoppen met internetten, de andere browsermakers gaan dit ook in de loop van dit jaar of begin volgend jaar doorvoeren.

En dat er andere manieren van hacken makkelijker zijn dan MITM, maakt nog niet dat deze maatregel (lees: alles over TLS maken) dan geen nut heeft. Het sluit in ieder geval weer een manier van hacken uit, of maakt het op z'n minst fors moeilijker. Dat is dus niet "fake security".
Het is ook ideaal als je op lokale netwerk apparaten zit....
Dit in de meeste gevallen een goede zaak, maar wat als er websites zijn waarop je alleen informatie kan winnen zonder een formulier of iets van gegevens door de sturen? Is het dan wel nodig om je website een https certificaat te geven?
http://vul_hier_je_soa_in.nl/hoekomikervanaf.htm

Ik hoef niet te weten wat jij wel of niet invult. Aan de url zelf zie ik al genoeg :)
http://vul_hier_je_soa_in.nl/hoekomikervanaf.htm

Ik hoef niet te weten wat jij wel of niet invult. Aan de url zelf zie ik al genoeg :)
Ja, maar de URL is nog steeds niet encrypted, alleen de content.
Dat is niet waar. Alle URL's zijn encrypted. Het enige wat niet encrypted zou zijn is de domeinnaam zelf tijdens het opzetten van de beveiliging. Dit is nodig als een server SNI ondersteunt waarbij meerdere domeinen gebruik maken van hetzelfde IP adres. Maar zelfs dan zijn de URL parameters veilig.
Bij TLS kan je de volledige URL niet zien! Dit is een veel gemaakte fout. Alleen het TLD is te achterhalen met wireshark bijv. Waar de request naar toe gaat om de verbinding op te bouwen. Zie ook hier https://stackoverflow.com.../are-https-urls-encrypted

Edit: link

[Reactie gewijzigd door glenn456 op 24 juli 2018 14:36]

Bekende mythe, URL is wel degelijk encrypted. Het ip adres niet. Dus een middleman kan zien welke server je aanspreekt maar niet welke site. Dus hij ziet bijvoorbeeld dat je aws aanspreekt. Geen idee over de inhoud.
De oorspronkelijke HTTPS handshake lekt de domeinnaam ook.
Alleen het domein gedeelte is niet versleuteld (Wordt kenbaar gemaakt via SNI), maar de rest van de URL wel. Voor zo'n website maakt dat niet uit, maar je kan niet zien welke pagina's iemand op wikipedia bekijkt bijvoorbeeld.
https://heeftmijnwebsitehttpsnodig.nl

Er zijn genoeg redenen waarom je altijd HTTPS wil hebben. Niet alleen als gebruiker; maar ook als beheerder
Die website kan zelf wel een taalcheck gebruiken, het staat helemaal vol met d/t-fouten.

Als je doel is om vertrouwen te wekken en mensen naar https te leiden, zorg dan in ieder geval voor fatsoenlijk Nederlands.
Laat ze op die site eerst maar eens wat doen aan hun Nederlands, als ze serieus genomen willen worden.

An sich eens met de adviezen, maar de fouten in de spelling maakt de site nogal amateuristisch.

Ook het stukje over hashen op die site is al achterhaald. Passwords wil je niet hashen, maar encrypten en dat is wat anders dan hashen. Het stukje over hashen is te algemeen (thanks voor het duwtje in de juiste richting, @3raser) en verdiend anno 2018 wat meer uitleg. Een md5-hash is immers ook een hash, maar intussen ook niet meer veilig!

[Reactie gewijzigd door CH4OS op 24 juli 2018 14:45]

Ben je sarcastisch? Gezien je zelf ook redelijk wat fouten maakt..
Had het snel getypt op mobiel, dan struikel ik. Intussen gecorrigeerd.
Goed advies negeren vanwege spelfouten is vrij dom als je het mij vraagt.

[Na je edit]
Het stukje over hashen is te algemeen
De website gaat dan ook niet over hashen maar over HTTPS. Wat de schrijver probeert te zeggen is dat zelfs als je je wachtwoorden veilig opslaat ze alsnog uit kunnen lekken als de verbinding niet encrypted is.

[Reactie gewijzigd door 3raser op 24 juli 2018 14:46]

Het haalt de betrouwbaarheid van een website gigantisch omlaag. Als ik een site zie bomvol spelfouten sla ik eigenlijk het advies over. Of het is een open deur, of ik kan vergelijkbare informatie vinden op een website die zijn zaakjes wel een beetje op orde heeft.
Ok, nu ben je gewoon aan het trollen.
Poeh, ik maak even een denkfoutje en ben dan gelijk maar aan het trollen, serieus? :?
Heb mijn bericht weer aangepast, overigens.

[Reactie gewijzigd door CH4OS op 24 juli 2018 14:42]

"We hashen de wachtwoorden."
Mooi. Vertel me nu alsjeblieft wel dat ze verstuurd worden via HTTPS. ... dat doe je toch?
Dit is wat ze zeggen. Daarmee impliceren ze dat alle hashes goed zijn, wat dus niet zo is. Kan dus wat mij betreft wel een nuance krijgen, ondanks dat de pagina iets anders ten doel heeft. Geef dan op zijn minst een duwtje in de juiste richting, zoals jij net ook deed, immers. Kleine moeite, groot plezier.

En ja, ook dat maakt voor mij de site minder waardevol. Zeker als je iets wilt zeggen aangaande veiligheid op het web.

[Reactie gewijzigd door CH4OS op 24 juli 2018 14:48]

Ja google filtert ook actief op websites met http en https een website met https komt hoger in de resultaten dan een non https website.
Dat is een gevolg, niet de oorzaak. Google doet dit omdat het van mening is dat het de privacy van de bezoekers beschermt. Een derde kan dan niet zien weke content je op een website hebt bezocht. Naast wat andere voordelen overigens :).

[Reactie gewijzigd door Eagle Creek op 24 juli 2018 14:07]

Het is ook om bezoekers te beschermen tegen MitM aanvallen waarbij men bijv. een (nep) Facebook login button op een site plaatst.
Het oude protocol HTTP/1.1 is inmiddels vervangen door HTTP/2, wat voor de gebruiker te merken is in snellere sites o.a. door multiplexing. De grote browsers en webservers ondersteunen alleen HTTP/2 over een TLS, waardoor je een certificaat moet hebben wil je HTTP/2 gebruiken als website.

[Reactie gewijzigd door ThomasG op 24 juli 2018 14:09]

HTTP/1.1 is niet "vervangen" door HTTP/2. Dat is een los protocol op zich. Er zijn genoeg sites die nog niet over zijn op HTTP/2. ;) Ja, het gebruik neemt toe, maar het protocol is nog verre van HTTP/1.1 doen verdwijnen op het web, helaas.
"nodig" is nogal vaag... je vraag kan daarom niet eenduidig beantwoord worden.

Nodig om je site onder normale omstandigheden te laten functioneren? Nee, het internet werkt al jaren "prima" zonder HTTPS. Wat HTTPS doet (in combinatie met andere technieken zoals DNSSEC) is gebruikers beschermen zodra de omstandigheden niet meer normaal zijn, en de route tussen jouw computer en de webserver niet langer zonder meer te vertrouwen is.

Denk hierbij bijvoorbeeld aan een publieke wifi router die verkeer herschrijft (omdat er malware op de router terecht gekomen is), zodat er bitcoin-mining in de browser gedaan wordt. Daar kun jij als site-beheerder niet veel aan doen als je geen HTTPS gebruikt, want de browser kan niet zien dat er met de content gerommeld is. Als jouw site over wel HTTPS geserveerd zou worden dan heeft je bezoeker redelijke zekerheid dat hetgeen hij/zij ontvangt ook hetgeen is wat jij verzonden hebt.

Ook surveillance ("tappen") wordt een stuk lastiger.

En omdat de kosten van HTTPS nu teruggelopen zijn naar welgeteld ¤0 (dankzij LetsEncrypt) is er eigenlijk geen enkele reden meer om het niet aan te bieden, behalve laksheid/gelatenheid.
Is dit niet allemaal gevalletje pseudo-veiligheid? Neem aan dat https sites hogere ranking krijgen dan de non-versies, maar hoe 'veilig' is veilig dan precies? Plaintext wachtwoorden opslaan, Get ipv post formuliertjes, cookies en javascripts van alles en iedereen. Alsof je de ramen van een auto volledig blindeert en daarmee claimt 'de auto is veilig', niemand kan meekijken, maar zegt niets over de staat van de auto zelf.
Dat is 1 van de dingen die HTTPS dus mooi afvangt: die GET formuliertjes aangezien de url encrypted is. Het IP/domein van de server is wel te vinden (het verkeer moet ergens naartoe/vandaan) maar niet de specifieke url 'http://site.nl/index.php?pass=admin1234'' :+
Zelfs het domein is niet in te zien met HTTPS. Zelfs dat zit encoded in de header. Het enige wat je kan zien is het IP adres van de server waarmee je verbinding maakt.
Dat klopt wel, maar een aanvaller zou DNS queries kunnen afluisteren, als die toch al naar http luistert...
Dan IP aan domein knopen dankzij diezelfde DNS queries en dan weet je welke naam erbij hoort.
Tenzij het slachtoffer meerdere sites bezoekt die op dezelfde shared hosting draaien wat mij onwaarschijnlijk lijkt zou je aanvaller dat dus kunnen vinden.
De aanvaller kan toch ook gewoon zelf de DNS-query doen als hij het IP-adres weet?
Jij zegt, DNS-queries afluisteren. Ik bedoelde, het ip-adres van de server afluisteren, en dan zelf het domein opvragen. Of begrijp ik verkeerd hoe het werkt?
Je hebt beide 'nodig' om ze te koppelen ;)
Je luistert het IP van de website waar ze mee bezig zijn af, dat geeft je het IP van de server waar de website gehost wordt, als het niet achter Cloudflare hangt en geen shared hosting is ben je er dan al.
DNS queries afluisteren en die dan matchen met de IP's waar HTTPS verkeer naar gaat geeft je zekerheid welke sites bezocht worden.
Meerdere websites kunnen op 1 IP zitten en meerdere IP's kunnen aan 1 website hangen, door de DNS query te matchen weet je het dus exact.

Je kan het gokken, maar Cloudflare (en soortgelijke diensten) hebben *nogal* wat klanten, zo'n gok zal niet echt precies zijn, zou knap zijn als je het juiste TLD al gokt in dat geval :+
OK ik begrijp wat je zegt.
Correct in de verbinding, het gaat mij ook om de veiligheid 'buiten' deze verbinding, de server zelf.

Ik zie het straks al in het nieuws
-'database met plaintext wachtwoorden lekken uit'.
-hoe kan dat nu? Chrome zei dat deze website 'veilig' was.

Dat is mijn punt met pseudo-veiligheid.
Neem aan dat het nu dus (voor Chrome iig) komt tot:
HTTP: Onveilig
HTTPS: (niks, geen speciale text ervoor in de url)
HTTPS EV: Veilig

Dat lijkt mij iig logisch, dat HTTPS de norm wordt en niet zozeer veilig is maar gewoon 'normaal'.
Anders wordt het een puinhoop inderdaad met mensen die denken 'Veilig = veilig' en bedrogen uitkomen :/
HTTPS zegt niet alles over veiligheid, vandaar dat ze dat weg gaan halen.
Geen HTTPS zegt wel wat over veiligheid. Iedere communicatie met die website is op hetzelfde netwerk of wifi router volledig inzichtelijk.

HTTPS is een extra laagje. Net als een raam dicht doen als je weggaat dat ook is. Het zegt niets over je slot op de deur, maar raam dicht is veiliger dan raam open.
Het zegt enkel en alleen iets over de 'data tussen jou en de server', verder niets. Geef dan expliciet aan dat de _verbinding_ secure is, niet een simpel icoontje dat lijkt te impliceren dat de 'website veilig' is.

Zoals nu in het bericht vertaald staat:
omdat Google vindt dat gebruikers mogen verwachten dat 'het web standaard veilig is'
Dat is dus pure onzin.

Natuurlijk, iets aanmerken als 'onveilig' geen niet direct de conclusie dat zonder deze tag het 'veilig' is, maar het geeft wel het idee dat alles 'veilig is'. Laat ik het dan anders 'schijn-veiligheid' noemen.
Mijn sites op mijn interne netwerk ga ik via een VPN heen met client-side certificaten. Veel veiliger dan HTTPS alleen. En toch roept Chrome dat het niet secure is. Geen HTTPS zegt dus ook niets. Maar het is makkelijk om een waarschuwing te geven en mensen een scare te geven. Aangezien het Google is die het doet zit er waarschijnlijk iets anders achter dan we vermoeden aangezien het "do no evil" ook al niet meer in het mantra van Google zit.
Het is dan ook moeilijk om de volledige context in dat kleine balkje te stoppen. "Not secure" betekend effectief dat de verbinding niet encrypted is. Over de veiligheid van de website zelf zegt het verder helemaal niets.
Denk dat het ergens ook in onze dubbele betekenis zit van 'onveilig'.

Een website waar de browser instapt en zegt 'this website is reported as unsafe' (malware)
Een website die geen https heeft en zegt 'this website is reported as not secure'. (http verbinding)

Beide krijgen de vertaling mee 'onveilig' (of niet veilig), ene programma zegt een, de ander weer iets anders.

Zag dat 1 van de firefalls juist de melding gaf:je verbinding met deze site is niet 'prive', als een vertaling van your connection is not secure. Maar een ander programma geeft op dezelfde pagina 'je verbinding met deze site is niet veilig'. In beide gevallen geven ze wel expliciet aan 'verbinding', wat al duidelijker is.

[Reactie gewijzigd door SinergyX op 24 juli 2018 14:58]

Dat is natuurlijk altijd een lastig iets, zeker omdat abstractheden als een HTTPS-certificaat voor de gewone man worden vereenvoudigd tot 'groen slotje' en het is prima. Terwijl dit dan inderdaad puur over een verbindingsveiligheid gaat. Terwijl een phishingsite ook prima HTTPS kan hebben, of een bepaalde webwinkel opgezet voor oplichting.

Wat dat betreft is veilig niet een enkelvoudig begrip, en is HTTPS altijd beter dan zonder, maar het is zeker niet heilig.
Het geen ik helaas ook maar wat vaak tegen mensen vertel. Ik vergelijk het zelf altijd met het "Politie-keurmerk". Er zijn legio mensen die denken dat het "Politie-keurmerk" staat voor een woning waarbij niet kan worden ingebroken, het verschil is echter dat het inbraak-vertragend werkt maar zeker geen inbraak voorkomt.

Ik ben bang dat deze vorm van schijnveiligheid een enorme hoeveelheid "gemiddelde consumenten" de indruk gaat geven dat ze veilig kunnen browsen en verder weinig moeite meer hoeven te doen qua beveiliging van hun device.

[Reactie gewijzigd door DarkForce op 24 juli 2018 15:19]

Get ipv post formuliertjes
Dat maakt qua veiligheid niks uit aangezien de POST data ook gewoon plaintekst over de lijn gaat als die niet beveiligd is.

Verschil tussen GET en POST is semantisch: met GET vraag je gegevens op maar wijzig je niks. Met POST (en PUT/DELETE bij REST APIs) maak/wijzig/verwijder je gegevens. Dat onderscheid is handig om te maken, zodat een mail client niet de URL opvraagt om een preview te genereren en dan plotseling iets onbedoeld van de server verwijdert bijvoorbeeld. Echter met beveiliging heeft het niks te maken. Een POST request afvuren is nauwelijks moeilijker dan een GET request.
Zucht, dan moet ik dat ook weer gaan uitleggen aan mijn ouders. Heb ze net uitgelegd dat ze op het groene slotje moeten letten (wat overigens ook niet altijd 100% veilig betekend).
Het is wel 100% veilig als de naam van het bedrijf er ook bij staat. Dat is een EV certificate. Als namelijk de private key van de ING gejat is kan je de site zelf(ook al is het de echte) ook niet meer vertrouwen.

[Reactie gewijzigd door NotCYF op 24 juli 2018 14:06]

Een groen slotje geeft aan dat de site overeenkomt met het certificaat, indien je niet op mijn.ing.nl maar op mijn.jng.nl zit kan dit slotje dus nog steeds tonen als het certificaat maar overeenkomt. Ja het certificaat is dan waarschijnlijk door een ander ondertekend, maar weet jij bij wie het ING certificaat ondertekend hoort te zijn?

Hier zit het probleem van de 100% veiligheid die niet voor mensen zichtbaar is. Ik weet niet bij wie alle sites hun certificaten hebben laten ondertekenen. De browser helpt hier al mee door bepaalde ondertekenaars als onveilig te markeren, echter is deze lijst nooit gegarandeerd 100% correct.

Het is dus zeer goed mogelijk om iemand die eventjes niet goed leest (omdat er een groen slotje staat) voor de gek te houden. Dit is ook de reden dat Chrome van dit slotje afstapt, het kan een vals gevoel van veiligheid creëren.

[Reactie gewijzigd door Martin.Air op 24 juli 2018 14:13]

Daarvoor gebruikt je browser een lijst van rootcertificaathouders.
Klopt, maar dit bevestigd echter enkel dat het certificaat klopt. Nog steeds niet dat het certificaat klopt voor de site die jij op denkt te zitten (ing.nl in mijn voorbeeld).
Het is dus zeer goed mogelijk om iemand die eventjes niet goed leest (omdat er een groen slotje staat) voor de gek te houden. Dit is ook de reden dat Chrome van dit slotje afstapt, het kan een vals gevoel van veiligheid creëren.
Certificaten zijn gekoppeld aan een domeinnaam. Dat is nou net het enige dat wel altijd wordt gecontroleerd. Echter je kunt prima een certificaat aanvragen voor jng.nl en dat ook krijgen. En weet je als klant veel of jng.nl een geldig domein van ING het bedrijf is of niet?
Dit is ook de reden dat Chrome van dit slotje afstapt, het kan een vals gevoel van veiligheid creëren.
Ik kan me voorstellen dat de naam/het logo van het bedrijf tonen bij een EV certificaat, en een soort van mystery man icoon bij andere certificaten wellicht een oplossing zou kunnen zijn.

[Reactie gewijzigd door OddesE op 24 juli 2018 19:36]

De certificaten zitten in een zogenaamde chain; jouw certificaat, de intermediate en het root certificaat. De intermediate bevestigd jouw certificaat, het root certificaat bevestigd de intermediate.
Kan iemand eigenlijk met een man-in-het-middenaanval de browser eigenlijk automatisch doorsturen naar een ander (kwaadaardig) domein met zijn eigen certificaat? Dan ziet het slachtoffer ook gewoon een (niet-groen) slotje. Zo ja, dan vraag ik me af wat zo'n niet-groen certificaat voor zin heeft qua authentificatie: als je denkt dat je naar Tweakers.net gaat maar wordt wordt omgeleid naar Tweekers.net zonder dat je het doorhebt, kun je daar toch net zo goed een vals formulier invullen?

Het enige wat niet kan met SSL, zo neem ik aan, is iemand met een mihm-aanval doorsturen naar een ander domein terwijl het eerste domein in de adresbalk van de browser blijft staan met slotje: klopt dat?
Het enige wat niet kan met SSL, zo neem ik aan, is iemand met een mihm-aanval doorsturen naar een ander domein terwijl het eerste domein in de adresbalk van de browser blijft staan met slotje: klopt dat?
Er zijn in het verleden timing aanvallen op bepaalde browsers geweest waarmee men het voor elkaar kreeg om te redirecten naar een ander domein terwijl de adresbalk niet bijgewerkt werd.

Of al die problemen ondertussen verholpen zijn? Wie zal het zeggen.
Hmm oké, maar dat is dus een uitzondering: normaliter zou dat niet mogelijk moeten zijn?

Dan ben ik wel benieuwd hoe ze dat voor elkaar kregen...
Het verschil tussen een EV certificaat en een gewoon certificaat is dat bij een gewoon certificaat alleen gecontroleerd wordt of de aanvrager van het certificaat controle heeft over het domein waarvoor het wordt aangevraagd of niet (bijv. door een DNS record aan te maken). Bij een EV certificaat wordt gecontroleerd dat het bedrijf dat het certificaat aanvraagt daadwerkelijk bestaat. Er wordt vaak een (papieren) brief gestuurd naar het adres dat bij het bedrijf wordt, dingen als KvK worden geraadpleegd etc.

Je kunt je afvragen hoe goed die controle is maar het zijn allemaal *extra* controles dus een EV certificaat is bijna per definitie veiliger dan een gewoon certificaat.
EV certificaten gaat ook genoeg mis mee. Dat gaat tegenwoordig ook vaak zo geautomatiseert (zeker bij de goedkope aanbieders) dat er soms nauwelijks meer controle op is. Zo is het makkelijk genoeg om een bedrijf op te zetten met een beetje vergelijkbare naam.
Sterker nog, tijdens een workshop die ik een maandje terug heb gehad van Troy Hunt, kwam ter sprake dat iemand een EV had geregistreerd met exact dezelfde naam als bedrijfsnaam als een bedrijf in een US-state verderop: daar kan je per state een bedrijfsnaam registreren (precieze details kan ik zo even niet terugvinden), dus dan is dat verschil al helemaal niet meer te zien, m.u.v. de url zelf, of als je certificate-details gaat opvragen, maar zeg nou zelf, hoe vaak doe je dat?

Daarnaast laten mobiele browsers die EV-informatie al niet zien, dus daar heeft het al geen meerwaarde meer, en de reguliere browsers gaan er ook naar toe om helemaal niets meer van HTTPS te laten zien, maar alleen meldingen te geven als het niet meer secure is; EV informatie zal dan ook niet meer getoond worden.
Dat laat wel een paper trail achter die een stuk makkelijker te volgen is dan een random dude die wat rottigheid uitspookt op het internet.
Dat is best wel erg! Zou je dan ook ABN Anro kunnen registeren met EV en een domein aanvragen dat er een beetje op lijkt?
EV informatie niet tonen vind ik een rare beslissing. Ik vind hoe Chrome dat nu doet best goed en had eigenlijk verwacht/gehoopt dat men dit verder uit zou breiden.
Wat versta je onder 100% veilig? Stel ik bestel bij webshop A met een mooi EV certificate, maar na betaling gaat deze failliet. Dan ben ik alsnog mijn geld kwijt hoor. Ook als het oplichters zijn overigens.
Tja als een webshop failliet gaat kun je dat natuurlijk niet zien aan het certificaat, maar een dosis gezond verstand en oplettendheid is ook vrij belangrijk tegenwoordig online..
Dat dachten we ook bij Afuture, die was echter plotsklaps failliet. Redelijk wat mensen die daar net wat besteld hadden. Mijn microSD kaart viel dan nog mee, sommigen hadden complete desktops samengesteld van ¤2000,-. ;)
Ja, maar failliet gaan is een economisch probleem dat verder niks met internet veiligheid te maken heeft. Als je naar de fysieke winkel gaat en daar bestelt en (aan-)betaalt kun je dezelfde pech hebben. Of opgelicht worden.

HTTPS is bedoeld om een bezoeker van een website een aantal garanties te kunnen geven:

* Domeinnaam kan niet gespoofed worden
* Communicatie kan niet worden ontcijferd
* Communicatie kan niet ongemerkt worden veranderd
* In het geval van een EV certificaat: de identiteit van de organisatie achter het domein is bewezen
Een fysieke winkel kan ook failliet gaan zonder dat je het van tevoren ziet aankomen. Staat volledig los van ssl. Wie weet landt er morgen een meteoriet van een km doorsnede op NL, dan krijg je je bestelling ook niet meer.

[Reactie gewijzigd door Engineer op 24 juli 2018 18:21]

Maar dat is het punt van ronn0 helemaal niet. Hij gaat dieper in op de definitie van veilig en ja, ergens zou je dan ook kunnen stellen dat wat je besteld 100% zeker geleverd gaat worden. Dat doet SSL weliswaar niet, maar dat kan wel je definitie van "veilig (webshoppen)" zijn.
Alles behalve het onderwerp https / ssl / tls is gewoon off-topic onder dit onderwerp. NotCYF heeft het over 100% veilig, als in de verbinding met de versleuteling is 100% veilig. Dat is ontopic. Daarna gaat ronn0 verder op faillisementen, wat de bedoeling van de NotCYF zijn tekst “100% veilig” uit z’n context “100% veilige verbinding” trekt.

Al zou het mogelijk zijn om een 100% veilige webshop te laten bestaan (wat niet kan), dan is het nog niet de webbrowser zijn rol om dit weer te geven.
Lol ik zie net pas dat we bijna hetzelfde tegenvoorbeeld geven :+
Een EV cert bevestigd de identiteit van de andere kant. Je weet dus niet alleen dat je verbinding veilig is, je hebt ook bevestiging dat de andere kant is wie dat ze zeggen dat ze zijn. Wat heeft het failliet gaan van een bedrijf te maken met veiligheid op het internet? En oplichters? Die gaan niet snel een EV nemen, kost te veel en ze worden daardoor wel heel eenvoudig op te sporen.
Ja en als je bestelling per vliegtuig verstuurd wordt, en dat vliegtuig stort neer, dan gaat het pakje ook kapot....

Faillissement is gewoon niet relevant voor deze discussie.
Ook als de naam er niet bij staat, weet je in elk geval zeker dat je met de juiste server te maken hebt. Een EV gaat dan enkel verder op de organisatie achter de server. Maar meer dan een uitgebreide kvk-check is dat eigenlijk ook niet, zover ik weet.
Ook de EV certificaten zijn een farce. Zo kon ik enkele weken terug nog (na een screw-up bij de initiele aanvraag) probleemloos het domein van een EV certificaat achteraf nog te veranderen naar een compleet ander domein (incl. andere houder!) zonder dat er een her-validatie plaats hoefde te vinden.

Het hele huidige princiepe werkt niet, wanneer het vertrouwen begint bij een grote commerciele partij. Waarom zou ik Symantec (die met al zijn sub-merken zo onderhand een monopolie lijkt te hebben) op hun blauwe ogen vertrouwen? Of een KPN, die zelfstandig certificaten op naam van de Nederlandse overheid kan aanmaken?

Het enige (grote!) voordeel van een ssl certificaat is de encryptie en deze is, anders dan wat de SSL boeren je willen laten geloven, onafhankelijk van het type certificaat exact het zelfde. Verder koop je bij een OV / EV certificaat enkel gebakken lucht ter waarde van enkele honderden / duizenden euro's .
Je moet niks, je wil het aan ze uitleggen. Uiteindelijk is het idee van een IT oplossing dat de usability goed genoeg is om de gemiddelde gebruiker door de applicatie te leiden.

De teksten secure en unsecure vertellen voldoende toch? Als er unsecure staat moet je geen bankdetails gaan intypen. Als je niks boeiends intoetst (weerbericht van morgen) dan maakt de unsecure tekst niks uit. Ik denk niet dat de voortgang van de IT wereld gestropt moet worden omdat een groep mensen niet voor zichzelf kan nadenken.

[Reactie gewijzigd door Engineer op 24 juli 2018 18:15]

hoe zit dit met sites die worden gehost op een apache windows server die niet open staan voor het internet en allen bereikbaar zijn voor personen binnen een bepaald netwerk. die kunnen zover ik weet niet een lichense generen zoals met let's encrypt bijvoorbeeld.
ie gebruikers krijgen daar dus ook een melding dat de site onveilig is terwijl dat dus eigenlijk niet van toepassing is? correct me if i'm wrong natuurlijk, ben hier totaal geen expert in.

[Reactie gewijzigd door sjoerddz op 24 juli 2018 14:01]

Dan zou je de websites kunnen laten draaien met een certificaat dat ondertekend is door de CA van de server zelf. Als andere PC's in hetzelfde domein zitten, zal het CA-certificaat van de server vertrouwd moeten zijn en de verbinding naar die website dus als veilig worden gezien.

[Reactie gewijzigd door CornéM op 24 juli 2018 14:02]

"In hetzelfde domein zitten" is een Microsoft Active Directory concept. In een thuisnetwerk heb je geen certificate server.
Dan maak je een self-signed certificaat voor aan, en installeer je die als vertrouwd op je clients?
Gewoon je internen CA beginnen en die op allee lokale clients erkennen. probleem opgelost ;)
Daarvoor kan je een eigen PKI server inrichten in je interne netwerk als je daar behoefte aan hebt. Zelfs voor kleine bedrijven is dat best wel te doen, zeker als je daarmee ook nog eens je interne verkeer over IPSec wil laten lopen.
Dan trek je jezelf er niets van aan. Als het puur voor eigen gebruik is zit je vandaag ook al met niet vertrouwde self signed certs of zonder cert bezig. Dat er in de url bar dan een melding kotm kan echt geen kwaad.
Dan mag ik hopen dat de eigenaar van het .com domein het makkelijker gaat maken om verificaties van SSL certificaten te voltooien. Door de GDPR worden emailadressen in de WHOIS nu geblokkeerd, waardoor validatie van de domeinnaamhouder er niet makkelijker op is geworden. Nu dient validatie via algemene mailboxen (die in de praktijk zeer zelden actief zijn) of via DNS TXT records te worden uitgevoerd.
Wat is er mis met een DNS TXT record?

Als je een auto wilt rijden heb je een rijbewijs nodig. Als je een website wilt beheren moet je een beetje leren hoe het werkt. Een lekke website is een gevaar voor anderen.
Daarnaast hebben een hoop webhosting bedrijven een 'parkeerassistent' zoals Let's Encrypt integratie met CPANEL.. 1 druk op de knop: HTTPS!
DNS TXT record heeft teveel variabelen. Zo dien je zelf maar net niet alleen de hosting van de website te doen, maar ook de DNS te beheren. Zeker bij grotere organisaties kan dat bij meerdere partijen zijn ondergebracht. Wanneer je als hoster een DNS wijziging wilt laten doen bij een andere partij, kan je zo weer minimaal een week verder zijn.

Ook dient je CA maar net geautomatiseerde DNS TXT verificatie te hebben, dat bieden helaas ook niet alle CA's aan.
Er zijn zovele manieren waarop validatie kan. Een bestand droppen op de webserver, DNS records of mail uit de WHOIS (niet meer met Europese TLDs). Hangt er puur vanaf welke techniek de aanbieder van het cert gebruikt. En persoonlijk vind ik mail uit de WHOIS records halen 1 van de slechtere.
Mail uit de WHOIS halen kan nog steeds met .nl, en is doorgaans de snelste methode.
(o.a.)De banken hebben er net zo'n beetje bij het gros van de mensen er in dat ze altijd het groene slotje moeten controleren wanneer ze bankieren. Ik vraag me af of de meerwaarde (een vals gevoel van veiligheid voorkomen) wel de nadelen verantwoordt...
Banken maken gebruik van extended validation, die zullen waarschijnlijk wel groen blijven. Het gaat meer om de domeinen die alleen op basis van een email of DNS record gevalideerd zijn.
@citegrene en @davekok Dank, dat klinkt inderdaad als een prima oplossing :)
De banken en velen andere websites hebben een EV certificaat.
Kon er niet zoveel over vinden maar als je het hier leest:
https://groups.google.com.../security-dev/lj0n5lgGpUo
Lijkt het er op dat daar nog geen wijziging gaat plaatsvinden
Krijg er wel een beetje jeuk van dat Google nu gaat bepalen wat wel of niet door de beugel kan.
Krijg er wel een beetje jeuk van dat Google nu gaat bepalen wat wel of niet door de beugel kan.
kennelijk vind "iedereen" het normaal dat google dit doet (Ze doen het al jaren immers)
Toen Microsoft dat deed stond iedereen met fakkels en hooivorken klaar 8)7

ik vind het wagelijk dat google de markt zo kan manipuleren, en in dit geval enorme verwarring gaat zaaien

[Reactie gewijzigd door mschol op 24 juli 2018 20:37]

Op sommige hosters, zoals one.com, kun je heel gemakkelijk (en voorlopig gratis) https inschakelen voor je website. Ze hebben ook een instructie hoe je met een .htaccess bestand alles automatisch naar https kunt redirecten. Dan hoef je zelf niet voor je site in de weer met het bestellen/genereren/installeren van SSL certificaten.

Natuurlijk zullen de meeste Tweakers dit zelf handmatig kunnen instellen, maar het laat zien dat het vrij eenvoudig kan zijn om dit aan te passen.
Er zijn al herkenningspunten voor beveiliging genoeg, van het slotje tot de compleet groene URL, en de "not trusted/invalid" die je vaker wel dan niet terecht krijgt.

Ik vraag me serieus af of dit voor de mensen die al niet op die bepaalde dingen letten en/of overal doorheen klikken dit nog enigzins nut heeft. Als je ze de vraag voorlegt of letterlijk aanwijst dat ze iets fout doen terwijl ze door waarschuwingen heenklikken krijg je standaardantwoorden "Pfff, al die dingen opletten, ben geen computerfiguur", of "Dat doet iedereen" en "dat hoef ik toch niet te snappen".

Je kan iemand het zijn voordeur met tientallen sloten beveiligen, als je die deur voor het gemak open laat staan en een touwtje uit de brievenbus hangt(chrome profiel vol met zooi) loopt men zo naar binnen.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True