Ik had bij sommige sites niet eens in de gaten dat het over http ging.
Kon al weken niet inloggen en er verscheen geen error message. Zei alleen maar dat ik succesvol ingelogd was, terwilj dat niet zo was. Totdat ik dit las en er https voor zette. Toen was ik wel ingelogd en kon ik eindelijk dingen doen.

De browser moet eigenlijk automatisch naar https omschakelen als het beschikbaar is als ik een site intoets.

Dat is te merken ja, je word gek van alle popups met waarschuwing dit en waarschuwing dat...

Fout; als er een https-versie is dient er een redirect aanwezig te zijn die dit al opvangt.

add-on https everywhere installeren

Nu nog de onveilige https websites en de websites met 'gemengde content" uitfaseren. Als je eens rondgluurt in de https everywhere atlas is er ook daar dan weer genoeg onveiligheid terug te vinden. Ik vind die hele Google en EFF gelanceerde acties nogal arbitrair en stoplapperig, zeg maar cosmetisch van gehalte. Piratenpartij, luistert u hier mee???

Nergens zien we het echte vertrouwen in de Internet infrastructuur terugkeren en dat er wat wordt hersteld, laat staan teruggegeven door de grote jongens, beleven we ook niet. (Google, M$, facebook, etc. etc.)

Doe hier echt niets af aan wat Google Safebrowsing etc. en mozilla observatory trachten te doen aan deze problematiek, maar zolang er fundamenteel niks op de helling gaat bij de global governance, nu in handen van Saoedi-Arabië en de Verenigde Arabische Emiraten, blijft het aanmodderen met een grote A. Ze vinden het wel best zo. Ik persoonlijk heb ik er niet zo'n vertrouwen in. En u, gewaardeerde lezers hier op security.nl?

Dan vermoed ik nog een dubbele agenda, die erachter steekt, namelijk het uitfiltreren van de invloed van de burger websites (onafhankelijk of activistisch, vaak bestempeld als fake news of opruiend) ten behoeve van de grotere commerciële websites in het belang van de 6 overgebleven grote media wereldspelers achter alle belangrijk nieuws, dat we voorgeschoteld krijgen, en waar 'nep nieuws' en 'truespeak' steeds meer de boventoon gaan voeren tegenover onafhankelijke vrije berichtgeving. We worden bel*zerd, waar we zelf bij staan, zou de wijze "Wim Zonneberg" opmerken.

Kijk hoe onze eigen NOS in handen is van GlobalSwitch, dus zo eenzijdig gekleurd 'als de piete'. Leg je synoniemenwoordenboek maar vast klaar om aan de online filters van global surveillance te kunnen ontkomen.
Ze hebben al een tunnelvisie voor je klaar liggen.

Veel is gebaseerd op 'leugen en bedrog': je 'sluwe' meter neemt je in de maling, je ledlamp 'gloeit' niet meer, Je groene slotje in de browser url balk kun je straks ook niet meer ten volle vertrouwen. Gaan we zo nog een poosje door, misschien?

En diegene, die het allemaal niet meer interesseert en moegebeukt is door alle ontregelingsacties verzucht: "Het zal wel. Geef mijn portie maar an fikkie,. Mij maakt het al lang niet meer uit. Ze doen maar een end weg!" en dan hebben ze je precies waar ze je hebben willen.

dat ben ik niet met je eens.
onze http://extranet.bedrijf.nl en de https://exchange.bedrijf.nl zitten op hetzelfde IP (en dat zal mogelijk bij veel meer bedrijven zo zijn)
ik zie geen noodzaak om dit automatisch om te zetten.
websites moeten gewoon zelf instellen dat je een redirect krijgt vanaf http naar https

En blokkeert Chrome ook https-pagina's waarvoor ingetrokken certificaten gebruikt zijn, of pagina's onjuist gekoppeld zijn of het berucht slecht bijgewerkte Plesk?

daarom heb ik een plugin in firefox http to https zet het automatich om als het mogelijk is

Middels https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security is dit engszins geregeld.
Als je echter voor het eerst op een site komt met http zal de strict-transport-security header niet meegegeven worden (of worden genegeerd door de browser).

Dus voor die eerste keer zal er inderdaad een redirect van http naar https uit de server getoverd moeten worden (rewriterule).

Ik snap je voorbeeld met 2 sites niet helemaal. Ik stel me zo voor dat dit 2 verschillende sites/virtual-hosts zijn binnen (bv.) Apache/tomcat/.... Per site/virtual-host kun je je instellingen configureren.
Yup....dat zou wel aardig van ze zijn.

Een beetje een oudje, maar wellicht aardig om kennis van te nemen i.v.m. Certificate Revocation (CRL/OCSP): https://www.imperialviolet.org/2012/02/05/crlsets.html

geen garantie : websites moeten eerst aangemeld worden om op de redirect lijst te komen

staat de website er niet op dan doet die addon niets (bij mijn weten)

tja, dat het over banken mekkert vind ik niet gek, als ik zie wat voor een fokking tracking scripts daar mee lopen, dan schrik je.

denk dat ik hem snap,
zakelijke internetverbindingen gebruiken meerdere servers op een IP op basis van port forwarding.
port 80 gaat neer server W(eb)
port 443 gaat naar server X(change)

als de browser automatisch zou controleren of op extranet.bedrijf.nl (123.123.123.123) ook port 443 bereikbaar is en je dan door stuurt zouden bezoekers van hun extranet op hun exchange server terecht komen (zelfde IP andere port)

gewoon door de hosting providers of de webdeveloper laten inrichten dus, anders heeft zakelijk nederland (of zekelijk planeet aarde) een probleem.

Ik zit me suf te prakkizeren waarom Google Chrome en Microsoft Edge op een Windows 10 computer die net binnen
is niet meer naar google.com willen ("je verbinding is niet privé) terwijl Firefox het prima doet. Invalid certificate issuer.
Maar als je die dan opvraagt is het wel Google, niet een of andere man-in-the-middle virusscanner ofzo.
Het is een "vers" Dell systeem maar het lijkt wel of er malware op zit. Er zit echter geen gratis virusscanner op ofzo,
alleen Microsoft Defender staat aan maar uitzetten helpt ook niet.
Afijn maandag maar weer verder mee tobben... en dit soort wijzigingen maakt het ook niet makkelijker want wie
weet waar het nu aan ligt.

Blijven denken, de browser zal dat op basis van domein doen. Niet op basis van IP. Dus de oorspronkelijke poster heeft niet helemaal door wat hij zegt en dat het technisch vrij eenvoudig is.

Hmmmm ik snap wat je zegt/schrijft.

Dan van buitenaf op port P naar binnen voor service A, en op port Q voor service B.
Juiste NAT regels configureren en de clients naar de juiste poort laaten kijken

Poort 443 zou ik toch vooral voor web TLS verkeer reserveren.
(zei hij die niet teveel op heeft met eindgebruikers en vooral aan de serverkant knutselt :-))

Dank voor de verduidelijking :-)

En wat te denken van de slechts 28% veilige websites als ze gebouwd werden met gebruikmaking van PHP of een op PHP gebaseerd CMS. 1e klas leerling developers leren niet coderen met inachtneming van de vereiste veiligheidsmaatregelen en beschermen tegen script injectie en cross-script-injectie, niet weten wat je terugkrijgt na een request, bij het gebruiken van onveilige third party scripts en plug-in code.

Ga hier eens kijken en maak de overige 75 procent van deze websites ook veilig(er): http://learnwebtutorials.com/things-check-to-make-sure-php-code-is-secure

luntrus

Nog iets over PHP beveiliging. Waarom 'zuigt' PHP zo?

Veiligheid dient nooit afhankelijk te moeten zijn van een toevoelig gelukkige afloop, maar gebaseerd op zinvolle veiligheidsoverwegingen en dienovereenkomstige oplossingen.

Dit kan invloed hebben op uw gehele code basis. Het kan een bedreiging zijn voor uw bibliotheken en die aantasten. Hou het simpel anders krijgt u te maken met nog meer onveiligheid. Parsers kunnen de zaken nog ingewikkelder maken. Vooral niet meer bij te houden dubbele escapes vormen een onuitwarbare kluwen later en de site draait niet meer of niet meer naar behoren.

Uw data vormen alles waar het echt om draait.

Applicaties kunnen weer opnieuw opgebouwd worden, terwijl corrupte data het meest vernietigende kunnen betekenen wat u in uw systeem kan aanrichten. Veel coderingen zijn eenduidig. Escapes kunnen context afhankelijk zijn.

De enige juiste manier van beveiligen is input te filteren en output te escapen *. Een escape on input brengt alleen ellende.
Prepared statements maken het verschil maar niet iedereen, die dat weet. PDO altijd gebruiken samen met prepared statements. Gebruikers input filteren is een missvatting. Dat is grote flauwekul, vergeet dus het filteren en het opschonen.
* een paar hele specifieke uitzonderingen daargelaten, zoals bij onveilige UTF-8 bij voorbeeld.

Waar zit de onveiligheid?

Als we toch PHP moeten gebruiken, waarom dan niet door al je gebruikers input vanaf punt 0 niet langer te vertrouwen.
De enige juiste weg.

Info credits: Security Stack Exchange.

Mijn vraag hierbij, wanneer leert men niet eerst de juiste beveiliging toepassen voordat men met een taal aan de gang gaat?
Ik neem dat opleidingsinstituten nogal kwalijk, het draagt veel bij aan de inherente onveilige inftastructuur, die we nu ervaren. Geen luiers met spelden, maar veiligheidsspelden of strips!