Bedankt Erik van Straten voor het aankaarten van dit initiële http://verbindingsprobleem.

Het probleem kan o.a. optreden bij bepaalde browsers.
Ik ben het ook tegengekomen bij het gebruikmaken van de Mullvad Browser.

Maar de http-tracker extensie slaat geen alarm.

Firefox probeert dat inderdaad:
https://support.mozilla.org/nl/kb/https-upgrades
En als je "https-only" instelt dan krijg je een waarschuwing als dat niet kan, met een mogelijkheid om toch http te gebruiken (dus https-only is niet echt https-only maar http-alleen-met-extra-interactie):
https://support.mozilla.org/nl/kb/alleen-https-modus-firefox

Als ik me goed herinner is de reden dat dit is ingevoerd dat, in de tijd dat men hiertoe besloot, veel websites bezig waren van http naar https over te stappen, maar daarbij vaak geen automatische redirect van http naar https regelden op de server. Veel hyperlinks op het web verwezen (nog) naar de http-versie van pagina's waar inmiddels een https-versie van was. In combinatie resulteerde dat erin dat veel bezoekers op de http-versie van een website belandden terwijl https beschikbaar was, en velen merkten dat natuurlijk niet op. Men heeft dit een duw richting https willen geven door de browser dan maar even te laten kijken of https beschikbaar is en dat dan te gebruiken. Dat is wat ik me herinner (of meen te herinneren) erover.

Een andere manier op dat te bereiken, die ik niet zelf heb bedacht maar iemand anders op deze site heb zien gebruiken, is een lege andere tag binnen de url-tag gebruiken. Als je dit intypt:

[[b][/b]url]https://www.security.nl[/url]

dan toont deze site:

[url]https://www.security.nl[/url]

en als je dat kopieert en in een reactie plakt krijg je netjes:

https://www.security.nl

Dit hangt natuurlijk af van een eigenaardigheid van hoe deze site tags nu afhandelt, maar het probleemloos kunnen kopiëren en plakken van het resultaat is niet verkeerd.

Dank voor de (eerste drie, momenteel zichtbare) reacties!

Ik zie dat ik vergeten ben on een zin af te maken, achter:
wilde ik nog schrijven: "verbinding blokkeren".

Met als consequentie (zoals Anoniem van 16:55 terecht schrijft) dat als je niet gewaarschuwd wordt voor de (potentieel zeer kortstondige, daardoor niet zichtbare) terugval naar een http-verbinding, een AitM jouw webbrowser naar elke gewenste website (ook met https-verbinding en met geldig certificaat) kan doorsturen.

Daarom is het zo ontzettend fout dat https://gemeente.amsterdam niet werkt. Dat is kip/ei: doordat browsers by default "coulant" zijn, ziet de gemeente Amsterdam geen aanleiding om die jumpsite van een certificaat te voorzien: "het werkt toch (in de meeste gevallen)"?

JA, MAAR DAT IS ONVEILIG. Want als een passieve AitM op een fout netwerk (denk vooral aan public WiFi met een Evil Twin access point) het verzoek om http://gemeente.amsterdam te openen, "voorbij" ziet komen, kan die AitM je naar een nepsite doosturen (denk aan iets als https:\\gemeente-amsterdam.nl.com, https:\\amsterdam.nl.weebly.com of iets dergelijks - met // i.p.v. \\).

Immers, https is als een tunnel met een voorspelbaar eindpunt (tenzij certificaatuitgevers certificaten aan de verkeerde partij afgeven, en rekening houdend met het feit dat een websitenaam (ook bekend als domeinnaam) potentieel niets zegt over wie de actuele huurder is van die domeinnaam.

@Anomiem 17:05: dat de forum-software, gebruikt door security.nl, van [urÍ]security.nl[/urI] de klikbare link http://security.nl maakt, is geen ramp — want de meeste reageerders op deze site weten wel dat je het beste [urÍ]https://security.nl[/urI] kunt intikken. Het is wel onnodige legacy code.

Feit blijft: op internet is veel te veel by default insecure.

Ik speel al een tijd met de volgende gedachte: het "risky" protocol, waarbij webbrowsers als volgt zouden moeten reageren:

• Bij zowel "https://sitename.tld" als bij "http://sitename.tld" (en zelfs bij "niks sitename.tld"): probeer uitsluitend https:// (verbind met TCP serverpoort 443).

• Indien er expliciet staat: "risky://sitename.tld": gebruik het oude http protocol (verbind uitsluitend met TCP serverpoort 80; de wereld is niet voor niets gestopt met telnet, authenticated ftp, POP3 en IMAP via non-TLS verbindingen).

Overwogen kan worden om tevens tunnel:// toe te staan - naast https:// (geen normaal mens weet wat de leet-speak "https" betekent, waar die afko voor staat en wat "Hyper Text Transport Protocol Secure" inhoudt).

En nu maar hopen dat al het bovenstaande voortaan "goed tussen de digitale oortjes komt te zitten".

Elke onveiligheid is er één te veel en kan leiden tot misbruik.

Een goede browser slaat dus hier alarm en geeft een reden waarom.

Wat is of zijn volgens jou goede browsers? Persoonlijk vind ik dat een lastige vraag, want elke bekende browser heeft zaken die m.i. veel beter kunnen, en van minder bekende browsers is het altijd maar afwachten of ze voldoende onderhouden worden en de ontwikkelaars zelf geen phishing-slachtoffers worden.