Google wil begin 2016 waarschuwing bij elke niet-https-site in Chrome tonen

Google werkt eraan om Chrome standaard aan te laten geven welke sites geen versleutelde verbinding bieden. Bij sites zonder https-verbinding toont de browser dan een rood waarschuwingskruis naast de url. Begin dit jaar moet de functie in de browser komen.

Bij een presentatie tijdens de Usenix Enigma-beveiligingsconferentie in San Francisco stuurde Chris Palmer, security engineer bij Google, een afbeelding van de New York Times-website, waarbij het rode kruis naast de url te zien was, met de belofte dat er meer op komst is. Zijn collega Parisa Tabriz liet daarop weten: "Http, we werken eraan om te laten blijken wat je bent: niet-veilig". Standaard toont Chrome een blanco pagina bij http-sites, maar Google wil af van dit 'neutrale' icoontje.

Het plan om sites die geen https-verbinding ondersteunen als 'niet-veilig' aan te duiden in Chrome is niet nieuw: dit werd eind 2014 al bekendgemaakt, met de belofte dat er in 2015 een overgangsplan zou komen. Daarna bleef het stil tot Palmer eind 2015 bekendmaakte dat het streven was om het begin 2016 uit te voeren, met een verwijzing naar een blogpost waarin staat dat er uiteindelijk twee aanduidingen over moeten blijven: veilig en niet-veilig. Vorige week is daarop het streven opgenomen in de issues-lijst van Chromium, wat erop duidt dat de waarschuwing inderdaad op weg is naar integratie in de browser.

Overigens is de functionaliteit al meer dan een half jaar handmatig te activeren in Chrome, door via chrome://flags "Niet-beveiligde beginpunten markeren als niet-veilig" te selecteren.

Reacties (199)

Boy Cry Wolf

Immers HTTPS is de toekomst zeker ivm HTTP 2.0 wat geen non-HTTPS variant kent, maar er is een groot verschil tussen een site die geen security gebruikt, en een site die wél security gebruikt en waarbij er expliciet iets mis is met de security. Denk aan een ongeldig certifciaat.

Als nu elke gewone website een rood kruis geeft, zal de gemiddelde gebruiker ook niet meer blikken of blozen als opeens hun bankwebsite ook een rood schild/kruis/waarschuwing geeft ...

HTTP 2.0 wat geen non-HTTPS variant kent

Dit klopt totaal niet, de HTTP 2.0 spec omschrijft heel expliciet hoe een niet beveiligde verbinding zou moeten werken. Browser makers zijn alleen eigenwijs genoeg om niet de volledige spec te implementeren... iets wat ze doen omdat ze het insecure web willen deprecaten door coole nieuwe functies alleen beschikbaar te maken op HTTPS sites . Op zich ben ik een voorstander van het pushen van HTTPS en ben het ook zeker niet eens met anderen die vinden dat HTTPS niet boeit voor de meeste sites (statische sites zijn een zeldzaamheid en zelf daar wil je liever niet dat iedereen zomaar de content van die statische sites kan veranderen puur omdat ze tussen jouw en de site zitten). Niettemin kan ik me echt niet vinden in de manier hoe HTTPS nu gepushed word... eerst in Chrome 46 verhoogden ze al de eisen voor HTTPS en nu slaan ze daar nog veel veel verder in door.

En als mensen beginnen over dat Letsencrypt zo makkelijk is: Ja, als je een Apache server hebt is het inderdaad makkelijk. Gebruik je alles behalve Apache dan gaat het verre van makkelijk. Laatst op nginx+node een Letsencrypt beveiliging willen gebruiken waar node geen files serveert... de tooling die specifiek voor node is werkt niet (als in, is een third party tool die momenteel een bug bevat) en de setup die je met nginx normaal gesproken zou gebruiken om te bewijzen dat je domein van jouw is, is bedoeld voor als je statische files serveert. Met andere woorden, tijdens iedere renewal moet m'n server voor een kleine tien minuten uit de lucht gaan en de maximum certificaat expiration is 90 dagen... en ze willen dat ook nog eens gaan verlagen (voor begrijpbare beweegredenen, maar het is dezelfde super pushy stijl van security opdringen ) .

PS. Mijn gehele verhaal is zwaar gekleurd door m'n frustraties met Letsencrypt En het feit dat ik HTTPS nodig had om Serviceworkers (een andere dergelijke coole nieuwe feature) te gebruiken. Trouwens, hier staan m'n ervaringen met HTTP/2 + Polymer mocht iemand dat gebruiken.

[Reactie gewijzigd door David Mulder op 28 januari 2016 23:14]

Ik zit niet in de web(hosting) wereld dus het kan zijn dat ik iets mis, maar als http/2 dezelfde soort certificaten gebruikt als https nu dan kunnen de kosten van de certificaten toch geen issue meer zijn, een domain validated single domain cert kost nu €8 euro per jaar bij mijn standaard certificaat boer (met zelfs nog korting als je voor meerdere jaren besteld), een organisatie validated certificaat €35 geloof ik, en een extenden validation cert (voor de groene balk) uit mijn hoofd iets van €100 per jaar.

Als ik dat soort bedragen zie, dan lijkt mij letsencrypt momenteel alleen alleen echt interessant voor hobby sites, daar je zeker wanneer je extra moeite moet door voor de implementatie het mij lijkt dat dit al snel meer kost dan een certificaat van een traditionele certificaat boer tot dat letsencrypt echt ingeburgerd is en standaard te gebruiken is op alle services, als dit al gaat gebeuren. Wij gebruiken certificaten vooral voor Exchange, Firewalls, VPN Appliances, extern te benaderen applicaties. ik heb nog geen aanwijzing gezien dat letsencrypt ook hiervoor beschikbaar gaat worden zonder omwegen te moeten gebruiken met een linux client en dan te exporteren / importeren, wat momenteel meer tijd / geld kost dan gewoon op de appliance / in de applicatie een CSR te maken, deze in te dienen en de paar euro te betalen.

Het installeren van een letsencrypt certificaat via mijn plesk panel kost mij per domein 1 click op de knop. Duurt ongeveer 10 seconden en €0,00

Het kopen van een certificaat en installeren in Plesk duurt al snel 10 min en €9,00.

Dan heb je het certificaat wel, maar dat duurt maar 90 dagen, dus je moet of iedere 90 dagen het met de hand in je software gooien of het automatiseren (<- wat dus het idee is), maar dat automatiseren loopt nog een beetje stroef hier en daar.

Daarom is dat in Plesk (voor Linux) geautomatiseerd, hoef je niets voor te doen!

Link: https://ext.plesk.com/pac...-d26a0183a8dd-letsencrypt

[Reactie gewijzigd door Timo002 op 29 januari 2016 09:17]

Niks 'op plesk is het geautomatiseerd', Plesk doet dus uiteindelijk niks meer en niks minder dan een GUI voor de officiële Letencrypt-auto CLI te bouwen. Leuk en wel, maar dat is totaal nutteloos voor mensen die niet apache gebruiken of een erg simpele site hosten.

De extensie stelt een cronjob in die elke maand de certificaten vernieuwd. Heb het zojuist getest en het werkt perfect, alle certificaten zijn vernieuwd.

Het klopt dat dit inderdaad alleen voor Plesk op Linux is, en dan ook nog een versie 12.5+ en je moet de mogelijkheid hebben om extenties te kunnen installeren. Dus weggelegd voor een erg kleine groep. Maar als je hier aan voldoet kun je nu wel erg eenvoudig al je websites / subdomains beveiligen met een certificaat.

Naja, en binnen dat alles moet je dus ook nog eens Plesk gebruiken in combinatie met Apache. Zover ik weet is dat niet per se verplicht en kan Plesk in principe ook met andere backends werken. Maar goed, geen serieuze ervaring met Plesk. Punt is alleen dat die het hernieuwen van die certificaten requests moet kunnen afhandelen op jouw server en daarvoor heb je dus uiteindelijk server specifieke plugins nodig.

...op Linux platformen . Ken iemand met een Windows based Plesk waar ik een domeintje host en daar werkt het dus niet.

[Reactie gewijzigd door Cilph op 29 januari 2016 08:40]

Het automatiseren op een linux server is op zich slechts het opzetten van een cron-job.
Ik ben er 5 minuten mee bezig geweest en nu wordt op de server iedere week gechecked of het certificaat vervangen moet worden, om dat vervolgens te doen.
Het grootste probleem wat er nu is, is dat de integratie momenteel vooral op *nix gericht is en de apache integratie de meest volledige is.
Gezien nginx integratie nog niet vertrouwd wordt door de makers zelf, betekent dit voor mij (nginx gebruiker) dat ik nginx uit moet zetten voor ik letsencrypt laat updaten.

edit: typo

[Reactie gewijzigd door MucGhuine op 29 januari 2016 08:46]

Naja, in die cron job moet je op de een of andere manier ACME validatie draaien, iets wat alleen kan als je ergens makkelijk de juiste bestanden kunt serveren. Iets wat verre van makkelijk is als je uberhaupt geen bestanden serveert.

Mijn cron-jobje is 5 regels (als ik apache zou draaien zelfs maar 3), maar inderdaad, letsencrypt gaat er van uit dat het proces van de renew (tijdelijk) iets beschikbaar kan zetten op poort 80 en/of 443.

Reden dat ik destijds van startssl naar comodo ben overgestapt is dat ik certificaten voor 3 jaar aan kan vragen. Van 90 dagen word je gewoon gek als je dat voor een aantal klanten beheert.

Uiteraard zal letsencrypt in bepaalde situaties al prettig werken en een kosten besparing zijn. Maar zodra er "handwerk" (niet standaard inrichting van je webservers, Appliances/Software waar je alleen via omwegen certificaten voor kan aanvragen en meer van dat soort zaken), voor nodig is dat meer is dan 1 klik op de knop iedere 90 dagen zie ik de besparing nog niet en dat zijn toch de meeste situaties die ik tegen kom in mijn vakgebied (en schijnbaar in de hosting wereld ook wanneer je geen plain apache gebruikt maar bijv een aaneenschakeling van verschillende stukken software voor je hosting).

Zoals hierboven geantwoord, in plesk is dat geautomatiseerd. Je hoeft er niets voor te doen!

Oke en nu voor 8 nassen en 35 servers. Daarnaast moet je handmatige voor elke iets doen voor implementeren oftewel ben je blij als je een wildcard hebt en dan moet je nogmaals de prijzen bekijken. En dat vergelijken met hosting.

Wildcard is €75 tot €215 (niet beschikbaar voor EV certificaten) nog steeds niet wereldschokkend duur, letsencrypt doet trouwens alleen de goedkope variant van €8 per jaar (org validated en EV zijn niet beschikbaar, dus pech als je die nodig hebt, dan is letsencrypt sowieso geen optie) en geen wildcard, dus voor Letsencrypt ben je tot alles daadwerkelijk volledig werkt en geautomatiseerd is voor alle platformen sowieso die tijd kwijt, dus dan lijkt mij het kopen van een Wildcard alleen maar kosten besparend tot Letsencrypt volledig ingeburgerd is, en standaard te gebruiken op alle platformen zonder omwegen, extra inrichting die extra tijd = geld kosten (stel dat ik bij een klant LetsEncrypt zou gaan inrichten op zijn webserver, en dat dit mij een uur kost voor de web(servers) die zijn domain serveren, voor dat zelfde geld zou hij ook voor de komende 15 jaar iedere 3 jaar een domain validated cert kunnen kopen van €20 per jaar).

Als je flink meer domeinen hebt dan zal het sneller een besparing worden, ben ik het zeker mee eens.

Neemt niet weg dat Letsencrypt een zeer mooi project is, maar imho zijn er nog wel wat hobbels te nemen voordat het daadwerkelijk in alle situaties (vooral zakelijk) een goed werkend alternatief is voor alle zaken die een certificaat vereisen / het handig is een certificaat te hebben.

[Reactie gewijzigd door Dennism op 29 januari 2016 00:51]

Dat is mijn punt inderdaad het is een mooi initiatief maar voor het echt de norm is zal nog wel even duren. Op de lange termijn is Letsencrypt goedkoper maar heb maar weinig klanten die de manuren er voor willen betalen.

Verder ben ik inderdaad wel voor om zo veel mogelijk sites of servers met certificaten uit te rusten, maar het is helaas wel schijnveiligheid. Een goede proxy er tussen met https en cert kan net zo goed en niemand die het domein valideert in het certificaat.

Naja, die korte validatie duur zou je eigenlijk dus overal willen hebben, dus rondklooien met automatische renewals zal wel de norm worden alhoewel tegen die tijd de tooling vast goed genoeg is. Hoe dan ook, in mijn geval had ik zeker liever $8 voor een certificaatje betaald als ik had geweten hoe lastig het ging zijn. Het is meer dat het standaard excuus voor HTTPS verplicht maken is: 'het is toch gratis en super makkelijk nu'. Iets wat maar gedeeltelijk waar is.

En wie is je standaard certificate boer ..?

Voor de meest standaard zaken bestel ik normaliter Comodo certificaten bij sslcertificaten.nl tenzij de opdrachtgever anders vereist.

Thnx, ik wel eens gezocht maar kon geen fijne of goed geprijsde vinden

En als mensen beginnen over dat Letsencrypt zo makkelijk is: Ja, als je een Apache server hebt is het inderdaad makkelijk. Gebruik je alles behalve Apache dan gaat het verre van makkelijk.

Er is inmiddels een hele riedel alternatieve clients geschreven. De belangrijkste vooruitgang voor mij is dat je nu ook DNS-validatie kan doen. Het is dus niet langer nodig om je webserver offline te halen. Je hebt geen webserver meer nodig; het is zelfs helemaal niet meer nodig dat je machines bereikbaar zijn via internet.

Ik probeer je verhaal niet te ontkennen, ik ben het met je eens dat letsencrypt is nog niet klaar voor algemeen gebruik. Ik sta echter wel achter de grote push richting HTTPS, er is een grote achterstand in te halen. We zullen sowieso nog jaren met HTTP blijven zitten, hoe langer we de overgang uitstellen hoe groter het probleem wordt. Zo'n waarschuwing van Chrome betekent nog niet dat je geen HTTP-sites meer kan bezoeken. Omdat niemand last heeft van die feature (afgezien van een lelijk rood kruisje) heb ik er geen bezwaar tegen een snelle invoering.

Dat is sowieso geweldig nieuws, heb je toevallig goeie linkjes naar documentatie betreffende hoe dat in z'n werk gaat of welke tools er zijn die met DNS validatie werken? M'n DNS provider heeft een uitgebreide API, dus ik zou graag naar DNS validatie overstappen, maar als ik er naar Google kom ik alleen de spec tegen. Alles wat ik nodig heb is een CLI om het record te genereren die ik in m'n DNS zou moeten zetten~ maar kan nergens zo iets vinden.

En trouwens, met deze verandering van Chrome heb ik weinig moeite... mogelijk doet hij enigszins af aan de security van Chrome gebruikers (doordat het minder opvalt als er iets mis is), maar goed, geen echt probleem mee. Maar dingen zoals het tegen de spec in verplicht stellen van TLS bij HTTP/2 en Serviceworkers of zo iets als een maximale certificaat duur van 90 dagen... dat is het soort push-y security die van mij echt niet nodig is. Als ik gewoon een decentraal servertje wil hosten zonder domein naam of wat dan ook dan moet ik niet plots in het verleden komen vast te zitten met HTTP1.1. Ik had liever gewoon gezien dat het doel was geweest om HTTPS zo simpel en goedkoop mogelijk te maken zodat er geen reden meer was om het niet te doen, maar zonder het verplicht te stellen zonder reden. Van mij mag Nginx en Apache prima standaard met Letsencrypt plugin worden geleverd en default aan staan in de default config file, zolang ik het ook maar gewoon kan uit zetten mocht ik het niet willen. En als ik het uit zet moet het enige verschil zijn dat m'n verbindingen niet beveiligd zijn, niet dat m'n site ook omvalt omdat SW's niet meer werken en de site traag laad omdat HTTP/2 uit gaat.

Dat is sowieso geweldig nieuws, heb je toevallig goeie linkjes naar documentatie betreffende hoe dat in z'n werk gaat of welke tools er zijn die met DNS validatie werken?

Ik gebruik https://github.com/CAPSLOCK2000/getssl

Er staat een hele waslijst aan clients op: https://community.letsenc...of-client-implementations

In essentie is het heel simpel. Je maakt je csr aan en meldt je bij letsencrypt. Die geven je een code terug die je via een TXT record in je DNS moet publiceren. Letsencrypt controleert dat het record is gepubliceerd en je krijgt je certificaat.

Dit is vanaf het begin af aan deel geweest van de ACME spec. https://tools.ietf.org/ht...-acme-acme-01#section-7.5
Het zit nog niet in de officiele client maar de server ondersteunt het wel.

Naja, van wat ik heb gelezen is het pas 9 dagen mogelijk om DNS verificatie te gebruiken op hun productie server: https://twitter.com/letsencrypt/status/689919523164721152 Dus de meeste clients die ik tot dusver heb gezien doen er niks mee, maar goed, dat ziet er inderdaad erg handig uit, dus ga d'r sowieso naar kijken

Letsencrypt is in beta, dat google en firefox dit pusht is te belachelijk voor woorden, webmakers zullen niet kunnen volgen en het gevolg : mensen zullen het negeren, en bij gevolg minder veilig af zijn.

Overigen heb ik Nginx + Letsencrypt zeer snel werkend gekregen, sneller zelfs dan Apache + Centos 6.

Dit klopt totaal niet, de HTTP 2.0 spec omschrijft heel expliciet hoe een niet beveiligde verbinding zou moeten werken. Browser makers zijn alleen eigenwijs genoeg om niet de volledige spec te implementeren... iets wat ze doen omdat ze het insecure web willen deprecaten door coole nieuwe functies alleen beschikbaar te maken op HTTPS sites

Bijna, tijdens het tot stand komen van de spec bleken de vaste en mobiele providers de grote tegenstanders van 'alles versleuteld' te zijn. De HTTP 2.0 spec kent enkel een non-versleutelde variant dankzij lobby-werk van hen. Maar het was vanaf het begin al duidelijk dat geen van de grote browser makers die zou implementeren. Niet achteraf, maar al vooraf was dat bekend.

Het zijn dus die 'eigenwijze' browsermakers die ons nu behoed hebben van al die 'traffic shaping', 'advertentie injectie' en 'header tracking' die de providers graag wilden behouden.

Het 'totaal' niet kloppen is dus een beetje overdreven

Het slaat helemaal nergens op om je ervaringen met LE te gebruiken als argument tegen het pushen van https. Heb jij een beter idee dan verplichten van TLS in de volgende versie van http? Handiger kan niet. De waarschuwing die Chrome gaat weergeven is meer dan terecht.

Het was gisteren al nodig om een einde te maken aan onversleutelde verbindingen, dus je doet er maar wat werk voor.

Zou een simpel programmaatje niet in staat zijn om TLS op inkomende verbindingen te eisen en lokaal door te sturen naar slecht meewerkende software zoals hierboven beschreven?

Naja, TLS is dus niet verplicht in HTTP/2, misschien in HTTP/3, maar daar zijn we nog niet aan toe... het is een breuk van de spec, juist omdat ze de vrijhoud wouden behouden dat het ook mogelijk moest zijn zonder een dergelijk centraal gezag om HTTP/2 te gebruiken. Dit was een gigantische discussie tijdens het schrijven van HTTP/2 en de conclusie was dat het niet verplicht zou zijn... maar de browsers hebben het toen eigenwijs wel verplicht waardoor je HTTP/2 zover ik weet bijvoorbeeld niet vanaf een IP zonder domein kunt doen... iets wat breuk doet in mijn opinie van het decentrale aspect van het internet.

En probleem zit hem er in dat je moet bewijzen dat je het domein beheert via ACME, en dat vereist dat je files kunt hosten op het domein met een gegenereerde tijdelijke key. Dus de proxy die er tussen zit moet dan zo ingericht zijn dat ie specifiek voor die bestanden doorverwijst naar de genereerde bestanden van LE, zeker niet onmogelijk, maar verre van makkelijk jammer genoeg.

[Reactie gewijzigd door David Mulder op 29 januari 2016 01:00]

Maar in praktijk is TLS dus wel verplicht als je http/2 wilt aanbieden

Op een paar van mijn shared hosting websites maak ik gebruik van SNI in TLS zodat ik geen eigen IP nodig heb voor TLS. Werkt prima met alle moderne browsers.

Ik denk trouwens dat het pushen van https niet de belangrijkste reden is van browsers om http/2 alleen over TLS te ondersteunen. Stel dat je zou verbinden met poort 80. Moet ik dan een request sturen met http/1 of 2? De manier om dit te bepalen is vreselijk, terwijl TLS je gewoon kan vertellen welk protocol er volgt.

Stel dat je zou verbinden met poort 80. Moet ik dan een request sturen met http/1 of 2? De manier om dit te bepalen is vreselijk, terwijl TLS je gewoon kan vertellen welk protocol er volgt.

Naja, de spec omschrijft dat gewoon allemaal, dus valt op zich allemaal wel mee.

Niet nodig om zelf een programmaatje te gebruiken. Gebruik bijvoorbeeld Apache httpd als reverse proxy. Aan de inkomende kant configureer je dat je alleen TLS support. En aan de lokale kant whatever je slecht meeewerkende software aankan. Apache is hier het SSL endpoint voor inkomende verbindingen. Lokaal kun je kiezen voor http of https.

Dit dus...
Ik ben op-zich een voorstander voor een https only internet maar de realiteit is momenteel gewoon anders en feitelijk boeit https niet op veruit de meeste (statische) websites.
Als je nu opeens heel het internet als onveilig gaat markeren gaan mensen het negeren en als er dan opeens een echt issue ontstaat klikken mensen die uit een soort pavlov reactie gewoon weg.

Dit effect is ook niet nieuw ofzo, dus ik vind deze keuze op zijn minst erg raar. Ik had gekozen voor een oranje slotje ofzo, als je er persé wat mee wil doen. Rooie kruizen is direct zo'n paniekvoetbal om niets.
Nu moet ik al die mensen die ik vertel dat ze op de kleur van hun adresbalk moeten letten gaan uitleggen dat daar weer een nuance op toegepast moet worden.
Dat is gewoon kut.

[Reactie gewijzigd door Alpha Bootis op 28 januari 2016 22:01]

Dit dus...
Ik ben op-zich een voorstander voor een https only internet maar de realiteit is momenteel gewoon anders en feitelijk boeit https niet op veruit de meeste (statische) websites.

Zelfs op statische webpagina's boeit het! Omdat het hele verzoek aan de server versleuteld wordt, kan niemand zien welke pagina's jij op zoekt.

Niemand hoeft te weten dat jij bij de GGD informatie zoekt over die lastige SOA, toch?

Ik vind een GGD die blijkbaar https niet op orde heeft van een iets andere orde van grootte als de treintjessite van Harry Doorsnee uit Den Haag zuid. Laatstgenoemde was toch iets meer waar ik aan dacht toen ik riep dat https niet boeide op statische sites.

Zelfs op statische webpagina's boeit het! Omdat het hele verzoek aan de server versleuteld wordt, kan niemand zien welke pagina's jij op zoekt.

Dat is niet waar. Google weet nog steeds wat jij in chrome uitspookt.

Het klink allemaal moi https maar zit met je site maar eens op een shared server en zie dan maar voor dat ip een certificaat te krijgen. Laat staan dat veel bedrijven met kleinere sites überhaupt een idee hebben hoe het werkt.

Er is niets mis met https maar het hangt puur van de site af of je het echt nodig hebt. Voor een blog of gewoon informatieve website zie ik weinig voordelen.

Certificaten op shared hosting is geen enkel probleem meer, technisch gezien. Het is doorgaans slechts een kwestie aan de kant van de hoster en de eventuele kosten en daar ligt net de crux...
Daarom zeg ik dus dat een volledig 'beveiligd' internet nog geen realiteit is.

Ben er wel van overtuigd dat we daar naartoe gaan. En ook op relatief kort termijn. Zaken als let's encrypt maken implementatie certificaten op grote schaal mogelijk en vooral kostenloos waarmee er effectief geen reden is voor een hostingprovider om dat aan te gaan bieden of misschien zelfs af te dwingen.

[Reactie gewijzigd door Alpha Bootis op 28 januari 2016 23:44]

Tenzij je klanten heb met oude IE versie...

Je bedoelt IE6? Als je dat nog gebruikt, zonder dat een heel bewuste keuze is i.v.m. met een of andere legacy webapp, hoort hoonlachen je deel te zijn...

als IE6 20% van je omzet is ja dan boeit dat. Anders niet

IE6 is niet 20% van je omzet. Een IE6 gebruiker moet door teveel hoepels springen om nog werkend het internet op te kunnen:
- Sites met HTTPS en SNI werken niet meer
- Veel sites met Javascript werken niet meer
- Veel webservers vereisen SSL protocollen die standaard uitgeschakeld staan in Windows versies met IE6 of dat OS ondersteunt de nieuwe TLS ciphers helemaal niet
- Banken weren gebruikers met verouderde browsers

Overigens is IE6 niet de enige die geen SNI ondersteunt, Android 2.2 en lager doen dat ook niet. Niet dat het fijn internetwinkelen is met een dergelijke oude telefoon, maar toch...

Hoe kom je aan die 20%? Volgens mij is IE6 nagenoeg weg uit het internetlandschap. (en terecht, weloverwogen)
Websites met een SSL implementatie die voldoen aan alle best practices werken sowieso niet meer in IE6, met of zonder SNI.

Een los IP is sinds SNI niet meer nodig. Wij bieden geen losse IPs meer aan en horen eigenlijk zelden tot nooit problemen van klanten.

Tegenwoordig bieden steeds meer webhosters (ik denk zelfs inmiddels het merendeel) gewoon de mogelijkheid om HTTPS in te schakelen dankzij SNI.

Zo kun je op een goedkope of zelfs gratis, manier gewoon gebruik maken van https. Bieden ze het niet maar heb je wel volledige toegang tot je domeinnaam waarbij je zelf dan de mogelijkheid hebt om de nameservers aan te passen? Kun je zelfs met een omweg https als nog gebruiken door CloudFlare te gebruiken. Mooiste is dat deze als CDN fungeren en je site zelfs al meteen via http/2.0 kunnen serveren.

[Reactie gewijzigd door DarkForce op 29 januari 2016 09:01]

Je hebt geen IP nodig om een certificaat aan te vragen enkel een domeinnaam. Er zijn al hosting panelen die de auto-optie hebben om een https versie te automatiseren, kortom de hosters zullen eens moeten werken voor hun geld.

Prima dat encryptie... maar laten ze eerst iets doen met dat signed certificaten. Dat kost klauwen met geld. Self signed zou een oplossing moeten zijn waarbij de server ook nog een controleert of de cliënt wel direct met de server praat.... kan die dure versign en aanverwanten de deur uit trappen. Want de huidige oplossing stinkt gewoon.

[Reactie gewijzigd door sokolum01 op 29 januari 2016 04:03]

Een domain validated certificaat kost 8 euro per jaar, waarschijnlijk kan het nog goedkoper. Hoezo klauwen met geld?

Leuk bedacht voor webservers, maar de doodsteek voor IoT. 8 euro per jaar voor elke apparaat met een web-interface of ajax API. Dus voor je kabelmodem, ja NAS, je desktop als je een (browser based) remote desktop wilt, je tv/radio/receiver/stb/console, maar ook voor elke 'connected' lamp .. dan hebben we het al snel over klauwen met geld.

Maar een connected lamp hoeft ook niet voor iedereen te benaderen zijn, dus daar kun je prima wegkomen met een self-signed certificaat dat je zelf vertrouwt.

Self signed certificates zorgen weer voor extra beperkingen.

Zelf kwam ik tegen dat als ik het self-signed certificate van mijn receiver's web-interface wil vertrouwen op mijn tablet, Android mij verplicht een lockscreen te installeren, wat erg onwenselijk is op mijn home-automation-tablet.

Maar als de browser op je telefoon het geheel weigert te openen, ben je nergens. Nog even los van de onmogelijkheid om het ge-installeerd te krijgen op de lamp in kwestie, zowel wat betreft de toegang, als wat betreft het beschikbare geheugen en cpu-power.

Dit zou bijvoorbeeld voldoende zijn om een lamp 'IoT' te maken met http:
http://www.csie.ntu.edu.t...paper/Got%20a%20Match.htm
(dit voorbeeld is wired, maar het punt is dat https duurdere hardware gaat vereisen, wat je niet wilt als je er elke lamp in je huis mee wil uitrusten.)

Als je alleen http gebruikt neem ik aan dat je lampen niet over internet aan te sturen zijn. Als dat wel zo is, is dat vragen om problemen natuurlijk. Als jij vanuit een openbare plek via WiFi je lampen aanstuurt via http, moet je niet raar opkijken als bij thuiskomst je huis een disco is geworden.

Met bijkomende nadeel dat je een public IP moet hebben voor een SSL en dat in ip4 space niet zo heel makkelijk is (los dat je ISP er toch in de regel echt maar 1 aan je leased).

Je hoeft helemaal geen public IP te hebben voor SSL. Als je alleen intern werkt gaat SSL ook prima op interne adressen, mits je een self-signed certificaat gebruikt of die interne adressen een DNS-naam geeft. Ook is het niet verplicht om op poort 443 te draaien; je kunt best op andere poorten ook SSL gebruiken.

Ging om échte' (niet self signed) certificaten natuurlijk. Verder ben je altijd vrij om de porten aan te passen, maar dat maakt publiek gebruik soms wat lastig.

Ik meen me een voorstel te herinneren van Firefox om een dergelijke melding pas te tonen als er op de pagina via http een wachtwoordveld staat. Dat lijkt me een stuk pragmatischer.

Edit: https://hacks.mozilla.org...-forms-over-https-please/

[Reactie gewijzigd door Rafe op 30 januari 2016 00:09]

Dat is een schijnveiligheid van epic proporties. Wat let iemand met een phisingsite om gewone tekstvelden ipv password velden te gebruiken zodat de website veilig overkomt?

Sterker nog, op het moment dat je input kun versturen op een website zou het per definitie al https moeten zijn. En liever zag ik zelf sowieso overal https, want wat ik doe op een domein is iets tussen dat domein en ik, en dat hoeft de rest van de wereld niet te weten.

Helaas zijn de mogelijkheden voor tracking ook uitgebreid. google's bemoeienis heeft gezorg dat http2 zo ongeveer cookies 2.0 is. En dit keer zal het niet zo makkelijk om 'cookies' te weigeren.

Tracking kan idd nog steeds, maar ik bedoelde bijvoorbeeld spionage diensten.

Maar veel sites hebben wel een https versie, maar veel mensen gebruiken deze niet.

Zelf heb ik hiervoor in firefox https anywhere geinstalleerd. Wat zoveel doet als altijd een poging doen om https te gebruiken ipv http.

Wat niet failsafe is, want statische sites kunnen prima http zijn, met op https de beheerinterface. In het beste geval (voor jou) zie je daar dezelfde, mogelijk dynamische (= tragere) pagina's met een mogelijkheid om (na inloggen) in place editen.

Er is geen enkele garantie dat de site op https dezelfde is als op http.

[Reactie gewijzigd door Roland684 op 29 januari 2016 13:11]

Klopt, maar beter wordt het niet. Maar het is zeker geen garantie.

Als nu elke gewone website een rood kruis geeft, zal de gemiddelde gebruiker ook niet meer blikken of blozen als opeens hun bankwebsite ook een rood schild/kruis/waarschuwing geeft ...

Dit klopt niet. Als er iets mis is met de beveiligde verbinding (certificaat domein klopt niet, verlopen certificaat etc.) dan kom je op een waarschuwingspagina en wordt het je zo moeilijk mogelijk gemaakt om verder te gaan naar de website. Het verschil is dus heel duidelijk.

De meeste browsers laten je niet eens op de pagina als er een certificaat fout optreedt. Tenminste, bij Firefox moet je aardig wat toeren uit halen als een certificaat is ingetrokken bijvoorbeeld (OCSP). Of als het invalid is.

Er is wel een verschil tussen een rood kruisje, en een full-page waarschuwing in je venster als je de pagina bezoekt, want dat zie je als er iets mis is met het certificaat.
Pas als je kiest om dat te negeren, dan zie je een https met rode streep erdoorheen in het adres.

Precies! En daarnaast: het is niet aan Google om dit eenzijdig te implementeren. Google is een commercieel bedrijf. Google gaat niet over de webstandaarden. Als ze dit belangrijk vinden dan kunnen ze dit aankaarten binnen het W3C.

Google biedt een product aan "Chrome" en kan hierin gewoon zelf bepalen wat ze wel of juist niet willen aanbieden. Een webstandaard houdt niet per definitie in dat iedere browser bakker zich er ook aan moet houden. Het zou mooi zijn, maar als je even terug denkt aan Internet Explorer dan vermoed ik dat je ook vast nog wel weet dat Microsoft jaren lang die standaarden met een korreltje zout nam.

Ja, dat herinner ik me. En volgens mij is dat voor Microsoft niet zo goed afgelopen toen. Hoe hoog was de boete ook alweer? Bijna één miljard?

Mijn punt is: Google heeft veel te veel macht en maakt daar misbruik van door ons van alles op te dringen/leggen. Vroeger werden bedrijven om dat soort redenen nog wel eens gestraft, bv. door ze op te splitsen. Dat overkwam AT&T in 1982. Het is maar een suggestie...

Volgens mij heeft Microsoft nooit een boete gehad voor het niet volledig voldoen aan de W3C standaard. Dat was juist meer omdat men MSIE door de strot duwde.

In principe wordt er weinig opgedrongen, okay... er wordt een waarschuwing getoond. Zolang je geen waarschuwing ziet zoals vaak voor komt bij het bezoeken van een https-site waarbij de certificaat onjuist (of vervallen) is... is er geen enkel probleem en wordt er niet veel opgedrongen.

[Reactie gewijzigd door DarkForce op 29 januari 2016 13:06]

Is Google dominant op de zoekmarkt? Ja. Ca. 90% van alle Nederlandse zoekopdrachten verloopt via Google. Of ik jouw site wel/niet vind is dus sterk afhankelijk van hoe jouw site in Google staat.

Feitelijk gaat Google nu eenzijdig beslissen dat alle sites https moeten invoeren. Geen https? Dan een waarschuwing in Chrome. Maar óók: lager in de zoekresultaten! Dat hebben ze ook gedaan met responsive sites en gaan ze vast ook doen met mobile HTML.

Wat Google hier doet raakt dus niet alleen de Chrome-gebruiker maar ons allemaal. Vergis je niet: Google bepaalt wat jij wel/niet ziet. Dat velen dat niet opmerken is omdat ze niet zien wat ze niet zien.

Google zet hier de facto een nieuwe "webstandaard". Maar daar gaat Google niet over.

Is Google dominant op de zoekmarkt? Ja. Ca. 90% van alle Nederlandse zoekopdrachten verloopt via Google. Of ik jouw site wel/niet vind is dus sterk afhankelijk van hoe jouw site in Google staat.

Dat is al jaren het geval, https is er als één van de eisen bijgekomen hoewel huidige zoekresultaten ook vrij vaak nog gewoon http-sites qua resultaten in de top 10 tonen.

Anderzijds, is https niet iets waar men zelf eigenlijk al geruimte tijd om vraagt? Na alle media aandacht van lekken, taps etc. loopt de gemiddelde consument nog net niet rond met een allu-hoedje maar vanaf diverse kanten wordt diezelfde consument wel bang gemaakt als het gaat om privacy. De gemiddelde internetter is zich ervan bewust dat https een stuk(je) veiligheid biedt... door dit standaard te maken wordt diezelfde consument weer een zorg uit handen genomen.

Het geen ik overigens wel altijd grappig vind om terug te lezen is dat er her en der mensen rondlopen die aanhalen dat Google de boel domineert. Zoekmachine, browser, mail enz. enz. enz. maar het is de keus van de consument zelf. De consument kan ook Bing of DuckDuckGo gebruiken. De consument kan ook een telefoon kopen met iOS of Windows. De consument kan ook Internet Explorer or FireFox gebruiken. Volgens mij zijn het vooral de tweakers die zich eraan storen, de gemiddelde consument interesseert het zich nauwelijks of pakken grofweg wel die alternatieve dienst/product als Google het niet biedt. Als de consument zich hier wel aan gestoord had, was Google lang niet zo groot geworden als wat het nu is of waren er wel meerdere bezwaren geweest vanuit de huis, tuin en keuken gebruikers.

[Reactie gewijzigd door DarkForce op 29 januari 2016 13:52]

Heb ik bezwaar gemaakt tegen https? Ik maak bezwaar tegen de manier waarop een buitenlandse, commerciële partij ons https wil opleggen.

En mensen kiezen zelf massaal voor Google... Ja. En? Omdat ze er zelf voor gekozen hebben kan er geen ongewenste situatie ontstaan?

Indien je een statische website hebt, zonder contactformulier etc., zie ik niet de noodzaak om https te implementeren.

Ik zie wel de noodzaak.
Waarom zou een tussenliggende persoon hoeven te weten dat jij naar die website gaat en wat er op je scherm te zien is? Ook al is het een simpele statische site zonder contactformulier?

Verder is het zo, dat tegenwoordig resources efficiënter geladen kunnen worden via HTTP/2 (verplicht over HTTPS). In sommige gevallen, afhankelijk van de latency, is HTTP/2 even snel als HTTP/1.1 maar vaak ook sneller.
Het heeft meer voordelen. Kijk bijvoorbeeld maar eens op https://http2.akamai.com.
In ieder geval implementeer ik voor al mijn klanten standaard HTTP/2 met een certificaat van Let's Encrypt. Zorgt ook nog eens voor hogere Google rankings. 😃

"Verder is het zo, dat tegenwoordig resources efficiënter geladen kunnen worden via HTTP/2 (verplicht over HTTPS). In sommige gevallen, afhankelijk van de latency, is HTTP/2 even snel als HTTP/1.1 maar vaak ook sneller."

Indien HTTP/2 sneller is dan HTTP/1.1 dan is dat niet dankzij encryptie maar ondanks encryptie. HTTP/2 is sneller vanwege multiplexing en header compressie, niet vanwege encryptie, terwijl je stelling dat wel impliceerd, wellicht onbedoeld.

Encryptie is ook helemaal geen verplicht onderdeel van HTTP/2 zelf. De reden dat dit door web server producenten toch "verplicht" gemaakt wordt is omdat anders oude proxies dit verkeer verkeerd interpreteren.

Met https weten ze ook nog steeds welke websites je bezoekt.

Met https weten ze ook nog steeds welke websites je bezoekt.

Inderdaad. Dit mag best iets uitgebreider toegelicht worden.

In het kort, als je over HTTPS een website bezoekt, dan moet de webserver je versleutelde verzoek ontsleutelen. Om dat te doen heeft de webserver het juiste certificaat (of eigenlijk: de bijbehorende private key) nodig. Maar welk certificaat/key dat is moet de webserver beslissen op basis van onversleutelde informatie! En als de webserver dat kan, dan kan een afluisteraar dat ook.

Historisch was het om deze reden niet mogelijk meerdere HTTPS-websites op één IP-adres te hosten. Elke HTTPS-website had zijn eigen IP-adres, waardoor de webserver geen keuze had in certificaat/key. Maar dat betekent dat HTTPS-verkeer naar dat IP-adres altijd gelijk staat aan een bezoek aan die specifieke website. Als iemand HTTPS-verkeer van mij naar 145.72.70.20 ziet, dan hoeft die persoon alleen maar http://145.72.70.20/ te bezoeken om te zien om welke website het gaat.

Tegenwoordig is het virtual-hosten van HTTPS-sites wel mogelijk door SNI (Server Name Indication). Dat komt er op neer dat in het HTTPS-verzoek onversleuteld de naam van de website (bv tweakers.net) wordt meegegeven, zodat de webserver weet welk certificaat/key hij moet gebruiken om de rest te ontsleutelen. Maarja, aangezien de website-naam onversleuteld mee wordt gestuurd is dat makkelijk af te luisteren.

Dus ja, met HTTPS weten ze inderdaad nog altijd welke websites je bezoekt. Maar niet wat je op die website doet.

Alleen ondersteund bijvoorbeeld Windows XP geen SNI. Met een marktaandeel van pak hem beet 10% is SNI voor een serieuze website dus geen optie. Dan heb je toch echt een dedicated IP nodig.

Met Windows XP behoor je geen verbinding meer te maken met internet, dan valt een certificaatwaarschuwing nog best mee (de website werkt verder wel gewoon). En je kan altijd nog een browser gebruiken die SNI ondersteunt.

Wat extra informatie.

Om SNI te gebruiken moet de SSL / TLS library die gebruikt wordt door een applicatie SNI ondersteunen en moet de applicatie de hostname doorgeven aan de SSL / TLS-bibliotheek. Een nadeel is dat de SSL / TLS library kan worden verzonden als onderdeel van de aanvraag en als onderdeel van het besturingssysteem. Hierdoor ondersteunen sommige browsers SNI op alle operating systems en andere alleen op specifieke operating systems. Vanaf 2011 hebben de meeste webbrowsers en SSL-libraries ondersteuning voor SNI geïmplementeerd, maar er zijn nog steeds een groot aantal gebruikers die een combinatie van browser en besturingssysteem hebben die het niet ondersteunt.

De volgende combinaties bieden geen ondersteuning voor SNI:

Client Side
• Internet Explorer (elke versie) op Windows XP
• Safari op Windows XP
• BlackBerry Browser
• Windows Mobile tot en met 6.5
• Android standaard browser op Android 2.x


Server Side
• IBM HTTP Server


De volgende combinaties bieden wel ondersteuning voor SNI:

Client Side
• Internet Explorer 7 of later, op Windows Vista of hoger. Werkt niet onder Windows XP, ook niet in Internet Explorer 8.
• Mozilla Firefox 2.0 of later
• Opera 8.0 of later (het TLS 1.1 protocol moet ingeschakeld worden)
• Opera Mobile ten minste versie 10.1 bèta op Android
• Google Chrome (Vista of later. XP op Chrome 6 of nieuwer)
• OS X 10.5.7 of hoger op Chrome 5.0.342.1 of nieuwer)
• Safari 2.1 of later (Mac OS X 10.5.6 of hoger en Windows Vista of hoger)
• Konqueror/KDE 4.7 of later
• MobileSafari in Apple iOS 4.0 of later
• Android default browser op Honeycomb of nieuwer
• Windows Phone 7
• MicroB op Maemo


Server Side
• Apache 2.2.12 of later door het gebruik van mod_ssl
• F5 Networks Local Traffic Manager met version 11.1 of later
• LiteSpeed 4.1 of later
• Pound 2.6 of later
• Apache Tomcat op Java 7 of later
• Microsoft Internet Information Server IIS 8
• PageKite tunneling reverse proxy

Internet Explorer 7/8 en Safari op Windows XP ondersteunen het niet. Chrome (vanaf versie 6) en Firefox ondersteunen het wel, ook op Windows XP. Als je nog IE 7/8 gebruikt heb je tegenwoordig wel meer problemen met browsen dan alleen geen SNI ondersteuning.

Dat hangt er natuurlijk maar vanaf, volgens mij is het marktaandeel van XP in Nederland inmiddels nog maar 1-2% (laats bekende percentage dat ik ken 2% in oktober 2015, Europa 6%), wat in principe makkelijk te negeren is voor een hippe Nederlandse site (daar hun doelgroep waarschijnlijk sowieso geen XP meer gebruikt). Volgens mij worden de wereldwijde nummers nogal krom getrokken door een relatief hoog gebruik van XP in Azië en Afrika (waar het beide nog ruim boven de 10% zit). Ik verwacht dat zeker Westers georiënteerde sites Windows XP langzaam aan makkelijk kunnen gaan negeren.

Ze zien alleen niet de artikels die ik lees en welk cookie- en header-waarden ik heb. Wat Google wel zou kunnen doen is certificaten aanbieden tegen een lage prijs of ad presence/tracking mogelijkheden.

Dat is denk ik ook een achterliggende reden van Google. Je eigen serverstats,zijn wat refers betreft waardeloos. Maar wie weet de refers wel? Google! Omdat 90% Google Analytics gebruikt.

Hooguit met welke IP's je verbinding maakt, specifieke webpagina's zijn er niet uit te halen (de URI in het http request wordt mee encrypted).

Dat is alleen zo als er maar een site op dat IP draait. Anders moet je vanwege SNI alsnog de hostname unencrypted meesturen zodat de server het juiste certificaat kan gebruiken.

Uh, ja er kan een domeinnaam worden afgeleid, maar goed als er maar één domein op een bepaald IP draait kun je dat ook uit dat IP afleiden.

Gaat er omdat je verder niets kunt zien over de pagina's die je bezoekt of welke content je precies bekijkt of andere details van je verkeer en communicatie met die server.

Een derden hoeft het niet te weten, maar het is ook totaal geen geheim als ik de website van de bakker om de hoek bezoek om te kijken welk brood hij vandaag in de aanbieding heeft. Er is voor een afluisteraar niets nuttigs te halen uit die informatie.

Het overal maar HTTPS op activeren is toch nog complexer dan het wellicht oogt, vergt ook extra server resources, is bovendien duur (de genoemde 8,- voor een SSL cert. is duur als je hosting voor 4,- per jaar hebt).

Maar het is dus bovendien niet nodig. HTTPS voorkomt sniffen. Verkeer sniffen op iets anders dan een publiek WiFi netwerk is behoorlijk complex en vereist fysieke toegang tot kabels en/of infrastructuur.

Anno 2016 geen of te verwaarlozen extra server resources. https://istlsfastyet.com
SSL-certificaten zijn inmiddels gratis. https://letsencrypt.org
Wat betreft sniffen: ik vind dat het aan de bezoeker is om te bepalen of hij/zij veilig wil browsen. De hostingprovider dient daarom de klant altijd een veilige optie te geven vind ik.

Dat iets in aanschaf gratis is (LE) maakt het niet gratis. Een certificaat moet ook onderhouden worden. Ja, LE kan automatisch upgraden, maar er moet wel gechecked worden of dat ook goed gaat. Alleen de shitload aan vragen die hosting providers gaan krijgen. Al die support uren moeten toch uiteindelijk ook weer terug verdiend worden. Oude browsers die in de toekomst niet meer werken met recente certificaten (zie nu het XP/IE probleem).

Daarnaast kunnen er weer issues in OpenSSL optreden, waardoor ineens alle private keys vervangen moeten worden, of er is een ander technisch probleem dat vernieuwing van certificaten vereist die geen 3 maanden kan wachten en dus handmatige interventie vereist.

Daarnaast kan het ook nog zijn dat de LE CA ook minder frisse websites gaat voorzien van SSL, wat de betrouwbaarheid van LE ondermijnt. Als er een browser is die een keer besluit dat de LE CA onvoldoende verificatie toepast is er een groot probleem.

"Geen of te verwaarlozen server resources" lijkt me wat te makkelijk. Je moet voor elke site een key en een crt in het geheugen laden. Hoe klein die ook zijn, met 1000 websites op een server tikt dat aan. Daarnaast kost SSL ook extra CPU. Verder kun je nu bv. in Apache met ServerAlias honderden, duizenden sites aan 1 virtual host knuppen. Dat gaat met "alles moet SSL zijn" niet meer werken. Dat moet een aparte vhost zijn voor elk domein. Dat kost dus wel degelijk aanzienlijk meer resources. (In het geval van Apache al 2 file descriptors per vhost als je logging wil)

"De klant" heeft volgens mij helemaal geen behoefte aan SSL op elke site. Anders was dat al wel reeds het geval. Het is een balletje van Google, en het is mij nog onduidelijk wat ze hier precies mee willen bereiken.

En nogmaals, ook met SSL is het nog steeds te sniffen welke site wordt opgevraagd. Als die site vervolgens publiek bereikbaar is (niet achter een login), dan kan iemand die sniffed dus nog steeds zien welke site bezocht wordt. Op basis van response size kan tot op zekere hoogte zelfs bepaald worden welke specifieke pagina.

Daarnaast zijn er bv. content scanners die inhoud van een site als "mitm" in bv. een corporate firewall/IDS scannen op het moment dat ie wordt opgevraagd. Zo'n scanner werkt niet meer als het SSL is (of hij moet dat al gaan decrypten en opnieuw crypten met een private CA). Dat is in een corporate omgeving nog wel te doen, maar voor een gemiddelde virusscanner op een lokale PC wordt het snel ingewikkeld.

Caching proxy servers op trage verbindingen kun je ook opdoeken, want die kunnen niet meer cachen.

Verder kun je geen mixed-content hebben, ofwel je kunt geen plaatjes over HTTP laden in een website die een browser opvraagt via HTTPS. Dat zorgt voor foutmeldingen/waarschuwingsschermen in de browser (terecht wellicht). Maar dat betekent dus tevens dat je een website niet op SSL kunt draaien zolang je externe content laad van niet-SSL servers. Denk aan banners, like-knopjes, embedded content, image-hosting servers en wat niet nog meer.

Kortom, dit zorgt voor meer problemen dan het oplost. Sites waarvoor encryptie echt belangrijk is hebben het allang. Ik ben hier geen voorstander van. Dit is _niet_ zo eenvoudig als "even letsencrypt aanslingeren"

[Reactie gewijzigd door Tozz op 30 januari 2016 21:14]

Nice, ik vind dat dat laat zien dat je verstand van zaken hebt. Het wordt steeds minder moeite. Ik vind let's encrypt echter nog een beetje "hacky" zeker voor Nginx, ik hoop heel erg dat Nginx (en andere) of Debian/Ubuntu etc het standaard gaan inbouwen, dat zou erg mooi zijn.

HTTP2 is standaard ingebouwd in Nginx tegenwoordig (sinds een maand ongeveer, vervangt SPDY).

Misschien gaat Tweakers eens over op SSL. Er is tegenwoordig geen reden meer om het niet te doen.

[Reactie gewijzigd door Megamind op 28 januari 2016 21:28]

't Is toch echt niet zo simpel als je lijkt te denken hoor...
Althans, als we echt over willen op een beveiligde site, dus niet alleen https aanbieden omdat jij en anderen hier vinden dat het hoort

Kortom, als we geen mixed content hebben en dat is op met name het forum op dit moment niet zonder ingrijpende wijzigingen mogelijk. Daar kan iedereen afbeeldingen en video's embedden van willekeurige servers, waarvan wij niet weten of ze wel of geen HTTPS ondersteunen. En dat hebben ze in het verleden ook zeer vaak gedaan.
Voor die afbeeldingen moeten we iets verzinnen:
- Ze helemaal weglaten (vervangen door links ofzo)
- Ze via e.o.a. click-to-active functie toch openbaar te laten worden (maar dan is het nog steeds mixed content, alleen dan uitgesteld)
- Ze via e.o.a. proxy te serveren (dat heeft weer allerlei juridische haken en ogen)
- Gebruikers te dwingen alleen nog https-afbeeldingen te embedden (maar wat doen we dan met de reeds geplaatste afbeeldigen?)

We gaan er ook zeker mee bezig, maar door bovenstaande zaken (en er zijn er vast nog wel meer) gaan we niet 'gewoon' https aanzetten... want dan krijgen we nog steeds rode kruisjes en/of grijze slotjes ipv de groene. Als we zoiets doen, willen we het wel goed doen.

HTTPS heeft verder nog wat implicaties voor de performance. Dat is te beperken/verhelpen met HTTP/2 en aan onze kant met ssl-termination op de loadbalancers. Maar voor goede ondersteuning van die beide zaken daarop moeten we nieuwe loadbalancers hebben en ook dat doen we niet zomaar even

Gewoon het mogelijk maken om afbeeldingen up te loaden. Heeft ook nog als voordeel dat sommige discussies niet eens waardeloos worden als hosts (en dus plaatjes) wegvallen.

Dat heeft uiteraard dezelfde juridische bezwaren als proxies, er zijn diverse topics waarvan het discutabel is of de plaatser wel de auteursrechten had voor de geplaatste afbeeldigen. En dan moeten wij dus op zijn minst faciliteren dat ze (bij ons) verwijderd kunnen worden (en dan ook blijven).

Op zich is het natuurlijk wel al mogelijk via onze fotoalbum-functie, maar het grootschalig uitrollen is niet een 'gewoon'-verandering

Bovendien lost dat het probleem niet met terugwerkende kracht op; reeds geplaatste afbeeldingen kunnen (of willen?) we ook niet zomaar gaan downloaden.

[Reactie gewijzigd door ACM op 28 januari 2016 22:53]

Het hele auteurs rechten verhaal heeft toch niets met HTTPS te maken? Als iemand in een forum topic een afbeelding plaats via http van een afbeelding waarvan hij niet de rechten heeft. Dan is dat toch nog steeds strafbaar, met of zonder HTTPS.

Volgens mij is Tweakers verantwoordelijk voor de content op hun site. Zo ook de content in het forum. Als daar foto's met copyright gebruikt worden, ook als zijn die extern gehost, dan is Tweakers daarvoor verantwoordelijk. Heeft niets met HTTPS uit te staan.

Ik begrijp dat argument dus ook niet echt. Daarnaast, op het forum na zou alles op HTTPS kunnen omdat die discussie er niet is.

Het is gewoon een kwestie van wil, tijd en dus geld!

Volgens mij is Tweakers verantwoordelijk voor de content op hun site. Zo ook de content in het forum. Als daar foto's met copyright gebruikt worden, ook als zijn die extern gehost, dan is Tweakers daarvoor verantwoordelijk. Heeft niets met HTTPS uit te staan.

Heeft niets met "HTTP vs HTTPS" te maken inderdaad, maar met "hosten vs linken" (en, voor zover ik weet, maakt dat wel degelijk een groot verschil).

De reden dat "hosten vs linken" van belang is bij de discussie "HTTP vs HTTPS" is dat er een boel oude HTTP-links op het forum staan; de enige gegarandeerde manier om die allemaal naar HTTPS om te zetten is door ze te downloaden en zelf (via HTTPS) aan te bieden; die proxy/cache/hoe-je-het-wil-noemen is waar het probleem zit.

Ik begrijp dat argument dus ook niet echt. Daarnaast, op het forum na zou alles op HTTPS kunnen omdat die discussie er niet is.

Ook bij nieuwsartikelen zie ik volgens mij wel eens extern-gehoste afbeeldingen en video's langskomen; daar moet dan ook een oplossing voor komen.

Volgens mij met de hele torrents discussie is linken alleen al voldoende om websites offline te halen! Dus linken of hosten maakt ook niet zoveel verschil!

Voor geplaatste afbeeldingen kan je heel makkelijk controleren of die naar https verwijst of naar http. In het tweede geval => automatisch link.

Bij het plaatsten van afbeeldingen in IMG-tag vereis je dat je moet linken aan een HTTPS server (je hebt als een JS controle op de grootte, dus dat moet niet al te moeilijk zijn) plus daarbij maak je het fotoalbum toegankelijk voor iedereen om direct naar het forum te uploaden, de karma functie beperk je dan tot het uploaden van losse afbeeldingen. (zoals nu) Bij geüploade bestanden kan je een hash opslaan en controleren of iemand dezelfde hash opnieuw upload; dan kan je die onderwater aan elkaar linken.

Maw. er is zéér zeker een eind aan te knopen. Maar dit kost tijd, mankracht en geld.

[Reactie gewijzigd door 90710 op 28 januari 2016 23:41]

Je kunt problemen ook overschatten. De waarde van oude threads is beperkt, vooral waar het plaatjes betreft, daar kun je immers niet op zoeken. Vervangen door een link lijkt me afdoende.

De enige posts die je misschien echt wil updaten naar HTTPS zijn de topic starters van nog lopende threads. Dat is een vrij klein aantal waarvan de OP het meestal zelf wel kan doen. Ik vermoed dat een email te van Tweakers volstaat.

https://secure.tweakers.net/my.tnet/fotoalbum/
zoiets?

Maar ja, die zit in de karma store en is heel beperkt als je weinig Karma hebt

Hmm, inderdaad... Ik dacht dat iedereen die had, maar blijkbaar heb ik die ooit eens een keer geactiveerd en is de ruimte afhankelijk van je totale hoeveelheid karma.

- Ze via e.o.a. proxy te serveren (dat heeft weer allerlei juridische haken en ogen)

Hoezo?
Je mag volgens mij gewoon cachen volgens EG 2000/31/EG.

"Caching" (wijze van opslag)

1. De lidstaten zorgen ervoor dat, wanneer een dienst van de informatiemaatschappij bestaat in het doorgeven in een communicatienetwerk van door een afnemer van de dienst verstrekte informatie, de dienstverlener niet aansprakelijk is voor de automatische, tussentijdse en tijdelijke opslag van die informatie, wanneer deze opslag enkel geschiedt om latere doorgifte van die informatie aan andere afnemers van de dienst en op hun verzoek doeltreffender te maken, op voorwaarde dat:

a) de dienstverlener de informatie niet wijzigt;

b) de dienstverlener de toegangsvoorwaarden voor de informatie in acht neemt;

c) de dienstverlener de alom erkende en in de bedrijfstak gangbare regels betreffende de bijwerking van de informatie naleeft;

d) de dienstverlener niets wijzigt aan het alom erkende en in de bedrijfstak gangbare rechtmatige gebruik van technologie voor het verkrijgen van gegevens over het gebruik van de informatie, en

e) de dienstverlener prompt handelt om de door hem opgeslagen informatie te verwijderen of de toegang ertoe onmogelijk te maken, zodra hij er daadwerkelijk kennis van heeft dat de informatie verwijderd werd van de plaats waar zij zich oorspronkelijk in het net bevond, of dat de toegang ertoe onmogelijk werd gemaakt, of zodra een rechtbank of een administratieve autoriteit heeft bevolen de informatie te verwijderen of de toegang daartoe onmogelijk te maken

Dit is ook waarom forum diensten als bijvoorbeeld XenForo en SMF gewoon een optie "Force SSL" hebben, waarbij afbeeldingen *on demand* worden gecached.
(Na enkele dagen wordt het weer uit de cache gegooid, en mocht iemand de afbeelding dan weer opvragen: dan wordt hij weer binnengehaald en in de cache gezet.)
Zolang je maar een redelijk lage TTL hebt voor de cache (enkele dagen) moet dat dus prima in orde zijn. Links naar plaatjes die reeds https gebruiken worden door de cache genegeerd.

Dat lijkt dus allemaal prima legaal te zijn, gezien behoorlijk wat mensen en bedrijven (ook in NL) daar gebruik van maken. En dan heb je dus ook geen gelazer als op het moment dat je mensen toelaat om afbeeldingen te uploaden, want dan sla je het op ipv tijdelijke opslag (cache).

[Reactie gewijzigd door WhatsappHack op 29 januari 2016 01:47]

Dat je mag cachen weet ik, maar punt 'e' vereist wel dat we een faciliteit hebben om bij klachten de boel eruit te verwijderen. Ik weet niet in hoeverre het dan volstaat om te antwoorden "zorg maar dat de bron het weggooit, dan is het bij ons automatisch 2 dagen later ook weg".

Sterker nog, effectief staat daar dat als een rechter bevolen heeft dat het onmogelijk gemaakt moet worden, dat wij dat dan ook moeten zodra we daar weet van hebben. Ongeacht of de bron daar zelf gehoor aan geeft.

Hoedanook, het is op zich niet een optie die we helemaal hebben uitgesloten en de genoemde voorbeelden maken het weer wat interessanter. Maar we zijn vaak genoeg benaderd voor het verwijderen van afbeeldingen uit het forum om hier in ieder geval van te mogen verwachten dat het een enkele keer per jaar zal gaan voorkomen.

- Ze via e.o.a. proxy te serveren (dat heeft weer allerlei juridische haken en ogen)

Dat is trouwens wel wat GitHub heeft gedaan, misschien kunnen jullie daar wat mee er is ook php-code om urls te genereren: https://github.com/willwashburn/Phpamo

[Reactie gewijzigd door Rafe op 28 januari 2016 22:38]

Klopt maar vanaf het begin en daar ga je dus ook mes akkoord, nu staan er linkjes naar afbeeldingen in en daar is geen akkoord voor.

Of je controleert of de url ook opvraagbaar is in een https variant en schotel die dan voor. Is die niet beschikbaar? Vraag aan de lezer of hij de afbeelding wil laden. Soort "not safe" zoals bij 9Gag.

Dit geeft wel aan dat er vele vele sites zullen zijn die een rood kruis van Google gaan krijgen. Dat zal niet snel veranderen ook.
Het zou wel jammer zijn als mensen hierom straks sites met een rood kruis links laten liggen. Veel (statische) sites hebben echt geen https nodig.

Wat bedoel je? Ik maak via SSL verbinding met Tweakers, alleen de advertenties zijn als ik me goed heb laten informeren nog niet compatibel met SSL.
Overigens is het developersteam van Tweakers hier al geruime tijd mee bezig, zijn ze hier transparant over en vragen ze input.
Zie ook: plan: Dilemma: moet Tweakers https inzetten?

Firefox zegt dat de verbinding niet veilig is als ik naar https://tweakers.net ga.
(Ik krijg niet die waarschuwing maar het slotje heeft een waarschuwingsdriehoekje er overheen.)

[Reactie gewijzigd door teek2 op 28 januari 2016 21:52]

Hmm melding krijg ik niet met Fx 45 beta 1 64 bit.

Er worden inderdaad heel veel afbeeldingen nog geladen via HTTP. Tweakers heeft dus nog wat te doen.

plan: Dilemma: moet Tweakers https inzetten? Zeer zeker wel... "eens over gaan", anderhalf jaar geleden kon je je in de discussie mengen.

Die reden is er wel: de meeste browsers accepteren alleen een https met een door een beperkt aantal bedrijven geaccepteerd certificaat.

Zelfgetekende certificaten moet je steeds opnieuw in de browser aangenev dat die veilig is.
En goedgekeurde certificaten zijn alleen nog voor veel geld te koop. Het initiatief om makkelijk self-signed certificates te certificeren is nog steeds niet van de grond, deze is er wel maar is nog in beta. Dus niet geschikt voor iemand die even een website wil https-en. Zelf geprobeerd, werkt voor geen meter.

[Reactie gewijzigd door skatebiker op 29 januari 2016 11:14]

Vind ik ook, maar ik vindt het wel heel goed dat ze dit doen. Dit gaat mensen wel bewuster maken voor matig beveiligde websites die je ww plain text het web over schieten.
Een waarschuwing als je gaat inloggen of data invoeren als er geen ssl/tls is zou nog beter zijn imo.

Nu is het ook wel krom:
Geen tls: Alles ziet er prima uit
Wel tls, goedgekeurd certificaat: Mooi slotje
Wel tls, self-signed certificaat: Wacht! Stop, dit zit helemaal fout!

Edit: Na het lezen van reacties hieronder, misschien is het zelfs handig om identiteit (is dit echt de website van de bank?) te scheiden van encryptie (gaan mijn gegevens zonder beveiliging het www over?) Niet in alle gevallen heb je beide nodig.

[Reactie gewijzigd door teek2 op 28 januari 2016 21:42]

Maar creeer je ook schijnveiligheid, mensen zijn dan zo gefocused op slotje/niet-slotje, dat het domein er verder niet meer toe doet. De phising van Rabobank gebruikt ook nette certificaten, alleen op een compleet ander domein.

Maar creeer je ook schijnveiligheid, mensen zijn dan zo gefocused op slotje/niet-slotje, dat het domein er verder niet meer toe doet. De phising van Rabobank gebruikt ook nette certificaten, alleen op een compleet ander domein.

Ik denk eerder dat als 99% van de sites zo'n icoontje met rood kruis laten zien, dat het niet meer opvalt.

Waarschuwen moet je doen wanneer je de aandacht wilt vestigen, niet tot nieuwe standaard melding verheffen.
Dus bij sites met inlog-velden zonder https met fatsoenlijk certificaat (wat gratis is te krijgen) is een waarschuwing op z'n plaats. En uiteraard ook bij dingen die gewoonweg niet kloppen, zoals certificaat wat ingetrokken is, of niet van dat domein is of kan zijn.

[Reactie gewijzigd door TD-er op 28 januari 2016 22:05]

Dus bij sites met inlog-velden zonder https met fatsoenlijk certificaat (wat gratis is te krijgen) is een waarschuwing op z'n plaats. En uiteraard ook bij dingen die gewoonweg niet kloppen, zoals certificaat wat ingetrokken is, of niet van dat domein is of kan zijn.

Waar dan ? Want dat selfsigned initiatief werkt vooralsnog voor geen meter.
Als dat wel zou werken dan vind ik dit een prima initiatief.

startssl.com
Kost wel een beetje moeite, in de zin dat je duidelijk moet maken wie je bent enzo, maar dat is ook het hele idee achter certificaten.
Verder heb je Let'sEncrypt, wat dus ook gratis is.

Ja, dat blijf je hebben, maar die hadden waarschijnlijk niet het Super-uber slotje (Extended Validation) waar je eigenlijk bij je bank weer op moet letten. Tja, het wordt er niet makkelijker op

Tja, en hoeveel mensen weten dat ze daar op moeten letten?

Het is helemaal niet krom. Het gaat toch in eerste plaats om vertrouwen? Iedereen kan een self signed certificaat maken en aan een site koppelen.

En hoe ga je die encryptie vertrouwen, als het niet door de bank zelf is geregeld?

Zeker een goede zaak van Google, maar een melding 'onveilig' is te zwaar benoemd denk ik.

Laat ze ook gelijk een markering geven of de site DNSSEC ondersteunt, zodat je ook meer zekerheid hebt dat de dns omzetting bij het correcte IP-adres uitkomt.

Mwha, vertrouwen kun je ook krijgen in een site als je er een tijdje mee werkt. En voor je eigen ownCloud of RoudCube webmail installatie is het ronduit irritant dat je aan jezelf moet bewijzen dat je wel echt jezelf bent. Ok, in dat geval kun je het cert natuurlijk ook toevoegen als vertrouwd. Hoe dan ook, met Lets encrypt is het hopelijk straks allemaal ingebouwd.

Mwha, vertrouwen kun je ook krijgen in een site als je er een tijdje mee werkt.

Wow. Nou succes.

En voor je eigen ownCloud of RoudCube webmail installatie is het ronduit irritant dat je aan jezelf moet bewijzen dat je wel echt jezelf bent.

Het gaat toch niet om identiteit maar om beveiligen van communicatiekanaal?

Precies, en met een self-signed certificaat kan je prima het communicatiekanaal beveiligen. Echter je krijgt veel zwaardere waarschuwingen dan dat je krijgt als je helemaal niets beveiligd.

Deze opmerking snap ik niet trouwens: En hoe ga je die encryptie vertrouwen, als het niet door de bank zelf is geregeld?
Met een self-signed certificaat heeft de bank het ook zelf geregeld, alleen weet je niet zeker of de URL echt naar de Bank wijst of, of je niet een typefout hebt gemaakt. Dat is minder belangrijk bij de ownCloud/RoundCube scenarios vind ik.

Wat als die site na een tijdje er mee te werken malafide blijkt te zijn?

Dat kan ook met sites die wel een geldig certificaat hebben. En het is geen issue bij je eigen sites.

Het voorkomt dat een partij als Norwegian Air content gaat toevoegen aan je pagina's.

Ook een mooi voorbeeld ja. Schandalig dat dat soort rotzooi plaatsvindt. Als je je dat realiseert is het inderdaad eens te meer hoogtijd voor 100% end-to-end encryptie overal.

Ik moest laatst geld overmaken naar de bankrekening van en stichting. Dat kon ik opzoeken op de contactpagina van de website (zonder formulier: er stonden adresgegevens en mailadressen e.d.). Dit is natuurlijk statisch, maar dat neemt niet weg dat het veranderen van zo'n rekeningnummer op zo'n statische pagina nog steeds een interessante aanval kan zijn.

Gelukkig was de pagina inderdaad via SSLTLS geserveerd dus kan ik ervanuitgaan dat het rekeningnummer in ieder geval niet via MITM gespoofed kan worden.

Dan ben je toch wat kortzichtig moet ik helaas constateren. Ook statische informatie kan zéér vertrouwelijk zijn. Dan kan je denken aan journalisten, vrijheidsstrijders, niet-hetero's, anders-gelovigen en ga maar door. Bedenk ook dat zelfs de metadata van niet-vertrouwelijke informatie zéér vertrouwelijk kan zijn.

Goede move van Google, met name voor het bewustzijn.

Je hoeft ook helemaal geen HTTPS te implementeren. Dit icoontje laat gewoon duidelijk aan de bezoeker zien dat de site onveilig is (wat hij ook is).

Wat is er precies onveilig? https is voor veel sites helemaal niet relevant. Zeker bij een toko als google is het een lachertje, gezien je persoonlijke data wel volledig doorzoekbaar is voor google zelf. "Ja maar we hebben wel een volledig beveiligde verbinding".

Oke, "onveilig" is misschien een vage term. Zoals je zelf al zegt, de verbinding is (on)veilig.

Of je de server/contentaanbieder vertrouwt is natuurlijk een andere vraag. Met HTTPS ben je er in ieder geval zeker van dat je je gegevens alleen maar aan Google geeft, en niet aan iemand anders die meekijkt.

Ik kan niet begrijpen waarom een normale site via https bereikbaar moet zijn.
Zodra je gegevens in moet vullen begrijp ik het, maar voor een site over bosmieren schiet het zijn doel voorbij en maakt zaken nodeloos complex, denk aan varnish. Mag je weer ssl offloading gaan doen om je site snel te houden. De enige die hier garen bij spinnen zijn de SSL boeren.

Maar goed google bepaald blijkbaar en bedrijven hollen er achter aan om maar zo hoog mogelijk in de zoek resultaten te komen.

Welnee, offloading was vroeger. Nu met AES-NI in de CPU's is er absoluut geen performance penalty meer, in tegendeel. Check https://istlsfastyet.com voor meer.
En sinds ik met al m'n servers gemigreerd ben van het snelle Varnish naar het nog snellere Nginx + HTTP/2 + FastCGI cache, is het helemaal geweldig. 😃

Welnee, offloading was vroeger. Nu met AES-NI in de CPU's is er absoluut geen performance penalty meer, in tegendeel.

Ehm, nee.

Voor een HTTPS verbinding moeten namelijk de signatures in de certificaten geverifieerd worden met asymmetrische crypto (bv het trage RSA, of minder trage elliptische curve crypto), en even later is een key-exchange nodig (bv het ook niet zo snelle Diffie-Hellman). Pas daarna komt (het wel snelle) AES er aan te pas. AES-NI helpt alleen met het laatste deel, wat al snel was.

Een simpele benchmark op een van de webservers van mijn werk:

% ab -c1 -t10 http://localhost/static/login.css | grep Requests
Requests per second: 3609.70 [#/sec] (mean)

% ab -c1 -t10 https://localhost/static/login.css | grep Requests
Requests per second: Requests per second: 98.06 [#/sec] (mean)

HTTPS is dus in dit geval een factor 36 trager (het certificaat in kwestie heeft een RSA-2048-signature overigens, RSA-4096 is nog een stuk erger).

Begrijp me niet verkeerd; performance is geen goed excuus om geen HTTPS te gebruiken, en mijn benchmark is een worst-case voor HTTPS (een nieuwe verbinding voor elk 904-byte bestandje).

Maar zeggen dat HTTPS "absoluut geen performance penalty meer heeft" is gewoon onterecht. Zeg dan dat de performance-impact van HTTPS in vrijwel elke situatie acceptabel is

Nu met AES-NI in de CPU's is er absoluut geen performance penalty meer, in tegendeel.

Het maakt niks uit welke CPU je gebruikt, je gaat hoe dan ook een performance penalty hebben; "pagina serveren + encryptie" zal altijd trager zijn dan simpelweg "pagina serveren". Hoe groot (en dus, hoe problematisch) die performance penalty is, dat is een andere vraag (en daar kunnen moderne CPUs inderdaad helpen), maar de penalty zal er altijd zijn.

ps. "in tegendeel" -> bedoel je nou dat HTTPS met een moderne CPU sneller is dan HTTP!? Dat is echt volkomen onmogelijk...

[Reactie gewijzigd door robvanwijk op 29 januari 2016 01:25]

SSL kan tegenwoordig gratis (zie o.a. initiatieven zoals Let'sEncrypt en FreeSsl en StartSsl), en kostte de laatste jaren ook al lang geen drol meer (je had al een meerjarig certificaat voor nog geen 5 dollar).

En waarom: omdat het derden gewoon geen zak aangaat. Doet er niet toe welke site. EN (minstens zo belangrijk) omdat we op deze manier met z'n allen ook de tomeloze 'sleepnet-dataverzameldrift' van inlichtingendiensten een halt toe roepen.

Privacyschending is normaal geworden, men is veel te ver doorgeslagen met het automatisch aftappen van alles en iedereen. Blijkbaar kunnen we er niet op vertrouwen dat overheden zelf een weloverwogen keuze maken. Dus dan beter eigen verantwoordelijkheid nemen en het technisch gewoon uitbannen.

En waarom: omdat het derden gewoon geen zak aangaat.

?? Is een site juist niet gemaakt om zaken te delen met derden!
Als het niemand wat aangaat moet je het niet op het web zetten en thuis in een document op je server laten staan.
Nogmaals als je formuieren gaat invullen dan snap ik https. Dan wil je niet dat derden het eventueel mee kunnen lezen. Maar een informatieve site ??

Als ik een site bezoek, is dat iets tussen die site en mij. Twee partijen dus, waar buitenstaanders verder geen zak mee te maken hebben.

Met derden bedoel ik: mijn internetprovider, de AIVD en allerlei andere inlichtingen- en overheidsdiensten, de mobiele zendmast operator, kabelbeheerder, glasvezelfaciliteerder.

En wat nu een informatieve site is, is straks misschien wel belastend materiaal, of het resulteert in een paar vlaggetjes die interessant zijn om voor potentiële werkgevers of verzekeraars om op te filteren.

Wat derden wel een zak aangaat zet ik wel op twitter en facebook. De rest graag 100% encrypted.

Want alle content MOET via https? Even voorbij gaand aan het feit dat dit meer data verkeer geeft? Wikipedia lezen hoeft bijvoorbeeld van mij echt niet https eigenlijk... Of mis ik de waarde compleet ?

Nee, het MOET niet, en dit verandert daar ook niks aan. Dit icoontje laat gewoon zien wat het is: onveilig.

Het weerhoudt de gebruiker er niet van de site te bezoeken, maar misschien denkt deze er dan wel beter over na om bijvoorbeeld zijn persoonlijke informatie in te vullen.

Het is niet onveilig, het is http en ze wensen https. Een rood kruis is "te zwaar". Ook https traffic kan nog een mitm modifcatie krijgen. Alle WAF's werken namelijk zo.

HTTPS traffic kan alleen maar MITM modificaties krijgen van tussenpartijen die jij vertrouwt. HTTP van alle tussenpartijen.

SSL geeft behalve wat extra initialisatie, niet meer dataverkeer. Alleen aan begin van de verbinding dus, verder is de bandbreedte factor van orde O(1).

Het is een stuk veiliger (bij http kan je makkelijker code injecteren via MITM aanvallen).

Het is een stuk veiliger (bij http kan je makkelijker code injecteren via MITM aanvallen).

Gezien het feit dat er veel van dit soort rotzooi komt via advertentie banners (waar de site eigenaar niet eens zo veel aan kan doen behalve geen banners gebruiken) of via een lek in Joomla / Wordpress / Drupal / etc., zie ik niet dat we nu allemaal een stuk veiliger zijn dan met alleen http. Een stuk schijnveiliger misschien...

Het is inderdaad niet meteen 'super' veel veiliger, maar kleine stapjes helpen. Een paar voorbeelden: veel malware die via advertenties wordt serveerd gaat via injecties van javascipt redirects. Het zijn zelden de advertentie servers zelf die de rotzooi serveren. Die redirects zijn vrijwel altijd HTTP naar een of andere vage (gehackte) server. Zou het web HTTPS zijn zou je als malware verspreider of zelf een certifciaat moeten krijgen voor die vage server, of tegen een mixed-content beveiliging van de browser aanlopen.

Nu is het krijgen vane en vals/gestolen/etc certifcaat niet onmogelijk, maar het is wel een extra drempel. Plus dat je niet makkelijk en snel die 'vage' server kunt wisselen zodra de eigenaar ontdekt dat hij gehackt is. En zo werkt security in de prtaktijk: telkens nieuwe drempels opwerpen.

Ander voorbeeld is dat injectie van advertenties en banners voor providers, tracking cookies, en traffic shaping niet meer kan. Niet zozeer een veiligheidsaspect, maar wel privacy.

Wel weer een veiligheids aspect is dat als alles standaard HTTPS is, een Man-in-the-Middle aanval ontzettend veel moeilijker wordt. Niet onmogelijk, maar wel heel moeilijk.

Ik zou het ook fijn vinden om eoa. officieel statement van Google te vinden ergens die zegt dat je voor SEO meerdere (SSL) sites op 1 IP mag hebben. Ik zit met klanten die zo vast houden aan dat iedere site op een dedicated IP moet draaien want anders slechte SEO, en ik kan eigenlijk nergens vinden (van Google zelf) dat het onzin is.

Een mogelijk nadeel van meerdere HTTPS sites op een enkel IP adres is dat je hiervoor SNI ondersteuning nodig hebt. Oudere browsers ondersteunen dat niet, waardoor je mogelijk klanten verliest. Het marktaandeel van deze browsers is onderhand zo klein dat het vrijwel niets meer uitmaakt. Volgens mij is er geen statement van Google, omdat het Google zelf helemaal niets uitmaakt.

Maar het officiële statement van Google (bron) is ook dat het niet uitmaakt of je iets op een subdomein zet (bijv. https://blog.example.com) of dat je het als subfolder hebt (bijv. https://example.com/blog). Toch zal vrijwel iedere SEO specialist opmerken dat dit laatste betere zoekresultaten geeft. Met andere woorden... Het maakt niet uit wat Google zegt. SEO specialisten hebben hun eigen waarheid. Dat komt deels doordat Google vaak erg vaag is omtrent indexering.

Thanks. Ja, helaas nog geen zekerheid dus. Maar als Google https zo wil promoten, prima. Maar help dan die mythe de wereld uit. Het is zo zonde van de schare IPv4 space om de wens van klanten te volgen (klant is vaak toch koning) en iedere site een IP te geven. SNI gebruiken we gewoon wel, we zijn ons bewust van de oude browsers (en dat is eigenlijk gewoon "jammer joh").

Dus tweakers, gaan jullie dan eindelijk overschakelen naar https? Waarom is dit eigenlijk nog niet gebeurd? Je site komt hoger te staan in de google zoekresultaten als je https hebt.

plan: Dilemma: moet Tweakers https inzetten?

nieuws: Google wil begin 2016 waarschuwing bij elke niet-https-site in Chrome tonen

standaard https hier

[Reactie gewijzigd door flashback1989 op 28 januari 2016 21:32]

Ook met https Everywhere plugin kom je een heel eind...

Ik gebruik zelf ook https-everywhere, erg handig -> https://www.eff.org/https-everywhere

HTTPS Everywhere is een gratis en open source webbrowser extensie voor Google Chrome, Mozilla Firefox en Opera, een samenwerking van The Tor Project en de Electronic Frontier Foundation (EFF). Bij websites maakt het automatisch gebruik van de meest beveiligde HTTPS-verbinding in plaats van HTTP, indien zij het ondersteunen.

Beetje betuttelend gedrag van Google hoor. Er is nu extra informatie in de vorm van een icoon bij beveiligde sites, nu moet er nog eentje extra komen voor onbeveiligde sites? Hebben mensen moeite met lezen van de URL of zo.

En ik zie echt het nut niet in van statische sites om https te moeten hebben. Daar wordt een site over aardappels met een paar foto's echt niet veiliger van en de computer van de bezoeker ook niet.

De discussie gaat hier alweer richting het moeten hebben van https als site anders ben je een prutser. Dat is dus niet het doel van dit nieuwsbericht, jammer dat het meteen alweer ontspoort.

[Reactie gewijzigd door Bastien op 28 januari 2016 22:00]

Misschien valt het wat sneller op als er een icoon wordt getoond wanneer een website niet via https gaat?

[Reactie gewijzigd door Zeehond op 30 januari 2016 23:36]

"He, Henk een rood kruis!"
"Ja, ja, Ingrid die die heb ik al tig keer gezien sinds ik 'ja' hebt geklik voor 'er is een nieuwe versie beschikbaar voor uw browser', niks aan de hand..."

Als je mensen niet EERST leert WAT beveiligde verbindingen zijn, gaan dit soort dingen totaal niet werken.

Veiliger browsen is niet 'betere' software... veiliger browsen is onderwijs.

Plus gaat dit ook het tegenovergestelde geven: mensen nemen de waarschuwingen niet meer serieus. Wanneer er écht wat aan de hand is wordt het genegeerd.

Zelfmoord voor Chrome, want gebruikers gaan het terecht irritant vinden. En ze nemen het Google kwalijk. Dit wordt net zo vervelend als de Vista user account control. Goed bedoeld echter the wrong tree.

Hoezo?
Mensen irriteren zich toch ook niet aan het SSL slotje?
Het enige dat er verandert is dat dit slotje er *altijd* staat; alleen met een kruis erbij indien ie niet beveiligd is; en groen als ie wel beveiligd is.

Ik zie niet in waarom je je daar in vredesnaam aan zou moeten irriteren. o0

O, dan had ik het niet goed gelezen. In de titel staat waarschuwing en ik dacht aan tekst/pop up venster die je eerst moet wegklikken. Als alleen het 'slotje' icon veranderd, dan vind ik het een beetje overdreven om hier een nieuwsartikel aan te wijden.