Firefox geeft vanaf versie 119 alleen nog HTTP-verbindingen weer, geen Https

Firefox 119 gaat geen Https meer weergeven in de adresbalk. Mozilla gaat de prefix alleen nog weergeven als een site geen gebruik maakt van TLS. Alleen HTTP is vanaf dat moment nog te zien. Subdomeinen blijven wel nog zichtbaar.

De veranderingen zijn te zien in een bugtrackinglijst van de browser. Daarin staat dat Firefox in de Nightly van versie 119 aan 'Https-trimming en een label voor onbeveiligde verbindingen' gaat doen. Dat betekent in de praktijk dat de browser niet meer gaat aangeven wanneer een website een Https-verbinding heeft. In dat geval staat er alleen de URL van de website inclusief een subdomein als www. Mozilla heeft geen plannen dat laatste weg te laten.

Volgens Mozilla maakt het overgrote deel van de websites inmiddels gebruik van een versleutelde verbinding. Daarom is het niet meer logisch die informatie weer te geven, aldus het bedrijf. Dat is wel het geval als een website via een niet-beveiligde verbinding loopt. In dat geval gaat Firefox wel tonen dat er een HTTP-verbinding is opgezet door HTTP in de adresbalk te zetten. Daarnaast verschijnt er in dat geval ook de tekst 'not secure'.

De aanpassingen komt in versie 119 van de browser. De Nightly-release daarvan is eind oktober. Gebruikers kunnen via een flag in about:config wel de instellingen terugdraaien.

Door Tijs Hofmans

Nieuwscoördinator

19-09-2023 • 16:44

110

Reacties (110)

110
107
53
5
0
42
Wijzig sortering
Gebruikers kunnen via een flag in about:config wel de instellingen terugdraaien.
browser.urlbar.trimHttps ---> false
Mooie. Goed om uit te rollen binnen organisaties ook lijkt me. Begint het eindelijk te lukken mensen te laten kijken naar https... :+
https boeit niet zo, als het alternatief is dat er 'not secure' staat dan lijkt mij dat veel duidelijker en makkelijker voor gebruikers om op te pikken in plaats van dat ze 1 letter verschil moeten zien. Als ik zie hoeveel mensen mij op de weg al over het hoofd zien dan maak je mij niet wijs dat ze die 's' in http/https wel elke keer zien.
Het probleem daarmee is dat als er niet 'not secure' staat, het niet betekent dat de site wel veilig is. En leg dat maar eens uit aan een leek. Leken krijgen 'https' als een van de meerdere signalen waar ze op moeten letten. Je moet er verder geen waarde aan hangen, dat is aan de gebruiker zelf om te beoordelen. Je zou het wel 'not https!' of 'insecure http' kunnen noemen.

[Reactie gewijzigd door Room42 op 23 juli 2024 12:55]

https betekend ook niet dat de site veilig is. Enkel dat de verbinding encrypted is.

Zo'n beetje iedere phishing site anno vandaag wordt aangeboden via https.
https betekend ook niet dat de site veilig is.
Dat is exact mijn punt.
Enkel dat de verbinding encrypted is.
En zelfs dat is enkel gegarandeerd van de browser tot de node (vaak een reverse proxy) die de 'TLS offloading' doet. Wat daarachter gebeurt kan nog steeds gewoon plain http zijn.
Zo'n beetje iedere phishing site anno vandaag wordt aangeboden via https.
Maar dat is dan altijd via onofficiële, alternatieve domeinen. (Tenzij de private key gelekt is, maar dat is uitzonderlijk.)

[Reactie gewijzigd door Room42 op 23 juli 2024 12:55]

Dit. En dan de (corporate) firewalls die grapjes uithalen met eigen certificaten, reverse proxy en/of certificate forwarding om aan content filtering etc. te doen. Dat https je verbinding end-to-end versleutelt, is gewoon een illusie.
Het enige waar je min of meer tegen beveiligd bent is zowat http meelezen vanop een promiscuous port op een switch onderweg en het prutsen aan de data. Maar elke hop (router/firewall) kan je request afvangen en forwarden/proxy'en en zo toch lekker alles meevolgen.
Nee dat is geen illusie. MitM is alleen mogelijk na importeren CA en dan nog is het lastig als er certificate pinning in de browser zit bijv.

Of vertrouwt jouw browser alle certificaten blind?
Je hebt gelijk dat je browser een trusted chain nodig heeft en een firewall niet zomaar doodleuk het originele certicaat kan presenteren (private key). De browser zal certificaten enkel accepteren met een trusted chain van CA's.
Ik doelde op scenarios met firewalls met https inspection. "Meevolgen" is dan inderdaad het gevolg van het feit dat je browser een "fake" certicaat gewoon vertrouwd zolang ie de CA vertrouwd en je als gebruiker niet weet/controleert wat de chain van je certificaat is.

* the_stickie ging eerder wat kort door de bocht
Mijn punt is vooral dat het dus niet uitmaakt of er https staat of niet.

Not secure is precies wat het zegt.

Anders is het altijd verstandig om te kijken wat de URL is. Niet je inloggegevens invullen op rs6.ro dus.

Dat https ontbreekt is niet zo boeiend om uit te leggen.

En van load balancer/offloader is verantwoordelijkheid van de site eigenaar lijkt me. Als ze in kunnen breken kunnen ze inbreken... niet iets waar de gebruiker verder wat aan kan doen.
En zelfs dat is niet helemaal correct. TLS versleuteld alleen laag 7 application layer van het IOS model. Alle onderliggende netwerk data is gewoon zichtbaar.
Bedankt, heb het alvast ingesteld voor als deze update komt. Die instelling zit er nu niet in maar je kan zelf een boolean toevoegen.
Ik zie er op zich de meerwaarde niet van. Zolang je zekerheid hebt dat er een beveiligde verbinding gebruikt wordt is het goed, toch? Dat hoeft (ook in de toekomst) zeker niet per se via HTTPS te zijn. Dat kan bijvoorbeeld ook QUIC (HTTP/3, HTTP-over-QUIC) worden, ik noem even wat. Uiteindelijk is het belangrijkste om te weten of de verbinding dus beveiligd is of niet. En die indicatie blijf je houden, vergelijkbaar met de strict modus van de browser, die een melding geeft wanneer je een onbeveiligde pagina benaderd. :)
Ik zie er op zich de meerwaarde niet van.
Ik wel. Different strokes for different folks.
Zolang je zekerheid hebt dat er een beveiligde verbinding gebruikt wordt is het goed, toch? Dat hoeft (ook in de toekomst) zeker niet per se via HTTPS te zijn. Dat kan bijvoorbeeld ook QUIC (HTTP/3, HTTP-over-QUIC) worden, ik noem even wat.
QUIC is een algemeen transport layer protocol. HTTP/3 gebruikt QUIC, maar QUIC is niet per se HTTP/3. Voor HTTP/3 wordt gewoon de https:// URI-scheme gebruikt. Dat is ook logisch.
Uiteindelijk is het belangrijkste om te weten of de verbinding dus beveiligd is of niet.
En dat zie ik graag d.m.v. https:// of http://.
QUIC is een algemeen transport layer protocol. HTTP/3 gebruikt QUIC, maar QUIC is niet per se HTTP/3. Voor HTTP/3 wordt gewoon de https:// scheme gebruikt. Dat is ook logisch.
Het punt is, dat het in de toekomst misschien ook scheme onafhankelijk kan worden. Dus dan hoef je geen HTTP/HTTPS te gebruiken, maar kan het ook prima iets anders zijn. Om dan altijd maar HTTP/HTTPS ervoor te hebben, is dan ook onlogisch. Daarop voorbereiden lijkt me niet verkeerd, zeker ook gezien de reacties alhier. ;)
En dat zie ik graag d.m.v. https:// of http://.
Ik zie dat liever aan de hand van het certificaat dan alleen aan HTTP/HTTPS. ;)

[Reactie gewijzigd door CH4OS op 23 juli 2024 12:55]

Zelf kijk ik niet zo vaak naar certificaten van verbindingen. Mijn tijd besteed ik liever aan nuttigere en/of leukere zaken.

Ik zie liever dat browsers straks gewoon HTTP-verbindingen gaan weigeren op dezelfde manier als dat nu incorrecte certificaten geweigerd worden. Dat kan nu al optioneel in Firefox. Met dat heb ik zekerheid dat ik niet onbewust een HTTP-site bezoek.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 12:55]

Zelf kijk ik niet zo vaak naar certificaten van verbindingen. Mijn tijd besteed ik liever aan productievere en nuttigere dingen.
Zo vertrouw je dus blindelings elke certificate chain en dat is waar men juist van af wilt. ;)
Ik zie liever dat browsers straks gewoon HTTP-verbindingen gaan weigeren op dezelfde manier als dat nu incorrecte certificaten geweigerd worden. Dat kan nu al optioneel in Firefox. Met dat heb ik zekerheid dat ik niet onbewust een HTTP-site bezoek.
Met de strict modus kan je dat nu al enigszins forceren, je moeet dat alleen zelf aan zetten. Je krijgt dan de melding "Yo, @The Zep Man, je staat op het punt een onbeveiligde pagina te openen!" hier zijn dan twee knoppen op: <toch doorgaan> <niet openen> ;)

Maar als dit laatste gemeengoed is, is het ook niet echt relevant meer of het HTTP of HTTPS is, dat is mijn punt. Deze update is daarvoor een stap. ;)

[Reactie gewijzigd door CH4OS op 23 juli 2024 12:55]

Maar als dit laatste gemeengoed is, is het ook niet echt relevant meer of het HTTP of HTTPS is, dat is mijn punt. Deze update is daarvoor een stap. ;)
Wel voor beheer, met soms lokale apparatuur die geen HTTPS ondersteunt.

Different strokes for different folks. Je hoeft mij niet te overtuigen van jouw voorkeur.
Zo, zo vertrouw je dus blindelings elke certificate chain en dat is waar men juist van af wilt. ;)
Wat kan er foutlopen misschien? Als de CA het certificaat heeft ondertekend, is het toch de facto betrouwbaar? Behalve natuurlijk als de private key van het certificaat gelekt is waardoor MitM weer mogelijk is, maar hopelijk is dat niet het geval.

[Reactie gewijzigd door RuddyMysterious op 23 juli 2024 12:55]

Wat kan er foutlopen misschien?
Dat is juist het punt: je moet niet zomaar elke certificate chain vertrouwen. Ook kwaadwillenden kunnen gratis TLS certificaten via Let's Encrypt verkrijgen bijvoorbeeld en heb je dus ook een valid beveiligde verbinding. Het beschermt dus niet tegen bijvoorbeeld phishing.

[Reactie gewijzigd door CH4OS op 23 juli 2024 12:55]

Als kwaadwillenden een gratis certificaat via Let's Encrypt willen kunnen krijgen moeten ze eerst controle hebben over het domein, dat lukt niet zomaar bij een domein dat ze oorspronkelijk niet zelf bezitten. Dit is exact de drempel die een HTTPS-verbinding afdwingt.

Akkoord dat bepaalde instellingen als banken of overheid vaak een hoger level certificaat hebben met extra garanties waar je inderdaad op kan letten, maar heel vaak is het kapen van een domein al voldoende intrusief zodanig dat je de gehele website al niet meer kan vertrouwen, dus gaat een hoger level certificaat al niet veel meer kunnen doen om jouw data of geld te beveiligen.
Kwaadwillenden kunnen ook phishers zijn. Die dus een eigen domein hebben, maar een kopie van de website van PostNL, DHL en noem ze maar op hebben. Lijkt me dat daarop het gemakkelijk te fixen is. :)

[Reactie gewijzigd door CH4OS op 23 juli 2024 12:55]

Liever niet. Ik zit er niet op te wachten voor elke lokale dev server een certificaat te moeten regelen (gaat ook zo lekker met localhost).
Je kan voor HTTPS only natuurlijk uitzonderingen maken voor lokale IP's. Firefox doet dit al.
Voor lokaal intern gebruik kan http nog altijd nuttig zijn, ook om iets te testen. Niet iedereen kan lokaal zomaar even ssl/nginx opzetten. Ik zie mezelf al les geven en verplicht over ssl ... De meeste studenten kunnen met moeite met een commandline werken, laat staan dat ze dan lokaal effe ssl voor een webapplicatie gaan opzetten. Zoals het nu werk is het prima: dikke vette melding dat dit http is, en dan is het je eigen keuze.

Nu zelf zou ik nooit iets draaien zonder ssl certificaat, maar voor hier thuis intern of op mijn eigen bak ? Waarom zou ik al die "moeite" moeten doen. Het draait hier wel uiteraard, om goed te kunnen testen. Van alle ex collega programmeurs zie ik geen 5 a 10% ssl werkende krijgen lokaal met nginx. En op Windows zou ik begot niet weten hoe ik er moet aan beginnen, IIS en daar ergens certificaat toevoegen ofzo.

Uiteraard kan je zeggen, ja maar download dan een docker ofzo, zelfde probleem voor een hele hoop mensen, die hebben daar geen flauw benul van, en dan is het ... ja maar al die rommel moet ik niet hebben

Afschaffen is geen optie
Voor lokaal intern gebruik kan http nog altijd nuttig zijn, ook om iets te testen.
Non-internet IP-adressen zijn uitgezonderd van HTTPS only in Firefox. Dit is een non-issue.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 12:55]

Begin wel.overtuigs te rakam dat het interne netwerk eigenlijk zo goed beveiligd moet zijn als je externe.

Heb vriendje gehad met versleutelde nas. Je hoeft maar 1 apparaat te hebben, verbonden met internet (of niet, denk aan chinese troep), en je kan de sjaak zijn. (Sorry, sjaak)
Ja maar op je eigen pc om iets te testen ? Sorry maar dat is er los over. Enja om het correct te doen moet het over https, wat bij mij ook het geval is.

Ik zou wel eens willen zien hoeveel tweakers er niet in slagen ssl werkend te krijgen op hun eigen pc voor iets dat lokaal op die pc draait. En dan op hun eigen netwerk alles over ssl, nee het merendeel zal er echt niet in slagen hoor

Enja een letsencrypt certificaat is "gemakkelijk" om het aan te maken, alvast een pak beter dan zelf via openssl cmdline eentje aanmaken. Maar dan, dat moet regelmatig geupdate worden (om de 3 maanden), en pfff moeten we dat nu weer doen, dat gaan we dus niet meer doen etc. Henk zal hier zeker niet in slagen, maar Henk wil wel zijn foto's op zijn NAS zetten, want hij heeft gehoord dat dit veilig is.

Je zou bijna elke producent van netwerk appliances moeten verplichten dan om alleen over ssl beschikbaar te zijn. Anders zal het niet gebeuren
Ik vind voor dat soort verplichtingen echt veel te zeggen.

Ik denk ook dat de industrie veel harder geduwd zou moeten worden op zaken als netwerksegmentatie, routers, ed. (Of standaarden die dat soort dingen veiliger en gebruiksvriendelijker maken)

Er zijn ook allerlei voorschriften over aansluiten electra en de cv ketel. Dit gebied loopt een beetje achter.
Ik hou er gewoon niet van om technische details te verbergen.

Als het bijvoorbeeld QUIC wordt, wil ik dat ook weten. Al gebruikt dat volgens mij helaas dezelfde prefix.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 12:55]

Ik neem aan dat je in de auto ook niet altijd zicht hebt op de bandenspanning? Dat is immers wat dit ook is.
Klopt maar dat zou ik ook graag willen :) Control freak enzo. Overigens heb ik al jaren geen auto meer :P

Vind ik ook een van de fijne dingen aan vliegtuigen dat je wel overal zicht op hebt. Kleine dingen kunnen grote gevolgen hebben. Bijvoorbeeld een oliedrukmeter en olietemperatuurmeter zit tegenwoordig niet meer in een auto, maar als het mis gaat heb je echt veel schade. En zoiets kan je aan zien komen als je bijvoorbeeld merkt dat je olie veel sneller op temperatuur is dan vroeger.

Tegenwoordig in de "Apple tijd" is het een beetje mode om technische details te verbergen. Of dat goed is, is een tweede wat mij betreft. Voor sommige mensen wellicht wel, voor mij zeker niet.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 12:55]

Ik neem aan dat je in de auto ook niet altijd zicht hebt op de bandenspanning?
Nou...
Sowieso moet dat wel ergens te vinden zijn, want de auto zelf heeft dat…
Meeste moderne auto's wel, maar niet allemaal. ;)
De meesten hebben toch alleen maar een soort delta mechanisme? Daarom dacht ik altijd dat je hem moest resetten na het opblazen.
Je kan toch gewoon met je ogen kijken of je banden zacht zijn?
Als het bijvoorbeeld QUIC wordt, wil ik dat ook weten. Al gebruikt dat volgens mij helaas dezelfde prefix.
Klopt. En alstu. :)
Oh bedankt! Helaas heb ik nu al erg veel addons, ik denk dat ik het even laat voorlopig. Ik heb dan liever 1 addon die heel veel info laat zien.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 12:55]

Het zal voor de leek nog handiger zijn als als die de keuze kan maken in instellingen. De verantwoordelijkheid leg je dan weer bij de gebruiker.
Bedankt. Die kan je nu al handmatig toevoegen, zodat je straks niet voor verrassingen komt te staan.
helemaal top dankjewel
Ik blijf dit rare denkwijze vinden, mensen met weinig kennis zullen dus denken, ah het moet altijd HTTP zijn ipv HTTPS want die zie je niet meer.
Dat doet doet er niet toe, http:// invoeren indien het https:// moet zijn, wordt vanzelf omgezet, dus dat gaat vanzelf goed. Probeer het maar, http://tweakers.net

Juist daarom is dit een uitstekend plan. Gebruikers die weten wat er gebeurt, zien nu direct dat ze op hun tellen moeten letten.

[Reactie gewijzigd door ABD op 23 juli 2024 12:55]

Dat wordt niet vanzelf omgezet.
Dat is omdat iemand het configureert heeft op de server, of geprogrammeerd heeft in de website dat dit een gewenst effect is.

Dit is dus niet iets wat zomaar altijd werkt en kan soms zelfs tegengehouden worden.
Voor zover ik weet zijn zowel Firefox als Chrome bezig met HTTPS de norm te maken. Dikke kans dat je nu al HTTPS-only mode aan hebt staan in bepaalde gevallen (privétabs bijvoorbeeld). Ik verwacht in de toekomst dat die toggle gewoon wordt omgezet en de boel inderdaad automatisch wordt omgezet.

Ik heb het zelf al aan staan en ik merk er eigenlijk nooit iets van. De enige uitzondering is de Fokke & Sukke website, die doet geen HTTPS om de een of andere reden.
Nee, door Tweakers (niet door Mozilla)... Er zouden ook twee verschillende sites kunnen bestaan :
http://tweakers.net
https://tweakers.net
Leuke discussie, maar jullie hebben allebei gelijk.

Browsers cachen dit, en servers redirecten.
Cachen is dus wat de server aangegeven heeft, en dus geen instelling van de browser.
En hoe stelt mozilla dit dan in op mijn server of mijn website?
Website bouwer hier:

Nee zo werkt het niet. Het redirecten wordt over t algemeen niet gedaan door de browser zelf. Er zijn hedendaags wel een paar nuances op die stelling, dus ik zal dr een paar samenvatten:
  • In beginsel is het wel/niet doorverwijzen server configuratie. In jouw voorbeeld heeft dus Tweakers zelf de redirect ingesteld. Dit is tegenwoordig eigenlijk standaard config, het kost amper moeite en is goed voor je SEO waarde, dus praktisch iedereen doet t. Zeker met LetsEncrypt kan alles zeer simpel en goedkoop.
    • Indien een browser de redirect krijgt van de server, gaat ie door naar de opgegeven url
    • Als de server een HSTS header mee stuurd vertel je de browser "kijk nooit meer naar http, altijd met de S.
    • De server is de baas. Die kan je dus ook zo configureren dat alles redirect naar non-secure, je browser zal volgen.
  • Je hebt plugins waarmee je idd automatisch altijd redirect naar Secure. Dit werkt door te kijken of het httpS equivalent bestaat van de url die je bezoek, if so redirect de plugin je.
In praktijk, omdat httpS eigenlijk de default is geworden (de vraag is niet meer "waarom zou ik t doen", maar "waarom zou je t niet doen?"), de meeste programma's stat nu standaard op https. Vroeger werd bijv. eerst gekeken of de non-secure versie bestaat, ja ->goto, nee -> check secure. Dat is nu omgedraaid omdat https meer voorkomt.

Dus ik kan me voorstellen dat je de conclusie trekt dat Mozilla dat voor je doet, maar dat is dus een beetje te kort door de bocht :) Je hebt soortvan gelijk, maar niet om de reden dat je denkt :)

[Reactie gewijzigd door Martijn.C.V op 23 juli 2024 12:55]

Dit wordt bijna altijd op het proxy niveau van een website ingesteld, daar heeft je browser helemaal niks mee te maken.
Dat doet doet er niet toe, http:// invoeren indien het https:// moet zijn, wordt vanzelf omgezet, dus dat gaat vanzelf goed. Probeer het maar, http://tweakers.net
Dat gaat niet "vanzelf", daar zijn https-redirects, hsts-preload en nog wat andere mechanismen voor (https-everywhere bijv.), maar die moeten dan wel (correct) gebruikt worden.

[Reactie gewijzigd door RobIII op 23 juli 2024 12:55]

Nee, inderdaad. Dat gaat niet vanzelf, dat is een standaard setting van firefox. Ik beloof je dat het mijn moeder niet lukt om op de http:// website te komen.

[Reactie gewijzigd door ABD op 23 juli 2024 12:55]

Bij mijn weten alleen als HTTPS-Only mode aan staat. En dat staat, by default, niet aan bij mijn weten.

Edit: Zojuist getest op een (interne) site die http én https ondersteunt in FireFox 117.0.1 en ik word niet naar de https versie doorgestuurd. En ik heb geen http(s) er voor getyped waardoor dat 'geforceerd' zou zijn ;) Gewoon "test.intern.nl" getyped. Voila, http.

[Reactie gewijzigd door RobIII op 23 juli 2024 12:55]

Je hebt gelijk, het staat op de mozilla pagina dat je https-only modus zelf in moet stellen.

Het lukt mij echter niet om op mijn nas in te loggen met http, terwijl die wel ingesteld is om via http en https te kunnen verbinden, en ik heb geen ssl certificaat aangemaakt. Ik kom standaard op de Secure Site Not Available pagina van firefox. Dit is al zo lang zo, wat op zich vreemd is, want ik moet http:// kunnen gebruiken op mijn nas. Op mijn werk gaat dit ook zo op een server zonder geldig certificaat waarop ik in moet loggen.

Ik heb dus een aanname gedaan op basis van mijn persoonlijke ervaringen.

[Reactie gewijzigd door ABD op 23 juli 2024 12:55]

Nee dat moet diegene die de website host goed regelen.

Http -> https en non-www naar www zijn redirects geregeld door de webserver.

Kan zijn dat de browser leuk dingen aanpast in de url, maar de hoster moet hier wel voor geconfigureerd zijn.

[Reactie gewijzigd door Navi op 23 juli 2024 12:55]

Dit is enkel als er er als hoster voor kiest om dit te doen.
http en https kunnen 2 totaal verschillende webites zijn!
FIrefox, en daar gaat het artikel over, converteert http:// standaard in https://
De vanilla (0 extensions, 0 non-default settings) Firefox op mijn linux doos krijgt gewoon de 302 naar HTTPS door die ik op HTTP heb ingesteld op mijn webserver. Misschien dat Firefox het standaard doet als er op HTTP niets luistert.
Maar het is in ieder geval niet zo dat Firefox zo maar standaard HTTPS pakt.
Mensen met weinig kennis maakt dat helemaal niets uit, als de website maar laad.
Wat jij al zegt, veel mensen die ik ken, en nu ik er over na denk tik ook al jaren geen http, https of www meer in, als ik naar Tweakers.net wil, dan tik ik dat alleen in en EDGE verbind me altijd goed door.
Volgens mij heb ik nooit standaard http of https getypt, dat ging al vanzelf in 1996 toen ik voor het eerst online ging... Alleen soms als een website niet goed geconfigureerd is dat ik het handmatig getypt heb, maar dat is niet iets waar een reguliere gebruiker tegen aan zal lopen.
en je gaat hetzelfde zien gebeuren als met bestandspaden
mensen weten niet meer wat het is want zien het nergens standaard meer
Dit is iets wat al jaren gebeurt:

"Ik moet toegang hebben tot de P-schijf."
- "Wat is de P-schijf?"
"Dat is de data die Jantje (die hier al 40 jaar werkt) heeft."

En dan is het aan de IT-er om uit te zoeken welke bestanden dit om gaat...

edit: -d -t blijft moeilijk

[Reactie gewijzigd door DragonSlayer666 op 23 juli 2024 12:55]

Kan ook best zijn, dat je door de webserver alsnog naar HTTPS geduwd wordt en die je een redirect naar de HTTPS-variant van de website geeft. Voor de (sub)domeinen die ik zelf vanuit huis host, doe ik dat namelijk ook. ;)
Ja uiteraard laden moet het altijd maar let maar op.. als je ze vraagt om een url in te voeren zullen ze nu allemaal voor HTTP kiezen ipv HTTPS want ze weten niet meer wat dit inhoudt.
Elke website zou standaard gewoon HTTPS moeten draaien en HTTP urls daarnaartoe redirecten, dus ik zie het probleem niet zo.

In de meeste gevallen moet je dat eigenlijk ook met WWW willen, alles wat niet WWW is redirecten naar WWW, er zijn namelijk wat technische limitaties als je geen WWW gebruikt, zoals CDN's of Cloud diensten die WWW moeten hebben voor bepaalde functionaliteiten: https://devcenter.heroku.com/articles/apex-domains
vanuit een milieuvriendelijkheids standpunt is dit absoluut onwaar
- niet alleen gebruik je meer rekenkracht en stroom voor een https verbinding
- je verkomt dat er caching gebruikt wordt, waardoor ook de hoeveelheid netwerkverkeer flink oploopt

voor de meeste gewone sites is https ook allesbehalve noodzakelijk
Dat ben ik eens Ik zie geen nut van publieke webpagina te versleutelen voor iedereen.
Als ik in het OV een krant lees, vind ik prima als iemand ook meeleest. Het is een publieke krant, iedereen kan het wel zien.

Voor het gesloten deel, wachtwoorden, etc, dan wel. Maar voor publiek toegankelijke info? Voor iedere persoon apart encrypt, decrypt, certificate check, … Nuttelos.
Het is niet alleen dat andere mensen kunnen zien wat jij bekijkt, maar ze kunnen ook aanpassen wat je ziet. En dan wordt het al een stuk vervelender, in het minst erge geval heb je ineens extra reclame op die websites.
Lang geleden met een squid proxy op die manier advertenties gefilterd. Dat werkte best goed. Dus het is niet alleen maar slecht :)
Je browser kan nog steeds gewoon cachen. En CloudFlare cachet ook (die de meeste websites serveert)

Je gebruikt inderdaad wel meer rekenkracht ja. Er is iets besparing omdat tekst automatisch gecomprimeerd wordt, wat bij HTTP1 en 2 niet automatisch gebeurde. Maar dat weegt er niet tegenop.

Niettemin is het veel veiliger en het werkt ook tegen deep packet inspection. In Nederland verboden maar in Amerika gebruiken iSP's dat om data van hun klanten in kaart te brengen en te verkopen.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 12:55]

Niet alleen dat, gaat vooral over subdomeinen. Cookies over het hoofddomein zijn geldig over alle subdomeinen, en dat wil je eigenlijk niet. Dus je wil eigenlijk www.domein.com, sub.domein.com en webmail.domein.com, maar niet zomaar standaard op domein.com luisteren (of dat redirecten naar www).

Helaas gebruiken beginnende webdevelopers vaak gewoon het hoofddomein zonder www, mede dankzij browsers die www verbergen om alles "gebruiksvriendelijker" te maken...
De mensen met weinig kennis die ik ken hebben geen idee wat beide is, die willen gewoon naar nos.nl. Het zal ze een worst wezen hoe dat dan precies gebeurt.
De strict modus van de browser gaat meer naar de voorgrond komen, wanneer je dus een pagina via een onbeveiligde verbinding opent, zal daar altijd een melding van verschijnen.
Welnee.
Stel ze willen naar de site van ikea:
Dan gaan ze eerst naar google, dan tikken ze ikea in in de adresbalk en dan klikken ze op een gesponsorde link van google om op de site van ikea te komen.
Meeste mensen typen ook niet meer https:///www. firefox en chrome type je gewooon tweakers.net en dan kom je er.

Chrome laat uberhaupt niks zien, voor huidige pagina begint de URL voor mij met tweakers.net, geen http,geen www etc.
Meeste mensen typen ook niet meer https:///www.
Is maar goed ook, want dan komen ze nergens met die 3 slashes :+
Iemand met genoeg kennis om erop te letten, maar te weinig om te weten wat het inhoud.... Kennis gaat met gradaties.
De melding dat de pagina niet met een beveiligde verbinding wordt weergegeven is/bijft er wel. Een beetje zoals nu strict mode te activeren. Maar dan staat dat dus standaard aan en wordt dat iets anders weergegeven.
Valt wel mee denk ik. Het is voor een gebruiker gemakkelijker om aan te nemen dat een site een beveiligde verbnding heeft, tenzij anders aangegeven, anders moet een gebruiker steeds handmatig gaan controleren of er wel/geen "https://" voor staat. In jouw verkeur moet de gebruiker steeds handmatig kijken of een site een beveiligde verbnding heeft. Beter is om een beveiligde verbinding de default te laten zijn, zodat de gebruiker niet meer handmatig hoeft te kijken, en een waarschuwing in de andere gevallen. Dat is dus wat Firefox in die nieuwe versie gaat doen.

[Reactie gewijzigd door Cyb op 23 juli 2024 12:55]

mensen met weinig kennis tikken geen http of https. Ze gaan een "unsecure" label plaatsen. En dat is voor de meesten duidelijker.

[Reactie gewijzigd door bzuidgeest op 23 juli 2024 12:55]

Ach, mensen met weinig kennis checken het certificaat niet eens.

Ik vind het wel jammer want men vergeet dat er ook nog andere protocollen zijn, die ook prima werken. Het is net zoiets als de gemeente Amsterdam met GVB: 'gemeentelijk vervoersbedrijf'. Er zijn meer gemeentes in Nederland dan enkel Amsterdam! Als zoiets komt door legacy (vroeger bleef je doorgaans in je eigen dorp of stad), begrijpelijk. Maar om zelf zo'n situatie te creëren? Niet doen.
GVB was een afkorting van Gemeentevervoerbedrijf, niet Gemeentelijk Vervoersbedrijf'. Die naam wordt nu niet meer gebruikt.
Maar een gemeentevervoerbedrijf zou een bedrijf zijn wat de hele gemeente vervoert (naar een nieuwe plek). Dat zou mij daadwerkelijk storen, die naam :)
Het was een vervoerbedrijf ván de gemeente. Overigens had Groningen ook een GVB...
Een bessenplukberijf is een bedrijf dat bessen plukt.
Een gemeentevervoerbedrijf is een bedrijf dat gemeenten vervoert.

Tenminste lees ik het zo en vind de nieuwe naam dus beter :)
Mensen kijken alleen of een website laad. Sterker nog als ze via Google zoeken kijken ze ook nergens na en gaan ze er van uit dat de zoekresultaten veilig zijn. Al twee keer dit jaar gehad dat iemand een ‘virus’ had gedownload omdat ze dachten op de officiële website te zitten.

Heb zelf ook al meegemaakt dat webservers kijken of je van Google komt. Als je van Google komt krijg je ineens een advertentie pagina te zien. Kom je niet van Google af en ga je direct naar de pagina wordt je geforward naar Google.com.
Beetje hetzelfde met de File extensions in Windows. Standaard staan bekende extensions uit.

Dit is een typische en nutteloze wijziging van Mozilla.
Waarom? Wat zijn de voordelen, de 20px die je bespaart in je url balk? Minimalistisch design?

Hou beide gewoon visible, evt met optie van opt-in, ipv opt-out hoe ze het nu willen doen

[Reactie gewijzigd door iCore op 23 juli 2024 12:55]

Volgens mij gaat het om een bepaalde visie die ze hebben. Ze willen duidelijk maken dat https niet betekend dat iets veilig is. Verder ben ik ook van maximale informatie. Https en http is gewoon niet hetzelfde en ik wil weten op welke ik zit, zodat ik ook weet dat ik de andere moet hebben als er iets niet werkt.
Maar waarom zou je nog https tonen als dat nu de standaard is die vrijwel elke verbinding gebruikt? Als je https weg laat valt het extra op wanneer een site het niet gebruikt.
Wat is het voordeel om HTTP/HTTPS prefixes erin te houden, wanneer straks misschien ook QUIC als prefix gaat komen, ik noem even wat. Daarnaast is HTTP/HTTPS als indicator of iets veilig is of niet, echt niet genoeg meer anno 2023. Genoeg aanvallen die ook met een volledige veilige certificate chain gaan. Daarnaast wil je veel explicieter zien of een pagina of verbinding, via een beveiligde verbinding gaat of niet. En of dat dan HTTP/HTTPS/QUIC/WHATEVER is, moet daarbij niet uitmaken.
Volgens mij stond er op de website van oa de Rabobank ook altijd een waarschuwing dat als je ging internetbankieren dat er wel op moest letten dat er altijd https moest staan. Anders was het niet goed.
Kan het nu niet terugvinden maar als dat er niet meer staat raken mensen misschien wel in de war.
Yup: https://www.rabobank.nl/b...ne-bankieren/rabo-scanner
Veelgestelde vragen over de Rabo Scanner > Is het veilig?
Inlog- en signeerschermen
In de adresbalk van je internetbrowser controleer je of je op de inlog- en signeeromgeving van de Rabobank bent. Ga alleen verder als de adresregel begint met https://bankieren.rabobank.nl/... Vertrouw je iets niet? Neem dan contact op met jouw Rabobank.

[Reactie gewijzigd door RobbyTown op 23 juli 2024 12:55]

De vraag is eerder wat men er mee wint? Wat is er extra belastend dat https wel wordt weergegeven? Het is gewoon een extra handigheidje om te herkennen dat je op een beveiligde verbinding zit en dat is nu net waarvoor we al die jaren onze oudjes hebben proberen te leren herkennen. En laat deze groep nou juist het slachtoffer zijn van allerlei fraude.

Imo een onnodige ‘feature’.
Ik wil persoonlijk ook gewoon het hele adres zien ja. Gelukkig kan dat nog met een optie.
Als ik het maar mee krijg bij kopiëren van de URL. Doe ik tig keer per dag.
Ik vind de Chrome manier wel OK. Geen http en geen https, tenzij je twee keer in de url balk klikt om de URL aan te passen. Maar wel het slotje om aan te geven dat het HTTPS is (of niet).
Chrome is heel vervelend als het http is en je veranderd de url dan wordt je redirect naar google search. Gebeurt me zo vaak met software development. En ga niet met ssl certificaten lopen te klooien voor lokaal development.
Oh dat is raar. Nooit last van, en ik develop meerdere dagen per week Angular webapps en APIs op localhost.
Standaard https (veilig) en een dikke melding als iets niet veilig is, lijkt mij een heel goed uitgangspunt.
Ergens snap ik de logica erachter wel want je hoeft ook geeneens meer https:// in te typen en kan gewoon volstaan met www. Dat is eigenlijk al wat jaren zo en daarom dan ook ergens een beetje onlogisch dat er nog http:// of https:// wel in de adresbalk staat.
Brave app op Android gaat al een stapje verder. Die haalt https weg en www. Alleen als je op de url balk klikt zie je dat het https is met www.

Op dit item kan niet meer gereageerd worden.