Firefox krijgt HTTPS-Only Mode die standaard alleen https-sites laadt
Mozilla introduceert vandaag een nieuwe Firefox-versie die van een beveiligingsfeature is voorzien waardoor http-sites standaard niet meer worden geladen. De HTTPS-Only Mode zorgt ervoor dat Firefox standaard elke website via https zal benaderen.
In het geval een website geen https ondersteunt vraagt de browser de gebruiker om toestemming om de site toch te laden. De meeste websites maken inmiddels gebruik van https. Toch vallen websites volgens Mozilla nog geregeld terug op het onveilige en gedateerde http-protocol. Daarnaast zijn er nog miljoenen oude http-links op het web te vinden die naar de http-versie van websites wijzen.
Met de HTTPS-Only Mode zal Firefox geen onbeveiligde verbindingen met websites meer opzetten tenzij de gebruiker dit toestaat. Ook wanneer de gebruiker http in de adresbalk tikt of op een http-link klikt zal Firefox bij deze mode standaard er https van maken. Wanneer een website geen https aanbiedt toont de browser een foutmelding en legt het beveiligingsrisico uit. Vervolgens kan de gebruiker ervoor kiezen om de website wel of niet te bezoeken.
In het geval van 'mixed-content', waarbij de website van https gebruikmaakt, maar bijvoorbeeld afbeeldingen, advertenties of filmpjes via http laadt, kan HTTPS-Only ervoor zorgen dat de website niet goed wordt weergegeven. In deze situaties is het mogelijk om de beveiligingsfeature tijdelijk voor de betreffende website uit te schakelen.
Mozilla stelt dat als het gebruik van https verder toeneemt browsers de ondersteuning van http volledig kunnen uitschakelen en https voor elke website kunnen verplichten. Volgens cijfers van Let's Encrypt wordt zo'n 84 procent van de websites die Firefox-gebruikers bezoeken via https geladen. De HTTPS Only Mode is beschikbaar in Firefox 83 die later vandaag verschijnt. Gebruikers moeten de optie wel zelf inschakelen.
Er zijn nog veel te veel en te vaak zogenaamde downgrade aanvallen mogelijk van https naar http.
Ook zijn er nog veel te veel http-only websites.
Zie https://atlas.eff.org/ voor bestaande problemen.
Het http-protocol zou hard uitgefaseerd moeten worden, net zoals met alles dat "end of lifetime" is.
Maar zoals altijd. Die het kunnen implementeren en er verstand van hebben, doen er niet toe in de discussie.
Die wellicht vanuit geheel andere belangen de beslissingen nemen, hebben er merendeels geen verstand van.
Zo verandert er maar mondjesmaat iets en komt er toch steeds meer gedulde onveiligheid bij,
en gaat het invoeren van "best policies" maar o zo langzaam (security als sluitstuk van de begroting).
Dan zijn er ook nog partijen, die een echt veilig internet nooit zullen dulden (DARPA, NSA, etc.).
Dit vanwege machtsgerelateerde en surveillance behoeften en zij maken per slot van rekening de dienst uit.
Jammer dat de eindgebruikersgemeenschap dat maar steeds blijft tolereren,
maar meestal hebben ze er geen zicht op of het komt niet boven hun bewustzijnshorizon dat dit nodig is
en tenslotte hebben ze helaas andere interessen.
Om soms moedeloos van te worden zo'n toestand.
Zeker voor Internet-puristen van het eerste uur, zoals,
luntrus
Toch is er menig scenario waar het geen ene enkele f uitmaakt.
En omdat letsencrypt gratis certificates weggeeft, denkt men deze policy te kunnen forceren. Ik heb in het begin al lastige vragen gesteld op het letsencrypt forum, onder andere waarom ze in de amazon abuse cloud zitten met een VS jurisdictie. Dat is wel de meest slechte keuze die je kunt maken. Met als resultaat dat ik geblokkeerd ben, lekkere (open) partij is dat letsencrypt. En de arrogantie ook van amazon om gewoon een ex NSA hoofd in de board op te nemen.
En het domme volk, is maar wat blij dat ze hun certificatetje gratis krijgen, verder kijkt men niet.
Maar wel met uitzonderingen. Bij apparaten die in je eigen lan staan is het apparaat zelf de webmaster en moet zelf die certificaten vernieuwen. Volgens de browser-eisen die sinds afgelopen september gelden moet zo'n apparaat elk jaar een nieuw certificaat krijgen die ook nog door een externe autoriteit ondertekend moet zijn.
Dit gaat heel veel problemen opleveren. Dus voor apparaten met een IP adres in de privé range, moet een lagere eis gesteld worden. b.v. Safari geeft bij dergelijke certificaten geen foutmelding als je het locale apparaat met zijn IP adres oproept. (wel als je een domeinnaam gebruikt die naar dat locale IP adres resolved.) Veel andere browsers geven altijd een foutmelding bij aanroepen via het IP adres. Voor de gemiddelde gebruiker zitten hier nog veel problemen bij https-only.
Normaal roep ik mijn router, die alleen http kent, op met "ubee.local". Dit geeft allerlei blokkeringen zoals in het artikel besproken. Gebruik ik het IP adres van de router, dan blijven die waarschuwingen weg. (Behalve dan dat er een doorgestreept slotje staat)
Waarom kunnen ze niet detecteren dat de url naar een locaal IP resolved en dit net zo behandelen als het locale IP zelf.
Daar heb ik nog geen zicht op, want 'HTTPS Everywhere' werkt met een gigantische lijst van TLDs waarvoor HTTPS als alternatief voor het onbeveiligde HTTP-domein voorhanden is. Dat is een ander mechanisme dan bij voorbaat HTTP geheel uitsluiten ten gunste van HTTPS, waarin de nieuwe 'HTTPS-Only Mode' functie van Firefox voorziet.
Ik ben benieuwd wat voor gevolgen dit heeft voor de implementatie van HTTPS Everywhere onder de Tor Browser.
Hopelijk houden site eigenaren even in de gaten dat https://website.[ext] vaak niet goed werkt, omdat ze verwachten dat hun klanten https://www.website.[ext] intypen en op het bare domain alleen http de redirect goed doet. Want zo een fout gaat weer roet in het eten gooien. Krijg je weer van die pieten discussie.
Normaal roep ik mijn router, die alleen http kent, op met "ubee.local". Dit geeft allerlei blokkeringen zoals in het artikel besproken. Gebruik ik het IP adres van de router, dan blijven die waarschuwingen weg. (Behalve dan dat er een doorgestreept slotje staat)
Waarom kunnen ze niet detecteren dat de url naar een locaal IP resolved en dit net zo behandelen als het locale IP zelf.
Verder: het grootste probleem heet roverheid. Ik geloof niet dat https daar veel tegen doet...
Inderdaad. Hier wordt door de meeste mensen veel te makkelijk aan voorbij gegaan. Zal wel komen door die “groene slotjes” campagne.
Als ik een website maak over mijn hobby, hier alleen statische content op host, niet vraagt aan mensen om gegevens in te vullen, wat is dan de meerwaarde van https?
luntrus
ligt hem in het feit dat de achterliggende webserver soms benaderbaar is.
We begrijpen nu ook beter de rol van 'de cloud' om dit te mitigeren.
Een eventuele "verkennende" aanvaller kan zo op zoek gaan naar "weak cgi" of "weak PHP" wetsbaarheden.
Dazzlepod scans kunnen hierbij ook helpen, maar waar misbruik van elke scan wordt gelogd
Http-sites werden zo letterlijk eens "uitgekamd" met een tooltje als "Intellitamper".
Nu kan men met een DOM-XSS sources and sinks scan nog steeds los op een website, die ook via http opent.
Ook een speciale malware analyse browser als Malzilla geeft een aardig beeld van de veiligheid.
Of een scan met een extensie als VULNERS en het onvermijdelijke shodannetje.
Maar er is meer en ook nog een graadje geniepiger. Dat ligt buiten het bestek van dit draadje.
Gaat dus hier niet zozeer om de content, die op een bepaalde website beveiligd moet worden (ook wel in zekere zin),
maar meer om een veilige verbinding te garanderen tussen website op de client (vaak in een browser dus)
naar de achterliggende webserver.
luntrus
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
