EFF stopt met ontwikkeling van Https Everywhere-browserextensie

De Electronic Frontier Foundation stopt eind dit jaar met de verdere ontwikkeling van zijn Https Everywhere-browserextensie. Volgens de makers wordt het protocol door genoeg browsers standaard ondersteund om de ontwikkeling te staken.

Vanaf volgend jaar zal de extensie in onderhoudsmodus geplaatst worden en dat tot het einde van 2022. Daarna wordt de ontwikkeling definitief gestaakt en raadt de Electronic Frontier Foundation aan om via browsers te surfen die een native https-only modus aanbieden zoals Firefox, Chrome, Safari en Edge.

De Https Everywhere-extensie verhindert dat browsers onbeveiligde Http-verbindingen tot stand brengen door door te verwijzen naar een domeinnaam die het veiligere Https-protocol ondersteunt. Dankzij een Https-verbinding is het moeilijker voor kwaadwilligen om informatie te onderscheppen die uitgewisseld wordt tijdens het browsen. Als het niet mogelijk is om een beveiligde verbinding tot stand te brengen, wordt de gebruiker gewaarschuwd. Hij of zij kan dan kiezen om verder te navigeren naar de website of om naar een andere website te surfen.

De eerste versie van de Https Everywhere-extensie kwam uit in 2010 als publieke bèta voor de Firefox-webbrowser. Sinds april dit jaar stapte de EFF over naar de database van DuckDuckGo's Smarter Encryption en voegde het zelf geen regels meer toe aan de database van websites waarvan het weet dat er een versleutelde Https-versie van bestaat. Toen werd ook bekendgemaakt dat de extensie later dit jaar zou worden uitgefaseerd.

Reacties (51)

Weet iemand of de Android versie van Firefox ook een HTTPS only setting heeft?

Dat heb ik helaas nog niet kunnen vinden dus is voor mij HTTPS everywhere zeker nog nodig op mobiel. Vooral omdat je daarmee wellicht vaker in de verleiding komt op onbekende WiFi in te loggen en goede HTTPS verbinding dan extra belangrijk is.

Dat kan door naar about:config te navigeren, en "dom.security.https_only_mode" op true te zetten.

Wat raar dat deze instelling niet standaard zichtbaar is, ook (nog) niet in de developer/nightly editie op Android.

Bedankt! En zoals @HollowGamer al aangeeft, wat suf dat deze instelling zo verstopt zit.

Hmmm, naar nu blijkt is about:config uitgeschakeld op recente versies van Firefox for Android.
Dan blijft HTTPS everywhere nog wel noodzakelijk op Firefox for Android....

Ah dat wist ik niet... ik draai inderdaad Firefox Beta

Off topic.

Jammer dat er naast gratis website certificaten geen gratis s/mime-everywhere-certificaten zijn voor e-mail.

Er zijn betaalde aanbieders. Of een "vage" partij als MeSign die bijvoorbeeld niet op IOS werkt. Actalis, werkt ook niet met Apple Mail.

Ik weet het. Er zijn voldoende andere e-mail encryptie systemen en encrypted e-mail aanbieders

Ik snap niet dat Google, Microsoft en Apple niet een keer samen om de tafel gaan zitten om een veilige opvolger van e-mail samen af te spreken. Als die vervolgens standaard in Android, iOS, MacOS & Windows zit en zo hard gepushed wordt als de browsers is de wereld in een jaar over. Zou voor hun ook een hoop problemen met spam en malware kunnen voorkomen als het een goed ontworpen standaard is.

Op zich bestaat het framework om spam zo goed als te killen al: https://en.wikipedia.org/wiki/Sender_Policy_Framework

Het is heel effectief tegen spam, echter het vereist wel 2 dingen:
1) De domein eigenaar moet aangeven in de DNS welke IP's namens het domein email mogen sturen. Een populaire optie is "mx", wat neer komt op alle servers in de MX-records.

2) Mail-servers moeten controleren op dit record en hard-fails droppen zonder notificatie.
Daardoor zou grofweg 90 a 95% van alle spam niet meer aan komen en dus nutteloos worden.

Ik ken spf, dmarc en dkim wel, maar dat voorkomt enkel dat de spam aan komt of zichtbaar is, niet dat gepoogd wordt het te versturen en je kan als spammer prima spammen vanaf geldige domeinen, een domein kost niet veel.

De extra energie die bedrijven als Google, Microsoft en Apple kwijt zijn aan spam verwerking is daarmee niet opgelost. En wat ook niet opgelost is, is dat mijn mail onbeveiligd kan zijn als de ontvangende partij een onveilige server gebruikt. Dan kan het zomaar zijn dat ik een datalek heb doordat de ontvanger z’n zaakjes niet op orde heeft. Je weet immers de weg niet als twee servers met elkaar praten en als de boodschap niet gegarandeerd beveiligd is moet je er vanuit gaan dat de gegevens op straat liggen.

Zeker het stopt spammers niet om te spammen vanaf hun eigen domeinen
Maar het stopt wel het spoofen van domeinen om de afzenders te verhullen. Wat phishing e.d. lastiger maakt. En spammen vanaf botnets wordt dan ook direct een stuk lastiger gezien er geldige domeinen nodig zijn zonder spf-record

Is het de heilige graal? Nee. Maar als je hierdoor als het gros van de huidige automatische spam kan killen wordt het een stuk makkelijker om de rest te filteren. En een domein met geldige servers kost wellicht niet zoveel, maar nog altijd stukken meer dan een botnetje voor een uurtje huren en 100.000 emails eruit schoppen

De email komt de eerste tijd wel nog aan op de mail-servers, maar niet meer in de inboxen van de gebruikers. Waardoor er niemand meer in trapt, waardoor er geen verdien-model is. Spammers willen geld verdienen.

[Reactie gewijzigd door hackerhater op 23 september 2021 14:46]

Omdat ook Google, Microsoft en Apple gezamelijk daar niet genoeg macht voor hebben in de techwereld. E-mail zit te diep verweven in de wereld. HTTP kunnen we ook nog heel lang niet loslaten en daar zijn we als internet-samenleving nu toch best wel een tijdje met zijn allen mee bezig.

Buiten het westen hebben die drie niet zo heel veel directe invloed. Zelfs al stappen we nu per direct over, e-mail gaat nog zeker 10 jaar nergens heen.

Er valt tegenwoordig nog maar weinig aan e-mail te verbeteren zonder het gedecentraliseerde kernprincipe onderuit te halen. Versleuteling zou standaard mooi zijn, maar nog genoeg systemen uit het jaar kruik dat aan het internet hangen die van email afhankelijk zijn of hele hordes mensen in de wereld die nog op laptops en 'smartphones' uit de oudheid draaien waarvan de software al eeuwen niet ondersteund wordt.

Die legacy raak je echt niet binnen een jaar kwijt. ~4.5miljard internet-gebruikers. Ze hebben niet allemaal Facebook, LinkedIn, een Telefoonnummer of whatever. Maar -praktisch- wel allemaal een e-mail adres.

Wie kan mij een voorbeeld geven van een populaire site waarbij je niet standaard al naar https wordt omgeleid?Ik kan me echt niet herinneren recent nog een site gezien te hebben die niet https standaard is.

Ik heb deze plugin nooit gehad, maar volgensmij is het doel om downgrade attacks te verhinderen.

De extensie heeft volgens mij twee scenario's.
De eerste raakt aan wat je noemt: de website is normaal wel via https beschikbaar, maar op het moment dat een slechterik jouw verkeer naar voorbeeldbank.com overneemt, laat hij https uit en valt het jou niet op. Daar zijn nu twee goede technieken tegen. Aan de ene kant maakt de browser steeds explicieter dat je géen https hebt. Aan de andere kant HSTS: de server vertelt je browser bij je eerste bezoek 'de komende {12} maanden* mag je alleen https verwachten van mijn server'.

De andere: websites die vanaf http mogelijk houden en je niet naar de bestaande https-veraint leiden. Bewust of door gebrekkige configuratie; in het eerste geval kan het zijn dat beheerder denkt dat er nog gebruikers zijn die behoefte hebben aan http of dat https een te grote performance hit kan zijn.

* 12 maanden is wat de richtlijnen van het NCSC voorschrijven. Je kunt je server testen hierop via https://internet.nl

Is er een voorbeeld waarbij dat ooit een serieuze aanval is geweest? Bijvoorbeeld bij een bank of zo?

Wie kan mij een voorbeeld geven van een populaire site waarbij je niet standaard al naar https wordt omgeleid?

Alstu.

Ik zie bij die site een certificaat:

Verstrekt door: Cloudflare Inc ECC CA-3; Verloopt op: woensdag 13 juli 2022 om 01:59:59 Midden-Europese zomertijd

Lijkt me ook niet echt een populaire site.

Verder de sites die daar genoemd worden: Ik zie niks dat echt populair is behalve Videoland.org. Maar als ik naar www.videolan.org ga wordt ik naar https geredirect. Lijkt alleen of ze hun Videoland.org niet goed hebben staan.

Tinypic was een belangrijke, maar als je daar nu naar toe gaat zie je: "TinyPic Has Ceased Operations; Make the switch to Photobucket".

Iedere enigszins normale site is toch wel https, zelfs als je er totaal geen gegevens kan invullen en de inhoud volstrekt onomstreden is.

[Reactie gewijzigd door Sannr2 op 23 september 2021 10:52]

Ik wil niks zeggen maar:

- http://apache.org/ redirect niet naar https. De makers van oa. de Apache web server
- http://myshopify.com/ redirect niet naar https. Een van de grootste e-commerce platforms (naast Magento en PrestaShop)

En dat zijn er 2 uit de eerste 5.

Toegegeven, sommige redirecten wel naar https inmiddels en sommige bestaan gewoon niet meer, dus dat lijstje kan wel een update gebruiken.

Precies, ik vond het redelijk pijnlijk dat w3.org erbij stond maar die redirect toch echt wel naar https.

Nouja...

Hij redirect wel, maar niet met een 301:
curl -I http://www.w3.org
HTTP/1.1 200 OK
vary: negotiate,accept,Accept-Encoding,upgrade-insecure-requests

w3c.org doet dat wel:
curl -I w3c.org
HTTP/1.1 301 Moved Permanently
Location: https://www.w3.org

videolan.org stuurt je wel degelijk niet door naar https. Maar hun https versie heeft wel STS, dus als je die 1 keer bezoekt dan zal je het half jaar daarna die site via die browser niet op http kunnen openen, dus mogelijk dat dat voor jouw browser het geval is.

Kijk je met curl bv naar de headers die ze terug geven dan zie je inderdaad dat er geen redirect op de http zit:
$ curl -v -o /dev/null http://www.videolan.org/
< HTTP/1.1 200 OK
< Server: nginx/1.21.3
< Date: Thu, 23 Sep 2021 09:56:37 GMT
< Content-Type: text/html
< Content-Length: 65710
< Connection: keep-alive
< Last-Modified: Thu, 23 Sep 2021 09:55:02 GMT
< Vary: Accept-Encoding
< ETag: "614c4ef6-100ae"
< X-Accepted-Language: en
< X-Accepted-Fulllang: en
< Accept-Ranges: bytes
< X-Clacks-Overhead: GNU Terry Pratchett

Een goede site geeft o.a. deze 2 in de headers terug:
< HTTP/1.1 301 Moved Permanently
< Location: https://tweakers.net/

Klopt, er staan veel sites tussen die gewoon wel aan http-https-redirects doen (bijv. Funda en Jumbo).

Wat mij wel verbaasde is dat nginx.org tussen die lijst staat. Lijkt me een slecht plan om de download pagina van zeer populaire software via http te serveren! Die pgp signatures heb je dan ook niks aan op de http-pagina.

Zelfde geldt trouwens voor de Apache-http-server. De httpS versie van hun projects-list op apache.org linkt zelfs naar de http versies van hun projecten.

Om zeker te zijn dat je de echte apache downloadt moet je dus handmatig een 's' toevoegen in je url, is dit niet een heel groot probleem? Zeker in sommige landen?

Wel gênant dat w3.org daar tussen staat.

Het punt is juist dat je met zo'n redirect potentieel al te laat bent.

Als ik naar http://rabobank.nl ga kan die verbinding op dat moment worden gekaapt en kunnen ze me doorverwijzen naar https://rabobank.nl/ waar een van de tekens niet de normale letter is maar iets wat er zo veel op lijkt dat ik het verschil niet zie. Dan ben ik dus naar het juiste domein gegaan, omgeleid naar een https-pagina, zoals ik verwacht hadm met een gledig certificaat en als ik in probeer te loggen ben ik de sigaar.

Wat je nodig hebt is dat de browser weet dat rabobank.nl https ondersteunt en nooit probeert de http variant te laden. Dat is wat deze plugin doet.

Maar je krijgt dan standaard toch al een flinke waarschuwing? Hij zal niet onzichtbaar redirecten aangezien het een ander domein is. Zoals hier: https://support.google.co...-site-is-not-secure?hl=en ?

Hij zal prima redirecten als het certificaat gewoon bij het domein hoort. Dus als ik http://rabobank.nl via een MITM kan omleiden naar https://rab0bank.nl dan is er voor de gebruiker niets aan de hand. Die krijgt gewoon een clone van de website van de bank te zien en de website is beveiligd met SSL. Simpelweg omdat het niet het juiste domein is.

Het doel van de HTTPS Everywhere extensie was dan ook dat het hele HTTP verzoek werd overgeslagen en dat de gebruiker direct naar https://rabobank.nl werd gestuurd. Veel veiliger natuurlijk.

http://www.httpvshttps.com Bedoel je zoiets?
Edit: http://http.badssl.com/ Dit is een ander testsite daarvoor.

Edit: Een site die al veel gebruikt wordt heeft meestal al een standaard verwijzing naar de https://, de vraag is eerder doet je browser dat wel?

[Reactie gewijzigd door cruysen op 23 september 2021 10:45]

Lijkt me ook niet echt een populaire site.

Als je browser dat niet doet, waarom zou je er dan op vertrouwen dat de plugin wel werkt? Waarom zou je browser dat niet doen? Als je een virus hebt dat dat gedrag veranderd, dan kan dat virus ook die plugin uitzetten toch?

Bij http://www.belastingdienst.nl was dit het geval.... blijkt nu wel een redirect naar https te doen.

Als je een schone browser gebruikte die nog nooit naar https:/www.belastingdienst.nl was geweest kreeg je nooit de website te zien, want er werd geen redirect/rewrite gebruikt om je van http naar https door te zetten.
Geen idee wanneer ze dit eigenlijk wel geregeld hebben.

Dan lijkt mij DuckDuckGo Privacy Essentials een goeie vervanger? Doet hetzelfde en gebruikt dezelfde database.

Een goeie vervanger? Je kan HTTPS al forceren in Chrome 94 (zie de source), dus waarom zou je deze extra extensie dan gebruiken?

(ook @Anoniem: 1657372)
Mijn browser kan dat niet (Firefox 78 ESR).
Zodra ik de nieuwe ESR heb wel, maar ik weet niet of je daarbij ook makkelijk per site kan regelen of https afgedwongen moet worden? Want niet alle sites hebben het (helaas).
Dus lijkt me zo'n addon nog wel handig.
edit: Ah, ik zie hier dat je het ook per site kan regelen. Maar dan moet je dat wel met de hand doen, die addon doet dat vanzelf. Of soms zijn er niet te voorspellen redirects nodig, bijv http://web.site/ -> https://secure.web.site/ .

[Reactie gewijzigd door N8w8 op 23 september 2021 10:28]

Zo had HTTPS Everywhere ook het gebrek dat als een website niet in de lijst van HTTPS Everywhere voorkwam dat je gewoon naar de http site gaat, tenzij de website zelf de verbinding upgradet wat later ook wel de standaard is geworden. Tenzij je HTTPS Everywhere in Encrypt All Sites Eligible is ON mode zet.
Wat dat betreft doet Firefox het beter, standaard altijd https aanvragen en als dat niet ondersteund wordt pas http aanbieden.

Tevens is State Partitioning geintroduceerd in Firefox 85 en 86, wat je privacy verhoogt:
State Partitioning:
https://developer.mozilla...rivacy/State_Partitioning
Introducing State Partitioning
https://hacks.mozilla.org...ucing-state-partitioning/
Firefox 85 Cracks Down on Supercookies
https://blog.mozilla.org/.../supercookie-protections/
Firefox 86 Introduces Total Cookie Protection
https://blog.mozilla.org/.../total-cookie-protection/

Tijd voor je upgrade naar Firefox 91.1.0esr.

Maar er is dus wel een nieuwere ESR waar je het op kunt gebruiken, lijkt me sowieso verstandig om wel altijd de nieuwste release te gebruiken (wat nu volgens mij 91 is voor de ESR?).

Daarnaast lijkt het me juist goed dat het eerst wordt afgedwongen, en dat je pas daarna de uitzondering maakt. Er zijn inderdaad sites die het niet ondersteunen, maar ik denk dat het voor de bewustwording wel goed is als je een foutmelding krijgt in plaats van een add-on die dat op de achtergrond voor je regelt. Ik kan me namelijk niet voorstellen dat dit honderden sites zijn die je er op moet zetten (ik weet natuurlijk niet wat je doet met je laptop, maar uiteindelijk bezoekt een gemiddelde internetter toch niet duizenden unieke sites per dag )

Helaas niet, voor ESR is Firefox 78 zo te zien een mogelijkheid:
https://www.mozilla.org/nl/firefox/all/#product-desktop-esr

Persoonlijk zou ik ook liever de nieuwste ESR draaien of gewoon de desktop variant, echter in enterprise kan het om verschillende reden weer ongewenst zijn (wederom helaas maar waar).

Ik heb 78 omdat dat in Debian zit. Dat werkt gewoon prima en voortijdig upgraden is gedoe.
En zo'n addon heb ik geen omkijken naar, behalve nu ff switchen naar DuckDuckGo, en dealen met alle reacties daarop (edit: waarvoor bedankt overigens)

Maar ik verwacht dat Debian die nieuwe ESR binnenkort biedt, dan kan ik dat https only proberen, wellicht is dat idd beter.
Want nu kijk ik voordat ik gevoelige dingen doe (zelden) of t veilig is.
Forceer je https, dan hoeft dat niet meer.
Maar je moet dan toch nog steeds het domein controleren, en dealen met de uitzonderingen.
Dan is het de vraag wat de minste aandacht vereist.
Alles https, ipv addon met n hele database, is achter de schermen iig een stuk eenvoudiger.

[Reactie gewijzigd door N8w8 op 23 september 2021 13:40]

Je krijgt simpelweg een scherm te zien dat het geen https site is. Dan kun je kiezen voor “continue without https”.

Je krijgt wanneer websites geen https ondersteunen een melding. Dan klik je op 'toch http bezoeken' en kun je de website bekijken. Ik gebruik de functie die ingebouwd zit in FireFox al lange tijd en het draait als een zonnetje.

Maar waarom wil je perse een vervanger? Ze stoppen er juist mee omdat het gros van de browsers ondertussen functies heeft ingebouwd die exact hetzelfde doen als de plugin, waardoor deze eigenlijk overbodig wordt.
Er zullen vast kleinere browsers zijn die ik niet ken die het niet ondersteunen, maar dan is de vraag of daar een makkelijk te installeren plugin voor is

Dat is niet exact hetzelfde. Ik heb HTTPS Everywhere bij mijn familie geinstalleerd omdat het stil in de achtergrond werkt. Als er geen HTTPS versie van de site is gaat hij gewoon naar HTTP, dat is voor 'noobs' veel geschikter dan een paginagrote waarschuwing of je door wilt gaan of niet.

Dat is toch al vrij standaard? Als ik naar tweakers.net surf kom ik uit op https:// omdat daar standaard naar wordt doorverwezen. Mocht er geen https:// zijn dan beland ik op http://.
Ik dacht juist dat het hele punt van HTTPS Everywhere was dat je niet zondermeer op een onbeveiligde website terecht kan komen, dus als hij 'gewoon' naar http:// gaat voegt het weinig toe?

Chrome geeft volgens mij tegenwoordig lelijke waarschuwingen als je http websites bezoekt. Edge en Firefox laten ook merken dat je 'niet veilig' bent.

Geen idee of HTTPS Everywhere dat allicht anders aanpakt.

Tegenwoordig is dat inderdaad steeds minder nodig, maar toen HTTPS Everywhere werd uitgebracht was doorsturen naar de https versie nog niet standaard. Daarnaast biedt het nog wel het voordeel dat het gelijk via https gaat, een aanvaller voldoende toegang tot het netwerkt voor MitM zou de doorverwijzing kunnen onderscheppen zodat het slachtoffer op toch de http pagina terecht komt, of op een eigen namaaksite van de aanvaller, die dan niet opvalt omdat de URL niet anders is.
HTTPS Everywhere heeft wel sinds een tijd een functie om unencrypted requests te blokkeren, ik neem aan dat je dan wel zo'n waarschuwing pagina krijgt, vergelijkbaar met die van de browser zelf, maar die functie staat standaard uit.

Jammer, want ik merk dat er soms als nog sites zijn die niet door de browser in https wordt weer gegeven en door deze extentie wel

Als je de gelinkte blogpost met aanbevelingen opent staat er per browser een simpele instelling die je moet veranderen om hetzelfde gedrag te krijgen als met de plugin. Je moet dus wel zelf nog een actie doen om de plugin overbodig te maken.

Ik ben wel benieuwd wanneer dat eindelijk de standaard gaat worden.

Dat is niet hetzelfde gedrag. Ik heb HTTPS Everywhere bij mijn familie geinstalleerd omdat het stil in de achtergrond werkt. Als er geen HTTPS versie van de site is gaat hij gewoon naar HTTP, dat is voor 'noobs' veel geschikter dan een paginagrote waarschuwing of je door wilt gaan of niet.

Is, zoals het artikel ook beschrijft, zonder deze extensie ook mogelijk.
nieuws: Firefox 83 met 'https-only'-modus verschijnt
nieuws: Edge 92 krijgt Automatic Https-functie die versleutelde verbindingen ...

waarom gebeurt die op basis van database,
het systeem kan toch ook een realtime check doen of er een https versie beschikbaar is?

Dat zou afhankelijk van de response time van de website een grote vertraging toe kunnen voegen aan elke nieuwe website die wordt geladen. Helemaal als websites niet correct geconfigureerd zijn en helemaal niet reageren op requests (wachten op timeout).

Omdat webservers wel eens verkeerd geconfigureerd zijn en op https reageren met een algemene hoster-pagina ipv een foutmelding te geven.