Chrome gaat vanaf juli sites zonder https als onveilig aanmerken

Vanaf Chrome 68, dat in juli 2018 verschijnt, duidt Googles browser sites die niet via https te benaderen zijn als 'onveilig' aan. Volgens de ontwikkelaar is er genoeg progressie naar een standaard https-web geboekt om de stap te rechtvaardigen.

Wie vanaf juli de dan verschenen versie 68 van Chrome gebruikt om een http-site te bezoeken, krijgt in de url-balk de waarschuwing te zien dat de verbinding onveilig is. Chrome 'beloont' sites met een beveiligde https-verbinding nu met een groen slotje. Bij sites zonder zo'n versleutelde verbinding blijft het slotje simpelweg achterwege.

Chrome dringt al jaren aan op een overgang naar een volledig https-web. Zo ver is het nog niet, maar het gaat volgens de ontwikkelaar wel de goede kant op. Meer dan 68 procent van het Chrome-verkeer op Android en Windows verliep vorig jaar via https en voor Chrome OS en macOS zou dat percentage zelfs op 78 liggen.

Google markeert sinds begin 2017 inlogpagina's zonder https als onveilig en Firefox doet dat ook al. Daarnaast waarschuwt Chrome vanaf versie 62 voor http-verbindingen bij overige invoervelden en de incognitomodus. Google claimt het ontwikkelaars makkelijker te maken naar https over te stappen, onder andere met zijn Lighthouse-tool, waarmee ontwikkelaars hun sites op de aanwezigheid van mixed content kunnen controleren.

Door Olaf van Miltenburg

Nieuwscoördinator

08-02-2018 • 20:18

230 Linkedin Whatsapp

Lees meer

Reacties (230)

230
227
100
11
0
103
Wijzig sortering
Ik vind het opvallend dat Google er expliciet voor kiest om Veilig/Niet veilig aan te duiden. Hoewel ik het nut (en noodzaak) van HTTPS zeker niet in vraag stel, vind ik het niet correct om op basis hiervan aan een gebruiker te laten zien of een website al dan niet veilig is. Iemand met wat IT-kennis kan hier zeker een beeld over vormen, maar mensen zonder IT-kennis weten hiervoor de onderliggende reden zeker niet.

Zo kan ik perfect op een malafide website terecht komen die beschikt over HTTPS, en te zien krijgen dat de website veilig is. Uiteraard als je op "Secure" klikt krijg je de uitleg waarom deze website als veilig wordt weergegeven, maar hoeveel mensen lezen dit?

Hoewel HTTPS zeker noodzakelijk is, vind ik niet dat er op basis daarvan kan gezegd worden of een website al dan niet veilig is. Je gegevens mogen onderweg dan wel versleuteld zijn, toch wil dit niet zeggen dat je website achteraf "veilig" zijn. Ook organisaties die informatie rondom een veilig internet verschaffen zouden moeten stoppen met mensen leren of een website veilig is wanneer deze HTTPS heeft, het nut van HTTPS en dat het beter is dan HTTP uiteraard wel. Beter zouden mensen op een andere manier aandachtig gemaakt worden op veilige/niet veilige websites.
Wat mij opvalt hoe gemakkelijk mensen accepteren dat Google hen oplegt om HTTPS te gaan gebruiken, nu gebruik ik zelf helemaal geen Chrome, maar voor mij zou het een reden zijn om er vanaf te stappen. Google gaat voor werelddominantie }>

Voor vele websites is er geen enkel nut of noodzaak voor HTTPS, er worden geen privacy gevoelige of persoongegevens verwerkt, het is voornamelijk informatie delen met de wereld.

Als je surft via onversleutelde WiFi verbindingen, dan heeft het grote voordelen. VPN anyone ?

Gevolgen:

- Zowel de server als de client gebruiken onnodig meer rekenkracht en dus energie - batterij van je telefoon sneller leeg en meer energie centrales nodig. Slechter voor het milieu dus.

- Het surfen wordt er weer iets(je) trager op. Maar daar zijn de reclames en alle tracking services veel meer debet aan.

- Iedereen afhankelijk van LetsEncrypt. Van 'gratis' diensten weten we inmiddels allemaal dat ze vaak niet gratis blijven. Zodra iedereen over is (of is moeten gaan, door browser verplichtingen) verandert dat vanzelf.

- Meer beheerwerk voor alle website beheerders en hosters, dus meer kosten. Meer werk voor ons ICT Tweakers dus _/-\o_
Alleen de overheid loopt nog achter
De filosofie erachter is tot op heden mooi.

Maar neemt Google nu niet een stukje regie van het internet over? Ieder die een website heeft, moet nu van Google iets doen om nog bezoekers te krijgen.

Op zijn zachtst gezegd is dat op een bepaald manier niet zo fraai.
De nood aan https wordt steeds groter. Daarnaast is de waarschuwing die ze gaan geven gewoon correct. Zolang dat alles wat ze tonen is het een non issue. De verbinding is namelijk niet veilig, waarom de gebruiker er dan niet subtiel op wijzen?
Welke nood is er bij een gemiddelde website zonder login aan beveiligde verbinding?
Man-in-the-middle die narigheid injecteert. Een man-in-the-middle kan bijvoorbeeld een ISP, access point of VPN exploitant zijn.

En ja, dit gebeurt. Er zijn zat voorbeelden te vinden van ISP's in de VS en andere bananenrepublieken. Ook zou zo'n aanval met een rogue AP kunnen gebeuren.

[Reactie gewijzigd door The Zep Man op 9 februari 2018 17:03]

Dit is al eeuwen zo, zie de enorme markt aan SEO aanbieders ;)

HTTPS kost tegenwoordig niks meer (Let’s Encrypt) en het moet wel gek lopen dat je je website niet kan beveiligen met SSL.

[Reactie gewijzigd door Ventieldopje op 8 februari 2018 23:20]

Correctie:

NU kost het niets enkel manuren en moeite om dingen in te stellen en afhankelijk van de context meer onderhoud.

Dat kan in de toekomst anders zijn.
Nu heb je HTTPS, dat kan in de toekomst anders zijn. Koffiedik kijken of niet? ;)
Zoals ik al zei: afhankelijk van de context.

Bij managed hosting hoef je op zijn minst een keuzevakje / switch om te zetten en je hoster doet al het werk gratis voor je.

Bij unmanaged moet je om de 60 dagen handmatig het Let's Encrypt certificaat vernieuwen als je nog niet weet dat er kant en klare scripts voor zijn die je in je cron oid kan gooien zodat het automatisch gebeurd.

[Reactie gewijzigd door RoestVrijStaal op 9 februari 2018 10:35]

Bij unmanaged moet je om de 60 dagen handmatig het Let's Encrypt certificaat vernieuwen als je nog niet weet dat er kant en klare scripts voor zijn die je in je cron oid kan gooien zodat het automatisch gebeurd.
Dat is wel wat Let's Encrypt zelf onderschrijft in hun FAQ. Uit het gelinkte artikel:
They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t continue to expect system administrators to manually handle renewals.
Als je per sé zelf wilt hosten, moet je dit soort taken ook op je nemen. Als je daar niks voor voelt, kan je beter bij een managed hosting provider blijven waar zij TLS voor je onderhouden.
mogelijk moet je certbot eens onderzoeken... verregaande automatisering van certificaat aanvragen en verlengingen.
Nou ja qua onderhoud zijn er genoeg manieren om dit te automatiseren :P
1. je kan lets encrypt als een service draaien(bestaat dat nog)
2. je kan een reverse proxy gebruiken die dat voor jou regelt(caddy)
3. je kan een script via een cron job laten uitvoeren.
enz.

Je hoeft tegenwoordig niet zoveel moeite meer te doen om een https vebinding klaar te zetten.

[Reactie gewijzigd door vSchooten op 9 februari 2018 10:31]

Ik dacht aan de interne sites van NAS apparaten. Ik ken nog steeds zat mensen die blij zijn dat ze weten hoe hij aan moet...
Of websites intern bij bedrijven.
is de snelheid (laadtijd) van https website ook net zo soepel als met http?
Heel weinig verschil, en met SSL kan je ook HTTP/2 gebruiken waardoor alle verzoeken samengevoegd en in één verbinding verstuurd worden naar de browser waardoor het dan juist weer sneller is.

Hier kan je http 1.1 vs 2 testen: https://http2.akamai.com/demo
Mits je website daarop aangepast is. Met http/1.1 was de trend om alle kleine assets te combineren tot een paar grotere assets, bijv wat webpack doet. Zo hoeft de browser maar een paar wat grotere bestanden binnen te halen i.t.t. veel kleine bestanden. De tijd die het kost om voor elk bestandje een verbinding op te zetten en te sluiten was langer dan het downloaden van een paar grote bestanden.

Met http/2 is dit niet het geval en is het mogelijk om heel snel meerdere kleine bestanden te downloaden. Afhankelijk van de website kan dit veel sneller zijn dan een paar grote bestanden te downloaden.
Je vergeet nog een belangrijke aan de serverside (file_exists) van al die bestandjes (heb zelf een development website en gebruik require in javascript, waardoor het aantal javascript bestandjes zo oploopt tot 80 die allemaal ingeladen moeten worden (daarna uiteraard cachen indien ik er niet aan werk) dit verzamelen in 1 bestand gaat de snelheid van de eerste keer naar beneden halen (gecached moet ook een file exists doen, en die kosten toch een paar miliseconde per bestand (kan wel asynchroon mits je hardeschijf zo snel kan seeken) dus slimme web assets is wel zo handig
Dan kan het geen kwaad om je caching en webserver configuratie eens na te kijken ;) Wellicht nginx gebruiken voor de statische bestanden?
En waarom alleen voor statische bestanden? werkt ook uitstekend met php-fpm als backend. (of andere fastcgi server).
En ook sites die met Symantic 'beveiligd' zijn.

[Reactie gewijzigd door MrMarcie op 8 februari 2018 20:25]

Dit gebeurd nu toch ook al? Aangezien het bij de eerste screenshot voorin de balk staat en hier een veilige pagina is geopend.

Het is wel een hele verbetering als alles via https zal gaan, jammer dat dergelijke certificaten al snel een paar 100€ kosten.
Anoniem: 58485
@Meg8 februari 2018 20:28
Lets encrypt is gratis, en voor iedere hostingboer in ieder geval toe te passen. Het kost dus niets, alleen een kleine handeling zoals de website omzetten van HTTP naar HTTPS, en inline content dus ook, als je bijv. een image in je pagina zet, je de verwijzing van http naar HTTPS omzet. :)
Offtopic: Maar door :// te gebruiken (dus http(s) weglaten, gebruikt je browser het huidige protocol. Zit je op http, wordt de resource over http ingeladen. Zit je op https, dan wordt de resource over https ingeladen.
Je bedoelt //example.com/? "://..." Wordt gezien als een bestand genaamd "://..." in de huidige map.

Als het herschrijven van bestaande http:-links ondoenlijk is, kan een websitebeheerder ook de Upgrade-Insecure-Requests header gebruiken: https://developer.mozilla...Upgrade-Insecure-Requests

OT: in de incognito mode van Chrome wordt er nu al standaard "Not Secure" weergeven bij http:-sites.
Nee hoor.

"//example.com" kijkt naar het protocol wat gebruikt is om de website te laden. Dit kan dus "file", "http" of "https" zijn, waarbij "file" de default is.
Dat kan je middels een header tegengaan, zoals al is gezegd. Daarnaast heb je ook nog HSTS en zelfs HSTS preload waardoor je browser zelf de site al upgrade.

Hoe dan ook hoort dat gewoon op de webserver ingesteld te zijn. Als je op een HTTPS-site een pagina al via HTTP in kan laden, heb je HTTPS verkeerd ingesteld op je site.
https everywhere?...
Bij Vevida moet je 7€ per maand extra (84€ per jaar) betalen voor het pakket (Veilige hosting) waar het dan bij zit. Een optie om zelf je certificaat te uploaden (wat bij Let's Encrypt ook kan) hebben ze niet, dus je hebt alleen maar SSL als je dit pakket neemt, of een duurder pakket. Uit communicatie is mij duidelijk geworden dat ze dit uploaden zelf in de hand willen houden, al dan niet om toch nog geld aan SSL te verdienen. Het Veilige Hosting pakket bevat daarnaast ook 4 weken backups voor je site, dus het is niet enkel voor dat SSL certificaat.

Edit: Foamy hieronder heeft gelijk, het is normaal maar 3€ per maand meer. Ik zat niet op te letten.

[Reactie gewijzigd door mischaatje2 op 9 februari 2018 00:51]

Je kunt altijd CloudFlare gebruiken, dat is een gratis reverse proxy CDN die je gelijk automatisch https aanbiedt.
Crimeflare

http://crimeflare.net:82/cfssl.html

[Reactie gewijzigd door BoozeWooz op 9 februari 2018 08:47]

Dat is ontzettend speculatief. Als het uitkomt dat CloudFlare een plain-text backdoor aanbiedt aan overheden, en dat gaat uitkomen, dan kunnen ze onmiddellijk opdoeken.

Maar het blijft een feit dat ze, omdat ze een CDN zijn, je https-verkeer moeten kunnen ontsleutelen. Als je dermate paranoïde bent dat je daar niet tegen kunt, dan moet je niet bij CloudFlare zijn. Aan de andere kant, kun je Comodo wél vertrouwen?
of je gebruikt caddy als een lokale optie.
Indirect helpt Google dus ook dit soort aasgieren de markt uit. Goede zaak! Dit lijkt me een reden een andere hoster met betere dienstverlening te kiezen. Zelfs Strato (van die vreselijke reclames) bied bij elk pakket standaard SSL aan, vanaf €3 dus.
Wel slechts voor 1 domein. Terwijl je bij alle pakketten behalve de goedkoopste minstens 3 krijgt. Dus je betaald voor meer als je het wil.
Hmm ik zou zeggen dat je dan ook wel een custom cert upload hebt. Hoewel dat inderdaad wat vaag is.
Hm, waar vind je dat dan? Als ik op hun productpagina kijk kun je een hostingpakket voor 2 euro per maand al uitbreiden met SSL..
Je hebt gelijk, ik ben scheel. Ik dacht dat ik (standaard) ingelogd was op een account met een actief domein, maar ik zat op een ander account met een geparkeerd domein.

Die 2€ per maand is normaal 3€ per maand, en komt bovenop de standaard 4€ per maand voor basic hosting. Het neemt overigens niet een aantal andere minpunten weg, maar die doen hier niet ter sprake.
Voor die prijs kun je bijna zelf je hosting doen op Azure/AWS....
keihard wegrennen bij zo'n boer. schande.
Nou mooie reden om die hoster te mijden als de pest dan toch. Het is allemaal gratis te regelen of voor minimale kosten. Dat zij nog extra geld uit je zakken proberen te kloppen voor iets dat anno 2018 gewoon default zou moeten zijn.
Bij Vevida was voorheen het goedkoopste pakket 4 euro per maand.
Daar komen er nu 3 euro bij voor het Security pakket.

Bij Realhosting kan je ook zo een SSL voor 3 Euro p/m er bij nemen.
Ik heb Realhosting een hele poos geleden daarover aangesproken.
Men gaf aan dat zij een aparte server hebben ingericht voor de registratie etc.
En dat zij een soort van beheer pakket bij Lets Encrypt hebben afgenomen. Dat schijnt weer niet gratis te zijn.
Of dit verhaal klopt weet ik niet. Maar ik vond het in iedergeval logisch klinken.

Ik heb dat toen bij Vevida nagetrokken, en ook zij gaven aan, dat zij het niet gratis kregen.
Ze hadden ook gewoon een script kunnen schrijven om Let's Encrypt gratis te implementeren. Ik kan sowieso nergens iets vinden over "Pakketten" bij Let's Encrypt, allicht bedoelen ze een uitbreiding op hun management software, die support toevoegt.
Klopt en de meeste hostingboeren doen dat idd al.
Helaas kwam ik er laatst eentje tegen waar in nog een pakketje had draaien zonder let's encrypt. Dus mail naar support, of ze op directadmin het konden activeren.
Als antwoord kreeg ik dan dat ze geen vertrouwen hadden in let's encrypt en dat het door problemen binnenkort op zwarte lijst zou komen. Ik kon natuurlijk we bij hun voor leuk bedrag een certificaat kopen.
Dat was dus einde hoster per direct en hup pakketje naar ander.
Het kan idd dus gewoon eenvoudig, de meeste doen het maar er zijn nog cowboys die klanten wat wijs maken en hup dik laten betalen.
Die 100 euros zijn dan wel voor van die uitgebreide certificaten zoals je bij banken ziet. Standaard kan het perfect gratis met bv. Let's Encrypt. Zoals Tweakers ook heeft.
tweakers draait op een ESET cert...
Draai je toevallig zelf ESET anti virus software? Zie ik zelf met Bitdefender soms ook. Certificaten die zogezegd van Bitdefender komen.
Is dat waarom ik superveel van Comodo tegenkom? Dat is m'n firewall.
Is mogelijk, maar Comodo is ook een vrij bekende CA, dus er zijn ook redelijk wat legitieme Comodo certificaten in omloop.

TransIP biedt bijvoorbeeld comodo aan bij hun klanten.
inderdaad, niet bij stil gestaan dat NOD32 natuurlijk van ESET is :+
Dat kan maar een ding betekenen, ESET doet een MITM aanval op je HTTPS sessie.....
(stript dus de SSL, bekijkt/bewerkt de data, en plakt er een eigen certificaat op voor doorgifte naar de browser.)

[Reactie gewijzigd door tweaknico op 9 februari 2018 15:08]

Ja, snel uitzetten die functionaliteit dus. Je wordt er niet echt beter van.
Ik weet niet waar jij aan het kijken bent, maar tweakers.net draait toch echt op een certificaat van Let's Encrypt: https://imgur.com/sJ9wllu
Dat vind ik wel heel erg vreemd. Ik testte het namelijk op dezelfde pagina. Precies wat @Slurpgeit zegt. Ik vermoedde dat al, maar wist het niet 100% zeker. Vermoedelijk heb je dus inderdaad ESET-software draaien.

[Reactie gewijzigd door Anonymoussaurus op 8 februari 2018 20:50]

misschien de backuplocatie nog op oude certs, al is het inderdaad vreemd dat de uitgifte datum wel 3 maanden is zoals bij LE gebruikelijk is ;)
ESET SSL Filter in de naam suggereert ook al dat je Eset een root certificaat heeft geinstalleerd om je HTTPS verkeer te scannen, of je dat moet willen is een tweede...
Nee het is echt die malware scannner. Edit: maar dat was al gezegd :P

[Reactie gewijzigd door CurtPoindexter op 8 februari 2018 21:08]

Dan draai je ESET, die gebruikt z'n eigen CA certificaat zodat je verkeer gecontroleerd kan worden op malware.
Kunnen ze lekker MitM'en. Bah.
Dat kan je OS, browser, overheid ook. Al ligt de kans daarop natuurlijk een heel stuk lager. Het zou natuurlijk beter zijn om een trust plugin te hebben om te zien of er malware op de gevraagde URLs zitten, die af en toe worden gescand door clients en geanonimiseerd worden opgeslagen in de cloud.
Sommige antivirussoftware hebben al dergelijke cloudtechnieken.
Ik denk dat een browser, met plugins althans, meer kans heeft om MitM te proberen dan een gerenommeerde virusscanner.
OS niet, Browser wel, of om het beter te zeggen het tool dat de SSL eraf haalt en alles erachter kan het.
OS kan natuurlijk wel processen stilleggen en data afdumpen...., dit "kan niet" is wat kort door de bocht..., maar de data stream is encrypted totdat het in het userproces uitgepakt wordt.
Kunnen ze sowieso wel, ze hebben namelijk gewoon kernel drivers. Als ze echt willen kunnen ze alles van je systeem monitoren, ook SSL voor- of nadat het versleuteld wordt. Alleen is dit de aanbevolen manier van Microsoft. Of je wil graag dat malware ongezien binnen komt, dat moet je zelf weten. Ook command en control servers gebruiken netjes letsencrypt tegenwoordig :).
Dat ESET cert is waarschijnlijk van je antivirus. ;)
@Markimoo En die uitgebreide certificaten waar jij het over hebt heten Extended Validation certificaten. ;)

[Reactie gewijzigd door Anonymoussaurus op 8 februari 2018 20:37]

Apart wel dat Google en MS outlook niet zo'n mooie naam in het groene slotje hebben wat bijv de NPO wel heeft.
Naja google is zijn eigen CA. Dus waarom zou die een uitebreid certificaat nodig hebben waarbij de CA extra goed valideert dat de host ook is wie hij zegt dat ie is. Zou beetje pretentieuze veiligheid zijn waarbij de bakker zijn eign brood valideert op goede ingredienten. Zij zijn de CA, en zij encrypten met hun eigen cert. Dan is in feite elk cert voldoende, aangezien wij als gebruiker zelf zeggen dat we Google vertouwen.
Elk EV certificaat is schijnveiligheid. De laatste die ik aanvroeg kreeg ik zonder een probleem mee, ze hadden volgens mij alleen de whois gecontroleert.

Daarnaast zijn ze vaak lang geldig (jaren) waardoor de onveiligheid alleen maar toeneemt. Bij LE controleer je normaal gesproken elke maand de site.
Dan mag je die CA wel eens rapporteren, want dat is niet volgens de regels van de kunst gebeurd. Telkens als ik een certificaat wens waar EV aan te pas komt moet ik een hoop administratieve hordes nemen.
Ah ja maar bedoelde gewoon de naam echt. Vind het wel echt chique staan ipv alleen een slotje.
Alsof de verklaring wij van wc-eend vinden dat wc-eend... meer chique is als er WC-eend op staat....???
8)7
Nou als ze er een gouden slotje van kunnen maken :)
JAZEUKERSTEWEUTE
Extended Validation wordt door veel mensen niet echt als betekenisvol gezien, terwijl het wel klauwen met geld kost TOV normale certs.
Aah dus 'extended' staat voor de naam achter het slotje?
de extended verification staat als het goed is voor controle bij KvK op bestaan, of de aanvrager tekenbevoegd is etc. etc. naast de controles of website bestaan, mail adres klopt...
Dat kost meer tijd, dus meer arbeidsuren ==> deze certificaten zijn duurder.
Voor de eindgebruiker moet het wel herkenbaar zijn... daarom wordt bij een EV-certificaat de naam die bij KvK is aangetroffen in het certificaat opgenomen.
Nee die heten in Nederland “Uitgebreide validatie certificaten” ;)
Kinda sucks for shared hosting..
eindelijk ook een rede om mijn no-user-input blogje ook maar na 20 jaar op een vpsje van 1$/mnd te zetten.
Gewoon gratis Cloudflare ervoor plaatsen en dat probleem is opgelost.
Dan moet je wel de dns-servers bij je hoster kunnen wijzigen ik stap op bij mijn hostser wat een gammele zooi daar
goed punt inderdaad..
Shared hosting biedt veelal ook gewoon SSL (iig betaalde shared hosting)
Als het goed is niet. de Hostname is zichtbaar in het unencrypted deel van de SSL setup onderhandeling.
dat heet SNI (Server Name Indication) op die manier kan een shared hoster nog steeds het onderscheid maken, en zelfs het juiste certificaat voor een sessie opzoeken.
Techniek is al een jaar of 7 oud, en een sinds jaar of 3 a 4 in gebruik.
Genoeg shared hosting aanbieders (ook in Nederland) die via Lets Encrypt te beveiligen zijn. De certificaten worden op domeinnaam uitgegeven, en er kunnen meerdere domeinnamen actief zijn op 1 IP-adres.

Zie onder andere Antagonist, TransIP, Hostnet en mijndomein.
Met Affiliate code en al in de link :Y)
Dat wist ik dus niet, zo leer je nog eens wat. Thanks!
Is dat een inlogpagina of is het überhaupt een pagina waar je ergens je gebruikersnaam en wachtwoord kunt invullen? Want dat wordt sinds 2016 al gedaan ja: nieuws: Chrome gaat loginpagina's die geen https gebruiken als onveilig markeren
Nee, waren beide normale webpagina's; geen inlogformulier.
Mijn blog heeft ook geen user-input, tis gewoon wat tekst wat ze lezen, niets 'onveiligs' aan en eigenlijk onterecht een melding van 'pas op voor deze enge site hoor' ..

Niet dat ik het niet goed vind, van mij part laden niet eens een site op http meer, maar er zijn heus nog wel sites met static content.
HTTPS is er ook niet alleen om er voor te zorgen dat de client->server verstuurde gegevens veilig zijn, je kunt ook vrij makkelijk een man-in-the-middle attack doen (server->hacker->client), immers is alles wat vanaf jou server naar de client verstuurd word letterlijk plain tekst!

Waardoor ik bijvoorbeeld je website onderkladder bij elk request, of wellicht wat sappige JS inject waardoor JOU website alsnog een shitload aan crap gaat versturen naar zijn visitors..

ben geen hacker, maar reken maar dat er nog veel meer dingen uit te halen zijn via alleen al dat pad:

* mining software injecten
* adware injecten
* JS injecten die gebruik maakt van oude browser leaks waardoor ik alsnog via jou website, de visitor zijn hele PC onder controle krijg en jou URL zal dan bij naam genoemd gaan worden
* een iframe onder je website leg, waardoor ik ze eigenlijk laat klikken op dingen die ze helemaal niet willen
* keyloggers probeer te injecten
* etc

een hacker hoeft in feite alleen 1 van de 'tussen-nodes' te hacken, zoals je router, server, telefoon etc waar je pc mee verbind tot aan de server, via daar alle html etc verstuurd, de hacker die aanpast en weer doorstuurt naar het bestemde adres

of maakt me dit nu een hacker 8)7

[Reactie gewijzigd door DutchKevv op 8 februari 2018 22:28]

Nee hoor, gewoon iemand die meer kennis heeft dan iemand die alleen maar op facebook zit te chatten.

Beetje kennis kan geen kwaad.
De hacker kan ook de wijkkast in en daar een tap leggen :+
Ik weet niet hoe vaak die ook gecheckt wordt maar dat lijkt mij het makkelijkst.
Wel veel grotere pakkans. Die dingen in steden hangen vol met camera's (of in ieder geval de omgeving). En de monitoring zal wel krijsen als die kast open gaat of er iets in/uitgeplugd wordt.
En wat nou als ik op jouw blog opeens een nieuwsbrief-invulveld zie om me te abonneren? Hoe weet ik dan of dat van jouw site komt, of van Henk de Hacker die er tussen zit?
Alleen stuur je met HTTP heel veel informatie mee die privacy gevoelig kan zijn. Ook dat wil je weer niet. Met HTTPS weet iemand die meekijkt alleen maar met welke server je verbinding hebt gemaakt en niets anders.
IP adres + hostname in SNI.
Een ssl certificaat is er vanaf 0 euro. Is vaak makkelijk toe te voegen bij je hostingpakket. En als je een VPS of iets dergelijks hebt is ook het automatisch vernieuwen simpel te doen. Je hebt er na het instellen geen omkijken meer naar.
en op je eigen server is met certbot het onderhoud ook iets waar je nauwelijks of geen aandacht aan hoeft te geven.
Inderdaad, ik had ook al opgemerkt dat Chrome dit al deed. Toen ik naar een normale http pagina ging stond er al "niet veilig". Misschien voert Google het nu meer globaal in.
Zou mooi zijn, maar eigenlijk elke website die ik bezoek heb ik het. :o

[Reactie gewijzigd door Meg op 8 februari 2018 20:37]

Google geeft het nu alleen aan bij formulieren.

Vanaf juli ongeacht wat de content is.
Bij AWS krijg je secure DNS, CDN incl. http2 en security http-headers & certificaat voor ongeveer €0,75 per maand. Heb je direct alles op https://observatory.mozilla.org groen :*)

[Reactie gewijzigd door djwice op 10 februari 2018 21:06]

Ik vind het een beetje vreemd. Heb je een simpele site met portfolio, iig iets zonder user input, dan heb je helemaal geen HTTPS nodig.

Verder kost het best veel, zo'n https hosting.

[Reactie gewijzigd door Menesis op 8 februari 2018 20:49]

Eigenlijk heb je altijd HTTPS nodig ;)

En certificaten zijn pittig veel goedkoper geworden.

Voor mijn persoonlijke pagina draai ik dyndns met een certificaat van Let's Encrypt. Gratis.
En certificaten zijn pittig veel goedkoper geworden.
Gratis ja
En als je het niet gratis wil/kunt/hebt/whatever dan kost een basis SSL je €9,68 per jaar!

Come on folks, er is echt geen enkele reden meer om geen HTTPS te hebben :)
5 euro per jaar zelfs (+BTW) bij Versio.
Jawel. Ik heb hier nog een server draaien met Win2008R2. Ondersteunt geen SNI en dus moet er voor elk certificaat een extra ip nummer aangeschaft worden.

Pas als die server overgezet is naar 2012 of nieuwer krijgen alle webjes een SSL certificaat.
Win2008 heeft al heel lang geen mainstream support meer en de extended support loopt nog 'maar' 2 jaar. Dan wordt het toch echt wel tijd om te upgraden. Je hebt nog een half jaar voordat Chrome gaat melden, dus je moet 1,5 jaar eerder upgraden dan je misschien van plan was.

Gezien de betere functionaliteit van Win2012 zie ik niet in waarom je niet gelijk zou upgraden. Maar goed, dat is weer een andere discussie. Persoonlijk vind ik de reden "ik draai nog oude software dus ik wordt benadeeld" niet helemaal valide.

[Reactie gewijzigd door michaelboon82 op 9 februari 2018 11:37]

Upgraden kost tijd, tijd kost geld.

Er werd gesteld: "er is echt geen enkele reden meer om geen HTTPS te hebben"

Die is er dus wel. En nee, ik voel me nergens benadeeld. Ik geef gewoon de reden aan waarom niet alles op HTTPS draait.
Of je gebruikt een stukje software die WEL SSL/SNI etc. ondersteunt: bv. NGINX of LIGHTTPS op basis can gnutls of openssl.
Die webservers ondersteunen geen ASP.NET en classic ASP en dat is voor de betreffende server nu juist van belang. Geen probleem verder, ik hoef niet alles op https te hebben, komt vanzelf.
Dus het maakt je niet uit dat jan en alleman maar op het draadje in kan haken en mee kan lezen met je?

Wat je leest maakt niet uit, al is het een recept. Het gaat niemand toch wat aan?

Voor elke website heeft het zin ;)
Anoniem: 221563
@Koffie9 februari 2018 00:52
Vreemd genoeg kan de content van een website niet eens van belang zijn. Genoeg andere info die te herleiden kan zijn waar je misschien niet direct bij stil staat. Gezien een SSL zo makkelijk beschikbaar is, is er geen reden meer om het niet te doen. Het is vooruitgang. Stilstaan is achteruitgaan ;)
Eigenlijk heb je altijd HTTPS nodig ;)
Kun je dat nader uitleggen?
Verkeer over http is makkelijker te modificeren door tussenpersonen zonder dat jij merkt dat dat gebeurt. Die hackers kunnen dan bijvoorbeeld content toevoegen met exploids.

Ook kan het zijn dat jij informatie ziet die in jou land heel normaal is, welke door andere landen een 'fout' stempel heeft. Over http zijn meer mensen in staat een profiel van je kijkgedrag op te bouwen. Het kan zijn dat je hierdoor in de toekomst onbedoeld in de problemen kunt komen als je bijvoorbeeld op vakantie of zakenreis bent.

Met HTTPS en FS zullen tussenpersonen met name de domein en timing informatie ontvangen. Potentieel een stuk minder gevoelig.
Dat is waar inderdaad. Aan de andere kant als je via een bedraad of verglaasd netwerk aan het surfen bent is de kans op een MITM aaval erg klein denk ik. In landen als China, Rusland en misschien Turkije zal dat eerder spelen dan hier vermoed ik.

Heel anders is het natuurlijk bij Internet toegang in hotels, vliegvelden (volgens mij op Schiphol ook alle gratis WiFi onversleuteld, ouch) , stations en dergelijke. Daar zou ik niet willen Internet bankieren :)

Ook in sommige aziatische landen is het surfen via een VPN nu al geen overbodige luxe. Denk juist dat DNS informatie erg interessant is om te zien wat iemand op het Internet doet, leuke kleine blokjes data die veel vertellen over iemand zijn interesses.
Tussen jouw internet aansluiting en de website die je bezoekt zitten vaak nog behoorlijk wat internet nodes, denk aan routers, relays en proxies. Ook die nodes kunnen kunnen jou http verkeer aanpassen of bijhouden.

Als ik weet dat jij op nu.nl of tweakers.net komt (DNS), weet ik nog niet welke informatie jij daar bekijkt. Met HTTP ziet de hacker ook de paden en content langs komen, met HTTPS niet.

[Reactie gewijzigd door djwice op 11 februari 2018 13:25]

Je legt uit waarom https nodig is, niet waarom het ALTIJD nodig is. Het ideallistische argument zal dan wel zoiets zijn als: "als iedereen https gebruikt trekt het geen aandacht als iemand het gebruikt die het echt nodig heeft", maar dat gaat volgens mij ook niet echt op.

Verder heb je het over sites met informatie die in sommige landen gevoelig is, maar voor zo'n regime maakt het echt niet uit wat precies de inhoud van de site was, het feit dat je erop geklikt hebt (metadata) is al genoeg en dat is met https ook gewoon te zien.

Overigens zijn er ook gewoon MITM-attacks bekend op een https verbinding, dus als het puntje bij paaltje komt....

[Reactie gewijzigd door mae-t.net op 11 februari 2018 14:44]

Een MITM-attack op een HTTPS verbinding met diverse goede keuzes wordt behoorlijk lastig voor de gemiddelde hacker. Een goed certificaat, DNS CAA, DNSsec, sterke cipher suite, en juiste http-headers voor de website. Geef jij maar aan hoe je dan een succesvolle MITM gaat uitvoeren zonder eerst controle te nemen over de client of de server.

Als je alleen nieuws kijkt over wiet op nu.nl zullen bepaalde landen daar anders op willen reageren dan als je alleen nieuws over CPU's kijkt op nu.nl dus zo generiek is die meta-data ook weer niet.

[Reactie gewijzigd door djwice op 11 februari 2018 16:08]

tegenwoordig hebben alle hosters wel lets-encrypt ondersteuning in hun control panel ergens, en als je zelf VPS hebt is letsencrypt super eenvoudig. Gratis en easy, erg mooi.

Zomaar voorbeelden:
https://www.versio.nl/art...t-certificaat-installeren
https://www.vimexx.eu/hel...op-je-website-installeren
https://www.mijnhostingpa...ts-Encrypt-activeren.html
https://www.neostrada.nl/letsencrypt-hosting.html

[Reactie gewijzigd door afraca op 8 februari 2018 21:04]

Zeker van dat je geen https nodig hebt? Want het doet meer dan alleen maar je wachtwoorden versleutelen.
Ik zie echt het nut niet bij een site die alleen openbare informatie biedt. Dus Yes, leg het me graag kort uit.. :)
Ook wanneer ik een intranet pagina bekijk?
Hoe weet Chrome wat intranet is?
intranet ipranges zijn algemeen bekend.
Man-in-the-middle aanvallen vinden juist vaak daar plaats. (rogue AP/DHCP/DNS etc) De aanvaller zit dan ook in die range. De beste bescherming daartegen is om gewoon echte HTTPS in te voeren. Dus dan is het goed dat Chrome ook waarschuwt als intranetverbindingen onbeveiligd zijn.
Dat werkt dus niet - voor een niet-publieke hostname / IP-adres in een private range krijg je geen SSL certificaat.

De beste oplossing is om zelf een CA op te zetten en op al je lokale machines die toegang moeten hebben deze CA toe te voegen als een vertrouwde CA. Doe je dat niet kun je wel HTTPS aan zetten maar zul je altijd veiligheidswaarschuwingen krijgen voor self-signed certificates.

[Reactie gewijzigd door MadEgg op 9 februari 2018 15:06]

voordeel/nadeel wel is dat dan de point of attack alleen die computer wordt. Dat is natuurlijk makkelijker te beschermen dan meerdere apparaten.
Dat werkt dus niet - voor een niet-publieke hostname / IP-adres in een private range krijg je een SSL certificaat.
Ik neem aan dat je "geen SSL certificaat" bedoelt?

Maar het kan wel.

* Ik heb bij mijn (hosting en) DNS provider zelf A-records aangemaakt voor test.bedrijfsnaam.be, wiki.bedrijfsnaam.be, mail.bedrijfsnaam.be en daar ons publiek IP ingevuld.
Hierbij is mail.bedrijfsnaam.be de enige die écht van buiten te bereiken is, de anderen enkel lokaal of via VPN.
* Ik heb een Virtual Machine geïnstalleerd op een aparte VLAN (enkel internet toegang) die de LE certificaatjes regelt voor de genoemde 3 websites.
* in de firewall ingesteld dat port 80 verwijst naar de LE server en 443 naar de 'echte' mailserver.
* Een cronjob checkt dagelijks of de certificaten vernieuwd moeten worden. Als ze nog minder dan 10 dagen te gaan hebben worden er ook effectief nieuwe aangevraagd.
* Een andere VM in het bedrijfsnetwerk haalt de certificaten op mijn LE-server
* In onze lokale DNS-server heb ik de nodige aanpassingen gedaan zodat wiki.bedrijfsnaam.be etc... naar het juiste interne IP kijkt.

Problem solved.

Geen gedoe met portforwarding of settings wijzigen in de firewall en eigenlijk verder ook geen omkijken naar...

[Reactie gewijzigd door tc-t op 9 februari 2018 13:57]

Je methode werkt wel, maar is een hele hoop gedoe en configuratie wat zeker niet voor iedereen weggelegd is. Daarnaast vereist het wel dat je een geregistreerde domeinnaam hebt (bedrijfsnaam.be), waaronder je zelf hostnames kunt definiëren die ook publiek resolven naar je LE-server (of je kunt een wildcard DNS gebruiken). Dat zijn een heleboel randvoorwaarden die het toepassen van LE-certificaten in een privé-omgeving zeer bewerkelijk maken.

Het voordeel van je eigen CA is dat je de geldigheid van het certificaat gewoon op 10 jaar oid kunt zetten, dan hoef je er ook niet zo vaak mee aan de slag en hoef je het ook niet allemaal te automatiseren hoe jij omschrijft.
Ik neem aan dat je "geen SSL certificaat" bedoelt?
Oeps, inderdaad. Gecorrigeerd.
Je methode werkt wel, maar is een hele hoop gedoe en configuratie wat zeker niet voor iedereen weggelegd is. Daarnaast vereist het wel dat je een geregistreerde domeinnaam hebt (bedrijfsnaam.be), waaronder je zelf hostnames kunt definiëren die ook publiek resolven naar je LE-server (of je kunt een wildcard DNS gebruiken).
Hier heb je uiteraard gelijk.
Het is niet voor iedereen weggelegd, maar het kán wel als je het echt wilt.
Vereist een beetje uitzoekwerk in het begin, maar eens opgezet heb je er niet veel omkijken meer naar.
eh er zijn organisaties die ook intern public IP adressen gebruiken.....
dus dat is geen sluitende test. En ook daar kan HTTPS best helpen.

Aanvulling:
Er zijn voldoende tools waarme je je eigen prive CA in kan stellen inclusief alle updates.
Microsoft levert er een in hun server tools.

Opensource is er ook: Bij openssl CA.pl, TinyCA is een andere.
Voor X gebaseerde systemen is er XCA.

[Reactie gewijzigd door tweaknico op 9 februari 2018 15:34]

Ook daarop kan je een certificaat instellen. Desnoods selfsigned.
Zo heb ik voor mijn localhost (hostname voor 127.0.01) ook een ssl.
Had ik ooit nodig om FIDO U2F protocol te implementeren. Tijdens devven op localhost had ik ook al ssl nodig.
Mooi, alleen misschien onhandig tijdens development, misschien een knopje om het alsnog goed te keuren “dev-mode” ofzo.
Development servers gebruiken vooral 127.0.0.1 / localhost, en die worden niet als onveilig gezien als je ze over HTTP serveert.
Euhm, moet je dat dan ergens instellen ? Niet dat het ergens belemmert maar bij mij staat het toch als onveilig

https://i.imgur.com/lmHDJ5a.png
Dat klopt, maar het "Not secure" stukje komt niet in de adresbalk te staan ;)
Dat kan nu toch ook al? Self-signed certificates kun je accepteren, in forms over HTTP kun je nu accepterne. Je krijgt alleen een dikke vette waarschuwing dat het gevaarlijk is en sterk afgeraden wordt. Als je developer bent weet je wel wat je kunt verwachten en wat de implicaties zijn.
Als de melding in de adresbalk het enige is heb je toch nergens last van als dev? Het is niet alsof ze elke pagina gaan beginnen blokkeren omdat er geen https is. Daar zijn ze nog minstens 10 jaar te vroeg mee.
Wat met appliances in het lokale netwerk? :O
Eigen CA instellen of eenmalig (per device) een self-signed certificaat permanent accepteren. In principe nog veiliger - je wordt er dan direct van op de hoogte gesteld indien het certificaat wijzigt en er dus mogelijk iets niet in de haak is.
Gaat niet met alles... Hotspot portals, byod, mobieltjes, linux clients...
Publiek bereikbare websites allemaal mooi en wel...
Je wordt -1 gemod, omdat je weinig onderbouwing geeft. Het is nu gewoon een set van woorden.

Ingaande op wat ik denk dat jij probeert te zeggen:
Ze worden aangemerkt als onveilig, ze worden niet ontoegankelijk gemaakt.

Hotspots portal kunnen ook gewoon een certificaat serveren, waarom zou dat niet kunnen? Zelfde geldt voor Linux clients. Wat is er met Bring-Your-Own-Device? BYOD? Wat gaat daar dan fout?
Waarom zou dat niet gaan? Een eigen CA is niet al te lastig op te zetten, en de benodigde certificaten kun je gewoon uitrollen naar Appliances, mobieltjes, linux clients via je management tools van de betreffende apparatuur of wanneer nodig zelfs handmatig.
Alleen zeurt android permanent en constant over "uw verbinding kan afgeluisterd worden" zodra er maar een (1) prive certificaat op het toestel staat.
Hmm, die ga ik eens onderzoeken, heb aardig wat toestellen in diverse MDM oplossingen zitten met in sommige gevallen certificaten van een eigen PKI infrastructuur en ben deze volgens mij nog nooit tegen gekomen.
Melding kwam bij mij toen ik CAcert.org certificaat instelde. en voor mn eigen .local domains.
Overigens op een ge-root toestel kun je een module laden om de melding te onderdrukken.
er veranderd helemaal niets daarvoor?

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee