Firefox 70 gaat waarschuwingen geven bij http-sites en uitgelekte wachtwoorden

Firefox gaat vanaf versie 70 webpagina's zonder https aanmerken als onveilig. Tot nu gebeurde dat andersom en werden https-pagina's juist als veilig aangemerkt. Daarnaast gaat Firefox waarschuwingen geven bij het gebruik van kwetsbare wachtwoorden.

Mozilla volgt met de waarschuwing het voorbeeld van Google. Dat toont al sinds Chrome 68, dat vorig jaar uitkwam, een grote waarschuwing bij niet-versleutelde websites. Ook voor Mozilla is de verandering niet helemaal nieuw; het bedrijf werkt er al sinds 2017 aan. Eerder toonde het bedrijf al waarschuwingen bij invulvelden op websites waar geen https beschikbaar was.

De waarschuwing komt bij websites te staan, maar ook bij ftp-verbindingen en certificaatfouten, zegt ontwikkelaar Johann Hofmann tegen ZDnet. Volgens Mozilla hoeven gebruikers niet meer te lezen dat een website veilig is, omdat inmiddels meer dan tachtig procent van alle sites versleuteld is met https.

Naast de onveiligheidsindicator krijgt Firefox 70 integratie met de database van datalekzoekmachine Have I Been Pwned. Als gebruikers in een invulveld een wachtwoord of e-mailadres invullen dat in een datalek is gevonden, krijgen zij daarvan een melding te zien. Dat gebeurt alleen als zowel het e-mailadres als het wachtwoord in een breach voorkomt bij Have I Been Pwned bekend is. De functie is gekoppeld aan Lockwise, de geïntegreerde wachtwoordmanager van Firefox. Mozilla zou ook overwegen betaalde diensten rondom die service aan te bieden, maar in welke vorm dat gebeurt, is nog niet bekend.

Reacties (121)

[AgamemnonZ]

inmiddels meer dan tachtig procent van alle sites versleuteld is met https

Niet 80% van alle sites hebben HTTPS, maar 80% van al het verkeer is via HTTPS. Anders gezegd, de meest bezochte websites hebben inmiddels bijna allemaal HTTPS waardoor effectief het meeste verkeer dus HTTPS gebruikt. Het zou prachtig zijn als 80% van alle websites HTTPS gebruikt, maar daar zijn we nog lang niet. In Nederland biedt bijvoorbeeld maar 70% van alle onderwijs- en zorgwebsites HTTPS aan (en dat zijn toch gevoelige websites die dit al helemaal op orde zouden moeten hebben), zie https://pulse.openstate.eu/.

[Ljuslmx]

Hoeveel nut heeft https voor een volledig statische website die niet als doel heeft om informatie te loggen?
Is dit dan wel echt nodig... of eerder gewoon een bonus?

[cracking cloud]

https geeft jou o.a. de zekerheid dat de informatie die je van de website ontvangt ook daadwerkelijk zo verzonden is door de server en niet gedurende het transport tussen de server en jouw browser is gemanipuleerd.

[latka]

Blijft natuurlijk het feit dat de informatie aan de bron verkeerd was. Ik denk dat het overal HTTPS systeem een vals gevoel van veiligheid geeft: was het zo dat mensen iets riepen omdat het op facebook stond, gaan ze nu iets roepen omdat er een slotje bij staat en het dus wel waar moet zijn.

[Yggdrasil]

gaan ze nu iets roepen omdat er een slotje bij staat en het dus wel waar moet zijn.

Dat argument heb ik gelukkig in de praktijk nog niet gehoord. Wél het idee dat de website 'veilig' zou zijn qua inhoud omdat deze via HTTPS wordt geserveerd.

Dat misverstand komt grotendeels omdat verkopers van SSL certificaten jarenlang dat soort bewoordingen gebruikt hebben om hun product te marketen. Onder druk van de gratis certificaten van Let's Encrypt begint dat langzaam te veranderen en beginnen ook browsers duidelijker te melden dat het alleen om een beveiligde verbinding gaat.

Is dat erg? Nee, HTTPS levert wel degelijk extra veiligheid op t.o.v. HTTP zelfs als de eindgebruiker niet snapt hoe het werkt en waarvoor het bedoeld is.

[Terrestrial]

Dat is niet waar! https is alleen voor versleuteling, er kan nog steeds een man in the middle tussen zitten, of je moet certifcaten gaan vergelijken. Er is overigens wel een uitbreiding (naam kwijt) waar het wel vrijwel onmogelijk mee wordt een mitm er tussen te zetten.

[kozue]

Certificaten vergelijken wordt dus ook gedaan... er wordt gekeken of de verzender een geldig certificaat heeft voor dat domein, en een mitm heeft zo’n certificaat dus niet. Daarom is het onzin wat je hier loopt te verkondigen. Zonder het privécertificaat van de server kun je de pakketten niet ontcijferen en heb je dus geen mitm op een https verbinding.

Die “uitbreiding” die je bedoelt is waarschijnlijk hsts (http strict transport security), waarmee het gebruik van https afgedwongen wordt. Hiermee kan worden voorkomen dat een verbinding naar onveilige http gedowngrade wordt. Maar zolang de browser waarschuwingen geeft bij het gebruik van http zou dat geen issue moeten zijn.

[KeesAlderlieste]

https://eric-diehl.com/do...an-in-the-middle-attacks/

[EraYaN]

Ja goed, natuurlijk werkt het niet tegen MiTM attacks als jij een extra CA certificaat aan je computer toevoegt. Ik bedoel wat verwacht je dan?

[vDorst]

Ik denk dat je dit bedoelt?
DANE: https://en.wikipedia.org/...ication_of_Named_Entities
Icm: TLSA RR (Resource Record)

[Jerie]

https geeft jou o.a. de zekerheid dat de informatie die je van de website ontvangt ook daadwerkelijk zo verzonden is door de server en niet gedurende het transport tussen de server en jouw browser is gemanipuleerd.

Yeah, well, "zekerheid", not really.

https://bugzilla.mozilla.org/show_bug.cgi?id=1567114

Het CA systeem is brak.

[d3burt]

Maar er zijn nog geen goede alternatieven voor. Deze aanval (door een staat op haar burgers) is al jaren bekend als het zwakste punt in DNS, en daarmee op ieder protocol wat van DNS afhankelijk is, en dus ook HTTPS.

Dit is een goede test case. Ik hoop dat Mozilla hier met gestrekt been ingaat.

[Jimbolino]

https is een vereiste voor http/2. Voordelen van http/2 zijn oa efficienter met meerdere verbindingen omgaan, en snellere handshakes.
Het belangrijkste voordeel van https is echter veiligheid. Als je bijvoorbeeld connect met een "rogue" access point waarop een proxy draait die het http verkeer aanpast. Dan kun je op je "vertrouwde" http websites alsnog banners te zien krijgen. Of nog erger, mallware aangeboden krijgen.
Daarnaast kunnen alle tussenliggende partijen precies zien welke site je met http hebt bezoekt. Tussenliggende partijen zijn niet alleen je eigen provider, maar kunnen ook andere instanties zoals overheden of transit partijen.

Zeker sinds de gratis ssl certificaten van letsencrypt, is er bijna geen reden meer te verzinnen om het niet te doen. Ook al is je website statisch, en staat er geen gevoelige informatie op. Het is gewoon een minimale bescherming die je moet bieden voor je bezoekers.

[Reactie gewijzigd door Jimbolino op 22 juli 2024 14:20]

[PolarBear]

HTTPS is geen vereiste voor HTTP/2. HTTP/2 de facto vereist TLS omdat alle grote browsers dat vereisen, is geen eis in de standaard.

[Jimbolino]

Klopt, als je via curl het internet bezoekt is https inderdaad geen vereiste voor http/2. Ik heb het nergens over een "standaard", dat heb je er zelf bij verzonnen.

[StefanJanssen]

Het is dus ook geen vereiste voor http/2

[Yggdrasil]

Praktisch gezien wel. We kunnen de hele dag discussiëren over de woordenboekdefinitie van standaarden, maar feit is dat je een boel moeite voor niks hebt gedaan als je http/2 implementeert in je server zonder HTTPS in te schakelen. Er is geen enkele mainstream webbrowser die http/2 implementeert zonder HTTPS.

[kozue]

TLS is ook vereist bij grote webservers als nginx en apache. Als zowel browsers als servers, de kerncomponenten van het internet, het beide vereisen kun je inderdaad stellen dat je geen HTTP/2 kunt gebruiken zonder TLS en is het dus in de praktijk een eis.

[pim]

Zeker sinds de gratis ssl certificaten van letsencrypt, is er bijna geen reden meer te verzinnen om het niet te doen.

Een bakker om de hoek heeft niks aan https.
Sommige websites staan online, maar niemand durft aan de instellingen te zitten.
Het is voor veel mensen technisch lastig om https werkend te krijgen.
En als automatisch verlengen fout gaat ligt je site plat.

Zie bijv. Altavista:
https://www.altavista.com/

[Jimbolino]

Altavista maakt geen gebruik van letsencrypt

Technisch lastig ben ik niet met je eens. Een letsencrypt certificaat installeren en automatisch laten renewen is net zo makkelijk als Linux Apache Mysql Php installeren, dus als dat ooit gelukt is dan moet moet het intypen van 3 commando's ook wel lukken.

[pim]

Ik durf toch wel te stellen dat 99% van de website eigenaren niet zelf apache mysql php heeft geinstalleerd.

[Jimbolino]

Letsencrypt is ook niet bedoeld voor die mensen, maar voor degene die de server in beheer heeft.

[pim]

Zeker sinds de gratis ssl certificaten van letsencrypt, is er bijna geen reden meer te verzinnen om het niet te doen.

Dan is een reden om het niet te doen als website eigenaar dat je iemand moet inhuren($) om het te doen.

[pim]

Of zelfs Reuters die https niet werkend heeft!

https://glossary.reuters.com

Toch niet zo vanzelfsprekend blijkbaar om https werkend te houden.

[MadEgg]

De belangrijkste reden vind ik dat je verkeer ook niet gelogd of afgeluisterd kan worden door je provider of netwerkbeheerder (tenzij die valse certificaten injecteren).

Het enige wat ze kunnen zien van je website-bezoek is de hostname van de website, dat wordt onversleuteld verstuurd. Maar welke pagina je op die website bezoekt is via HTTPS niet te achterhalen, terwijl dat met HTTP open en bloot is voor alle routers tussen jouw device en de server van de website die je bezoekt. Afhankelijk van de (statische) website die je bezoekt kan dat vanuit privacy-oogpunt zeer wenselijk zijn, zelfs als je er niet inlogd of actief andere informatie naartoe stuurt.

[afraca]

Er zijn trouwens initiatieven voor encrypted SNI, waarmee het ook niet zomaar meer mogelijk is om de hostname af te leiden. Support hiervoor is nog wat schaars en het moet nog handmatig ingesteld worden her en der, in Firefox is er ook wel wat voor, ben helaas niet in gelegenheid dat even op te zoeken.

[MadEgg]

Dank voor deze heads-up. Naar aanleiding van je post vond ik dit bericht: https://miketabor.com/ena...encrypted-sni-in-firefox/

Dat gaat over ESNI wat wel interessant klinkt. Maar ook over TRR, waarbij blijkbaar Mozilla van mening is dat het een goed idee is om je DNS requests via Cloudflare te gaan routeren. Het lijkt nog standaard 'off by default' te staan maar ik had het bestaan van deze functie volledig gemist. Weer een extra setting die ik uit moet gaan zetten elke keer dat ik Firefox installeer

Update
Het lijkt erop dat ESNI vooralsnog een cloudflare/firefox-only ding is. Cloudflare blaast hoogt van de toren hierover, maar geeft geen officiele specs vrij voor zover ik kan zien, en ook geen referentie-implementatie. Dat betekent dus dat je het momenteel niet op je eigen server kunt uitrollen. Dat zou nog kunnen wijziginen. Ook lijken de blog-posts hierover te suggereren dat het alleen werkt als TRR ingeschakeld is wat het helemaal een grote miskleun maakt. Sure, DNS is ook niet encrypted by default en als je daar geen maatregelen voor treft is dit naast SNI een andere manier waarop je browse-gedrag naar buiten kan lekken, maar TRR is zeker niet de holy grail en geeft de nodige andere privacy-bezwaren. En er zijn andere manieren om je DNS-verkeer veilig te stellen.

Vooralsnog verwacht ik dus niet te veel van ESNI, hoewel het concept om de SNI te versleutelen via PKI met een public key in DNS een redelijke oplossing is natuurlijk.

Wat ik niet snap is dat ze niet gelijk al de shortcut genomen hebben bij SNI om de SNI hostname te versleutelen zonder certificaat. Met behulp van DH kan simpelweg een key overeengekomen worden. Daarmee kan dan versleuteld de SNI hostname naar de server verstuurd worden zodat de server dan het juiste certificaat erbij kan zoeken. ESNI is wat netter maar niet per sé noodzakelijk.

[Reactie gewijzigd door MadEgg op 22 juli 2024 14:20]

[Verwijderd]

HTTPS is niet alleen encryptie maar ook en vooral ook authenticatie. Het zorgt ervoor dat jij weet dat je daadwerkelijk op de website van je bank zit en niet op een phishing site. Daarnaast zijn statische pagina's vaak groot en dan zorgt HTTP/2 voor snellere laadtijden doordat alle bestanden via 1 request worden binnengehaald ipv elk bestand apart. Nog een voordeel van HTTPS is dat de HTTP header versleuteld is waardoor een hacker niet kan zien welk domein je opvraagt. Die kan uiteraard wel de IP adressen zien maar als je een website bezoekt op een shared hosting server dan weet een hacker nog niet van welke website de data bij jou binnenkomt. HTTP is dus in meerdere opzichten geen handige keuze meer.

[vDorst]

Met HTTPS kan je helaas nog wel zien welk domein je opvraagt bij het opzetten van de verbinding.

[Jimbolino]

niet als je DNS over HTTPS (DoH) + ESNI gebruikt

[Reactie gewijzigd door Jimbolino op 22 juli 2024 14:20]

[Verwijderd]

DoH valt makkelijk te implementeren voor meteen het hele internet vanuit het perspectief van de gebruiker. ESNI helaas niet want dan ben je afhankelijk van de DNS server van het domein dat je wilt bezoeken. Hopelijk wordt het common practice maar voor alle software en alle DNS servers ervan zijn voorzien zijn we weer heel wat jaren verder.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:20]

[vDorst]

Wist nog niet van ESNI.
Weet wel dat men het jammer vond dat dit niet verplicht was in de TLSv1.3 specificatie.

[vsub]

Certificaten worden ook voor authenticatie gebruikt ja, maar dan heb je het voornamelijk over client certificaten (zoals bij SSH). Domeincertificaten gebruiken een 'chain of trust' op basis van root certificaten die op je apparaat geïnstalleerd staan, welke bijv. anti-viruspakketten, systeembeheerders of malware kunnen aanpassen en daarmee het stukje authenticatie (dat je ook daadwerkelijk met de juiste server verbind) niet het voornaamste doel van HTTPS/TLS genoemd kan worden.

HTTP/2 maakt verder wel meerdere requests, maar kan die over een enkele verbinding versturen/ontvangen (connection multiplexing): https://developer.mozilla...l_for_greater_performance

De meeste websites gebruiken HTTPS SNI, zodat er meerdere domeinen/certificaten op een enkel IP-adres gehost kunnen worden. Dit betekend echter dat de domeinnaam dus niet versleuteld verzonden wordt! Hier zijn wel ontwikkelingen in gaande, maar vooralsnog is dat geen gemeengoed: https://blog.cloudflare.com/encrypted-sni/

Dat HTTP geen verstandige keuze is, ben ik het wel helemaal met je eens!

[t link]

nee het is echt nodig. ik kan extreem makkelijk anders scripts in de pagina injecteren om bijvoorbeeld je wachtwoord manager extentie de wachtwoorden te laten dumpen ofzo. je wilt zeker zijn dat je kan vertrouwen dat je echt alleen data krijgt van iemand die je het wilt krijgen.

[H3llskrieg]

Als je password manager extensie gevoelig is voor scripts op de pagina, is je extensie beheer (je browser) al slecht, chrome isoleert de extensies bijvoorbeeld helemaal van de pagina's. Al kan een extensie wel toestemming vragen de pagina te lezen, dan zal de extensie nog steeds niet een script uitvoeren. Hiernaast zouden passwordmanagers niet zomaar passwords in plaintext in memory of in de local storage/cookies hebben staan.

[t link]

onzin. het heeft niks met het geheugen uitlezen te maken maar met automatisch inloggen dmv credentials invullen. autocomplete word vaker op die manier misbruikt, ook met hidden fields waardoor je opeens alle gegevens stuurt ipv alleen je email.

[H3llskrieg]

Ik zou bijzonder graag zien hoe jij met een script mijn password manager uitleest: https://chrome.google.com...aikbpkpnahfjdaniockkjoldi
en voor de source: https://github.com/erikknaake/EKVault

[t link]

mijn script leest niet jou password manager uit. stop met strooiman argumenten maken. jou password manager geeft die gegevens vrijwillig af. hier is bijvoorbeeld een demo. https://senglehardt.com/d...s/loginmanager/index.html

[Reactie gewijzigd door t link op 22 juli 2024 14:20]

[Verwijderd]

Ja, dat heeft nut. Zonder HTTPS kan eender wie extra data in de website injecteren alvorens die bij jou komt.

Voorbeeld: Je bezoekt de statische http-only website van de bakker in de buurt, via een wifi hotspot die je zelf niet beheert. Die hotspot/router kan advertenties, extra tracking cookies, of virussen in die pagina injecteren alvorens de pagina in jouw browser komt.

HTTPS beschermt de ONTVANGER van de website, niet de zender. Mensen durven dit al eens te vergeten. De aard van de website is bijgevolg totaal irrelevant.

[1superheld]

Voor de mensen die denken "Https op een statische site is toch niet nodig".

Daar heeft Troy Hunt een mooie blogpost over gemaakt. zie hier https://www.troyhunt.com/...atic-website-needs-https/.

In het kort. Is je site nog http? Ga hem nu https maken

[zap8]

Ik snap je punt. Daar moet je echter wel zin, tijd of geld voor hebben. Zoals ik hieronder ook al aan heb gegeven. Er is inmiddels onwijs veel content gemaakt op websites die niet meer geupdate worden en gemaakt zijn op basis http. Daar zit ook heel wat waardevolle en unique content bij. Ik vind het vooral zonde dat deze content dreigt de verdwijnen door https er doorheen te drukken.
Realiseer je vooral dat we over 20 jaar of wellicht nog korter er nieuwe protocollen komen die nog weer veiliger of beter zijn kunnen worden doorgedrukt en een enorm deel van de huidige content die op dezelfde manier in het verdomhoekje terecht zal komen.

[Reactie gewijzigd door zap8 op 22 juli 2024 14:20]

[JustFogMaxi]

Kom op, je logt in bij hosting provider (plesk etc), klikt op HTTPS en gratis LetsEncrypt cert en je bent klaar...

[zap8]

Volgens mij begrijp je m'n punt niet. Geld heeft geen betrekking op cerificaten maar omzetten van html code. Voordat https ueberhaupt toegepast werd, linkte je plaatjes en html pagina's je gewoon naar de volledige urls. Gooi een een certificaat op zo'n site werken de links de "hardcoded" zijn niet meer en zie je dus ook plaatjes en dat soort zaken niet meer.
Veel mensen die ooit tijd geinvesteerd hebben en nu hun site alleen maar up houden omdat ze hun bouwsel interessant vinden hebben vaak niet eens de kennis meer om het even "gemakkelijk" bij te werken. ewoon even logisch nadenken, jij houdt nu een dagboek bij doet dat nog 2 jaar, vindt dat een leuk project en betaald daar jaarlijks voor want toch de moeite waard. Moet je opeens 15 jaar later als allerlei dingen verandert zijn opeens verdiepen in alles en nog wat om de boel te weer fatsoenlijk te laten lopen. Hoe simpel het ook mag zijn het kost je tijd en je moet er maar zin in hebben. Als websites en programmeren je dagelijkse praktijk is stelt het natuurlijk niets voor maar veel websites zijn door veel mensen met liefde voor dingen waar ze mee bezig zijn geweest met "bloed, zweet en tranen" in elkaar gezet.
Kortom het is voor een grote groep mensen niet zomaar even een certificaat op de website gooien, want het is toch een handeling die verricht moet worden. Daarnaast is zoals aangegeven het ook nog maar de vraag of de boel na het certificatie allemaal nog werkt. Plaatjes die door hardcoded (volledige) urls niet meer zichtbaar zijn. Vooral als je niet zo technisch onderlegd bent en/ of al heel lang niet meer iets aan je website gedaan hebt zal je dat niet leuk vinden. Je onderschat dus volgens mij hoe ingewikkeld het proces voor sommige mensen kan zijn.

[1superheld]

Misschien doe ik het toch wat te makkelijk maar.

Cloudflare ervoor, een paar vinkjes zetten en poef een A+ score bij SSLlabs. Volgens mij geen code wijziging nodig dan?

https://httpsiseasy.com/

[pim]

Ik zit bij Transip. Heb een Centos vps met DirectAdmin.
Klik op HTTPS en gratis LetsEncrypt cert en het werkt niet. Niet eens een error.
Ik neem aan dat miljoenen andere directadmin gebruikers hetzelfde probleem hebben. Ik had een schone installatie.

[mj.oke]

totaal met je eens,
als iets makkelijk te beveiligen is wil nog niet zeggen dat het oude als onveilig bestempelt moet worden
zelfs al is eenvoudig te kapen, onveilig is een zware classificatie, kapen is nog steeds niet legaal, net zoals tasjes roof. heb al bezorgde mailtjes gehad van de digibeten om me heen.
als er word geblokkeerd op de manier zoals nu bij de onveilige https certificaten is het totale einde bereikt

de oude zelf gehoste websites,
sterker nog, de niet commerciële websites werden bij RTL nieuws al bestempelt als het deep-web
in de classificatie,
je hebt het internet; google - facebook - instagram wikipedia etc,
je hebt het deep weg; gewone websites
en het dark web; het 'verborgen internet voor illegale zaken'
aldus RTL, in de trant van de film; ralphs breaks the internet, leuke film om te zien hoe de normale mensen het internet voorstelt.

een groot deel van het internet waar we mee opgegroeid zijn word nu/straks als onveilig bestempeld.
ze hebben op zich een punt, voor mensen die geen ene kaas gegeten hebben van internet en de oude onveilige binnensteden in Nederland ook liever ontwijken.
het zal zo, er hoeft niet meer verloren te gaan, alleen gaat de generatie internetters van na 2005 ofzo nooit meer zien dan de commercieel/gecontroleerde content laag

[zap8]

Helemaal juist. Dit is ook het punt van discussie dat ik wilde aanzwengelen. Jonge mensen die nu in de ICT zitten hebben maar weinig kaas gegeten dat het internet van voor de sociale media en grote commerciele sites werd beheerst door websites die zelf in veel gevallen in elkaar werden gezet door mensen die alles zelf moesten doen. Even een site aanmaken was toch andere koek itt tegenwoordig waar je dat met ene paar clicks kan doen. Het waren zoals al eerder gesteld mensen die vaak met liefde voor hun passie iets met zwoegen in elkaar zetten. Het is te simpel om te stellen dat deze mensen maar even simpel even een certificaatje moeten installeren en alles is weer goed. urls werden vaak op een andere manier gelinkt (via volledige url, dus met http://) waardoor de boel opeens niet meer goed doorlinkt met een https certificaat. Door de drive van de techgiganten lijkt hier dus een heel stuk internet met bijbehorende content verloren te gaan. Ipv met de vaart van de techgiganten mee te gaan zou je op het minst een discussie kunnen zijn hoe je dze http:// sites dan wel toegankelijk kunt houden ipv ze tegelijk maar als onveilg te labelen. Heel veel van dit soort sites bestaan gewoon uit pure en simpele html waar mijns inziens weinig gevaarlijks aan is.

[mj.oke]

ik vind de reacties, even een certificaat installeren ook zo mooi,
bij heel veel sites van verenigingen zal dat niet zo werken, de standaard/goedkope hostings partijen zullen dat vast niet gratis gaan leveren.
en allemaal over op de LetsEncrypt, klinkt mij meer als, allemaal afhankelijk van de LetsEncrypt,
hoe meer mensen er van 1 dienst gebruik maken des te interessanter voor hackers, als doelwit.

+be +d
onbeveiligd

nu neemt de waarde van het woord "onveilig" ook meteen af.
er zullen volksstammen zijn die deze melding gaan negeren, met nieuwe verwarring als vervolg.

tja
de mensen in hun Brexit land denken ook dat hun land het internet heeft uitgevonden, in mijn geheugen was het een brit die alleen het "tcp/ip http html en browser gebeuren" heeft toegevoegd.
in dienst van CERN.
dus ja, internet definitie is vrij subjectief geworden.

[AgamemnonZ]

HTTPS maakt juist HTTP/2 mogelijk waardoor HTTPS juist het sneller laden van website mogelijk maakt! Theoretisch zou HTTP/2 ook kunnen werken zonder HTTPS, maar alle browsers accepteren enkel HTTP/2 in combinatie met een HTTPS verbinding. Alle websites moeten HTTPS hebben: https://doesmysiteneedhttps.com/

[kodak]

Weet iemand hoe het zit met het verwerken van deze login gegevens? Komt er een lokale database met hashes op het systeem van de gebruiker, of nemen Mozilla/HaveIBeenPwned gegevens tot zich om een resultaat te geven?

[batjes]

Lokaal gehashed en dan vergeleken. Volgens mij gaat er ook maar een X aantal karakters van die hash de kant van HaveIBeenPwned op, krijg je een selectie terug die daar aan voldoet en wordt lokaal gekeken of je er tussen zit.

[ApexAlpha]

Correct, jij (je browser) maakt een hash aan en stuurt de eerste 10 characters op naar de server.
Dan stuurt de server alle hashes die beginnen met dezelfde 10 terug en dan kun jij (je browser) kijken of hij ertussen zit. Dit heet k-anonimity.

Dit kost uiteraard meer data maar zo voorkom je dat je je wachtwoord opstuurt ter verificatie. Iets dat je natuurlijk alleen met credit cards moet doen .

Meer info over k-anonimity: https://blog.cloudflare.c...sswords-with-k-anonymity/

[Reactie gewijzigd door ApexAlpha op 22 juli 2024 14:20]

[djvdorp]

En een interessant k-anonymity related artikel van afgelopen week:

"Attacks on applications of k-anonymity for password retrieval" - https://cablej.io/blog/k-anonymity/

[kodak]

Lijkt me echt heel verstandig, om je inlog gegevens (zelfs als ze niet gelekt zijn) aan een protocol toe te vertrouwen waar al sinds het bedenken twijfels over zijn en nu uit serieus onderzoek blijkt dat een deel van die twijfels ook bewezen is.

[1superheld]

Er wordt lokaal hash gemaakt van het wachtwoord. De eerste 5 karakters worden opgestuurd en alle hashes welke matchen (beginnen met) worden teruggestuurd
Dan wordt in het result gezocht of het ingevoerde wachtwoord bestaat .
Leuke blog post https://blog.cloudflare.c...sswords-with-k-anonymity/

Is inderdaad haveibeenpwnd waar Firefox monitor ook gebruik van maakt

[Keypunchie]

Volgens mij gebruiken ze Firefox Monitor: https://monitor.firefox.com/

Die heeft eigen databases, maar vergelijkbaar met HaveIBeenPwned. Misschien wisselen ze wel databases uit. (update: volgens hun FAQ is HIBP inderdaad hun bron). Vergelijken op basis van hash lijkt me vele malen verstandiger en efficiënter, en dat vertrouw ik Mozilla wel toe.

[Reactie gewijzigd door Keypunchie op 22 juli 2024 14:20]

[tom.cx]

Het is goed dat ze dit doen. Alleen vraag ik mij af; als je een HTML website hebt met alleen wat informatie. Geen contactformulier of persoonsgegevens. Waarom zou je dan https nemen? Niet echt nodig lijkt mij.

[GertMenkel]

Als het echt alleen dat is:
- Browsers hebben gekozen HTTP/2 niet zonder encryptie te ondersteunen, dus je kunt geen gebruik maken van de snelheidsverbeteringen die HTTP/2 biedt.
- Bepaalde internetproviders (bijvoorbeeld in Amerika) injecteren Javascript met advertenties in jouw pagina als die over HTTP wordt verzonden, waar mensen jouw misschien de schuld over geven (want het staat op jouw pagina)
- Bepaalde providers proberen "slim" afbeeldingen op je site te comprimeren (Simpel heeft dit gedaan de laatste keer dat daar klant was) en via een transparante proxy door te sturen. Uitzetten van die "feature" kan vaak niet en kan de plaatjes/grafieken op je website slecht leesbaar maken.
- Bepaalde Javascript-functionaliteit wordt alleen toegestaan vanaf veilige locaties (localhost en HTTPS-pagina's over het algemeen). Als je informatie interactieve visualisaties gebruikt, kan dit relevant zijn.
- Groen slotje, dus veilig, dus betrouwbaar, aldus mijn tante

Dat zijn de argumenten voor HTTPS die ik kan bedenken. De argumenten tegen zijn over het algemeen "dat is me te veel moeite" en dat is een acceptabel argument als je geen tijd hebt/niet de capaciteiten hebt om je server te onderhouden. Aan de andere kant is het letterlijk 1 commando uitvoeren en zorgen dat de automatische update draait, dus als je dat niet kan, vrees ik voor de veiligheid van je server.

't is tegenwoordig zo'n standaarddingetje dat je doet als je een server maakt (OS erop, firewall aan, webserver aan, certificaat erop) waardoor de vraag "waarom niet" vaker voorkomt. Plus, als je later besluit toch een formulier toe te voegen, scheelt dat je weer tijd als je daarmee bezig gaat

[Krulliebol]

- Groen slotje, dus veilig, dus betrouwbaar, aldus mijn tante

Dat is dus precies waar het fout gaat

[GertMenkel]

Ik geloof dat Firefox standaard de domain validated certificaten een grijs slotje geeft, dus er is al vooruitgang.
Chrome is ook bezig EV-certificaten uit de UI te slopen door ze als normale certificaten te behandelen. De groene slotjes beginnen dus te verdwijnen

[Nickkname]

Volgens mij moet de vraag eerder zijn: waarom niet? Het is ondertussen met LetsEncrypt kinderlijk eenvoudig gratis een certificaat te regelen voor elke website. Dus waarom zou je het niet doen?

[WoutervOorschot]

Extra moeite, en in het geval van zelf-hosted (zoals thuisserver) totaal onnodig en vaak onmogelijk (zonder dns record)

[CH4OS]

Er zijn meerdere manieren bij Let's Encrypt om de validatie te doen. DNS is daar 1 optie van, die pas recentelijk erbij gekomen is.

In theorie kan een HTTP-01 challenge immers gewoon op IP-adres, maar misschien dat Let's Encrypt dat niet doet of ondersteund.

[Reactie gewijzigd door CH4OS op 22 juli 2024 14:20]

[GertMenkel]

Als je een website kunt hosten, kun je een Let's Encrypt certificaat krijgen. Je hoeft niet aan DNS te komen, je kunt het bezit van je domein bewijzen door op poort 80 te antwoorden. Als je dat al niet kon, is je website sowieso onbereikbaar voor de meeste mensen dus heb je inderdaad weinig aan je certificaat.

[latka]

Als het een shared host is moet je vervolgens wel je certificaat aan de webserver kunnen voeren. Verificatie kan met het plaatsen van wat content op je website (een file neerzetten). Echt gebruiken van het certificaat vereist iets meer werk (en rechten).

[Tweekzor]

Een shared host gebruikt Plesk of DirectAdmin en die hebben gewoon een setting voor het instellen van SSL op een aantal manieren. Waaronder tegenwoordig vaak een 1-click optie om LetsEncrypt te gebruiken.

[GertMenkel]

De meeste degelijke shared hosts hebben Let's Encrypt tegenwoordig ingebouwd. Er zijn wat uitzonderingen, waar hosts je extra willen laten betalen om een duur certificaat bij ze te kopen, maar die shared hosts wil je toch al liever niet vertrouwen met je website.

[zap8]

Redenen genoeg. Er zijn genoeg hobbyisten maar ook pro's die ergens in de afgelopen 25 jaar een poos hebben besteed aan het bouwen van een informatieve eigen site mbt hun hobby of bv onderzoek. Dat kunnen mensen zijn die treintjes verzamelen, info van specifieke dieet kuren hebben bijgehouden, etc.. Daarnaast stikt het van de sites met artikelen waar mensen een poos zijn mee bezig geweest die interessante en verder nergens toegankelijke info of gewoon persoonlijke ervaringen bevatten. Deze sites bevatten vaak geen javascripts en zijn vaak gemaakt met html only. De mensen onderhouden deze sites niet of nauwelijks meer maar betalen voor hun website omdat ze deze info relevant vinden.
Zelf heb ik in het diepe verleden ook ingewikkelde sites van honderden html pagina's gebouwd die allemaal "hardcoded" doorgelinkt zijn en "hardcoded" urls naar plaatjes en andere media verwijzen. Dat was destijds voor 2000 een redelijk normale praktijk. Sommige van deze sites zijn nog up. Voor de grap heb ik 2 jaar geleden een van deze site voorzien van een certificaat. Waardoor opeens veel pagina's niet meer doorlinkten of plaatjes gewoon niet meer zichtbaar waren.
Kortom vooral met oudere websites is het soms ondoenlijk om deze nog simpele en fatsoenlijk om te zetten. Tenzij je geld of tijd genoeg hebt. Er zal dus simpel gezegd heel veel content verloren gaan. Jammer en wat mij betreft ook totaal onnodig voor websites die ik bovenaan beschreef.

[Reactie gewijzigd door zap8 op 22 juli 2024 14:20]

[kozue]

Dat is heel simpel op te lossen hoor. Gewoon je broncode doorzoeken naar http:// en het http: gedeelte er overal vanaf halen zodat je links overhoudt die beginnen met //. Zo’n link werkt hetzelfde als de oude links, maar gebruikt het protocol waarmee de site geopend is. Dus als je m op http bezoekt krijg je http://domein.nl/bla en als je m via https bezoekt krijg je https://domein.nl/bla.

[zap8]

Zo simpel is het helaas niet als je pagina's, plaatjes en films en ander media materiaal in mappen van mappen in weer mappen hebt staan met die weer naar elkaar verwijzen (urls die bv soms 3 mappen naar voren, etc. en waar plaatjes op staan die weer naar andere mappen verwijzen, etc.). Je moet dan elke pagina bij langs. Als het allemaal zo simpel is en je er zin in hebt stuur me even een PM dan nodig ik je uit om eens met een website aan de slag te gaan

[hackerhater]

Code downloaden in een IDE en dan gewoon een globale find & replace?

[zap8]

Bedankt voor de tip zal eens een poging wagen als dat gaat lukken.

[kozue]

Het is inderdaad allemaal heel simpel. Maar aangezien ik tijdens m'n kantooruren al genoeg met webshit bezig ben ga ik daar niet nog meer vrije tijd in steken (ook niet als je bereid bent te betalen).
Deze mag je wel gratis hebben als inspiratie:
find . -type f -print0 | xargs -0 sed -i 's|http://|//|g'
Heb m niet getest maar zou alle http:// in // om moeten zetten.

[zap8]

Bedankt, maar je onderschrijft precies m'n argumenten dat het alles te maken heeft met geld, zin en tijd. Als het even een kwestie was van een simpele handeling zou het verder ook geen probleem zijn om een mede tweaker even uit de brand te helpen eventueel voor een vergoeding. Het heeft bij jou dus alles te maken met geen zin. Dat begrijp en repecteer ik, maar begrijp dan ook dat mensen die minder/ nauwelijks of niet onderlegd zijn in dit soort werk er helemaal geen zin in hebben juist vanwege kennis die ze niet hebben.

Dat m'n oorspronkelijke reacties de grond in worden gemod zegt mi veel over de hedendaagse generatie die blijkbaar niet begrijpt dat als je in een ver verleden (15 jaar of ouder) met veel moeite en pijn een website in elkaar hebt gezet. Het op dit moment voor deze mensen niet even een kwestie is van even wat simpele handelingen verrichten en je hebt de boel weer up en running onder https. Zoals gezegd stel je eens voor dat je nu iets in elkaar zet 15 jaar lang niet met programmeren (wat an sich al niet je ding was) bent bezig geweest en je moet opeens weer aan de slag omdat iets wat altijd perfect werkte en waar niks fout aan is opeens onveilig wordt verklaard. IK vind dat er gewoon te gemakkelijk over dit feit wordt heen gewalst iets dat ik jammer vindt. Wat mij betreft zou dat juist het punt van discussie moeten zijn. Dus hoe houden we de boel uit het verleden open en toegankelijk op het internet. En dit geldt ook voor de zaken die nu worden gebouwd want je kunt er op rekenen dat ook deze zaken gedateerd zullen worden.

[kozue]

Persoonlijk ben ik van mening dat we beter af zijn met een kleiner maar schoner web dan een web vol onveilige meuk uit de jaren '90. Als dat betekent dat er bepaalde informatie verdwijnt, dan is dat maar zo. En zeg nou zelf, als iets al 15 jaar de moeite niet was om te updaten en op geen enkele andere site te vinden is, zou het dan echt zo cruciaal zijn dat het beschikbaar moet blijven?

Ik heb begin jaren '00 ook wel eens wat in elkaar geknutseld wat helemaal niet meer aan de huidige standaarden zou voldoen. Na een tijdje heb ik dat gewoon zelf verwijderd omdat het toch voor bijna niemand interessant zou zijn en de moeite van het updaten niet waard was.

Zonder https stel je gebruikers gewoon bloot aan een heel scala aan aanvallen en ik vind dat iedereen z'n verantwoordelijkheid moet nemen en het ofwel updaten, ofwel verwijderen.

[veltnet]

Al je bij een site niet hoeft in te loggen en geen formulieren hoeft in te vullen dan heeft https niet zo heel veel toegevoegde waarde boven http

[zap8]

Denk dat we helaas verschillen van mening. Wat jij als onveilige meuk bestempled zal er ongetwijfeld ook bij zitten. Toch kan ik genoeg info bedenken die voor mensen interessant genoeg die je niet of niet zo snel tegen zult komende op social media en huidige websites. Van lokale tijdschriftartikelen in de buurt tot mensen die hun verzamelingen ooit online hebben gezet. En van mensen die specifieke persoonlijke problemen ooit op een bijzondere manier ooit hebben overwonnen tm kennis van oude apparaten waarvoor op die moment maar weinigen in geinteresseerd zijn.

Je laatste stelling vind ik overigens absurd en zelfs eng. Je stelt een zwart wit redenering op: https of verwijderen omdat zonder https de boel niet veilig zou zijn. Terwijl dat lang niet in alle gevallen het geval is.
Zie ook de bovenstaande draad @mj.oke die overigens ook weggemod wordt omdat er kritische vragen worden geteld bij de technologische update/ veiligheidshonger.

[RobNL]

Kijk even hack yourself first van Troy Hunt.
Je kunt alles vervangen op een http-only website, ik kan ervoor zorgen dat jouw website vanuit mijn netwerk wél een contactformulier heeft of doorverwijzen naar een soort phishing website.

De vraag is eerder; waarom zou je het niét doen. Het kan gratis zoals velen al beschrijven via Let’s Encrypt.

[PhoenixT]

Het is dan geen risico voor jou als ontwikkelaar, maar wel voor de gebruiker. Iedereen kan zien welke pagina’s worden opgevraagd, en voor een aanvaller is het makkelijk om de content aan te passen; bijvoorbeeld om een nep inlogmenu juist toe te voegen
Bovendien zijn er ook “legitieme” bedrijven (vliegvelden zijn berucht) die gewoon reclame injecteren op HTTP pagina’s, ook niet fijn voor je gebruikers.

[satoer]

Dus alle login gegevens die je ergens invult worden ook verstuurd naar Firefox om gecontrolleert te worden. Hoewel het doel nobel is, geeft dit mij ook niet echt een veilig gevoel moet ik zeggen. Het is natuurlijk wachten totdat hier een groot datalek in gevonden wordt. Daarbij hebben ze bij Firefox dus de beschikking van al je plain text wachtwoorden en inloggegevens. Waarschijnlijk wordt het wel geencodeerd verstuurd, maar om het te kunnen vergelijken, moeten ze het toch kunnen decoderen.

[Stevie-P]

Nee, er is een grote database met hashes van uitgelekte wachtwoorden. Vervolgens wordt zelfs maar een gedeelte van de hash van jouw invoer hiermee vergeleken. Vervolgens toont je browser alleen een waarschuwing als het een complete match is. Oh en uiteraard gebeurt dit alles over een https verbinding. Maar je plaintext wachtwoord verlaat jouw browser niet

[Reactie gewijzigd door Stevie-P op 22 juli 2024 14:20]

[kodak]

De intentie lijkt om het deels anoniem online te laten controleren. Mozilla/HaveIBeenPwned zou gebruik maken van cryptografische hashing en k-anonimity. Helaas is de combinatie vooral bewezen handig om te controleren of data gelekt is. En dat is meestal geen goed uitgangspunt om het dan maar te accepteren als veilig genoeg om gevoelige gegevens mee te verwerken. Zeker niet als dat de gegevens van anderen zijn.

Verder zijn er nog een paar andere problemen met de controle.
Zo geeft het HaveIBeenPwned/Mozilla leuk inzicht in het gebruik van credentials en het gedrag van de gebruiker. Bijvoorbeeld wie waarvan welke credentials gebruikt en wanneer.
Als Firefox alle willekeurige credentials/mailadressen laat controleren (wat ze nu al doen zonder enige vorm van controle of de persoon die de gegevens opgeeft wel de juiste persoon is om te informeren) zet dat de deur extra open om daar minder vriendelijke acties mee uit te voeren.

[bartje]

Worden mijn crrdentials dan altijd gequeried bij have i been pwnd? Dat lijkt me nogal een security risico.

[kodak]

Daar lijkt Mozilla nog geen antwoord op te hebben. Je zou mogen verwachten dat ze niet zomaar (gehashde) credentials naar zichzelf of een partner sturen. Ze hebben in principe niets met die gegevens te maken en uit een eerdere reactie bleek al dat de hashing die ze gebruiken risicovol is om te vertrouwen dat je daar credentials mee geheim kan houden.

Dat Mozilla het niet meer zo nauw neemt met omgang met de persoonsgegevens of toestemming mocht al duidelijk zijn uit de opt-out wijze om deel te nemen in ontransparante dataverzameling en hoe ze zonder enige vorm van controle willekeurige mailadressen accepteren om terug te melden of die in een datalek zitten en in welke.

Ze zullen vast goedbedoelde intenties hebben om gebruikers bewuster te maken, maar ze nemen privacy zelf niet zo heel erg nauw. Ik zou even wachten met een eventuele upgrade voor er meer duidelijkheid is.

[Niemand_Anders]

Ze sturen niet de volledige hash naar de validatie service. Ze sturen alleen de eerste 10 bytes van de hash naar de validatie service. Deze stuurt vervolgens een lijst terug van alle hashes in de database welke beginnen met deze eerste 10 bytes. Vervolgens moet de client (browser) controleren of de volledige hash van jouw password voorkomt in de lijst van terug gestuurde hashes..

Is er een match, dan gebruik je een wachtwoord welke eerder is uitgelekt..

[kodak]

En wat heeft Mozilla te maken met wat voor deel dan ook van andermans (hashed) inlog gegevens?

[Niemand_Anders]

Ik vermoed dat zodra jij de credentials voor een website wilt bewaren in Lockwise, dat jouw browser automatisch controleert of dat wachtwoord (de hash) niet eerder is gelekt..

[banaj]

Ik snap het niet: Have I Been Pwnd heeft toch helemaal geen *combinaties* van email + wachtwoord? Wanneer gaat het alarm dan af?

• Als op email dan heel vaak vals alarm want HIBP voegt b.v. ook SPAM-lijsten zie (zie https://haveibeenpwned.com/PwnedWebsites, zoek op SPAM).
• Als op wachtwoord (niet gerelateerd email, zie https://haveibeenpwned.com/Passwords) dan gaat ie ook vaak af omdat b.v. VeryC0mpl3XPASSWORD123! (prima wachtwoord) al eens gebruikt is door Jantje in Verwegistan (totaal niet gelinkt aan mij).

Wat mis ik? Of niet nuttig en wel vervelend?

[Reactie gewijzigd door banaj op 22 juli 2024 14:20]

[Stevie-P]

In situatie 2 is dat complexe wachtwoord onveilig geworden omdat die bijna unieke combinatie van tekens blijkbaar voorkomt in een plaintext dump met het wachtwoord van Jantje. Wanneer nu een database wordt gehackt van een service die jij gebruikt is jouw wachtwoord kwetsbaar. Zelfs wanneer deze service nette hashing gebruikt voor de wachtwoorden, is de hash snel gematcht omdat de aanvaller eerst wat bekende wachtwoorden test, waaronder die uit de dump met Jantjes wachtwoord.
Nu kan de aanvaller dus inloggen met jouw account want je wachtwoord was in nog geen seconde gekraakt omdat die tussen de paar miljoen wachtwoorden stond die geprobeerd moesten worden voordat er ook maar gebruteforced hoefde te worden (enkel dan, in het geval van bruteforcen, biedt die complexiteit van het wachtwoord veiligheid).

[Reactie gewijzigd door Stevie-P op 22 juli 2024 14:20]

[H3llskrieg]

Happened to me once, en dat is ook precies waarom je niet maar 1 wachtwoord moet gebruiken

[SubSpace]

Ehhh, dus we sturen bij inloggen even je username en password naar een API om te checken of ze gelekt zijn?

Ik neem aan dat er over nagedacht is, maar ik heb er toch een ongemakkelijk gevoel bij

[MadEgg]

Een deel van de hash van je wachtwoord. Theoretisch niet herleidbaar.

Toch is het een hint in de richting van je wachtwoorden die niet nodig is - zeker niet herhaaldelijk. Password manager in Firefox maak ik ook geen gebruik van - Firefox mag alleen mijn wachtwoorden versturen bij het inloggen en mag er verder helemaal niets mee. Ik hoop dus wel dat de functie uit te schakelen is. Mijn wachtwoorden zijn wel veilig - daar heb ik Firefox niet voor nodig.

[SubSpace]

Hopelijk zelfs geen hash, eigenlijk
De API van Have I Been Pwned heeft de mogelijkheid om alle breaches te listen die bij een account horen, maar voor zover ik weet geeft die site uberhaupt niet de wachtwoorden uit, in verband met mogelijk misbruik. De exacte output kon ik niet zo snel vinden in de documentatie. Wellicht dat ze voor Mozilla dan inderdaad een hash van het gelekte wachtwoord sturen, zodat dat lokaal vergeleken kan worden.

Ik gebruik de password manager van Firefox zelf ook niet, omdat ik meerdere browsers gebruik. Mijn password manager (LastPass) heeft zo zijn eigen problemen gehad, maar ik vind hun check tegen gelekte passwords best netjes werken.

[Reactie gewijzigd door SubSpace op 22 juli 2024 14:20]

[Yggdrasil]

Er wordt een andere API gebruikt, genaamd Pwned Passwords, ook gemaakt door Troy Hunt de maker van Have I Been Pwned. De Pwned Passwords API gebruikt een algoritme genaamd k-anonimity om wachtwoorden te vergelijken zonder te laten uitlekken welk wachtwoord je probeert op te zoeken.

Hier staat wat uitleg over hoe het werkt:
https://www.troyhunt.com/...flareprivacyandkanonymity

Het komt erop neer dat je wachtwoord lokaal gehashed wordt. Dan word een substring (de eerste vijf karakters) van die hash genomen en als query naar de Pwned Passwords database gestuurd. Die stuurt alle (honderden) hashes terug die matchen met die substring. Lokaal wordt dan gekeken of in die lijst met hashes ook de volledige hash van het wachtwoord voorkomt. Zo ja, dan is dit wachtwoord aanwezig in de remote database, dus ooit uitgelekt geweest en dat is alles wat ze willen weten.

Er zijn best wat artikelen te vinden die dit k-Anonimity model analyseren als je er meer over wilt weten.

[mschol]

helaas trapt iedereen in het "https" moet en zal verhaal; slechte, slechte zaak

lets encrypt wordt geroepen als "de oplossing"
helaas werkt dat alleen als de server config aangepast kan worden, meer dan genoeg hosters die dit niet toestaan, of (indien in eigen beheer gehost) de configuratie zo nodeloos ingewikkeld wordt voor onderhoud dat het de moeite niet loont en zo uiteindelijk waardevolle informatie van internet verdwijnt.
ergo: internet wordt er door kapot gemaakt in mijn optiek (voor een risico dat, relatief gezien, minimaal is als "de grote" sites wel https voeren, het risico dat de client besmet is, is groter imho)

[kodak]

Als Mozilla HTTPS zou verkopen als schijnveiligheid zou ik me nog kunnen vinden in een redenering dat de promotie slecht zou zijn. Maar dat lijkt Mozilla niet te doen. Ze waarschuwen straks dat communiceren over HTTP niet betrouwbaar is. En daar hebben ze toch een punt. Het lijkt me zelfs een betere aanpak dan in geval van HTTPS net te doen alsof dat betrouwbaar zou zijn. Welk voorstel zou jij hebben om het voor de gebruikers veiliger te maken?

[TomsDiner]

Er wordt hier al 100x gezegd "Een simpele statische website". Maar het gaat eigenlijk om het domein. Zit daar geen mail aan? En stuurt je mailprogramma niet om de haverklap de inloggegevens mee? Volgens mij moet je momenteel meer moeite doen om een certificaatloos domein te blijven vertrouwen in je mailprogramma, dan de installatie van Let's Encrypt kost.

[Yggdrasil]

Klopt, maar omdat het artikel gaat over webbrowsers negeren we onveilige mailverbindingen voor het gemak even.

[Paul]

Certificaten gaan per host, per website, per naam, per dienst. En aan één naam kunnen meerdere diensten hangen. Als (www).jouwsite.nl geen HTTPS spreekt wil dat niet zeggen dat je IMAP-server, of om bij HTTPS te blijven, je webmail, geen SSL/TLS doet

Je kunt aan de hand van één website niet zeggen dat alles op het hele domein certificaatloos is.

[TomsDiner]

Klopt, maar een algemene tendens die ik hier lees "certificaten zijn te moeilijk voor mijn makkelijke site". En je moet er toch al één voor de mai lhebben, en de wildcard certificaten -die web en mail afdekken- zijn gratis bij Let's Encrypt. Dus twee vliegen in één klap.

Dat was mijn argument

[Paul]

Waarom zou je er een voor de mail moeten hebben? Juist 'simpele sites' hebben dat over het algemeen helemaal uitbesteed aan hun hoster.

Persoonlijk ben ik geen fan van wildcards, veel te makkelijk om uit het oog te verliezen waar je deze allemaal geïnstalleerd hebt. Als je dan toch voor Let's Encrypt gaat dan kun je net zo goed twee certificaten aanvragen.

En aanvragen is niet genoeg, je moet het ook installeren, instellen en onderhouden. En dat doe je niet één keer per domein, dat is per website / naam / server / dienst. Dus nee, het gaat niet om het domein

[TomsDiner]

Ehhh... Hou jij van denken in problemen? Al je argumenten zijn beren die er niet of nauwelijks zijn....
(Omdat je het uitbesteed hoeft het niet? onzin)

Imho is het heel simpel: domein met mail = ssl. Omdat de meeste simpele websites ook mail hebben, dus ook ssl.

Ik snap je opmerking tegen wildcards ook niet, ben je bang dat je teveel beveiligt? Want vervolgens geef je het nadeel aan *als je geen wildcard gebruikt*: je moet het allemaal onderhouden.... Wat is nou eigenlijk je punt? Of is zeuren zonder argumenten leuk?

En ja een wildcard is één per domein, en let's encrypt heeft auto-update, dus één keer instellen (drie minuten werk) en klaar.

[Paul]

Sorry, maar je hebt gewoon geen idee waar je het over hebt, en je begrijpend lezen is ook niet al te best (al snap ik dat als je niet weet waar je het over hebt je ook niet begrijpt wat er staat). Gecombineerd met de toon die je aanslaat heb ik ook totaal geen zin je uit te leggen hoe het wel zit.

Mocht je serieus willen weten hoe het zit, mijn DM staat open, maar dan graag zonder het denigrerende toontje. Hier gaat het in ieder geval off-topic.

[Bazer]

Hmmm, mooie ontwikkeling maar toch een vraag.
Gaat FF nu het wachtwoord eerst naar een eigen database/I have been pwnd database sturen voor een match?
zo ja, hoe wordt dit dan verstuurd naar FF voordat dit naar de betreffende website wordt verstuurd?
zo ja, dan kan I Have been pwnd flink wat wachtwoorden verzamelen....

Mooie target...