Nee, de beheerder van de website is hiervoor aansprakelijk. Die beheerder kun je sowieso vinden via de registratie (zoek op: DOMAIN INFORMATION), welke terug te vinden is op talloze websites, waaronder http://www.tcpiputils.com

Let wel even op dat je geen spam-abuse mail-adres gebruikt om de beheerder te bereiken, deze is hier namelijk niet voor bedoeld en kan (door automatisering) er zomaar voor zorgen dat je mail niet op de juiste plek terecht komt.

Puur uit interesse, om welke site gaat het precies?

Het contact adres van de pagina? Altijd eerst bij de instantie zelf he?

En anders: http://www.rijksoverheid.nl/contact

Melden bij info@ncsc.nl is ook een goede optie.

"Ik ben een onbeveiligde webpagina (http:// ipv https://) van de overheid (niet overheid.nl) tegengekomen waar een form vraagt om mijn naam, adres, email én BSN nummer."

Een zinnig antwoord is moeilijk te geven wanneer je geen verdere informatie verstrekt. Overigens hoeft niet de hele website https te zijn, zolang de gegevens die je invult maar via https verstuurd worden. Weet je zeker dat er daadwerkelijk sprake is van een probleem, en dat je geen voorbarige conclusies trekt ?

"Is er een centraal punt waar ik dergelijke problemen kan aankaarten?"

Waarom bij een centraal punt, en waarom niet bij de organisatie welke hoort bij die website ? Dat lijkt mij de eerste optie. Daarna NCSC.

Dit is een wijdverbreid misverstand. Je hebt als gebruiker namelijk geen idee of de door jou ingevulde gegevens via https zullen worden verzonden op het moment dat je op de "submit" knop drukt.

Sterker, je hoeft tegenwoordig helemaal niet meer op knoppen te drukken voordat er informatie wordt verzonden (zie bijv. http://www.bing.com/ en begin maar met een willekeurige zoekstring te typen, het getoonde komt echt niet uit jouw browser).

Een zeer belangrijk aspect van https is dat je als gebruiker weet met welke site je communiceert (dat implementaties nog brak zijn is een ander verhaal, zie https://www.security.nl/posting/367370/Criminelen+stelen+creditcarddata+via+Google+Analytics en mijn reactie daaronder). Als je niet weet met wie je communiceert (de bedoelde site of een MITM aanvaller) is versleutelen zinloos.

Als delen van de webpagina wel en andere delen niet in https worden aangeboden, krijgt de gebruiker een -terechte- waarschuwing te zien. Als de hoofdpagina in http wordt aangeboden, heb je als gebruiker veel minder zekerheid over de site waar je mee communiceert dan in het geval van https (zie bijv. https://www.security.nl/posting/366518/DNS+anti-virusbedrijven+ESET+en+Bitdefender+gekaapt).

Kortom, gebruikers hebben de meeste zekerheid als zij zelf de URL vanuit een bookmark oproepen en vervolgens de gehele sessie, zonder redirects, middels SSL is versleuteld nadat de remote server is geauthenticeerd, het dus duidelijk kan zijn voor de gebruiker met welke (hoofd-) site zij communiceert en de gebruiker zelf kan bepalen hoeveel vertrouwen zij in die site schenkt.

Melding van maken bij het Collega Bescherming Persoonsgegevens, zij zijn namelijk de toezichthoudende partij (Volgende de Wet Bescherming Persoonsgegeven)

Over het algemeen heeft ieder officieel domain een e-mail adres wat begint met 'abuse@' en daar zou je de gevonden webite kunen rapporteren als mogelijke Phishing site!

"Dit is een wijdverbreid misverstand. Je hebt als gebruiker namelijk geen idee of de door jou ingevulde gegevens via https zullen worden verzonden op het moment dat je op de "submit" knop drukt."

Dat jij iets niet weet maakt een website niet onveilig.

"Sterker, je hoeft tegenwoordig helemaal niet meer op knoppen te drukken voordat er informatie wordt verzonden (zie bijv. http://www.bing.com/ en begin maar met een willekeurige zoekstring te typen, het getoonde komt echt niet uit jouw browser)."

En iedere website werkt net zoals Bing ?

"Kortom, gebruikers hebben de meeste zekerheid als zij zelf de URL vanuit een bookmark oproepen en vervolgens de gehele sessie, zonder redirects, middels SSL is versleuteld nadat de remote server is geauthenticeerd"

Klopt geheel. Maar ook zonder die zekerheid kan er sprake zijn van een veilige verbinding. Wil je bij een meldpunt gaan melden dat jouw gevoel van veiligheid niet goed genoeg is of dat de verbinding op zich niet veilig is ?

"Kortom, gebruikers hebben de meeste zekerheid als zij zelf de URL vanuit een bookmark oproepen en vervolgens de gehele sessie, zonder redirects, middels SSL is versleuteld nadat de remote server is geauthenticeerd."

Klopt, echter zorgt encryptie van de gehele sessie voor veel meer load op de webserver, zeker bij drukke websites. Verder is encryptie van de gehele sessie zelden nodig.

"Ik ben een onbeveiligde webpagina (http:// ipv https://) van de overheid (niet overheid.nl) tegengekomen waar een form vraagt om mijn naam, adres, email én BSN nummer."

Indien je nou gewoon even meldt om welke website het gaat, dan wordt de discussie een stuk inhoudelijker. Indien je bang bent dat iemand met de ''eer'' gaat strijken, het vaststellen of een website http of https gebruikt is nou niet echt bijzonder interessant.

Dat het formulier zelf niet via https wordt opgevraagd wil niet zeggen dat de post action niet via https verloopt.
Een blik in de broncode zal moeten leren of de <form action> property met http of https is gevuld.

En dat doe jij, elke keer als je zo'n site bezoekt net voordat je op de "submit" knop drukt? En begrijp je dan ook precies wat er gebeurt, rekening houdend met alle mogelijke javascript includes en iframes e.d. die je ziet? En hoe denk je dat een leek dat zou moeten kunnen?

Waarom denk je dat (eindelijk) steeds meer sitebeheerders zich van de risico's bewust worden en de gehele sessie, zonder uitzonderingen, via SSL laten plaatsvinden? Zoals ik al schreef, vaak ben je er dan nog niet, maar het is wel een eerste begin om de meest voor de hand liggende risico's uit te sluiten.

Wat je als gebruiker wilt is (A) kunnen vaststellen dat dat de eigenaar en beheerders van een website jou niet belazeren - maar daar ken ik, helaas, geen technische oplossingen voor. Wat je als gebruiker ook wilt is (B): als je besluit de eigenaar en beheerders van een website te vertrouwen, je behoorlijke zekerheid hebt dat de website daarwerkelijk van de bedoelde eigenaar is en de broncode in jouw webbrowser daadwerkelijk afkomstig is van die website. En daar was nou net SSL voor uitgevonden! Waarom gebruik je het dan niet voor de hele sessie?

Je bedoelt dat je, in tegenstelling tot waarschijnlijk veel drukker bezochte websites als https://www.google.com/, geen geld overhebt voor apparatuur die dit probleem voor je oplost. DIt natuurlijk ten koste van de beveiliging van jouw bezoekers.Oneens om eerdergenoemde redenen.

Helaas is het zo dat veel websites, ook die met SSL verbindingen, vaak slecht met allerlei non-standard webbrowser instellingen en plugins/addons kunnen omgaan. Testers controleren vaak de "vanilla" uitvoeringen (dus met standaard instellingen en gangbare plugins/add-ons) van meerdere webbrowsers en gaan dus niet zover dat ze alle denkbare varianten van plugins en (beveiligings-) instellingen testen.

Redirects hebben een risico maar soms moet je ze toestaan om te kijken waar je naartoe gestuurd wordt. Beoordeel dan zorgvuldig of je nog steeds met de bedoelde site(s) communiceert. Als dat het geval is kun je de nieuwe URL bookmarken en die voortaan direct gebruiken (meestal zonder dat je dan weer redirects krijgt).

Als je bijv. bij ING zit en wilt internetbankieren, kun je natuurlijk een Google pagina openen, zoeken naar ING internetbankieren en op 1 van de getoonde links klikken, zoals op http://www.ing.nl/particulier/internetbankieren/. Ik raad dat af; op dit moment brengt https://mijn.ing.nl/internetbankieren/SesamLoginServlet je meteen naar de gewenste pagina. Maak daar dus een bookmark/favoriet/internetsnelkoppeling van en wees extra alert als die plotseling niet meer werkt. Overtuig je er in dat geval van dat de URL daadwerkelijk gewijzigd is en de hostname daarin klopt voordat je wijzigingen opslaat in een updated bookmark/favoriet/internetsnelkoppeling.

Zonder die zekerheid kan er dus net zo goed sprake zijn van een onveilige verbinding. Wat heb je daar dan aan?

"Zonder die zekerheid kan er dus net zo goed sprake zijn van een onveilige verbinding. Wat heb je daar dan aan?"

Niets, maar het is dan nog steeds geen onveilige verbinding. Ik zou niet alles gaan encrypten op mijn website en daarmee de load onnodig verhogen, enkel omdat anders niet iedere gebruiker in staat is uit te vogelen hoe veilig de verbinding is. Lukt dat je niet, zorg dan dat je genoeg kennis op doet om dat wel uit te zoeken. En anders vertrouw je er maar op. Veel gebruikers weten niet eens wat HTTPS is.

Sorry maar anno 2013 en load en HTTPS met elkaar in verband brengen is echt een no go.
Dat was 10 jaar of 20 jaar geleden nog misschien een kwestie maar een beetje fatsoenlijke load balancer heeft SSL offloading en daarnaast kan je prima schalen met VM's en zullen hedendaagse cpu's en software eenvoudig een 10-voud van de load van 1996 aankunnen.

Laat je statische content lekker over HTTP en Varnish gaan en je aparte login procedure over HTTPS zodat je niet alles over HTTPS hoeft te serveren.

als je een fout op oa websites van de rijksoverheid krijgt kun je dit melden op

http://www.rijksoverheid.nl/documenten-en-publicaties/vragen-en-antwoorden/responsible-disclosure.html