En meer en meer bepaalt Google de werking van het internet. Wil je gevonden worden door de zoekmachine 'monopolist', dan moet je verplicht HTTPS gebruiken, een responsive website hebben en je SEO inrichten zoals Google het graag wil. Google heeft via SPDY al de nieuwste versie van HTTP bepaald, waarmee ze het belangrijkste internet protocol voor zichzelf hebben kunnen optimaliseren. Waar eindigt dit??

Hah, ik heb de indeling van mijn website ook laatst aangepast aan de hand van Google guidelines om te zorgen dat dropdown menus niet per ongeluk over advertenties kunnen komen. Google maakt zelf zich hier wel soms schuldig aan.

Wat een onzin, wanneer ik kijk naar mijn eigen websites, deze gebruiken geen Java, geen Javascript, en communiceren in kale HTML (100% volgens de W3C standaard).
Er zit ook geen antwoord mogelijk in, dus het gevaar is in mijn ogen verwaarloosbaar klein.
https heeft een certificaat nodig, bij één van de websites is dat zelfs onmogelijk (subdomein).

De grote vraag is: gaat Firefox volgen?

Niet iedere website heeft een beveiligde verbinding nodig.
Ik heb zelf ook een paar (informatieve) websites met enkel wat tekst en plaatjes, maar zonder javascript, formulieren etc.
Beheer doe ik met Notepad++, via sftp. Het gaat maar om een klein aantal pagina's. Waarom zou ik deze websites via https willen laten lopen?!

technisch gezien onwaar.

En zo gaat het verder. De monopolisten denken alleen aan hun eigen winst en zullen dus proberen om alle anderen uit de markt te drukken. Ikke, ikke, ikke . Boycotten die hap. Massaal gebruik gaan maken van alles behalve google.

De meeste websites bevatten geen content wat het beveiligen waard is. http verkeer daarentegen is veel efficiënter. Het scheelt encryptie op de server en decryptie bij de ontvanger. (Extra stoomverbruik op mobiele apparaten).
Verder kun je http verkeer goed cachen op een bedrijfs proxyserver, wat ook weer de belasting van het internet en de server verlaagd.

Ik zie alleen maar voordelen van http bij standaard websites. Daarnaast ziet iedereen toch al dat er geen slotje op zit, dus waarom nog weer extra toeters en bellen toepassen om aan te geven dat er geen slotje is?

Ik ben het met de meeste reacties niet eens.

Natuurlijk is de website zelf niet in gevaar met het http protocol, een bezoeker zelf echter wel. Denk daarbij aan proxy servers, mobiel internet en sociale engineering en malvertising.

Daarbovenop komt, dat veel mensen de hakken in het zand zetten als het maar even riekt naar 'bescherming privacy en persoonsgegevens' om vervolgens achteloos de schouders op te halen bij het vraagstuk versleutelde verbindingen voor web verkeer.

Het is in mijn optiek een 2-snijdend zwaard. Als systeembeheerder ben ik happy met niet versleutelde verbindingen waar dit dan kan uit het oogpunt van eenvoud en verhoogde privacy en versleutelde verbindingen waar dit 'noodzakelijk' is omdat ik dat veel eenvoudiger kan beheersen en beveiligen en bovendien minder cycle intensief is voor het serverfarm. Een versleutelde verbinding voor die zaken die dat vereisen, niet meer in niet minder. Althans, dat was hetgeen als vuistregel tot voor kort werd gebruikt. Dat kan nu binnenkort op de schop en ik denk met lichte voorkeur zelfs terecht.

We kunnen natuurlijk blijven google bashen, maar ik zie ook tendensen waar google heel erg goed inzicht heeft in de komende noodzakelijk veranderingen die 'goed' zijn voor het IT landschap. Ik hoop alleen dat 'don't be evil' de boventoon zal blijven voeren. En ik zie niet in, waarom https 'evil' zou kunnen zijn.

Mijn 2 centen.

Het is natuurlijk heel belangrijk om al die Wordpress kookblogs en fashionblogs van huisvrouwen te encrypted.

Niet evil, maar vaak niet nodig.
En door de http sites als niet-veilig te bestempelen worden ze gewoon als onveilig gezien door
normale gebruikers.

Om te voorkomen dat een MitM-aanvaller (NSA anyone?) tijdens het transport schadelijke content toevoegd. Dat de webserver geen Java, Javascript o.i.d. levert, weet de browser van de gebruiker niet. Als het verkeer aangepast wordt, kunnen de bezoekers net zo goed met malware geïnfecteerd worden. En nee, de gemiddelde internetter heeft geen NoScript om toegevoegde meuk te blokkeren.

Ander thema: Het zou goed zijn als Chrome dan ook gelijk de leek duidelijk maakt dat https niet betekent dat de website veilig is, maar alleen dat de browser een verbinding met de gewenste server heeft gemaakt. De inhoud van de website (ads, phishing-forms, etc.) kan over https (met een DV-certificaat) net zo goed kwaadaardig zijn.

Dat houd je echt niet tegen met https hoor! Zeker niet meer nu de kwaliteit van de certificaten zo downgraded is.
Iedereen die een MiTM op jouw website kan uitvoeren kan een certificaat voor je aanvragen waardoor het ook met https
gewoon nog kan.

Nee, dit is echt een totaal nutteloze operatie.

Misschien een domme vraag, maar wat heb je nog aan het webscannen van je antivirusprogramma als zoveel mogelijk websites gebruik moeten gaan maken van https?
Bij mijn antivirusprogramma kan ik instellen dat het ook https-sites scant, maar dat vertrouw ik niet zo... Het idee dat je het originele certificaat dan niet meer kunt zien (soort van man-in-the-middle) vind ik niet veilig.
Of kun je deze functie tegenwoordig beter wel aanzetten?

Ik begrijp niet helemaal wat de toegevoegde waarde is van het gebruik van HTTPS bij websites die uitsluitend publieke data bevatten, d.w.z data die iedereen kan en mag lezen. Als je kan inloggen, een persoonlijke omgeving hebt, voorkeuren kan opslaan, etc etc natuurlijk wel, maar voor een site als, zeg, www.nu.nl zie ik niet in waarom je dat zou willen encrypten.

Iemand een goede reden anders dan "encrypt all the things!" ?

Maar door het standaard toe te staan voor alle websites, heb je eigenlijk zelf al de deur opengezet............

Ik begrijp niets van de bovenstaande boze reacties.

Chrome gaat geen verbindingen met http websites weigeren, Chrome gaat alleen duidelijker maken dat het bij http:// om een onveilige verbinding gaat. D.w.z. dat je niet zeker weet dat je met de bedoelde server communiceert (d.w.z. waarvan de domeinnaam in de URL-balk van de browser wordt getoond), en dat bovendien de verbinding niet versleuteld is (afgeluisterd kan worden, dus geen vertrouwelijkheid en/of privacy) en de informatie bovendien manipuleerbaar is (geen garanties m.b.t. de integriteit).

Ik vind dat wel een waarschuwingssignaal waard; de bezoeker van de website mag er toch ook wel wat van vinden? En ik verwacht dat dit phishing weer ietsje lastiger maakt; de meeste phishingmails verwijzen nu naar nepsites met http URL's, en dat levert in de huidige browsers nog geen waarschuwingssignaal op.

Je kunt niet een MiTM aanval uitvoeren op "een website". Wel kun je, als je daartoe in de gelegenheid bent, een MitM aanval uitvoeren op de verbinding tussen "jouw" (een willekeurige) website en een ander internet IP-adres.

Alleen als je een MiTM aanval kunt uitvoeren op de verbinding tussen een specifieke website (of bijbehorende mailserver) en de servers van Let'sEncrypt (of een andere DV certificaatprovider), dan kun je, onrechtmatig, een certificaat krijgen voor die website.

Dat dit kan vind ik heel slecht, maar het is ook weer niet zo erg dat certificaten hiermee totaal nutteloos worden (want niet iedereen kan zo'n aanval op een dergelijke plaats zomaar uitvoeren).

Erik van Straten++
De rest is overduidelijk anafabeet want ze kunnen overduidelijk niet lezen.

Firefox gaat ook deze richting op! In de Developer releases kan je het bewonderen op sites met insecure password-forms.

Denk je echt dat een gebruiker nog naar dat symbooltje kijkt?
Je kunt een gebruiker wel 1 keer uitleggen "als er een slotje staat is het veilig" maar als je dan vervolgens ieder jaar
de betekenis daarvan verandert, de kleur anders maakt, er kruisjes bij gaat zetten, bestaande betekenissen gaat
veranderen (als er een slotje staat betekent dat niks) etc dan gaan ze daar op een gegeven moment gewoon niet meer
naar kijken. Dat punt is allang gepasseerd.

Als dat zo zou zijn, snap ik echt helemaal niets meer van de boze http-website-eigenaren hierboven...

De waarheid zal wel weer ergens in het midden liggen. Google vertelt maar een deel van het verhaal en om sommigen hier gelijk te geven "waar de vos de passie preekt, boer let op je kippen". Ga maar eens naar de https everywhere atlas en zie waar het daar bij domeinen nog aan e.e.a. schort. Header security, men is nog niet eens goed en wel begonnen te implementeren. Hele continenten met beveiligingsachterstand vanwege Amerikaanse export beperkingen (bijv. mainland China). Op de site waar ik dit berichtje schrijf zie ik het volgende met Tracker SSL: 75% of the trackers on this site could be helping protect you from NSA snooping. But, even though security.nl uses HTTPS, there's at least one third party that's been communicating insecurely.
Tell security.nl to fix it. Unique IDs about your web browsing habits have been insecurely sent to third parties.
3~bjc6eehxxxxxxxxmt801fugp3 -www.security.nl sessionid
-local.adguard.com 4 partijen doen aan IDS tracking en weten dat ik dit bericht zit in te kloppen - www.security.nl
local.adguard.com local.adguard.com; Google; www.mustbebuilt.co.uk en Legend.

Over sommige zaken die Google deelt mag het zelfs geen mededelingen doen, en ligt het onder "government gag order". Als we dus een duistere overheid krijgen, kan je voor een bepaald twitter bericht de politie over de vloer krijgen.
Leer mensen op de werkvloer eerst eens hoe ze een website veilig in de lucht moeten krijgen en houden, log, monitor, patch, upgrade, voer brakke en onveilige en verlaten code af. Leer de eindgebruiker (misschien van de lagere school af) hoe hij, zij en het zich beter kunnen weren tegen onveilige websites (ja, http en https-only), leer ze over script en advertentie blokkeren, over het gevaar van java en javascript, onveilige webformulieren, frauduleuze clicks en andere onveiligheid.
Leer eenieder dus zelfredzaamheid. Google laat je daar het liefst over in het duister, beter voor hun verdienmodel. Ze doen veel, maar is dat ook met de beste intensies?
Ten slotte, ga eens deze pagina scannen hier: http://cyh.herokuapp.com/cyh ->
Security Headers for https://www.security.nl/posting/459148/Google+Chrome+wil+http-sites+als+onveilig+weergeven
Using user-agent for Chrome 30.0-WinXP 32-bit
Ik krijg zes headers met "best policy", drie met een waarchuwing en vier die ontbreken. Laten we ons eerst eens op deze zaken gaan richten.

Boos ? helemaal niet !
Alleen zie ik er het nut niet van in, wanneer er geen privé gegevens verzonden worden.

Wat Google hier doet is belangrijk om het volgende.

1. Er zijn nog zeer veel websites die wel HTTPS zouden moeten hebben maar dit niet doen. Ik kom nog bijna dagelijks site tegen waarbij je over HTTP:
- Kan inloggen
- Een formulier met persoonsgegevens kan verzenden
- En ja zelf ook sites die een volledige medische amnese afnemen.
Allemaal over HTTP.
(de ervaring leert dat ijk van security.nl geen voorbeelden mag geven want dan laten de moderators mijn bericht niet door maar. ik heb momenteel 3 incidenten aanstaan waarbij er medische gegevens via HTTP worden verzonden. Dit gewijzigd krijgen bij de website beheerder is soms als trekken aan een dood paard.)
2. Als een dissident, mensenrechten activist, journalist of wie dan ook in de kijker van een overheid komt 1 HTTP pagina bezoekt kan het over zijn. Aan de HTTP pagina wordt extra code toegevoegd en boem het is over een sluiten voor deze en gene. de exploit is geladen en de firmware rootkit is geïnstalleerd. Alleen maar omdat hij wilde weten wat de bakker om de hoek voor openingstijden had.

Nog even wat leesvoer:
Baidu’s traffic hijacked to DDoS GitHub.com
http://insight-labs.org/?p=1682
Hotspots AT&T injecteren advertenties in wifi-verkeer
https://www.security.nl/posting/441059/Hotspots+AT%26T+injecteren+advertenties+in+wifi-verkeer
Israeli Firm Strong-Arms Indian Techie for Exposing Suspicious Code
http://thewire.in/2015/06/09/israeli-firm-strong-arms-indian-techie-for-exposing-suspicious-code-3528/

SSL gebruik je om de dataverbinding te beveiligen. Helaas werkt SSL niet tegen een besmetting van je server via malware en kan er dus een vals gevoel van veiligheid optreden. En een besmetting kan best snel optreden, zeker als het om sites gaan op een shared hosting omgeving!

Een besmetting van jouw server kan b.v. betekenen dat een hacker een extra pagina aanmaakt op jouw site waarop bezoekers gevraagd worden om in te loggen voor een bepaalde service. B.v. PayPal, GMail of wat dan ook maar. Dat zou dan niet via SSL gaan, zou je verwachten. Maar helaas! Als je hoofddomein met SSL is beveiligd dan zal deze malware-pagina ook via hetzelfde certificaat beveiligd worden en zullen mensen dus een mooi slotje zien en denken dat alles in orde is.
En controleren mensen wel de URL? Of klikken ze op het slotje om het certificaat verder te inspecteren? In het algemeen niet, volgens mij.

Dus nu Google gaat afdwingen dat iedereen op SSL moet overstappen gaat straks ook een boel malware automatisch mee beveiligd worden en lijkt het mij dat we in de toekomst juist onveiliger gaan internetten! Een server raakt besmet met malware die op de server extra login pagina's aanmaakt om zo populaire login-sites na te bootsen. De boel is beveiligd omdat SSL door Google is afgedwongen dus de malware verbinding is lekker veilig. Via het dataverkeer kan dan niet eens meer gezien worden dat er data richting een malware-site gaat.

Het lijkt mij dat hackers nu zullen proberen om beveiligde domeinen te hacken en te infecteren. Dat zal nog niet al te eenvoudig zijn, maar er zijn wel vele truken te bedenken. Bij shared hosting, bijvoorbeeld, ga je gewoon zelf een pagina beginnen bij die host. Nepgegevens invullen en een gestolen creditcard gebruiken en vervolgens je malware-tool uploaden en kijken of je deze op de een of andere manier kunt laten uitvoeren. (Bij Windows/IIS heel eenvoudig! Gewoon onder IIS hangen en dan de URL aanroepen als https://example.com/malware.exe en klaar!) Okay, je moet dan wel enkele kwetsbaarheden weten binnen het besturings-systeem maar die zijn er genoeg.
Is de malware eenmaal uitgevoerd dan kan deze proberen zichzelf verder te verspreiden.
Voor het besmetten van andere servers zijn genoeg methodes over.

Dus nee, ik ben tegen het afdwingen van SSL. Het draagt namelijk alleen bij aan schijnveiligheid! Maar goed, als Google dit doorvoert kunnen we altijd overstappen op andere web browsers. Of iemand gaat gewoon een branch maken van het Chromium project en dan komt er een concurrent op de markt waar het slotje gewoon bij het oude blijft...

En dat is exact wat ze zijn! Zonder HTTPS kan je computer niet controleren of je met de juiste site communiceert. Man-in-the-middle aanvallen kunnen dus niet gedetecteerd worden. Een gebruiker heeft dus geen idee of ie de juiste inhoud te zien krijgt. Verder kan iedereen op de juiste plek op het netwerk het verkeer afluisteren. Hoog tijd dat HTTP verdwijnt.

Duh. Nee, natuurlijk werkt SSL niet regen rotte, lekke sites. Het werkt tegen MitM-aanvallen en het aanpassen en afluisteren van verkeer. Het is dus een oplossing voor hele andere beveiligingsrisico's. Geen schijnveiligheid, maar een onderdeel van een pakket aan nodige maatregelen.

Stel een kennis van jou bezoekt, via een publieke WiFi hotspot, jouw website http://www.ron625.nl/ - althans dat is de URL die zij invoert (of de snelkoppeling die zij gebruikt).

De DNS-server instelling heeft haar notebook, tablet of smartphone van de WiFi router gekregen - een access point dat net zo goed van een aanvaller als van de rechtmatige eigenaar kan zijn. Maar ook in dat laatste geval kan deze andere belangen hebben. In elk geval moet je maar afwachten of het IP-adres dat haar browser terugkrijgt na een DNS lookup van www.ron625.nl wel het IP-adres van de echte www.ron625.nl is. Nb. als in de URL balk https://www.ron625.nl/ staat en een ander IP-adres wordt aangeboden, zal de browser een foutmelding geven, omdat de server met dat (afwijkende) IP adres (normaal gesproken) geen geldig certificaat voor www.ron625.nl kan opsturen naar de browser.

De echte www.ron625.nl zal de gebruiker niet vragen om privé gegevens te verzenden. Maar dat hoeft niet te gelden voor een nepsite. Jouw kennis weet dat jij security-aware bent, en zal wellicht niet gek opkijken als "jouw" website ineens meldt: Nog een mogelijkheid: Of de kennis wordt de stuipen op het lijf gejaagd met "Deze website is gehackt en nu ook jouw computer" en/of met (kinder-) porno plaatjes met daarbij "en die staan nu ook, niet te verwijderen, op jouw PC!", of "al jouw bestanden zijn versleuteld" etc. etc.

Okay, stel jouw website is gehost bij een provider die DNSSEC ondersteunt, en de apparatuur van jouw kennis checkt daarop (kleine kans, maar goed, stel dat). Dan kan de aanvaller nog steeds on-the-fly webpagina's wijzigen, overlays plaatsen of delen vervangen (o.a. advertenties invoegen). Bijv. met de melding: Of:
Of:
Of een messagebox met: Of, als de browser en/of plugins niet up-to-date zijn, een exploit meesturen die malware installeert.

Natuurlijk heb je gelijk als je zegt dat de kans hierop in de praktijk erg klein is, en veel mensen trappen niet overal in en een aantal houdt PC's en andere devices up-todate. Maar uitsluiten dat niemand hier slachtoffer van wordt, kun je niet.

Als jij wilt dat mensen jouw website bezoeken, moeten die bezoekers er m.i. op kunnen vertrouwen dat ze daar zo min mogelijk risico mee lopen. Eigenaren van sites die http blijven gebruiken, lappen dit aan hun laars. Met name website-eigenaren die security.nl bezoeken, zouden beter moeten weten.

Geheel mee eens. Belangrijk is wel dat we gebruikers "opvoeden" door ze te leren waar dat slotje voor staat, en dat is niet "een veilige website".

Je betoog is duidelijk :-)

wel leuk dat dat Googol in de Chrome browser standaard de adresbalk zo veel als mogelijk is verbergt. Dan leren gebruikers het natuurlijk nooit...

Straks willen ze ook dat we verplicht allemaal de Google DNS servers gaan gebruiken zeker. Veeeeeeel veiliger.
Oh, en dan nog wat: Google = EVIL! Nough said.
Smerige monopolisten zijn het, allemaal.

@Erik van Straten,

Het groene slotje beschermt dan weliswaar het bestaande protocol, maar dat is toch in sommige opzichten weer niet helemaal zo. Het beschermt namelijk niet tegen tracking via unieke IDs. Er is gelukkig voor de commerciële tracker en de trackers bij de overheid wat dat aangaat nog niets bij protocol geregeld. NSA snooping bijvoorbeeld kan dus zo ongehinderd doorgaan, direct of via derde partijen die dit aanleveren, tenminste als de hele boel niet 100% veilig wordt verzonden.
Alle SSL websites zou Google dus ook moeten verplichten om unieke IDs bijvoorbeeld 100% veilig naar derde partijen te verzenden.
Ik heb ze daarover nog niet gehoord en ik vrees dat we ze er niet over zullen horen ook. Ik zie verder nog vele https sites waar de log-in nog gewoon onveilig over de draad gaat.
Het zowel mensen die met domeinen/websites omgaan als eind-gebruikers tot veiliger gedrag opvoeden is een van de eerste vereisten.

Even vanuit een privacy perspectief bekeken:

Mensen kunnen als ze een verbinding afluisteren met SSL/HTTPS/TLS alsnog zien welke website iemand bezoekt.
Welke pagina men bezoekt zou wel veilig moeten zijn (GET/POST).

Dus iemand bezoekt: https://www.medicijnen.org, iedereen kan dat zien/achterhalen via DNS requests,handshake opbouw en nog wat dingen. Echter niet dat de bezoeker een bepaalde pagina oproept op die website ( Request header, GET /aandoening/aids.html ).

Ik zie hierboven wat mensen die zich afvroegen waarom hun simpele HTML site zonder forms enz. encrypted zou moeten zijn, dan zou dit een privacy reden kunnen zijn. Het biedt dan uiteraard geen bescherming op het werk, door https adult sites te bezoeken.

Iedereen begrijpt hier denk ik wel dat het qua veiligheid weinig toevoegt verder als iemand geen formulieren en simpele HTML opbouw heeft.

ben vooral benieuwd hoe de ad boeren dit gaan doen...straks krijg je op elke nieuws website allerlei meldingen over mixed content..

De "ad boeren" leveren hun content keurig over https als de website ook https is. Mits goed geconfigureerd natuurlijk.