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

Door , , 102 reacties

Vanaf Chrome versie 56 gaat Google websites die wachtwoorden en betalingsgegevens doorsturen als onveilig aanduiden als deze geen https gebruiken. Versie 56 moet in januari 2017 uitkomen. Op den duur wil het bedrijf alle niet-https-sites als onveilig bestempelen.

Chrome gaat vanaf dan rechts naast het informatietekentje in de browserbalk 'Not secure' of 'Niet veilig' weergeven. Op dit moment is de indicatie van een http-pagina nog neutraal schrijft het Security-team van Google op een blog. Bij het weergeven van pagina's met een beveiligde verbinding wordt er een groen slotje weergegeven in de browserbalk.Treatment of http pages by ChromeGoogle had al eerder het plan om een niet-https-pagina als onveilig weer te geven door middel van een slotje met een groot rood kruis erdoor. Dit zou al begin 2016 ingevoerd worden, iets wat tot nu toe niet gebeurd is. Sinds Google startte met zijn kruistocht tegen http-verbindingen zou onlangs een mijlpaal behaald zijn, namelijk meer dan de helft van alle sites die via de desktopversie van Chrome laden, zouden via een https-verbinding geserveerd worden.

De reden dat Google een duidelijker waarschuwing wil geven, is omdat mensen gewend raken aan waarschuwingen en ook het veilige slotje al vaak over het hoofd zien en er niet meer over nadenken. In eerste instantie zal via de normale Chrome-browser alleen een waarschuwing te zien zijn bij pagina's waar gevoelige gegevens ingevoerd moeten worden, maar uiteindelijk wil het overal een waarschuwing tonen. Als de browser in privémodus gebruikt wordt verschijnt vanaf Chrome 56 wel bij elke niet-https-pagina een waarschuwing.

Chrome veiligheid httpsUiteindelijk moet het er zo uit komen te zien

Moderatie-faq Wijzig weergave

Reacties (102)

Hoewel dit idee op zichzelf niet gek is, zitten er wel wat haken en ogen aan. Het zorgt er bijvoorbeeld ook voor dat al je thuisapparatuur die je via een webbrowser kan bedienen over geldige SSL-certificaten moet gaan beschikken (want in ongeldig certificaten worden nog harder afgestraft).

En dat is niet iets dat je eventjes regelt. Want waar halen die apparaten (je modem, tv, AV-receiver, koffiezetter, wasmachine, ...) die certificaten vandaan? Van letsencrypt? Hebben ze daar uberhaupt wel de rekenkracht of geheugenruimte voor? Of voor ssl zelf? Nog los van het feit dat letsencrypt een publiek toegankelijke website verwacht...

[Reactie gewijzigd door ACM op 8 september 2016 19:41]

Het zorgt er bijvoorbeeld ook voor dat al je thuisapparatuur die je via een webbrowser kan bedienen over geldige SSL-certificaten moet gaan beschikken

Waarschijnlijk zal het niet voor intra-net gelden. Zo wordt certifciaat-pinning bijvoorbeeld ook uitgeschakeld bij Chrome voor intra-net ivm anti-malware proxies.
Ik krijg anders wel een melding van Chrome dat de boel niet te vertrouwen is als ik op mijn router in wil loggen.

Gelukkig kan ik daar zonder te klikken voorbij door "badidea" te typen in dat venster. Was eerst "danger" volgens mij.
Ik krijg anders wel een melding van Chrome dat de boel niet te vertrouwen is als ik op mijn router in wil loggen

Omdat routers doorgaans een self-signed certifciaat serveren over de HTTPS site. Log je in op HTTP zal Chrome geen melding geven. En ik voorspel dat dat zou zal blijven op intra-net.
of je zet al je slimme aparaten achter een reversy proxy (bv nginx) en je laat die dan de https verbindingen afhandelen. Uiteraard is dat niet zomaar voor elke thuisgebruiker even te regelen, maar het kan wel. Er zal dan wel ergens een slimmerik zijn die een embedded device (een RPI?) op de markt brengt die een reverse proxy aan boord heeft en waar je met een (over https :p) webpagina kan instellen voor welke interne, niet https verbindingen hij wel httpd moet aanbieden. Niet zo erg moeilijk, gezien de hoge graad van automatisatie die letsencrypt heeft...
Zolang je een uitzondering kan maken voor die websites is het prima.
Maar ook op een lan kan het gevaarlijk zijn of als je je wasmachine over het internet wil gaan bedienen, dus dan is https nog steeds nodig.
Natuurlijk zou het beter zijn als dat soort "IoT"-apparaten ook allemaal goed beveiligd worden. Maar het is wel heel lastig om fatsoenlijke en actuele SSL-certificaten te regelen als er vaak niet eens een domeinnaam aan het specifieke apparaat wordt gekoppeld.

Het gaat nog lang duren voor dat dat allemaal geregeld is, als het ooit gebeurd.
Ik hoop nogsteeds dat Let's Encrypt (of een vergelijkbaar initiatief) zo iets mogelijk gaat maken.
Het probleem daarmee is dat Let's Encrypt bedoeld is om webservers te beveiligen. Hun aanmeld methode werkt met een call naar de website waar dan een beveiligingscode terug moet worden gegeven (zodat je kunt aantonen dat je die website inderdaad onder je beheer hebt).

Sowieso zie ik hier wel een beetje eigenbelang van Google in doorsijpelen. Onder het mom van veiligheid iedereen op HTTPS duwen betekent voor de slager op de hoek gewoon weer kosten. Google is een groot internetbedrijf en dan is het soms lastig om vanuit een klein niet-technisch bedrijf te redeneneren, dus het kan gewoon een blinde vlek zijn. Maar de sites van Google vergroten wel hun voorsprong op die van kleine bedrijven die geen HTTPS hebben.

Sowieso, waarom horen we dit nieuws nu al? Zo snel is Google meestal niet met aankondigen van features. Het lijkt een beetje op een politiek proefballonnetje. Maar waarom zouden ze daar zo mee om gaan? Het kan paranoia zijn maar ik vind het een beetje verdacht dat ze dit zo snel zo ver willen doorduwen. Ze weten als geen ander dat het internet zo traag beweegt als een gletsjer. Grote wijzigingen duren jaren, zelfs decennia. Zie IP6 bijvoorbeeld. Dus die waarschuwing staat straks bij heel veel websites erbij. Maar niet bij die van de tech reuzen natuurlijk...
Natuurlijk zou het beter zijn als dat soort "IoT"-apparaten ook allemaal goed beveiligd worden. Maar het is wel heel lastig om fatsoenlijke en actuele SSL-certificaten te regelen als er vaak niet eens een domeinnaam aan het specifieke apparaat wordt gekoppeld.

Het gaat nog lang duren voor dat dat allemaal geregeld is, als het ooit gebeurd.
Self-signed certificaten die je zelf als vertrouwd installeert in de credentials vault van je browser of OS. Niets moeilijks aan en is hoe dit al jaren werkt.
een simpele en broodnodige oplossing in browsers is naar mijn mening nodig: ssl verificatie uitschakelen in de lokale netwerk segmenten. Het zijn er tenslotte maar 3 en het is makkelijk te identificeren.

Het gebruikers tonen van zoon waarschuwing bij lokale apparaten zorgt er in mijn ervaring alleen voor dat ze de melding niet meer serieus nemen.
Ze zullen wel kijken of er een html input field van het password type aanwezig is. Dus deze melding zal niet enkel op login pagina's gelden maar uiteraard ook op change password pagina's.
Waarschijnlijk is het gewoon hetzelfde systeem wanneer chrome vraagt om je password te onthouden.
Een keurig streven van Google, dat ze wat mij betreft goed staat.

Het mooie hiervan is dat als 1 browser dit doet, alle respectabele website beheerders hier rekening mee gaan houden. Deel van de bezoekers gebruikt immers Chrome en ook die bezoekers moeten de juiste indruk krijgen van hun website.
Dat ze dit doen op een login-pagina kan ik best begrijpen inderdaad, alleen maar goed. Maar dat ze ook het voornemen hebben om dit op ten duur op alle http-pagina's te doen, staat me niet zo aan. In ieder geval in de vorm die ze hierboven beschrijven, 'niet veilig'. Zometeen denkt men nog, als ze een simpele portfolio-site (in http, zonder login o.i.d.) bezoeken en daar staat 'Niet veilig' met een rood uitroepteken, dat hun computer door die website geinfecteerd kan worden door een of ander virus. Want ja, he, het is 'niet veilig'. Vraag me af hoe goed dat uit gaat pakken...

> "Kijk, hier staat 'niet veilig'. Moet ik het dan wegklikken?"
< "Ja nee, er staat wel dat het niet veilig is, maar het is wel veilig."
> "Oh..."
Die website ís dan ook per definitie niet veilig! Of het iets uitmaakt dat hij onveilig is, daar valt over te discussiëren, maar hij ís niet veilig.

Je kunt het vergelijken met een chat: Je denkt dat je met iemand aan het chatten bent, maar je hebt geen flauw idee of die persoon ook echt is wie hij/zij claimt te zijn. Is dat erg? Dat ligt er maar net aan. Is het veilig? Nee, want je hebt hier geen zekerheid.

Stel jij hebt jouw simpele portfolio-site, en jij stuurt daar clienten naar toe. Prima, kunnen ze mooi je websitejes bekijken. Met HTTPS weten ze ook zeker dat ze op jouw geverifieerde domein zitten, en kunnen er dus redelijkerwijs vanuit gaan dat die website ook echt van jou is. Mocht jouw portfolio-site in HTTP informatie bevatten die bijvoorbeeld een regering, instantie, of ISP niet zint, zouden iemand eventueel een MITM-aanval kunnen doen en mensen een andere pagina serveren dan die ze denken te zien. Dat zal voor een simpele portfolio-site wellicht minder snel gebeuren, maar bij andere types websites kan dit wel.

Een onderdeel van HTTPS (of ja, eigenlijk van SSL) is natuurlijk niet alleen het encrypten, maar ook het identificeren/valideren van websites. Ofwel, als je een HTTPS verbinding met bol.com hebt, en het SSL-certificaat is ook van bol.com, kun je er redelijkerwijs vanuit gaan dat je met bol.com praat. Bij HTTP is dat simpelweg maar de vraag omdat je het niet zelf kunt controleren. Ergo: Onveilig.
Eh, https gaat allen of de verbinding veilig is. Of de website veilig is zegt het helemaal niets.

Identificeren? Je weet nog steeds niet wie achter de site zit. Alleen dat het verkeer niet omgeleid is door een derde partij.

[Reactie gewijzigd door leuk_he op 8 september 2016 19:33]

Dus
Identificeren? Je weet nog steeds niet wie achter de site zit. Alleen dat het verkeer niet omgeleid is door een derde partij.
En zelfs dat weet je niet.
Ook de omleidende partij kan natuurlijk gezorgd hebben voor het plaatsen van een valide certificaat, zolang het daadwerkelijke eigenaarschap van een domein niet gecontroleerd wordt.
HTTPS is ook niet per se veilig.. onder andere door de hoeveelheid CAs die iedere browser vertrouwt.
Maar daarmee bepaal je juist of het veilig is.
Het aantal CA's is geexplodeerd en daar er voor de CA's verder ook weinig beperkingen gelden kan je ze steeds minder als Trusted Third Party zien. DigiNotar was daar natuurlijk een goed voorbeeld van, maar ook CA's die niet gehacked zijn kunnen een gevaar zijn. Zo hebben veel landen en banken ook CA's. En je weet nooit wat daar allemaal mee gebeurd.
Ik heb er net zo'n dubbel gevoel bij.

Op zichzelf is de ontwikkeling positief. Zelfs voor een portfolio site. Barrieres worden in rap tempo weggenomen om SSL te implementeren, dus waarom niet?

Waar ik echter een principieel bezwaar tegen heb is dat Google inmiddels een dermate grote macht heeft dat het dit eenzijdig kan besluiten, voor het hele internet. Die waarschuwing dwingt website eigenaren richting SSL. Zo niet, dan moeten die maar op de blaren zitten. Een dik rood kruis door je site of wellicht lager in de index. En niet alleen dat, Google bepaald ook het tempo waarin dit gebeurd.

Nogmaals, het eindresultaat is toevallig goed, maar het is goed om stil te staan bij deze macht. Google bepaald bijvoorbeeld ook of, wanneer en hoe je site "mobile friendly" is. Dat doe je op hun manier. Zo niet,dan dikke minpunten en lager in de index.

En zo kunnen we nog even doorgaan. Bottom line is dat Google de baas van het internet is inmiddels. Website eigenaren moeten Google volgen of anders de gevolgen dragen.
En zo kunnen we nog even doorgaan. Bottom line is dat Google de baas van het internet is inmiddels. Website eigenaren moeten Google volgen of anders de gevolgen dragen.
Dat klopt wel zo'n beetje.

Maar toch is het minder erg dan je denkt. Er is namelijk ruimte voor concurrentie en er is keus. En mensen die Google gevolgd hebben zullen denk ik ook wel gezien hebben dat ze een beetje arrogant aan het worden zijn daar. En hoe raar ook, het is die arrogantie die ook tot de correctie zal leiden.

Chrome is een fijne browser maar je kunt switchen. Op Google Search kun je goed zoeken, maar je kunt ook switchen naar Bing bijvoorbeeld. En dat doe ik dus de laatste tijd steeds vaker. Ik heb gemerkt dat Google soms wel erg veel bias heeft voor hun eigen diensten. Tot op het punt dat ze doodleuk melden dat er geen resultaten zijn als ik hun eigen dienst wegdruk (-youtube toevoegen)... Ga ik dan naar Bing vind ik honderden... wat? duizenden resultaten die Google me niet liet zien. Dus ja ik switch de laatste tijd vaker. En dat kan nog steeds. Gelukkig.
Met alle respect, maar wat je schetst is niet het daadwerkelijke probleem. Jazeker, een gebruiker kan switchen van search engine. Weinigen die dat doen, maar goed, het is mogelijk.

Een aanbieder, een website dus, heeft NUL keus. Je MOET in Google goed gevonden worden anders besta je voor de wereld niet. En als je goed gevonden wilt worden, heb je Googles regels maar te volgen.

En daarom is Google effectief de baas van alle websites. Het heeft de macht om te bepalen of jij bestaat of niet, en het heeft de macht om de complete richting van het internet te dirrigeren.
Je moet in Google gevonden worden, omdat Google de grootste search engine is. Maar als mensen gaan switchen naar andere search engines wordt dat ineens minder belangrijk.

Gaan websites niet mee in Googles ideeen, en gaat Google echt het halve internet als onveilig aanmerken, dan gaan gebruikers denken van nou die Google die snapt het gewoon niet, ik ga maar Bing gebruiken.

Juist als iedereen mee blijft gaan in Googles ideeën blijft Google Search de beste search engine (want websites tweaken hun site zodat hij optimaal in Google Search verschijnt) en blijven mensen hem gebruiken. De content leveranciers kunnen beter een vuist maken dan bezoekers.

Google is Google Search als een soort breekijzer aan het gebruiken. Beetje wat Sony deed met de PS3: BluRay pushen door het op de PS3 te gebruiken... Een nieuw product pushen vanuit een melkkoe product. Een gevaarlijke strategie want meestal niet direct goed voor het melkkoe product.
HTTPS wordt pas relevant op het moment dat er data verstuurd wordt. Ik denk (educated guess) dat Chrome zelfs dan jouw portfolio pagina zonder formulieren niet zal aanmerken als onveilig. Wellicht wel als je daarop ook een contactformulier hebt staan waarin iemand zijn naam invult. En zou dan ook terecht zijn vind ik.

edit: typo
Daar zou ik me ook wel in kunnen vinden inderdaad; maar dan zou 't dus ook niet "alle pagina's" omvatten, zoals nu wel in het artikel & de afbeelding beschreven staat.
HTTPS wordt pas relevant op het moment dat er data verstuurd wordt...
edit: typo
Onzin, zowel versturen als ontvangen doet er toe.
Ja, door een man in the midlle attack kan een virus geïnjecteerd worden in een http pagina.
Met https kan dat niet, dan moet de server gehacked worden, of door een ad-netwerk.
en met die laatste noem je al wat moois, je kunt het hele internet https maken, zodra er maar één verwijzing staat die gekaapt is (al is het maar een ingesloten afbeelding) ben je al de sjaak en vervalt je complete beveiliging....

Https garandeert tot zekere hoogte alleen de veiligheid van de verbinding, niet de content die daaroverheen gepompt word door de server, dat is iets wat veel mensen vergeten.
Maar dat ze ook het voornemen hebben om dit op ten duur op alle http-pagina's te doen, staat me niet zo aan.
Eens! Voor login pagina's? Perfect. Als je dat hebt op je website dien je verantwoordelijkheid te nemen voor de 'veiligheid' van je gebruikers. Maar als je dat niet hebt en je hebt alleen maar kattenfoto's op je pagina staan, waarom moet die dan achter HTTPS? Met bijbehorende kosten / rompslomp van dien? Dit maakt het internet als platform om te publiceren minder toegankelijk voor hobbyisten.
> "Kijk, hier staat 'niet veilig'. Moet ik het dan wegklikken?"
< "Ja nee, er staat wel dat het niet veilig is, maar het is wel veilig."
> "Oh..."
Dat gaat er inderdaad gebeuren dan. En wie wil dat voor zijn website? Niemand.
Het komt eigenlijk neer op een algeheel verbod op HTTP dus.
Ik denk dat het met grootschalige taps ook heeft te maken. Je verstuurt onversleuteld gegevens over een verbinding heen dat getapt wordt. Ook al ben je niet verdacht, het massa opslaan van data over internet wordt nog steeds gedaan.

Big data is waar het op neerkomt, en het is een kwalijke zaak.
Ik ben pro-SSL, maar het dwingende karakter van Google's maatregelen gaat wel erg ver. Gaat het ze echt om de veiligheid en privacy van gebruikers? Of is Google straks de enige die - middels zoekmachine en advertentienetwerken - nog wat gebruikers uitvoeren?
Ik stoor me juist mateloos aan dat webstandaardbemoeien van Google. Vreemde bijeefect is dat je zichzelf hiermee minder en minder relevant maken. Alle kleine web/blog makers jagen ze hiermee naar Facebook omdat die zelf al dit webstandaardgejonas niet meer kunnen bolwerken,
Hele goede zaak! Had wat mij betreft gister ingevoerd mogen worden. Het is natuurlijk belachelijk als een website deze gegevens als plain text doorstuurt.
Het gaat hier over de verbinding tussen de cliënt en de server. Een HTTPS verbinding geeft aan of jij ook daadwerkelijk communiceert met de valide website en niet een website die zich voordoet als [jouw website].

Wat je aangeeft over het versturen van plain text / platte tekst heeft hier in essentie (in dit geval) weinig mee te maken. Een front-end developer in kwestie kan er namelijk gewoon voor gekozen hebben om een bepaald hashing algoritme toe te passen met bijbehorende salt. Deze stap kan gewoon plaatsvinden aan de cliënt side waardoor je het wachtwoord niet als plain text verstuurd.

[Reactie gewijzigd door triplecore op 8 september 2016 19:19]

Maar je ISP ziet dan gewoon welke websites je bezoekt, vind ik niet nodig. Als je een website hebt, heb je de mogelijkheid een gratis certificaat te gebruiken ( Let's Encrypt ). Doe dat dan ook gewoon, want waarom niet?
Genoeg reden waarom men het niet doet. Waarom denk je dat het bij Tweakers zo lang geduurd heeft? Het is niet 1-2-3 geregeld, zeker niet binnen een complexe omgeving.

Bij het maken van een nieuwe website is het idd slim om ervoor te kiezen, maar zelfs daar moet rekening gehouden worden met prestatie verlies. Ook moet je je afvragen of het per se nodig is om alles in https te bezoeken, mij maakt het niet uit of een informatieve website, waarbij ik niet inlog, http of https gebruikt.
Reclame injectie, malware injectie, redirects, analyse door je ISP of provider, ongewilde buffering of downscaling van plaatjes, etc. Wordt allemaal voorkomen.

HTTPS heeft veel voordelen ook voor een gewone website.

Maar met HTTP 2.0 gaan we daar toch heen, want de non-TLS variant bestaat welliswaar op papier maar geen van de grote techbedrijven heeft aangegeven dit te gaan ondersteunen.
Misschien overbodig om te zeggen, maar zelfs met HTTPS kan een ISP zien welke sites je bezoekt. Niet de exacte URL, maar zeker wel de hostname.

Vergeet niet dat ISP's ook gewoon de DNS servers en het DNS verkeer regelen voor de meeste mensen. Daarbij maken praktisch alle sites tegenwoordig gebruik van SNI, wat de hostname van een website ongecodeerd verstuurd.

Zelfs al doe je alles over HTTPS, je ISP kan met DPI makkelijk zien welke sites je bezoekt. Voor bezoekers van sites als tweakers.net zal dat geen groot probleem zijn (de site gaat over ICT, maar je kan net zo goed een pagina bezoeken over hacking, games of de pricewatch bijvoorbeeld), maar voor bezoekers van sites als uitdekastkomen.nl en erectieproblemen. nl wordt het een heel ander verhaal. Dan is een lekkende hostname eigenlijk al te veel.

Als je veilig wilt browser ben je beter af met een VPN bij een bedrijf dat als business model heeft niet te monitoren, alhoewel je dan in feite alleen het probleem verplaatst.
DPI is verboden in Nederland, dus daar ben ik niet zo bang voor.
Als er clientside gehasht wordt is die hash dus effectief het password geworden. Als de hash onderschept wordt kan daarmee dus gewoon ingelogd worden.
tweakers heeft ook pas een paar maanden https 8)7 , en dat is zelfs een website specifiek gericht op techniek.
Op de inlog pagina al veel eerder.
Artikel geeft aan dat chrome ALLE paginas duur gaat blokkeren zonder https.
Dat had wat mij betreft ook veel eerder kunnen zijn hoor, ik begrijp niet of je comment als verzachtend bedoeld was of niet...
Ik bedoelde dat bedrijven het niet als zelfsprekend nemen. Als tweakers dat regelmatig over hacks/lekken rapporteert er al niks aan doet laat staan een persoonlijke pagina die 5x per dag bezocht wordt.
Prima ontwikkeling. Niet-encrypted verkeer moet zo snel mogelijk worden uitgefaseerd. De talloze schandelen en gevallen van privacy-inbreuk hebben daar de noodzaak wel van aangetoond.

Privémodus of niet, login pagina of anderszins, ik hoop dat op den duur al het HTTP verkeer alleen nog met SSL plaatsvindt.
Hoewel ik het op zich wel met je eens ben, zijn veel - zo niet de meeste - van die talloze, bekendgemaakte voorvallen voortgekomen uit iets anders dan een onveilige netwerkverbinding. Vaak uit gebrekkige beveiliging bij de websites zelf, die niet of nauwelijks te voorkomen zou zijn geweest met het gebruik van HTTPS.
Met HTTP/2 is het waarschijnlijk ook de defacto standaard. Het protocol vereist geen TLS 1.2 of hoger, maar de meeste browsers wel.
In lijn ogen is het duur en niet haalbaar voor sommige kleine spelers om https aan te sxhaffen, of ben ik hierin mis? Klopt het dat ik dan zeg dat Google de dood wil voor de kleine websites?

(Dit is een open vraag waarbij je me misschien het tegendeel kunt bewijzen?)

[Reactie gewijzigd door MrAndy9797 op 8 september 2016 20:29]

Prima vraag. Vroeger had je gelijk had want dan moest je de kosten ophoesten voor een SSL certificaat bij een van de gevestigde spelers en dan kostte dan wat euro's. (Hoewel huidige prijzen al lager zijn, 10 euro bijvoorbeeld.)

Tegenwoordig heb je de optie om gratis een SSL certificaat te krijgen bij Let's Encrypt (LE).
Je kan dan dus gratis je website via https laten verlopen met zo'n door hen uitgegeven certificaat.
Het enige dat je zelf nog moet doen is de implementatie.

Nu kan dat overweldigend overkomen maar eerlijk gezegd: als je je eigen website beheert dan zijn de handleidingen en geautomatiseerde bot die LE aanbiedt best goed te gebruiken. Binnen no time heb je het draaiend.

Dus nee: kleine websites hoeven niet dood in Google's optiek lijkt me. Wel zal je als website-beheerder iets meer moeite moeten doen dan alleen af en toe een berichtje schrijven.
Maar eerlijk gezegd is dat niet verkeerd: immers zou je ook al ervoor moeten zorgen dat je je software up to date houdt. Het gebruik van iets als LE is dan niet echt veel meer moeite/een grotere stap, los van het feit dat het niet verkeerd is verantwoordelijkheid te nemen voor je eigen site(s).

[Reactie gewijzigd door neokarasu op 8 september 2016 21:36]

Letsencrypt... veel hosts bieden het al aan. Zelf fixen is niet veel werk.
Maar dat gebeurde toch al?

https://portal-lln.hetassink.nl/Pages/Default.aspx In chrome krijgt mijn schoolshite al een jaar lang een slot met een kruisje.
Dat komt doordat het SSL certificaat nog een SHA-1 algoritme gebruikt en dat is al een tijdje (aantal jaar) niet meer veilig. Risico als je school een certificaat van 5 jaar afneemt ...
Tja, risico... een re-issue is doorgaans gratis en 5 minuten werk. Gewoon domme beheerder.
Gewoon domme beheerder.
Een op het kantje crimineel nalatige beheerder als het een omgeving is waar persoonsgegevens op verwerkt worden.
Maar een HTTP-verbinding is toch niet per definitie niet veilig? Dat zou betekenen dat wanneer je naar mijn persoonlijke website gaat, waar je verder niet op in kunt loggen,waar geen cookies gebruikt worden en waar geen advertenties op staan, opeens onveilig zou zijn? Dat is gewoon keihard mensen voorliegen :/
Je ISP kan wel exact zien welke pagina's worden bezocht met HTTP. Met HTTPS is dit alleen het domein
Het domein kunnen ze alleen zien als jij de DNS server gebruikt van de ISP. Je kunt met HTTPS enkel zien met welke server en welke poort je verbonden bent, de gehele HTTP header (waar de domein, of Host, onderdeel van is) gewoon is versleuteld. Het is vaak wel enigszins te raden welke domeinnaam het is aan de hand van het IP adres van de server, omdat veel servers per HTTPS domain een ander IP adres gebruiken.
Om meerdere domeinen op een server te kunnen draaien met HTTPS wordt veel gebruik gemaakt van SNI en dan kun je wel degelijk het domein zien.
Kleine nuancering aangaande die "en dan". Om SNI te laten werken moet de client sowieso de hostname opsturen. Maar de client weet niet of een server van SNI gebruik maakt, dus die zal de hostname dan ook standaard altijd in plain text meesturen, ookal gebruikt de server in kwestie geen SNI. De praktijk is dus dat je gewoon altijd de hostname kunt intercepten.
Ben bang dat je mensen hier toch op het verkeerde been zet. Bij zowel NPN en ALPN is de domeinnaam te achterhalen. Bovendien is ALPN min of meer verplicht aan het worden omdat je anders geen TLS False Start en andere optimalisaties kan gebruiken.
9 van de 10 sites lekken die info juist met google analytics naar Google.
Stel je logt in op een HTTP pagina, dan is je verkeer niet versleuteld. Je hoeft het verkeer dus alleen te onderscheppen om te kijken welk wachtwoord diegene heeft ingetikt.

Cookies en advertenties staan hier los van.
Behalve dan dat mijn website geen mogelijkheid biedt tot inloggen ;)
Nee, dat is een gratis man in the middle attack die door de eindgebruiker niet gedetecteerd gaat worden ;)
Het is onveilig omdat het wachtwoord doorgaans in dit geval onversleuteld verstuurd wordt. Iemand op het netwerk die het verkeer beluistert ziet dus het wachtwoord. Wat natuurlijk heel simpel is, zeg in de trein.
Een HTTP-verbinding is niet per definitie niet veilig (althans, voor sommige definities van veilig), maar jij kan niet vaststellen dat er daadwerkelijk niet is afgeluisterd of gegevens zijn aangepast. Met HTTPS heb je op zijn minst een wiskundig bewijs dat dit hoogstwaarschijnlijk niet kan gebeuren.

[Reactie gewijzigd door Zr40 op 8 september 2016 19:02]

Het gaat alleen over de privemodus. Die gebruikt het gross toch al niet.
Maar een HTTP-verbinding is toch niet per definitie niet veilig?

Klopt, daarom ben ik niet zo blij met het plan om alle HTTP als onveilig te bestempelen. Boy Cry Wolf.

Doch in dit geval gaat het om inlog pagina's. Dan lijkt me de waarschuwing juist wel op zijn plaatst.
Op termijn alle http pagina's als onveilig staat er ook...
Ja oké, maar wat is op termijn? Als ze dat over zeg 1 jaar doen, dan mag ik toch wel aannemen dat iedereen die iets met websites te maken heeft even de moeite neemt om een Let's Encrypt certificaat aan te vragen? Nu weet je dat het er aan komt!
Ja oké, maar wat is op termijn? Als ze dat over zeg 1 jaar doen, dan mag ik toch wel aannemen dat iedereen die iets met websites te maken heeft even de moeite neemt om een Let's Encrypt certificaat aan te vragen? Nu weet je dat het er aan komt!
Ik draai voor mij persoonlijk wat webservices ( spotweb, sabnzb en dergelijken ) die niemand kunnen bereiken, behalve ikzelf.
Ik heb geen zin om een certificaat aan te vragen, en elke x maanden te moeten updaten.
Maar ondertussen krijg ik op elke locatie dus te zien dat ik onveilig kan zijn ...

Kijk, voor een publieke service kan ik het me indenken, maar op privedomein en structureel minimale toegang ... pff
Ik weet niet hoe je die dingen draait, maar Lets Encrypt is gewoon te automatiseren
Ik begrijp je goed. Wel wil ik opmerken dat - afhankelijk van je webserver - letsencrypt volledig automatisch de certificaten update. Eenmaal geïnstalleerd heb je er geen omkijken meer maar.
* FreshMaker draait het op een XPenology.

Zal me er eens voor zetten dan, om het zover te krijgen ... ooit ... :+
Maar ondertussen krijg ik op elke locatie dus te zien dat ik onveilig kan zijn ...
Er zijn natuurlijk nog andere browsers... Dus het hoeft niet ;)
Veel hostingpartijen leveren dure SSL certificaten met een leuke marge. Ik vraag me af of zij Let's Encrypt aanbieden. En de mensen met een kleine portfolio website of een blogje voor de kerstkaartenclub zullen er verder 0 verstand van hebben. Edit: zij hebben geen idee dat dit eraan komt, maar zullen wel denken "oh help mijn website is gehackt!". Bron: jarenlange ervaring met website-eigenaren :P

[Reactie gewijzigd door Zenomyscus op 8 september 2016 19:34]

Ik heb recentelijk met CCCHosting het hier over gehad. Ik gebruik daar voor meerdere websites DirectAdmin en dat biedt nu ook support voor Lets Encrypt.

Na wat emails heeft CCCHosting voor alle klanten de optie Lets Encrypt (gratis) aangezet. Je moet alleen zelf aangeven of je SSL wilt gebruiken of niet. Maar zie bieden dus de optie, samen met het automatisch vernieuweren.

Bij een andere hostingpartij heb ik dit ook aangekaart maar die hebben het vooralsnog niet aangezet.

[Reactie gewijzigd door RobinF op 8 september 2016 20:05]

Ik vraag me altijd of wat de beweegreden is voor hosters om Let's Encrypt te ondersteunen. Ik werk met een paar hosters en eentje biedt bijvoorbeeld Let's Encrypt aan waardoor ik alle sites die ik daar heb achter TLS heb gestopt. Een ander doet dat niet en daar betaal ik nu £59 per jaar om een enkele site achter TLS te hebben.

Ik vind het allemaal prima dat ik bij de ene niet hoef te betalen. Toch vraag ik me af waarom je als hoster jezelf in de voet zou schieten door Let's Encrypt te ondersteunen? Zouden de kosten van het beheren en regelen van al die certificaten dan eigenlijk niet opwegen tegen de baten?
Zullen die hosters zoveel verdienen aan die certificaten die ze (door)verkopen aan jou?
Een goede hoster biedt gewoon support op o.a lets encrypt. En zeker als je een eigen (VPS) server hebt, kan je gewoon installeren.

Echter de crue is dat betaalde certificaten natuurlijk een bepaalde standaard en hoge security hebben. Lets encrypt is nieuw, en het kan zomaar zijn dat er een exploit tegen betaling voor is om dat HTTPS van lets encrypt te onderscheppen.

Voor een kleine website ga ik geen premium SSL voor neerlappen, maar bij grote websites wel.

We gaan dit straks ook stapsgewijs op meer dan 1000 websites loslaten onder mijn beheer (lets encrypt) voor de sites die of een login of 'persoonlijke gegevens' verwerken maar de kosten het niet opwegen tegen de baten. De grotere sites krijgen gewoon een premium certificaat.

Zou wel gek zijn als ik voor ruim 2500 sites even een HTTPS "moet" aanschaffen omdat google z'n standaarden even aanpast.
op termijn wil google gewoon dat mensen standaard https gebruiken, de reden lijkt me duidelijk, 1 simpel wardriving scriptjes en je kunt precies zien waar mensen naar zoeken, (google), welke pagina's ze lezen (wiki) en dus binnen no time, of je ze moet zien als potentiele moslim-terrorist (op basis van totale arbitraire filters waar niemand ooit inzicht in heeft... als dat geen 1984 is dan weet ik het niet meer..

en laten we eerlijk zijn, hardware is tegenwordig meer dan snel genoeg om een simpele 128bit key hardwarematig te versnellen, en voor login en overige 'gevoelige gegevens kunnen we ook nog prima naar 2M keys.
Nouja, uit het artikel, he ;) .
In eerste instantie zal via de normale Chrome-browser alleen een waarschuwing te zien zijn bij pagina's waar gevoelige gegevens ingevoerd moeten worden, maar uiteindelijk wil het overal een waarschuwing tonen.

[Reactie gewijzigd door marcovo op 8 september 2016 18:54]

"Op den duur wil het bedrijf alle niet-https-sites als onveilig bestempelen."
"Als de browser in privémodus gebruikt wordt verschijnt vanaf Chrome 56 wel bij elke niet-https-pagina een waarschuwing."
Vanaf Chrome versie 56 gaat Google websites die wachtwoorden en betalingsgegevens doorsturen als onveilig aanduiden als deze geen https gebruiken. Versie 56 moet in januari 2017 uitkomen. Op den duur wil het bedrijf alle niet-https-sites als onveilig bestempelen.

het dik gedrukte gedeelte. Dus in versie 56 alleen in privé modes. In versie(nog te noemen) ook de normale modus. En elke non https website.
Zo jammer dat encryptie en identificatie op een hoop wordt gegooid,
Encryptie is iets wat je altijd moeten moet willen.
Identificatie (de zekerheid dat je met een bepaalde site geconnect bent) is soms bijzonder belangrijk, maar vaak ook totaal niet.
Met het huidige https protocol wordt dat helaas op een hoop gegooid.
Vind dit wel een goede ontwikkeling.
Nu overheden druk aan het lobyen(?) zijn om achterdeuren in te bouwen. Ook is het nu nog zo dat je als je https gebruikt JE DUS IETS TE VERBERGEN HEBT. (in hun retoriek).
En als alles zo over https gaat is er geen onderscheid meer en dus onmogelijk om nog te discrimineren.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True