Ik vind het eerlijk gezegd vrij misleidend om https sites allemaal als veilig te bestempelen voor de eindgebruiker.

En http heeft gewoon caching voordelen waarbij het aantrekkelijk is om te gebruiken op sites met weinig interactie. Dus het streven om het af te schaffen vind ik eigenlijk ook niet zo geweldig. Voor kleine hobby websites drijft het de prijs alleen maar op.

HTTPS sites worden ook niet als "veilig" bestempeld.
HTTP sites (waarop gevoelige gegevens moeten worden ingevuld) worden als "onveilig" bestempeld en zijn dat in feite ook doordat ze de betreffende gegevens niet versleuteld versturen. Alleen het aanzetten van https maakt ze ook niet per definitie "veilig".
Voor kleine hobby websites kun je gewoon lets encrypt gebruiken, dat kost helemaal niets en op dat soort websites zul je het ook echt niet merken in de performance. Vergelijk het met de verplichte kreukelzone in auto's, de negatieve effecten zijn zeer beperkt (fabricagekosten/brandstofverbruik door extra gewicht) en de positieve effecten zijn duidelijk minder letsel bij ongelukken. Is een auto met een kreukelzone per definitie "veilig" te noemen? Nee, maar wel veiliger dan een gelijke auto zonder.

Voor hobby heb je voor 10 euro een ip. Met Lets crypt kan je gratis certificaat genereren.
Alternatief is cloudflare. Deze oplossing is zelfs gratis.

Ik vind het eigenlijk wel goed. Ik stoor me aan websites die het niet hebben.

Voor veel informatie boeit het voor geen meter of iemand eventueel meeluistert of niet. Door alle HTTP als 'niet veilig' te brandmerken verwaterd hun systeem gewoon en heeft het dadelijk geen waarde meer om sites die daadwerkelijk schadelijk (kunnen) zijn te onderscheiden.

Snake-oil for the uninformed aka kwakzalf eerste soort voor die niet weten waar het over gaat.

Wat weten we dan nog???? Dat Google staat achter de https-everywhere beweging. Het geeft immers verhoogd valse veiligheid! Blader eens door de https everywhere atlas online en ril en huiver! bij nader kennis nemen.

En Google meent en nu 'oogjes dicht en snaveltjes toe', beste website kindertjes.

Er zijn veilige http web sites, die goed input en output monitoren en waarvan het bezoek zeker geen gevaar oplevert.

Er zijn veel "draken" van https sites, waar de log-in nog in platte tekst over de draad gaat. Zo te monitoren bij de NSA voor meta-data, want sites die 60 tot 100 procent openstaan voor onveilige IDs tracking.

Bovendien hebben veel https sites ook gedeeltelijk onveilig script dat toegang wil. Geen groen slotje dus!

Er zijn veel websites die geen security headers hebben geïmplementeerd, waar zwaar gezondigd wordt tegen de "same origin" policy. voor meer dan 3rd party code en stylesheets. Geen sri-hashes gegenereerd, widget code over te nemen is vanwege clickjacking kwetsbaarheden,

CMS code die afgevoerd moet worden, verkeerd geïnstalleerde certificaten, DROWn kwetsbare naamservers, stealth naamservers, en die buitensporige serverversie info verspreiden. en ga zo nog maar een tijdje door.

Dan moet je de ene helft als potentieel onveilig bestempelen, omdat het niet in overeenstemming is met best policy implementatie. En de andere helft als potentieel iets veiliger.

Tenslotte daar waar alles klopt volgens het boekje hebben we een "rara avis" oftewel een zeldzaamheid. A-status all around, Ik kom het zelden tegen.

Dus dit soort stemmingmakerij voegt veiligheidsmatig echt niet veel toe. Klik veilig, mensen.

Hoewel de auteur in [1] het aanvankelijk heeft over "HTTP connections", verandert dit al heel snel in "HTTP sites" en draagt zo bij aan het, m.i. zeer ernstige, misverstand dat een slotje en andere markeringen iets over de veiligheid van de site zouden zeggen. De redactie corrigeert dit beeld helaas niet, integendeel.

En zo moeilijk is het echt niet: een slotje geeft aan dat jouw browser heeft vastgesteld dat je daadwerkelijk verbinding hebt met de website waarvan de domainname in de URL balk van jouw browser wordt getoond (ongeacht het IP-adres, waardoor de onbetrouwbaarheid van DNS geen rol speelt meer speelt), en dat die verbinding versleuteld is.

Dat zijn allemaal legitieme argumenten, maar daar staan de risico's, die (met name WiFi-) gebruikers lopen, tegenover.

Persoonlijk vind ik het een uitstekend idee als we het aantal ongeauthenticeerde en onversleutelde Internetverbindingen minimaliseren, en waar dat niet "kan" of door de serverbeheerder als onwenselijk wordt beschouwd (bijv. omdat het te duur is of te ingewikkeld gevonden wordt), mensen gewaarschuwd worden als ze dergelijke, potentieel onveilige, verbindindingen gebruiken.

[1] http://blog.chromium.org/2016/09/moving-towards-more-secure-web.html?m=1

https sites zijn niet veiliger, het transport is iets veiliger, de site kan nog steeds brak zijn. https is ook niet te cachen voor consumenten. en het kost veel cpu om te encrypten. en is ook onzinnig voor een verbinding die nooit het lan verlaat en waarbij het lan alleen betrouwbare gebruikers bevat.
dat geouwehoer met chrome nu al op mijn eigen servers MET https zorgt er nu al voor dat ik MSIE gebruik, want firefox zit net zo erg te miepen.
2016.. het jaar dat je MSIE gebruikt omdat het gebruikersvriendelijker is.. moet niet gekker worden.

Zo'n naïeve reactie verwacht ik op Tweakers, maar niet op security.nl.

Hoewel het privacyaspect een rol speelt, kan iemand met toegang tot de verbinding ook informatie (in beide richtingen) wijzigen. Wat de bezoeker van een http website leest is daarmee sowieso altijd minder betrouwbaar.

In hoeverre een aanvaller er baat bij heeft om iemand andere informatie voor te schotelen dan de website levert, hangt grotendeels af van het soort informatie op die website. Echter doelgerichte aanvallers kunnen ook op ogenschijnlijk flauwe kul sites informatie injecteren die een specifieke bezoeker op een verkeerd been zet.

Voorbeelden:
1) op nu.nl een nepbericht waarin staat dat veel rekeningen van de bank van het slachtoffer zijn geplunderd, in de hoop dat het slachtoffer gaat internetbankieren en niet op een ontbrekend slotje let;
2) op je klaverjaswebsite een artikelje (met downloadlink) dat de vereniging een licentie gekocht heeft voor een bekend klaverjasoefenprogramma, gratis te gebruiken door de leden.
De mogelijkheden zijn legio.

Maar aanvallers kunnen meer. O.a. door DNS manipulatie kunnen zij jou op een totaal andere site laten uitkomen dan bedoeld (terwijl de correcte domainname in de URL balk van de browser wordt getoond). Ook kan de aanvaller bijv. kwaadaardige Javascript en/of malware injecteren (bijv. middels een popup melden dat een plugin moet worden geïnstalleerd of geüpdated, of meteen een exploit "inschieten").

Extra kwetsbaar zijn bezoekers van websites die, voor algemene pagina's, http toestaan (of zelfs vereisen door naar http te schakelen als je https probeert) en pas naar https schakelen als er vertrouwelijke gegevens moeten worden uitgewisseld. Een MitM (Man in the Middle) aanvaller realiseert op dat moment de versleutelde verbinding met de site en wisselt informatie via http uit met de gebruiker - die zich niet realiseert dat de verbinding naar https had moeten omschakelen.

Met name omdat het op internet nog barst van dat soort sites (maar ook vanwege de eerder door mij genoemde redenen) vind ik het een uitstekend idee om gebruikers te waarschuwen als ze ongeauthenticeerde en onversleutelde verbindingen gebruiken.

De protocollen http en https hebben niets te maken met de betrouwbaarheid (al dan niet schadelijk zijn) van websites.

Door https i.p.v. http te gebruiken voorkom je dat derden zich sneaky met verbindingen tussen webbrowsers en websites kunnen bemoeien (blokkeren, DoS dus, kunnen MitM aanvallers nog wel). Onder bepaalde omstandigheden is https zeer zinvol, maar het is niet zo dat https betekent dat de primaire website zelf, of secundaire websites waar de primaire website jouw browser content laat ophalen, betrouwbaar zijn.

Dat is minder eenvoudig dan je het doet voorkomen. In de keten van een eindgebruiker naar de website zijn er weinig tot geen locaties waar iemand zomaar even wat neer kan zetten om http verkeer om te leiden. Een dure operatie om wat informatie te vervalsen, dan dat moet dan wat opleveren. Het is eenvoudiger om iemands pc te hacken (kan op afstand), of via een openbaar wifi acces-point te vissen. Dan helpt ook HTTPS niet vanzelfsprekend meer, en tja, als je over publieke wifi je bankzaken regelt ...


Dan moet je ergens in de verdeelkasten van de provider iets neerzetten dat http verkeer onderschept en omleidt. Hoe succesvol gaat dat zijn? Niet echt. Of je breekt in bij de eindgebruiker en vervangt zijn router? Kun je er net zo goed meteen een neerzetten die ook https verkeer onderschept. Hackt zijn PC, dan helpt ook https niet meer.

En als je zo gericht aanvalt werkt een via de post bezorgde brief waarschijnlijk beter om slachtoffers om de tuin te leiden. Anderzijds kun je ook nu.nl proberen te hacken, of om de tuin te leiden. Email werkt ook nog best goed.


De website hacken is veel eenvoudiger, en goedkoper, en doeltreffender.

Dat heeft niets met de veiligheid van HTTPS versus HTTP van doen. Als een aanvaller succesvol het DNS voor een gebuiker kan manipuleren helpt ook https niet meer, tenslotte wordt om een certificaten te verifiëren ook DNS gebruikt. DNSSEC helpt iets, en een lokale resolver gebruiken misschien nog meer, maar wie doet dat nog. Het blijft nog steeds een dure oplossing om hardware te installeren tussen de pc van de gebruiker en het internet. Goedkoper is het om direct een pc aanvallen, pf te vissen op een publieke wifi en ook dan helpt ook https niet meer en is zo'n slotje eigenlijk valse veiligheid.

Daar helpt het kruisje van Google dan weer niet bij, sites die content deels via http aanbieden vallen hier ook onder, of ze Google mist weer te veel. Je moet wel duidelijk maken wat de zwakte van zo'n site (of domein) precies is.

Waarschuwen is prima, het 'slotje' kan niet groot genoeg zijn, maar gooi niet te veel op deze hoop want als gebruikers dat kruisje maar vaak genoeg (moeten) negeren dan wordt dat een gewoonte. Overigens garandeert een groen slotje niet dat je verbinding ook echt 'veilig' is en met de site die je denkt dat het is.


Mijn fout, ik meende oorspronkelijk dat dit over hun 'safe-browsing' indicaties bij zoekresultaten ging.


Dat snap ik. Over een niet-vertrouwde verbinding, dan wel netwerk, is ook HTTPS niet betrouwbaar. Eigenlijk zou je certificaten op het systeem moeten cachen, of zoiets, en een waarschuwing geven als een certificaat (onverwacht) wijzigt. Ook analyse van de aangeboden certificaten, als ze allemaal dezelfde root hebben is er iets fout, zou welkom zijn. Ik zou dat liever zien dan dat emmeren over http wat ze nu doen.

Laten we inderdaad maar onversleuteld logingegevens over het internet sturen :).... Zoveel kost een certificaat niet; €5 per jaar? En de meeste webhosting partijen laten je dit zonder issues installeren omdat je toch op shared hosting meerdere SSL certificaten kan toepassen.

Echter de persoon kiest ervoor om een website te hebben, dat betekend ook dat je met de veranderingen mee gaan.

Zoals hierboven gezegd, wanneer gaat Google DNSSEC ondersteunen?

Dat maakt het al een stuk veiliger want de groep mensen die DNSSEC kan manipuleren is een stuk kleiner dan de groep die DNS kan redirecten.

Open (gratis) wifi.

En ook op je eigen netwerk kun je nooit zeker zijn dat het 100% veilig is. Als je in je eigen netwerk onversleuteld verkeer uitwisselt, kan iemand die al op dat netwerk zit, meer machines overnemen.

Aanvulling op het voorbeeld van nu.nl: Je hoeft geen nieuwsbericht aan te maken. Je kunt eenvoudig een besmette advertentie meesturen.

Peter

Dat kan voor jouw deur. Als de notebook/tablet/e-reader/smartphone die jij gebruikt, verbinding heeft gehad met een public WiFi access point (eventueel met wachtwoord, maar dan moet de aanvaller dat wachtwoord kennen - wat zelden een probleem is) en die associatie is niet verwijderd uit het device, en de aanvaller biedt een sterker signaal aan dan jouw modem, dan is er een kans dat jouw device via het AP van de aanvaller gaat communiceren en jij dit niet merkt. Toegegeven, voor doorsnee burgers is de kans op zo'n heel gerichte aanval natuurlijk niet zo groot, maar uitsluiten kun je dit niet. En belangrijker wat mij betreft: niet iedereen is een doorsnee burger (er zijn allerlei soorten mensen waar wel veel te halen valt, denk aan jouw huisarts of specialist).

En wat Peter al schreef: op vakantie, in de trein, op vliegvelden etc. maken we met z'n allen massaal gebruik van public WiFi, en dan ben je zo kwetsbaar als het maar kan.

Je hebt gelijk dat een operatie "lonend" moet zijn. Maar het gaat niet alleen om geld; denk aan stalkers, burenruzies, netwerkgluren in studentenhuizen etc.

Dit is een kul argument, want het is helemaal niet zo eenvoudig om een willekeurige PC te hacken als je geen toegang hebt tot verbindingen met die PC.

Bij een gehackt device heeft de gebruiker inderdaad niets meer aan https. Maar https i.p.v http helpt wel in een aantal gevallen voorkomen dat devices worden gehackt.

Bij een gehackte router (en/of modem) of kwaadaardige WPAD proxy biedt https absuluut bescherming, indien:
- De bezochte websites HSTS inzetten en de betrokkene die sites niet te lang geleden heeft bezocht, of
- De gebruiker opmerkt dat een verbinding http is terwijl zij https verwacht. De waarschuwing van Chrome draagt hier aan bij.

Dat zijn inderdaad allemaal risico's maar die staan los van het beveiligen van verbindingen met websites.

Dat geldt niet voor alle websites. Een gebruiker die uitsluitend niet gehackte websites bezoekt is gebaat bij https in plaats van http. Net als bij het vorige punt kom je met andere aanvalsscenario's i.p.v. steekhoudende argumenten.

Dat is volstrekt onjuist.

Als de gebruiker bijv. naar https://www.security.nl/ surft en de browser het IP-adres van www.security.nl opvraagt, retourneert DNS ofwel het IP-adres van de bedoelde webserver, ofwel een gemanipuleerd antwoord. Bij een gemanipuleerd antwoord krijgt de gebruiker altijd een certificaatfoutmelding te zien (tenzij de private key van www.security.nl gelekt is, of als een certificaatprovider een certificaat voor www.security.nl heeft uitgegeven aan iemand die niets met security.nl te maken heeft). Daardoor zijn https verbindingen totaal onafhankelijk van DNS.

Irrelevant in deze context, zie DNS hierboven.

Je vervalt in herhalingen.

Het initiatief van Google (waar ik volledig achter sta) is het uitroeien van http. Vanzelfsprekend geldt dat ook voor sites met mixed content, ook daar hoort een rood kruis bij.

Goed dat we het met elkaar een zijn dat zo min mogelijk sites http moeten gebruiken i.p.v. https!

Daarin heb je absoluut gelijk, maar dat is een andere discussie - die wel steeds gevoerd moet blijven worden (niet voor niets heb ik er op deze site op gehamerd dat RC4 te zwak is).

Vanzelfsprekend moeten we https goed toepassen. Zaken als betrouwbare authenticatie van de betreffende website (feitelijk wil je de identiteit van de verantwoordelijke organisatie achter een domainname kennen) zijn loeibelangrijk, maar voor huis-en-tuin websites kan een self-signed certificaat dat 30 jaar geldig is, goed genoeg zijn om van de voordelen van https boven http te profiteren.

https is niet 100% betrouwbaar en zal dat nooit worden. Maar een https verbinding is, om de door mij aangevoerde redenen, wel véél betrouwbaarder dan een http verbinding.

Als ik dit zo lees, vraag ik me af of er überhaupt op Internet wel iets veilig(s) is. Als het toch allemaal niet veilig is, dan kunnen we beter opdoeken met elke website en elk gebruik met de eigen computer. Valt het hele systeem sowieso wel te vertrouwen? WWW World Wide Web zegt al dat alles de hele wereld rondgaat. Wat is nog veilig?

Nee hoor. En niet alleen omdat ik uitstekend uitzicht heb vanuit mijn raam. Maar ik ga even kortsluiten om bij de kern te blijven.

Het punt is juist dat wanneer een aanvaller zich een positie heeft weten te veroveren waarbij hij je HTTP verkeer kan omleiden, hij ook in een positie is waarbij hij dat met HTTPS kan. Tenzij je browser alle certificaten kan valideren zonder controle t.o.v. een externe certificaat validatie zou je bij een MitM namelijk ook die validatie kunnen onderscheppen.

Onze firewall met Intrusion Prevention System blokkeert bestanden (zoals javascript) indien verdachte inhoud wordt gezien. Met een HTTPS verbinding is de inhoud versleuteld en kan hij zijn werk niet doen. Er moet een reverse proxy tussen komen om te zorgen dat versleuteling tussen web server naar firewall loopt en tussen firewall en client zodat IPS weer z'n werk kan doen.

Per definitie is HTTPS dus niet veiliger dan HTTP.

Ook kan de Man In The Middle nog proberen eerst een server certificaat te stelen en je daarna verleiden via hem zaken te doen.

Het beste werkt gezond verstand en enige achterdocht. Bewustzijn van mogelijke gevaren. En zelfs dan ...

Als dat zou kloppen zou je gelijk hebben dat https niet veiliger is dan http, maar gelukkig klopt jouw stelling niet. D.w.z. omleiden kan, maar ofwel de MitM ziet uitsluitend versleuteld verkeer tussen webbrowser en de bedoelde website, ofwel de gebruiker krijgt een certificaatwaarschuwing.

Nee dat kan niet. Ik ken 2 systemen:

1) Een complete set rootcertificaten "preloaded" (meegeleverd met full versions of updates). Voorbeelden: Firefox en Java SE.

2) Een minimaal aantal rootcertificaten, en dynamisch aanvullen indien nodig. Microsoft Windows doet dit sinds Vista als ik me niet vergis. Indien een specifiek rootcertificaat niet aanwezig is, kan een MitM aanvaller verbindingen met Microsoft sites wellicht blokkeren en zo verhinderen dat het benodigde rootcertificaat wordt nageladen, maar dan zal het servercertificaat niet valideren en krijgt de gebruiker een certificaatfoutmelding.

Wat een MitM wel kan saboteren zijn CRL en/of OCSP requests, iets waar de aanvaller wat aan heeft indien zij/hij over de private key van een revoked (ingetrokken) certificaat beschikt. Echter, als de gebruiker de default instelling "silently ignore" heeft gewijzigd in "block upon CRL/OCSP failures", werkt zelfs dat niet.

Ernstiger is dat een MitM tussen de webserver en CSP (Certificate Service Provider) in de meeste gevallen een DV certificaat (waaronder Let's Encrypt) kan verkrijgen. Maar MitM aanvallen op dat soort plaatsen zijn (voor anderen dan geheime diensten) veel lastiger uit te voeren dan via bijv. (public) WiFi.

Dat klinkt prachtig in reclamemateriaal maar werkt voor geen meter. Veel van de gespamde ransomware downloaders in het afgelopen jaar bestaan uit obfuscated javascript waar aanvankelijk geen enkele virusscanner op aanslaat (dat duurt uren - als jouw virusscanner de specifieke malware ooit al gaat detecteren). Bij e-mail heb je nog het voordeel dat het enige tijd kan duren voordat de gebruiker zijn mail opent en zijn virusscanner ondertussen is bijgewerkt; als verse Javascript malware jouw firewall passeert is de kans minimaal dat de scanner in die firewall die malware herkent en blokkeert.

Een ander probleem is dat firewalls vaak "geen tijd" hebben om bestanden uit netwerkpakketjes samen te stellen en grondig te analyseren alvorens ze door te sturen naar de gebruiker; de throughput wordt dan al snel onacceptabel laag.

Een bijkomend risico is dat zo'n device een kwetsbaarheid bevat (bijv. in een decompress library) waamee een aanvaller er rootrechten op krijgt, jij biedt hem dan een MitM positie voor alle versleutelde verbindingen van/naar jouw bedrijf. Ik ben benieuwd of je nog zo positief bent nadat Tavis Ormandy jouw firewall aan de tand heeft gevoeld...

Verder blijken dit soort devices tot nu toe bij herhaling slecht geïmplementeerd te zijn: identieke private key (tussen meerdere devices) in firmware, lek voor Poodle/Logjam etc., slechte CSPRNG, slechte ondersteuning van moderne TLS protocollen (tip: check eens [1]), slechte of geen revocation checking en onveilige distributiemethode van het rootcertificaat. En bij HPKP websites krijgt de gebruiker altijd een foutmelding.

Ten slotte is het discutabel of het een goed idee is om geauthenticeerde en versleutelde verbindingen open te breken. Tenzij je aan gebruikers heel duidelijk maakt dat je dit doet, zou je wel eens de WBP kunnen overtreden.

Dat vind jij, ik (en vele anderen) niet.

Wellicht wat flauw, maar digitale (server-) certificaten hoef je niet te stelen, die zijn openbaar (elke https webserver stuurt ongevraagd een kopie van haar certificaat, nog via een onversleutelde verbinding, naar jouw browser - kort na het opzetten van de TCP/IP verbinding). De MitM zal de private key van de server moeten stelen. Een server waarop zoiets kan, hoort niet aan Internet, ook niet als http server.

[1] https://www.ssllabs.com/ssltest/viewMyClient.html