Edge 92 krijgt Automatic Https-functie die versleutelde verbindingen forceert

De nieuwe versie van Edge krijgt een functie om automatisch over te schakelen van een onbeveiligde HTTP- naar een Https-verbinding. Het gaat om een test in een previewversie van de browser.

De functie heet Automatic Https en is vergelijkbaar met plug-ins zoals Https Everywhere. Microsoft zegt dat de feature in een previewversie van Edge 92 komt. Testers in het Canary- en Developer-kanaal kunnen de functie inschakelen door de flag edge://flags/#edge-automatic-https aan te zetten. De feature is dan met een toggle aan en uit te zetten.

Microsoft maakt onderscheid tussen twee typen websites. Automatic Https kan worden gebruikt bij alle http-websites, maar ook alleen bij websites die 'waarschijnlijk https ondersteunen'. Die laatste categorie is de standaard, zegt Microsoft. Het gaat om websites die weliswaar een https-verbinding aanbieden, maar verkeerd zijn geconfigureerd en die daardoor niet aanbieden. Via die categorie zegt Microsoft dat gebruikers geen verbindingsproblemen krijgen met websites die ze willen bezoeken. Het bedrijf houdt zelf een lijst bij met sites die zo verkeerd zijn geconfigureerd.

Reacties (71)

[tom.cx]

Firefox heeft ook een functie ingebouwd die hetzelfde doet. Hij maakt altijd verbinding via https. Kan dat niet dan krijg je de vraag of je de website überhaupt wilt bezoeken via http. Heb je ook geen https everywhere plugin nodig.

[Triblade_8472]

Waarom kan de browser niet gewoon goed nagaan of er https aanwezig (door een korte check) is en zo ja, dan pas overschakelen?

Google's geforceerd is niet goed.
Microsoft's eigen lijstjes bijhouden is iets beter maar ook niet goed.

[sorted.bits]

Omdat er tegenwoordig geen reden is om geen HTTPS aan te bieden als website. Ik hoop dat straks browsen naar een HTTP site direct een foutmelding geeft.

[fretnn]

Bij interne domeinnamen naar management consoles kan dit nogal een pita zijn

[Blokker_1999]

Weker omdat vele van die appliances simpelweg niet goed te configureren zijn. De afgelopen weken ook bezig geweest met het installeren van een wildcard certificaat op zoveel mogelijk van onze systemen en sommige maken het gewoon onmogelijk om een eigen, geldig certificaat toe te passen

[Dutch2007]

Gewoon zoals depl0y aangeeft een reverse proxy er voor zetten, kan heel eenvoudig middels https://nginxproxymanager.com/, VM --> docker of als je al een docker VM hebt, 1 docker container er bij.

Heeft let's encrypt intergratie (en ondersteuning voor generated certs die x-jaar/tijd geldig zijn.)

[downtime]

Wat heb je aan een reverse proxy? Aan de achterkant van dat ding is het dan nog steeds gewoon HTTP.

[fretnn]

idd !

een reverse proxy is soms de enige oplossing

[forkless]

En soms ook niet, ik heb de meeste interne sites hier via reverse proxy een SSL adres gegeven echter worden header directives soms gewoon niet geaccepteerd door de wat meer 'exotische' http listeners.

[fretnn]

ah hiermee heb ik nog geen problemen gehad.

Het probleem wat we wel hebben (slightly offtopic) is dat we via javaws niet meer aan de consoles kunnen, en die certificaten vallen niet up te graden .. IT leuke job

[sorted.bits]

Reverse proxy er voor? Dat voorkomt dat je allerlei rare configuraties door moet.

[forkless]

Jammer genoeg niet altijd.

[kimborntobewild]

Bij interne domeinnamen naar management consoles kan dit nogal een pita zijn

Wat hebben pita broodjes hier mee te maken??

[drdelta]

Pain In The Ass

[walteij]

Daar heb je toch een interne PKI voor?

[Punkbuster]

Precies, weinig mensen die dat hebben draaien.

[Dutch2007]

https://nginxproxymanager.com/ + DNS API Let's encrypt verificatie en je kan alles versleutelen, even inlezen hoe/wat en dan vrij snel klaar.

[D11]

Dan nog is het soms enorm veel werk om iedere appliance (printers, switches, scanners, accesspoints, etc) van zo'n certificaat te voorzien (en bij iedere soort appliance werkt het natuurlijk net weer iets anders).

[Dutch2007]

Dan weet je niet hoe een reverse proxy werkt, je zet het certificaat op de reverse proxy, die kan gerust gewoon HTTP (un-secure HTTP) praten met de achterliggende devices. (of HTTP als het apparaat zelf een self-signed certificaat generate/heeft).

Je maakt op 1 plek (de NGINX proxy manager), een lijst aan met devices die je op basis van hostname wilt bereiken e.g. printer01.company.domain.com, switch232.company.domain.com

Niets hoeft public routable te zijn om een certificaat te krijgen.

[Reactie gewijzigd door Dutch2007 op 23 juli 2024 06:38]

[D11]

Klink als een oplossing voor een probleem, maar niet echt security minded, aangezien niet de hele keten is beveiligd. Dan blijft er alleen nog de "noodoplossing" over om alle devices in een (of meerdere) subnet's te plaatsen (zowiezo verstandig) en alleen de proxy toegang te geven tot deze subnets.

[walteij]

Waarom zou je Letsencrypt certificaten gaan gebruiken voor internal only domeinnamen en devices?
Daar is die interne PKI juist de mooiste oplossing voor. Via group policy het Root en intermediate CA Certificaat opnemen in de Trusted Certificate Authorities store en je kunt eenvoudig alle interne websites/devices van een certificaat te voorzien.
Windows devices kun je zelfs auto-renewal voor inschakelen, voor niet-Windows devices kun je op de intermediate CA een powershell script draaien waarin je kunt zien welke certificaten binnen 30 dagen verlopen, zodat je die op tijd kunt vervangen.

[Dutch2007]

Omdat wat mij betreft, dat nog steeds meer werk is (en die CA02 / CA03, waarbij de main CA01 uit staat), nog steeds onderhoud e.d. nodig hebben, als het voor andere diensten (ook) kan gebruiken is het, het overwegen waard.

Daarnaast heb je middels een reverse-proxy, alle certificaten/koppelingen op 1 centrale plek.

Met servers/clients kan je die via een GPO mooi vervangen, maar bijv. switches/routers, die kan je hiermee ook allemaal centraal bereikbaar maken & voorzien van een automatisch vernieuwd certificaat.

[walteij]

Maar vanuit de reverse proxy naar het endpoint mis je wat security, of communiceer je alsnog via een non-trusted-self-signed certificaat.
Met een PKI heb je het beheer van alle certificaten op 1 plek, de certificaten staat op de plek waar ze horen te staan, namelijk op het device waarvoor het certificaat bedoeld is (en mogelijk een F5 die er voor staat).

Met een interne PKI heb je daarnaast het voordeel dat je zelf kunt bepalen hoe lang je certificaat geldig is/blijft.
De oplossing van de reverse proxy voor LE certificaten is leuk en werkt op zich prima, maar voor een organisatie van 1000+ medewerkers is een PKI helemaal niet zoveel extra werk.

Alle certificaten op 1 centrale plek brengt daarnaast ook de nodige risico's met zich mee, zeker als die plek ook meteen de reverse proxy is. Is die machine gecompromitteerd, is het hek van de dam.

[Dutch2007]

Voor grote organisaties is een interne PKI zeker niet veel werk. En voor veel zaken zoals een (always-on VPN), ook zeker nodig.

En van de gehele chain is er altijd wel iets dat centraal staat, de (intermediate) root authority / CA staat immers op 1 plek, als iemand daar toegang tot heeft, kan die zelf certificaten aanmaken

[walteij]

Je hebt uiteraard gelijk wat betreft iets centraals in de gehele chain. Maar met een PKI heb je niet alleen meer controle, je hebt ook een mechanisme om foutief uitgegeven certificaten centraal zelf in te trekken. namelijk de CRL van je eigen Root CA.

De Root CA zet je natuurlijk uit, zoals het hoort.
Als een van de Intermediate CA's wordt gecompromitteerd, en je komt hier achter, kun je de ICA eenvoudig ongeldig maken, door het issueing certificate vanuit de RCA te revoken. Alle certificaten die door de gecompromitteerde CA zijn uitgegeven, zijn dan in een klap ongeldig geworden, of je zorgt dat alle certificaten die door de ICA zijn uitgegeven tussen nu en het moment dat je wist dat de ICA nog veilig is worden ingetrokken.

Dankzij het overzicht van uitgegeven certificaten en wie het certificaat heeft aangevraagd (is zichtbaar in de PKI) kun je vervolgens eenvoudig terughalen welke switches/websites handmatig een nieuw certificaat moeten krijgen.

De systemen die automatisch kunnen vernieuwen/aanvragen, zullen hun certificaten gaan aanvragen bij een nieuwe en veilige ICA. Dit mechanisme mis ik bij een reverse proxy. Daar zul je dus een goede backup van de config moeten hebben, en een stukje documentatie over welke certificaten op de reverse proxy staan. Als documentatie en config met elkaar overeen komen, kun je de certificaten opnieuw aanvragen bij de externe partij.

Een PKI neerzetten is inderdaad meer beheerwerk, maar een goed neergezette PKI zorgt ook voor een snelle recovery bij een beveiligingslek dat is misbruikt.

[lenwar]

Er zijn ook weinig mensen met een hele vracht management consoles. Een iets groter bedrijf zal al snel een eiken PKI hebben om alles te regelen. Je desktops/telefoons/enz kan je middels management software van de root en intermediate certificaten voorzien. En voor de rest dus hopen dat je hardwareboeren werkbare managementsoftware meeleveren om de certificaten op afstand te beheren/

Particulieren zullen dat thuis uiteraard niet hebben, en die kunnen, als ze dat echt graag willen zelf met LetsEcnrypt aan de slag icm DNS-01-challenge.

(Anekdotisch: Zo heb ik thuis onder andere mijnprinter.mijndomein.nl een certificaat gegeven van LE met een hostname die niet op internet bekend is)

Of anders accepteren dat je steeds een 'ongeldig certificaat' melding krijgt

[fretnn]

maar soms kan je dat ongeldig certificaat niet accepteren. En dan moet je gaan switchen tussen browsers, heb er me nog niet in verdiept waarom dit precies is, maar het kan irritant zijn

[lenwar]

Oei, dan heeft je web interface wel een heel rot certificaat meegekregen van de fabrikant. Dat klinkt in elk geval als iets dat ik zsm zou proberen op te lossen, bij voorkeur met een eigen PKI en een certificaat van 5 jaar ofzo.

[Punkbuster]

Apple ondersteund geen certificaten die langer dan +- 2 jaar geldig zijn

[lenwar]

https://support.apple.com/en-us/HT211025

This change will not affect certificates issued from user-added or administrator-added Root CAs

Wel als je een eigen PKI hebt.

[Punkbuster]

iOS i.c.m. Firefox slikt dit niet hoor. Tenminste niet bij mij haha

[lenwar]

Is dit dan niet meer een Firefox ding?
https://blog.mozilla.org/...te-lifespans-to-398-days/

[Punkbuster]

Ik denk dat jij gelijk hebt haha, is dus wel een firefox dingetje.

[fretnn]

dit lost het probleem (bij ons) niet op, enkel een reverse proxy

[oktoberpaard]

De browser zou onderscheid kunnen maken tussen private en public IP-adressen en voor public IP-adressen geen HTTPS forceren. Volgens mij doet de implementatie van Firefox precies dat. Dat scheelt al een berg edge cases. Voor de overige gevallen zou je een knop moeten hebben om toch door te gaan via HTTP.

[lenwar]

Ja, dat klopt. Het is echter wel bijzonder aan te raden dit te doen. Het verschilt uiteraard heel erg aan wat voor soort apparaten je in je in netwerk hebt. ILOs (van HP servers) kan je op afstand van certificaten voorzien via management services, zakelijke printers veelal idem dito.

Maar onder aan de streep kan het een boel werk zijn.

[CAPSLOCK2000]

Bij interne domeinnamen naar management consoles kan dit nogal een pita zijn

Eerlijk gezegd heb ik daar niet heel veel sympathie voor. Dat je niet zomaar een domeinnaam moet verzinnen voor intern gebruik is nu wel lang genoeg bekend. Nu weet ik ook wel dat er nog steeds een hoop IT geleverd wordt die wel zo werkt maar dat vind ik geen excuus. Die had bij inkoop tegen gehouden moeten worden. Juist bij management consoles vind ik dat je niet mag beknippelen op elementaire veiligheid.

[SpoekGTi]

Enigszins eens maar als het gewoon een site is die redelijk static is en geen whatsoever invullenden heeft heeft https ook 0 meerwaarde

[XeroFox]

Het kost tegenwoordig geen extra moeite of geld om een site naar HTTPS om te zetten. Er is dus geen rede om het niet te doen. De rede om het wel te doen is dat HTTP sites in de Google resultaten lager gezet worden. Google gaat https-sites hoger zetten in zoekresultaten

[kimborntobewild]

Geld misschien niet; moeite wel. Want dan moet je weer googlen hoe dat moet; en het vervolgens ook uitvoeren.

[gimbal]

En volgens mij verlopen Let's Encrypt certificaten vrij snel dus dan moet je ook nog een automatische vernieuwing inregelen wil je niet gillend gek worden om het allemaal bij te houden. Het is makkelijk om het allemaal te zeggen maar onder de eindstreep als je dan 100+ certificaten op tig systemen in diverse netwerk setups moet gaan bijhouden wat in veel organisaties echt niet raar is, dan is het ineens helemaal niet meer zo eenvoudig.

[Dutch2007]

Daarom kan/moet / zou je, dat ook automatiseren, LE bied de mogelijkheid aan om emails te versturen bij niet verlengen van certificaten, als er dan iets mis gaat, weet je meteen waar je moet zijn om het te verlengen.

[1superheld]

Voor een statische site heeft het ook zeker meerwaarde

https://www.troyhunt.com/...atic-website-needs-https/

[lenwar]

https://www.troyhunt.com/...atic-website-needs-https/

Troy Hunt en ik zijn het niet met je eens. Ik ben van mening dat alle telecommunicatie versleuteld en ondertekend (als in dat je zeker weet dat je daadwerkelijk praat met de site waarmee je denkt dat je praat) moet worden. (Zo ben ik ook heel blij met versleutelde DNS (DoT, DoH, enz. enz. enz.). Het maakt mij niet uit of ik naar m'n bank ga, of naar een website over Floris en z'n cavia die Joep heet. Alles moet versleuteld en ondertekend worden.

https regelt meer dan alleen maar versleuteling tussen de internetverkenner en de webserver. Het zorgt er, versimpeld gezegd, ook voor dat de data halverwege je lijn niet aangepast kan worden, zonder dat dit gedetecteerd wordt. Jij weet dus (redelijkerwijs) zeker de inhoud die jij op je internetverkenner ziet, daadwerkelijk de inhoud is, die de webserver die jij wilde benaderen, dat verstuurd heeft.
Met http is het kinderlijk simpel voor een stukje malware op je pc, in je router of in je switch, maar ook je ISP kan bij http heel simpel aangepaste code injecteren. (In de VS injecteren sommige ISPs advertenties in je http-datastream)). (zie het filmpje bovenin m'n betoog)

Je kan dan natuurlijk denken "Ik vind het niet zo erg als iemand Floris z'n Cavia-website heeft veranderd in Chantal d'r gerbil-website", maar het feit dat het zo simpel kan is natuurlijk ronduit onwenselijk.

De meerwaarde van https is er altijd, en er is absoluut nooit een reden om geen https te gebruiken. Ook binnen je eigen netwerk, waarvan je denkt dat je het allemaal goed dicht hebt. Vrijwel iedereen (en ik denk bij tweakers.net gebruikers zelfs bovengemiddeld veel), heeft wel een één of andere apparaat in z'n netwerk die hij/zij niet zelf in beheer/controle heeft. Een slimme thermostaat/wasmachine/koelkast/afzuigkap/ventilator/huisparfumdispensor/combimagnetron. Al die apparaten zijn potentiele beveiligingsproblemen in je netwerk. Die apparaten worden vaak na een jaartje of twee (als je mazzel hebt) niet meer geüpdatet door de fabrikanten (omdat die zich focussen op het volgende model) en kunnen dan dus een springplank in je netwerk worden. Dit is op zich al een groot genoeg probleem, maar als je dan ook nog is onversleuteld verkeer in je netwerk hebt, maakt het dit voor de hacker in kwestie nog makkelijker.

Ik roep dan ook altijd op om ook in je eigen netwerk te proberen om een DoH/DoT service op te richten (via AdGuard Home is het bijvoorbeeld kinderlijk simpel om dat te doen 'aanzetten en klaar') en zo veel mogelijk services ermee te laten praten.

[walteij]

Dan kies je voor een webhoster die dat gratis voor je regelt.
Ik heb wat websites draaien voor mezelf en wat vrienden, heb gewoon een Linux bak met ISPConfig er op, daarmee kun je met 1 vinkje een Letsencrypt certificaat aanvragen.

[GeroldM]

Een HTTPS verbinding naar een onbetrouwbare website, is nog steeds een verbinding naar een onbetrouwbare website.

Dat het nodig is ontken ik niet. Maar ik stel wel dat men heel veel vertrouwen stelt in de uitgevers van certificaten, waarbij er meer dan genoeg zijn die het helemaal niet zo nouw nemen met de beloofde eisen voor uitgifte van certificaten. Minder dan de teksten op hun websites beloven.

Helaas is het ook zo dat de markt van certificaat uitgevers heemaal niet zo uitgebreid is als men je wil laten geloven. Er zijn onderzoeken gedaan en het blijkt dat er maar een 15 tot 20 certificaat-uitgevers zijn. Alle andere tokos zijn dochter ondernemingen en sommigen zelfs dochter ondernemingen van dochter ondernemingen.

Conceptueel is HTTPS een goed iets, maar het is allemaal schots en scheef als het gaat om de praktische uitvoering.

HTTPS geeft mij bij lange na niet gevoel dat ik veiliger aan het internetten ben dan met HTTP alleen. Man-in-the-middle aanvallen hoef je niet zoveel meer te vrezen, dat is waar. Maar uiteindelijk is HTTPS niet meer dan een pleister en deze is niet of niet correct op de (schaaf) wond geplakt.

[rant]
Heb het al vaker in commentaar aangegeven, maar zelf zit ik in een vreemde situatie waarbij mijn ISP (in Paraguay, waar ik woon en mijn server host) niet mee werkt met een reverse DNS probleem, is het niet eens mogelijk om zelfs Let's ENcrypt certificaten aan mijn domein te koppelen

En nee, het plaatsen van een specifiek record op de server zorgt er alleen voor de Let's Encrypt validatie procedure later vastloopt, in plaats van meteen, vanwege een mismatched reverse DNS die mijn ISP niet aan wil passen. Helaas is dit de enige ISP die internet wil leveren op mijn locatie. Tussen wal en schip dus. En na contact te hebben opgenomen met LACNIC is het eigenlijk tussen wal, band en schip...dat hielp ook niet.

Ben dus bijna verplicht om maar ergens een VPS te huren en daar alles maar te parkeren. Doe al jaren zelf mijn eigen website beheer, DNS server beheer, mail server beheer, cloud server beheer etc. op eigen locatie. Maar door dit kinderachtige gedoe met de ISP begin ik dat wel een beetje beu te geraken. Wel een beetje een zwaktebod voor iets wat je volledig in eigen beheer kan houden, maar goed.
[/rant]

[Reactie gewijzigd door GeroldM op 23 juli 2024 06:38]

[mcmnio]

Kan je de Let's Encrypt/ACME challenges die via DNS werken niet gebruiken in dat geval?

[lenwar]

Een HTTPS verbinding naar een onbetrouwbare website, is nog steeds een verbinding naar een onbetrouwbare website.

Uiteraard. https zorgt er alleen voor dat de data van die onbetrouwbare website authentiek is, en versleuteld is. Het heeft geen mening over de inhoud van een data.

Er zijn onderzoeken gedaan en het blijkt dat er maar een 15 tot 20 certificaat-uitgevers zijn.

Dit is wat mij betreft niet zo'n probleem toch? De netto-kosten van certificaten zijn vrij laag. Ook de EV-certificaten zijn voor het beoogde doel goed te betalen voor de bedrijven die het nodig achten. Voor kleine bedrijven en particulieren zijn er ook gratis ondertekende certificaten.

Maar uiteindelijk is HTTPS niet meer dan een pleister en deze is niet of niet correct op de (schaaf) wond geplakt.

https is een methode om ervoor te zorgen dat de telecommunicatie tussen software, bijvoorbeeld een internetverkenner en een webserver, versleuteld en ondertekend is. Niks meer of minder dan dat. Je weet nog steeds niet met 'wie' je praat. Alleen dat je met één specifieke webserver praat. Met de EV-certificaten zou er een extra controle moeten zijn dat de certificaateigenaar is gecontroleerd door de certificaatuitgever. Hoe betrouwbaar dat is, is uiteraard te bediscussiëren.


In jouw geval met je DNS-probleem icm Lets Encrypt, zou ik is kijken naar een DNS-01-challenge. Ik gebruik dit zelf voor hostnames op mijn domeinnaam die niet op internet bekend zijn.

Ik heb www.domeinnaam.nl publiek en bijvoorbeeld "mijnprinter.domeinnaam.nl of mijnhomeassistant.domeinnaam.nl" in m'n eigen netwerk zitten. Echter zijn die hostnames niet bekend op internet, maar wel op m'n eigen lokale DNS-server. De DNS-01-Challenge van Letsencrypt doet alleen een controle of jij controle hebt over domeinnaam.nl. Daarna kan je ieder certificaat aanvragen die je wilt voor je domeinnaam.

[HunterPro]

web-protocollen worden door meer dingen gebruikt dan 'sites'. Veel microcontrollers en IoT devices gebruiken (zeker voor development) non-TLS encrypted verbindingen omdat je dan gewoon simpel, lichtgewicht tekst naar de netwerkinterface kan brullen. Dus roepen 'alles moet gewoon https en de rest moet erroren' is echt te kort door de bocht.
Ook is TLS een 'non functional' in de applicatieve stack, die ik graag wil kunnen uitschakelen in een devomgeving om de werking te checken (en te kijken of het niet TLS is die roet in 't eten gooit).
Er is een reden dat auto's nog steeds willen starten en rijden zonder gordel, ondanks dat ze verdraaid goed weten met alle sensoren dat de stoel bezeten is en de gordel niet gesloten is.

[Verwijderd]

Mooi op kleine devices. Die doen geen https en al zeker niet met een geldig certificaat

[cricque]

Geen reden ... Kijk jan modal om de hoek kan het geen barst schelen als zijn website http of https is. Dit is dikwijls iets jaren geleden in elkaar gestoken en dat is alleen omdat het "moest" en meestal gedaan door een kennis of familielid. Zelfs zie ik nog website "ontwikkelaars" die nog altijd niet weten wat https is blijkbaar. Het zou niet mogen, maar er is de ideale wereld en er is de realiteit. Ik zie nog altijd klanten van mijn saas applicatie die een website hebben op http ... dan zeg je dat en leg je uit dat dit ook handig is om beter gevonden te worden door Google, toch het verkoopsargument ... Ja we zullen dat wel doen, en 6 maanden later is dat nog altijd niet het geval. Tsja, voor velen heeft zoiets absoluut geen prioriteit. De enige manier zou zijn, gewoon http blokkeren. Dan zullen ze wel moeten, maar dan zou elke browser dat moeten doen.

De meeste mensen weten ook niet wat https is, simpel. DIt gaat dan meestal over de kleinere (familie) bedrijven. Natuurlijk is dat niet overal zo, maar je ziet veel zaken die al lang bestaan (meestal goederen en diensten), denk aan bakkers/kappers/electriciens/loodgieters ... Dit zal niet snel veranderen. Dikwijls is het ... ik heb nu al werk te veel, maar dit is alleen omdat het "moet". En als je goed bent, dan heb je dat eigenlijk niet nodig, mond of mond reclame is nog altijd het beste. Want ik heb gehoord van een goeie vriend ...

Als het aan mij ligt zou alles https zijn, maar spijtig genoeg is dit niet realiteit, en dat zal nog niet zo snel wijzigen

[Triblade_8472]

Je dwingt feitelijk het hele internet services af te nemen van derden.
Dáár ben ik op tegen!

[Triblade_8472]

Jawel.
Http heb je geen 3e partij nodig voor het maken van 'geldige' certificaten.

Sites zonder inlog kunnen prima zonder https als dat niet nodig is.

[obimk1]

Volgens mij heeft Firefox al jaren een plugin die https verkeer afdwingt

[drdelta]

Jep, die wordt ook genoemd in het artikel (oa.) HTTPS Everywhere.

[CAPSLOCK2000]

Waarom kan de browser niet gewoon goed nagaan of er https aanwezig (door een korte check) is en zo ja, dan pas overschakelen?

Omdat het heel moeilijk is om vast te stellen of de http en https versies van zo'n pagina hetzelfde zijn. Je zal beide pagina's helemaal moeten opvragen en byte voor byte vergelijken en dan hopen dat er geen dynamische elementen (zoals een klok) in zitten waardoor je nooit twee keer exact dezelfde pagina krijgt.
De hoeveelheid javascript en externe verwijzingen maakt het nog lastiger om het echt goed te doen.

[gimbal]

Daarom zou ik dat ook niet nagaan maar gewoon een botte aanname doen. Als de HTTPS variant antwoord geeft dan is het HTTPS ja. Een site die andere content op gaat leveren afhankelijk van het protocol zou toch echt de uitzondering op de regel moeten zijn en naar mijn idee kun je nog steeds naar de http versie navigeren door voor die specifieke site een uitzondering te configureren. Als de browser die optie niet biedt dan bestempel ik dat als een bug.

[CAPSLOCK2000]

Daarom zou ik dat ook niet nagaan maar gewoon een botte aanname doen. Als de HTTPS variant antwoord geeft dan is het HTTPS ja. Een site die andere content op gaat leveren afhankelijk van het protocol zou toch echt de uitzondering op de regel moeten zijn en naar mijn idee kun je nog steeds naar de http versie navigeren door voor die specifieke site een uitzondering te configureren. Als de browser die optie niet biedt dan bestempel ik dat als een bug.

Ik ben het daar op zich wel mee eens maar weet niet of de wereld er al klaar voor is.
De eerste browser die dat doet zal gebruikers verliezen omdat ze merken dat ze niet de site krijgen die ze willen terwijl het met andere browsers wel werkt. Dat is wel vaker het probleem met beveiliging, gebruikers ervaren het altijd als dat iets niet werkt.

Deze stap van Microsoft gaat wel de goede kant op. Het lijkt veel op dat de HTTPS Anywhere plugin deed. Het zou mooi zijn als Microsoft het lijstje met sites die niet compatible zijn deelt met de wereld zodat andere browsers er gebruik van kunnen maken en wij druk kunnen uitoefenen op de sites die nog niet goed zijn.

Ik hoop wel dat we na een tijdje het lijstje sluiten en vastleggen als "geschiedenis" en bij nieuwe sites gewoon aannemen dat het HTTPS doet.

[batjes]

Wat ik tevens niet begrijp is dat de browsers voor intranet websites geen uitzondering hebben. Interne webpagina's hebben geen https nodig en het is nergens voor nodig om gebruikers angstig te maken voor https-loze websites, als mensen de hele godsganse dag werken op https-loze websites.

[Triblade_8472]

Ik zie het simpel.

Login form? Https aan.
Geen login form? Http kan prima.

[CAPSLOCK2000]

Interne webpagina's hebben geen https nodig

Het hele idee van een 'intern netwerk' is aan het verdwijnen. In de tijd van 'cloud', 'bring your own device' en 'thuiswerken' is het niet meer houdbaar om een strak onderscheid te maken tussen intern en extern.

Daarbij dwing ik liever overal dezelfde regels af zodat mijn gebruikers en beheerders niet zelf hoeven te beslissen of ze in dit geval wel of geen https nodig hebben. Want mensen maken nu eenmaal fouten en de functie van systemen verandert nog wel eens. Daarom kies ik er voor om overal https toe te passen.

[Verwijderd]

Zijn er sites die https gebruiken en hun http er niet heen redirecten? 🤷🏻‍♂️ En https de standaard, lachen als sites geen https hebben 🙄 (en helaas zijn die er nog genoeg!)

[P1nGu1n]

Zijn er sites die https gebruiken en hun http er niet heen redirecten?

Naast dat die websites inderdaad bestaan, is het probleem dat er dan nog steeds een onbeveiligd request heeft plaatsgevonden voor de redirect, met alle risico's van dien (privacy, MITM aanval, etc).

[Reactie gewijzigd door P1nGu1n op 23 juli 2024 06:38]

[beerse]

Het mooiste zijn de sites die op http en https echt verschillend zijn.

Mijn idee:
- als ik http of https opgeef, dan dat gebruiken. Is het er niet, dan waarschuwen.
- als ik geen http of https specificeer, dan default https.
- als https een error opgeeft, dan mij vragen wat te doen: doorgaan, omschakelen naar http of stoppen.
- als http er niet is, automatisch omschakelen naar https
- als https er niet is, automatisch omschakelen naar http

[Reactie gewijzigd door beerse op 23 juli 2024 06:38]

[lenwar]

- als https een error opgeeft, dan mij vragen wat te doen: doorgaan, omschakelen naar http of stoppen.

Die is gevaarlijk natuurlijk. Dan dresseren we mensen weer om fouten maar te accepteren en door te gaan met alle gevolgen van dien.

- als http er niet is, automatisch omschakelen naar https
- als https er niet is, automatisch omschakelen naar http

Die tweede zou ik niet doen. Nooit automatisch naar een onveilig protocol gaan als je er vanuit ging dat je naar een veilig protocol bent gegaan. Ook niet met een pop-upje, want ook daarvoor geldt dat mensen dan fouten gaan wegklikken.

[kamerplant]

Is in alle moderne browsers HTTP (80) nog nodig om bereikbaar te zijn? Niemand typt een url in met protocol, proberen browsers dan überhaupt nog http://, of zou je als website beheerder poort 80 net zo goed kunnen afsluiten?

“Vroeger” kwam je binnen op http, kreeg je een redirect naar https. Beiden implementaties zijn/waren dus nodig.

[Reactie gewijzigd door kamerplant op 23 juli 2024 06:38]

[pizzafried]

helaas wel ja. Beide implementaties zijn niet per definitie nodig. Alleen als je op twkrs.net alleen op poort 80 een redirect naar https://tweakers.net draait, zal dat nodig zijn. Maar dat is puur de server implementatie. Als alle browsers eerst https proberen kunnen servers de http en http=>https uitfaseren en dan is die serverside redirect implementatie niet meer nodig.

[davekok]

Volgende stap is http deprecaten en daarna uitfaseren. Daarna zal de push komen om http 1.0/1.1/2.0 langzaam uit te faseren. En dan worden de tech bedrijven langzaam aan de nieuwe telecom bedrijven. Gezien de kosten om zelf even http 3 te implementeren te hoog is. Vaarwel open web.

[janpiet]

Prachtige nieuwe geforceerde functies allemaal: edge forceerde bij de laatste update het voor de zoveelste keer wegvallen van startpagina's. en negeert deze nu volledig.

[xFeverr]

Hoe durven ze het internet voor alle Windows gebruikers veiliger proberen te maken! De schoften!

Van alle dingen waarover je kan klagen in Windows, en dat kunnen er best een aantal zijn, is dit er toch geen?