Pleegt Mozilla smaad met haar anti-http-waarschuwing?

Een beheerder van de website Oil and Gas International heeft tegenover Mozilla geklaagd omdat Firefox op de website een melding geeft dat het onveilig is om in te loggen of via een creditcard te betalen. Dat las ik bij Security.nl vorige week. De website biedt gebruikers namelijk een inlogveld via http aan en sinds kort waarschuwt Firefox hiervoor. Zou een claim wegens smaad hier kans maken?

Recent heeft Mozilla, de organisatie achter browser Firefox, actie genomen om website-eigenaren te stimuleren om beveiligde verbindingen (https) te gebruiken voor het insturen van informatie. Dit zou de veiligheid op het web moeten verhogen.

Sites als deze wisten daar waarschijnlijk niet van en zijn dus onaangenaam verrast als browsers ineens “Connection is Not Secure” en “Logins entered on this page could be compromised” zeggen tegen bezoekers. Maar zou je dat smaad kunnen noemen?

De wet (art. 261 Strafrecht) definieert smaad als volgt:

Hij die opzettelijk iemands eer of goede naam aanrandt, door telastlegging van een bepaald feit, met het kennelijke doel om daaraan ruchtbaarheid te geven, wordt, als schuldig aan smaad, gestraft met gevangenisstraf van ten hoogste zes maanden of geldboete van de derde categorie. … Noch smaad, noch smaadschrift bestaat voor zover de dader heeft gehandeld tot noodzakelijke verdediging, of te goeder trouw heeft kunnen aannemen dat het te last gelegde waar was en dat het algemeen belang de telastlegging eiste.

Mozilla bazuint dus rond in het openbaar dat een website onveilig is, en baseert dat op het feit dat bepaalde formulieren onveilig worden verstuurd. Je kunt je afvragen in hoeverre dat als wáár te bestempelen is. Het is niet echt een feitelijke analyse, maar meer een mening over hoe veiligheid op het web te verhogen. Die mening is natuurlijk wel breed gedragen, dus in die zin zou je hem ‘waar’ kunnen noemen.

Minstens zo belangrijk is dat het algemeen belang de telastlegging eiste. Het is niet zo dat de waarheid dus nóóit smaad kan zijn. Een waar maar zeer genânt oud triviaal feitje rondbazuinen kan dus smaad opleveren, omdat er dan geen of te weinig algemeen belang is bij het vertellen. Smaad is een belangenafweging, geen binaire waar/onwaar kwestie.

Veiligheid op het web is een onderwerp van algemeen belang, die stelling durf ik wel aan. En dat formulieren beveiligd moeten zijn, die zie ik ook nog wel. Dus om dan als browser mensen hier op te attenderen, dat lijkt mij dan in het algemeen belang.

De tekst waarmee ze dat doen, is redelijk neutraal. Hoewel ik bij “Logins entered on this page could be compromised” dan wel een beetje dubbel gevoel krijgt: hoezo ‘could’, waar hangt dat dan van af? Een naïeve lezer zou dit kunnen opvatten als slechts een kleine slag om de arm in plaats van een “het is in theorie mogelijk”. Maar afgezien daarvan zie ik geen probleem met wat Mozilla doet.

Arnoud

19 reacties

  1. Het tegendeel is ook een vreemde: Chrome browser meldt dat een site ‘Veilig’ is als er gebruik wordt gemaakt van https. Helaas is dat evenmin per definitie het geval. Veiligheid wordt door vele factoren bepaald. Het gebruik van een certificaat wil feitelijk alleen zeggen dat de verbinding tussen de website en de browser van de gebruiker versleuteld is en dat die communicatie niet kan worden afgeluisterd. Chrome zegt echter helemaal niets over het niveau van beveiliging van de webserver, van het netwerk of van de manier waarop de website zelf gebouwd is. Chrome zegt al helemaal niets over het niveau van beveiliging van de werkplek van de gebruiker ervan. Daarnaast wil een certificaat ook niet zeggen dat de persoon die het certificaat heeft aangevraagd ook betrouwbaar is. Er zijn phishing sites met geldige certificaten!

    In mijn optiek is de manier waarop Mozilla werkt verstandiger 🙂

  2. Google heeft onlangs aangekondigd iets dergelijks te doen in hun zoekresultaten met websites die nog inlog-schermpjes via kaal HTTP weergeven. Voor veel kleine sites (zoals de mijne) is het eenvoudig over te stappen op Let’s Encrypt, dus waarom zo’n situatie nog laten bestaan? Laat HTTP maar uitsterven en HTTPS de standaard worden.

  3. Zo lang het nog gaat over login vind ik het prima; het is veel te makkelijk om een gebruikersnaam/wachtwoord van HTTP op te plukken door op een open netwerk mee te luisteren (NS, Schiphol, McDonalds, etc.), maar ik hoop dat de waarschuwing daar wel toe beperkt wordt.

    Als je een pagina met alleen statische content aanbiedt, (geen mogelijkheid tot inloggen e.d.) zie ik nog steeds niet waarom HTTPS vereist moet zijn. Het is een beetje veiliger met, dat wel; je hebt dan een betere garantie dat de data die je op het scherm ziet ook de echte data op de site is – en niet onderweg aangepast, maar daar houdt het ongeveer wel op.

    Ik ben een beetje huiverig voor de HTTPS-op-alles hype die nu gaande is. En dan niet het HTTPS-gedeelte (crypto is prima), maar de verplichting om een certificaat te regelen dat ondertekend is door een vertrouwde partij. Op dit moment heeft namelijk Let’s Encrypt monopolie in de markt van gratis certificaten (StartCom doet blijkbaar niet meer mee), en daarmee geef je Let’s Encrypt een sterk censuurapparaat in handen, waarvan je maar moet hopen dat ze het nooit gaan misbruiken.

    Het zou fijn zijn als browsermakers eens fatsoenlijke DANE-ondersteuning zouden gaan inbouwen. Daarmee kun je namelijk van de CA’s af komen, en dan heb je dat probleem niet meer. Maar het ziet er naar uit dat in ieder geval Google en Mozilla daar niet aan willen, omdat DANE meer tijd kost om te valideren dan de bestaande CA infrastructuur. Tsja..

    1. Op zoek naar meer info over DANE klik ik op de eerste Google hit die me wil brengen naar een pagina op DNSSEC.nl en hopla: “De eigenaar van http://www.dnssec.nl heeft zijn of haar website niet juist geconfigureerd. Om uw gegevens tegen diefstal te beschermen, heeft Firefox geen verbinding met deze website gemaakt”. Vanwege SECERRORUNKNOWN_ISSUER op Windows 7 met Firefox 52.0. Isn’t it ironic.

    2. Dit is eigenlijk niet de plek maar DANE is ook geen oplossing, alleen maar een verplaatsing van het probleem (want DNSSEC en de discussie daarover kan nog wel eens tien jaar duren).

      Startcom doet niet meer mee want die zijn onaangekondigd Chinees geworden (overgenomen door WoSign), niet dat dat per se erg is maar men had afgesproken dat soort overnames te melden. Daarnaast hadden ze ook backdated certificates uitgegeven, nog veel grotere no-no.

      Symantec’s SSL-afdeling krijgt binnenkort ook op z’n kop van Chrome, en dat is een veel grotere speler.

      1. Dit is eigenlijk niet de plek maar DANE is ook geen oplossing, alleen maar een verplaatsing van het probleem (want DNSSEC en de discussie daarover kan nog wel eens tien jaar duren).

        Niet helemaal waar; het is weliswaar zo dat je met DNSSEC één centrale sleutel hebt die alles beheert, maar als je daar niet op vertrouwt kun je ook sleutels van individuele TLDs pinnen. Je maakt daarmee het probleem per-land (SIDN) in plaats van Amerika (ICANN). Maar ik ken nog geen resolver die dat kan doen, behalve drill, de referentieimplementatie.

        Ik zal niet zeggen dat StartCom onterecht verwijderd is. Maar het resultaat is wel dat Let’s Encrypt nu het monopolie van StartCom heeft overgenomen.

        De DNSSEC.nl-pagina die Marcel noemt heeft een certificaat van Symantec. Datzelfde Symantec dat nu op z’n kop krijgt van Chrome. Bij mij werkt ‘ie nu in sommige browsers wel, in sommige niet.

    3. Als je een pagina met alleen statische content aanbiedt, (geen mogelijkheid tot inloggen e.d.) zie ik nog steeds niet waarom HTTPS vereist moet zijn. Het is een beetje veiliger met, dat wel; je hebt dan een betere garantie dat de data die je op het scherm ziet ook de echte data op de site is – en niet onderweg aangepast, maar daar houdt het ongeveer wel op.

      Je mist een essentieel punt: het prive houden van het browse-gedrag van de gebruiker. Dit kan alleen volledig werken als al het verkeer versleuteld is, inclusief “statische content”.

      Het idee dat statische content geen privacy- of beveiligingsrisico met zich mee kan brengen is simpelweg onjuist. Neem bijvoorbeeld het volgende voorbeeld:

      1. Een gebruiker bezoekt een link over een veiligheidslek in een bepaald stuk serversoftware.
      2. De gebruiker zoekt vervolgens naar “how to patch software linux server” op een zoekmachine.
      3. De gebruiker bezoekt dan de website van hun server-provider.

      Op dit punt is het al overduidelijk dat 1) de gebruiker niet zeer sterk onderlegd is in serverbeheer, en 2) zij hoogstwaarschijnlijk software met een actief beveiligingslek draaien 3) bij een bepaalde provider.

      Dit is genoeg voor een gerichte aanval op de betreffende server, en nergens is er ook maar een formulier aan te pas gekomen. Dat hele verhaal dat “alles versleuteld moet worden” bestaat niet zomaar; er zitten wel degelijk technische redenen achter.

      Op dit moment heeft namelijk Let’s Encrypt monopolie in de markt van gratis certificaten (StartCom doet blijkbaar niet meer mee), en daarmee geef je Let’s Encrypt een sterk censuurapparaat in handen, waarvan je maar moet hopen dat ze het nooit gaan misbruiken.

      Dit ben ik met je eens. Echter is de oplossing hier niet om dan dus maar pagina’s onveilig te laten, maar om te ageren voor meer van dergelijke CAs. Dit is ook de reden dat bijvoorbeeld het ACME-protocol (dat LE gebruikt) vrij bruikbaar is, ook door andere CAs.

      Het zou fijn zijn als browsermakers eens fatsoenlijke DANE-ondersteuning zouden gaan inbouwen. Daarmee kun je namelijk van de CA’s af komen, en dan heb je dat probleem niet meer. Maar het ziet er naar uit dat in ieder geval Google en Mozilla daar niet aan willen, omdat DANE meer tijd kost om te valideren dan de bestaande CA infrastructuur. Tsja..

      Dit is dan helaas weer volslagen onjuist. Met DANE ben je helemaal niet van de CAs af – nu is de beheerder van het TLD dat je gebruikt (wat doorgaans een overheid is) je CA. Dit maakt het censuur-probleem dat je benoemt dus alleen maar erger. DNSSEC en DANE zijn absoluut niet wenselijk, en zijn een gedrocht vanuit beveiligings-oogpunt.

      1. Je mist een essentieel punt: het prive houden van het browse-gedrag van de gebruiker. […] Dit is genoeg voor een gerichte aanval op de betreffende server, en nergens is er ook maar een formulier aan te pas gekomen. Dat hele verhaal dat “alles versleuteld moet worden” bestaat niet zomaar; er zitten wel degelijk technische redenen achter.

        Als jij met die gebruiker meeluistert in een koffiezaak (op onbeveiligd WiFi), kun je hetzelfde bereiken door mee te kijken op z’n scherm, wat ook niet zo moeilijk moet zijn. Als de gebruiker dit thuis doet (beveiligd WiFi of bekabeld) en jij kan ‘m alsnog afluisteren, heeft hij een groter probleem dan dat jij alleen maar weet wat ‘ie op z’n server draait. Dan ben jij namelijk dusdanig in die gebruiker geïnteresseerd dat jij ook wel andere methodes aanwendt om uit te vinden waar die gebruiker zoal mee bezig is.

        Echter is de oplossing hier niet om dan dus maar pagina’s onveilig te laten, maar om te ageren voor meer van dergelijke CAs. Dit is ook de reden dat bijvoorbeeld het ACME-protocol (dat LE gebruikt) vrij bruikbaar is, ook door andere CAs.

        De oplossing is óók niet om maar TLS op alle pagina’s af te dwingen, en alarmbellen te laten rinkelen als iemand dat niet doet. Daarmee geef je namelijk CAs een middel in handen om censuur te plegen. Op dit moment is Let’s Encrypt de enige gratis CA, dus als jij een website hebt en je wil niet dat die rode waarschuwingen laat zien, moet jij zaken doen met Let’s Encrypt of je portemonnee trekken bij een concurrent. Zelfs als andere CAs ACME gaan ondersteunen, vraag ik me af of ze dat gratis gaan doen. We hebben met z’n allen browsers op onze computers staan die ons vertellen dat een website onveilig is als een Amerikaans bedrijf ‘m niet eerst goedgekeurd heeft.

        Met DANE ben je helemaal niet van de CAs af – nu is de beheerder van het TLD dat je gebruikt (wat doorgaans een overheid is) je CA.

        Da’s prima toch? Je vertrouwt al op de beheerder van de TLD dat ‘ie de juiste waarden in z’n eigen zone zet, zodat jouw website bereikbaar is en de CA kan bevestigen dat jij de gerechtigde ontvanger van het certificaat bent (we nemen DV aan, want Let’s Encrypt). Met of zonder DANE, de TLD kan gewoon jouw domein intrekken en dan is het gedaan met je site. DANE/DNSSEC voegt dus niets toe aan censuurmogelijkheden, maar door de samenvoeging van CA en TLD verdwijnt er een partij die jou kan censureren. Overigens kun je nog steeds een traditionele CA hebben, bijvoorbeeld voor een EV certificaat.

        Dan kan je natuurlijk altijd nog het argument gebruiken dat het met DANE onwenselijk is dat dezelfde partij zowel je DNS als je certificaat doet. Dat maakt het namelijk makkelijk voor ze om gebruikers om te leiden naar hun eigen server en verkeer te inspecteren. Behalve dat dat al zo is zonder DANE; de SIDN kan, als ze dat zouden willen, een andere NS-post terugsturen naar Let’s Encrypt, en zo met ACME een certificaat voor jouw domein regelen.

        Dat dat nog nooit mis gegaan is in Nederland of Amerika is omdat we blijkbaar betrouwbare TLDs hebben, of omdat we het niet weten. Maar ook al is DANE niet perfect, het is beter dan niets doen (zoals wordt aangeraden in het door jou aangehaalde artikel).

        1. Als jij met die gebruiker meeluistert in een koffiezaak (op onbeveiligd WiFi), kun je hetzelfde bereiken door mee te kijken op z’n scherm, wat ook niet zo moeilijk moet zijn. Als de gebruiker dit thuis doet (beveiligd WiFi of bekabeld) en jij kan ‘m alsnog afluisteren, heeft hij een groter probleem dan dat jij alleen maar weet wat ‘ie op z’n server draait. Dan ben jij namelijk dusdanig in die gebruiker geïnteresseerd dat jij ook wel andere methodes aanwendt om uit te vinden waar die gebruiker zoal mee bezig is.

          Dit is geen zinnige vergelijking. In persoon afluisteren is veel duurder dan verkeer onderscheppen, en met “gerichte aanval” bedoel ik niet dat er slechts een enkel persoon getarget wordt; maar dat er een mens aan te pas komt om de puzzelstukjes te combineren. Dat kan prima zijn d.m.v. het in de gaten houden van bezoekjes aan de eerder genoemde pagina over een beveiligingslek.

          Ik heb het ook niet alleen over koffiezaken; je meeste interverkeer gaat door heel wat providers heen, en daar is veel mogelijkheid om verkeer te onderscheppen (en dat gebeurt dus ook).

          De oplossing is óók niet om maar TLS op alle pagina’s af te dwingen, en alarmbellen te laten rinkelen als iemand dat niet doet. Daarmee geef je namelijk CAs een middel in handen om censuur te plegen. Op dit moment is Let’s Encrypt de enige gratis CA, dus als jij een website hebt en je wil niet dat die rode waarschuwingen laat zien, moet jij zaken doen met Let’s Encrypt of je portemonnee trekken bij een concurrent. Zelfs als andere CAs ACME gaan ondersteunen, vraag ik me af of ze dat gratis gaan doen. We hebben met z’n allen browsers op onze computers staan die ons vertellen dat een website onveilig is als een Amerikaans bedrijf ‘m niet eerst goedgekeurd heeft.

          Wederom: als je dit een probleem vindt, pak dan het daadwerkelijke probleem aan. Desnoods start je zelf een CA. Zadel niet de rest van de maatschappij ermee op.

          Da’s prima toch? Je vertrouwt al op de beheerder van de TLD dat ‘ie de juiste waarden in z’n eigen zone zet, zodat jouw website bereikbaar is en de CA kan bevestigen dat jij de gerechtigde ontvanger van het certificaat bent. Met of zonder DANE, de TLD kan gewoon jouw domein intrekken en dan is het gedaan met je site. DANE/DNSSEC voegt dus niets toe aan censuurmogelijkheden, maar door de samenvoeging van CA en TLD verdwijnt er een partij die jou kan censureren. Dan kan je natuurlijk altijd nog het argument gebruiken dat het met DANE onwenselijk is dat dezelfde partij zowel je DNS als je certificaat doet. Dat maakt het namelijk makkelijk voor ze om gebruikers om te leiden naar hun eigen server en verkeer te inspecteren. Behalve dat dat al zo is zonder DANE; de SIDN kan, als ze dat zouden willen, een andere NS-post terugsturen naar Let’s Encrypt, en zo met ACME een certificaat voor jouw domein regelen.

          Dit is veel te versimpeld gezien. Het wordt door DANE wel degelijk gemakkelijker voor een partij om als MITM te fungeren; er is namelijk directe controle over welke sleutels gebruikt worden. Als diezelfde partij eerst een CA om de tuin moet leiden, wordt dit een heel stuk lastiger; 1) het duurt langer, 2) het is moeilijker/niet te targeten op specifieke gebruikers of regios, en 3) je stelt een derde partij op de hoogte van de wijziging.

          Het doel van beveiliging is niet om alle problemen met zekerheid te voorkomen; het doel is om aanvallen zo duur en onaantrekkelijk mogelijk te maken. De introductie van DANE maakt de kosten en risico’s van een dergelijke aanval aanzienlijk lager, en dat is zeer onwenselijk.

          Dat dat nog nooit mis gegaan is in Nederland of Amerika is omdat we blijkbaar betrouwbare TLDs hebben, of omdat we het niet weten. Maar ook al is DANE niet perfect, het is beter dan niets doen (zoals wordt aangeraden in het door jou aangehaalde artikel).

          “Beter dan niets” is simpelweg niet van toepassing in beveiliging. Het is veel te fragiel om maar maatregel op maatregel te stapelen zonder dat daar een duidelijk doel voor is; het enige wat je ermee bereikt is het vergroten van je attack surface, vaak op zo’n manier dat we er ook nooit meer vanaf komen.

          Wat beveiliging betreft is “niets” absoluut beter dan “een slecht geimplementeerde beveiligingsmaatregel”.

          1. Dit is veel te versimpeld gezien. Het wordt door DANE wel degelijk gemakkelijker voor een partij om als MITM te fungeren; er is namelijk directe controle over welke sleutels gebruikt worden. Als diezelfde partij eerst een CA om de tuin moet leiden, wordt dit een heel stuk lastiger;
            Het wordt voor een MITM toch een stuk lastiger om een verkeerd (maar werkend) certificaat terug te geven, als de cliënt (die zonder DANE van te voren verder ook geen flauw idee had welk certificaat de server zou aanbieden) het ontvangen certificaat kan vergelijken met de DNS informatie, die met DNSSEC is beveiligd. Dit is tenminste wat ik begrijp van de DNSSEC pagina over DANE.

          2. Dit is geen zinnige vergelijking. In persoon afluisteren is veel duurder dan verkeer onderscheppen, en met “gerichte aanval” bedoel ik niet dat er slechts een enkel persoon getarget wordt; maar dat er een mens aan te pas komt om de puzzelstukjes te combineren. Dat kan prima zijn d.m.v. het in de gaten houden van bezoekjes aan de eerder genoemde pagina over een beveiligingslek.

            Dan houd je toch de nieuwssites in de gaten, kijkt waar ze heen linken en vervolgens ga je SNI-headers besnuffelen.

            Ik heb het ook niet alleen over koffiezaken; je meeste interverkeer gaat door heel wat providers heen, en daar is veel mogelijkheid om verkeer te onderscheppen (en dat gebeurt dus ook).

            Nederlandse providers gaan dat niet makkelijk maken voor je als je niet bij een opsporingsdienst werkt.

            Wederom: als je dit een probleem vindt, pak dan het daadwerkelijke probleem aan. Desnoods start je zelf een CA. Zadel niet de rest van de maatschappij ermee op.

            Een eigen CA maken is hartstikke simpel, en heb ik ook al lang gedaan. Is heel handig voor dingen die op mijn eigen server draaien die ik alleen zelf gebruik. Maar jij krijgt een certificaatfout als je diezelfde dingen probeert te benaderen. Ik heb namelijk niet de middelen om de grote browsers mijn CA te laten accepteren; en dat is niet zo simpel als jij voordoet.

            De maatschappij is al opgezadeld met problemen, namelijk een CA-markt die moeilijk open te breken is, tenzij je de groten al achter je hebt. Daar een alternatief voor bieden is goed.

            Als diezelfde partij eerst een CA om de tuin moet leiden, wordt dit een heel stuk lastiger; 1) het duurt langer, 2) het is moeilijker/niet te targeten op specifieke gebruikers of regios, en 3) je stelt een derde partij op de hoogte van de wijziging.

            Eens, voor de introductie van ACME. Maar nu kun je het proces 100% automatiseren.

            De introductie van DANE maakt de kosten en risico’s van een dergelijke aanval aanzienlijk lager, en dat is zeer onwenselijk.

            De aanval blijft moeilijk, want al het verkeer moet dan via de aanvaller. Dat valt op in de logs van de server. Opnieuw, wel of geen DANE maakt geen verschil hierin omdat je TLD de aanval nu ook al kan doen. Het probleem dat je aanhaalt kan opgelost worden met pinning.

            Wat beveiliging betreft is “niets” absoluut beter dan “een slecht geimplementeerde beveiligingsmaatregel”.

            Eens, daarom vind ik het ook niet handig als browsers gaan brullen wanneer je een statische pagina bezoekt via HTTP. Maar in de CA situatie is niets doen effectief goedkeuren dat een kleine groep kan besluiten wat wel en wat niet veilig is op het internet. DNSSEC heeft er al meer dan 10 jaar op zitten, ik hoop niet dat de CAs rare dingen gaan doen terwijl we nog eens 10 jaar gaan wachten op de “perfecte” oplossing.

    4. Een ander alternatief zou kunnen bestaan uit naam-registratie op een block chain, zoals Namecoin doet (deed?). Dan is het volledig de-centraal (even aangenomen dat je het Bitcoin-model volgt, en niet zoiets raars als de “permissioned block chains” waar sommige banken mee experimenteren). Consequentie is wel dat het beleid m.b.t. wie welke naam kan claimen vrij beperkt is: het eenvoudigst te implementeren is een “first-come-first-serve” beleid, misschien in combinatie met automatisch vervallen van niet-regelmatig-ververste namen. Er kunnen absoluut geen uitzonderingen gemaakt worden, want er is geen centrale autoriteit die kan beslissen tot het maken van een uitzondering.

      Een naam kan dan gekoppeld worden aan een IP-adres (DNS-functie), maar ook aan andere data, zoals een public key (CA-functie). Met een beetje standaardisatie-effort is het systeem willekeurig ver uit te breiden: je zou een complete record met key-value paren kunnen hashen, en dan je naam aan die hash kunnen koppelen. Dan hoef je alleen nog maar je complete record te delen met geïnteresseerden, bijv. als onderdeel van of voorafgaande aan TLS-initialisatie (ik weet niet precies hoe flexibel TLS is).

  4. Het is niet echt een feitelijke analyse,

    Waarom niet? De feitelijke analyse die hieraan ten grondslag ligt is vrij simpel:

    • * Je gebruikt geen TLS, en verstuurt login-gegevens als plaintext.
    • * Het lekken van logingegevens (en creditcardgegevens) is onwenselijk omdat het hier gevoelige en voor misbruik vatbare informatie betreft.
    • * Je internetverkeer gaat door vele providers heen, die het allen kunnen inspecteren, inclusief providers (zoals publieke wi-fi APs) die bewust bestaan om gevoelige gegevens te onderscheppen.
    • * Het versturen als plaintext is onnodig, omdat het probleem gemakkelijk op te lossen is door TLS te gebruiken.
    • * Ergo, het is feitelijk vastgesteld dat de formulieren onveilig verstuurd worden, zonder dat daar noodzaak voor is.
    1. Eens met jouw analyse dat TLS beschermt tegen de “domme” luitstervink. Maar TLS is geen oplossing voor alle privacyproblemen.

      In theorie zou je met TLS-certificaten moeten kunnen vaststellen dat je met de correcte webserver contact maakt, maar helaas:

      • Certificate Authorities maken fouten bij het uitdelen van certificaten,

      • CA’s worden gehackt en zijn gevoelig voor overheidsdruk,

      • Weel websitebeheerders geven hun certificaat vrijwillig aan een CMS of DOS-beschermer.

      Er zijn dus de nodige aangrijpingspunten voor een actieve MitM aanval op https-verkeer.

      1. Eens met jouw analyse dat TLS beschermt tegen de “domme” luitstervink. Maar TLS is geen oplossing voor alle privacyproblemen.

        Maar dat zeg ik toch ook niet? Het gaat er enkel om of er wel een feitelijke analyse bestaat voor de bewering dat “dit formulier onveilig verstuurd wordt”, en dat is het geval voor een TLS-loze verbinding. Dat je ook mét TLS nog steeds privacy-/beveiligingsproblemen kunt hebben in bepaalde situaties doet daar niets aan af.

        Overigens is het niet zo gemakkelijk om valse certificaten uit te geven als je hier lijkt te stellen. Het is vrijwel onmogelijk om dit stilletjes te doen, dus zelfs als een MITM vanwege een edgecase toch mogelijk is, is het nog altijd veiliger dan helemaal geen TLS gebruiken – simpelweg omdat valse certificaten opvallen, en zeer waarschijnlijk gevonden worden.

        (CloudFlare en dergelijke organisaties zijn een speciaal geval, en m.i. mag er best wel wat meer druk op browser vendors gezet worden om verkeer dat via dit soort MITM-aanbieders gaat standaard als onveilig te bestempelen.)

  5. 1) Mozilla laat deze waarschuwing op meer pagina’s dan slechts die met formulieren zien. 2) HTTPS voorkomt niet bijvoorbeeld XSS; HTTPS wil dus niet zeggen dat een site of een verbinding veilig is. 3) Mozilla laat de waarschuwing ook zien op sites die HTTPS zonder certificaat gebruiken. 4) Een certificaat bewijst alleen dat iemand met een bepaald e-mailadres dat certificaat heeft aangevraagd – het zegt niets over de beveiliging van de verbinding. 5) HTTPS-verkeer kan worden onderschept.

    Kortom, Mozilla laat de waarschuwing bij beveiligde verbindingen zien en laat de waarschuwing weg bij slecht beveiligde websites. Dat is security-cargo-culting in het gunstigste geval en in het ongunstigste geval … ik durf er niet aan te denken. Willen Google en Mozilla soms dat er meer certificaten worden verkocht? Zo ja, waarom?

    1. 1) Mozilla laat deze waarschuwing op meer pagina’s dan slechts die met formulieren zien.

      Zoals ik al eerder hierboven heb aangegeven, is “formulieren” totaal irrelevant.

      2) HTTPS voorkomt niet bijvoorbeeld XSS; HTTPS wil dus niet zeggen dat een site of een verbinding veilig is.

      Waarom niet? XSS heeft uberhaupt niets met de verbinding te maken.

      3) Mozilla laat de waarschuwing ook zien op sites die HTTPS zonder certificaat gebruiken.

      HTTPS “zonder certificaat gebruiken” is een technische onmogelijkheid. Je bedoelt waarschijnlijk self-signed certificates; zie daarvoor onderstaand punt.

      4) Een certificaat bewijst alleen dat iemand met een bepaald e-mailadres dat certificaat heeft aangevraagd – het zegt niets over de beveiliging van de verbinding.

      Authenticatie is een essentieel onderdeel van een beveiligde verbinding. Versleuteling alleen maakt een verbinding niet veilig. “Het zegt niets over de beveiliging van de verbinding” is dus pertinent onjuist.

      5) HTTPS-verkeer kan worden onderschept.

      Enkel onder zeer beperkte omstandigheden, dus dit presenteren als “HTTPS-verkeer kan worden onderschept” is zeer misleidend. Dat is zeker niet zomaar het geval.

      Die omstandigheden zijn:

      1. Er is een aangepast CA-certificaat geladen op de client (dus de client is al gecompromitteerd, en versleutelde verbindingen zijn dan al niet zo boeiend meer). Dit is wat je vaak ziet in bedrijfsnetwerken.
      2. Er is een CA gecompromitteerd. Zeer zeldzaam en moeilijk stil te houden. Niet relevant als je niet bijzonder high-profile bent.
      3. De site-eigenaar laat bewust een MITM toe (zoals bijv. via CloudFlare). Zorgelijk, maar wederom een bewuste keuze van een van de twee partijen in de verbinding.
      4. De client draait een verkeerd geimplementeerde lokale MITM-implementatie, zoals bijv. die van een virusscanner. Wederom, de keus van de client.

      TLS is bedoeld om de verbinding te versleutelen, en je een garantie te geven dat je communiceert met de partij waar je mee denkt te communiceren. Dat een van de twee partijen geen betrouwbaar lokaal execution environment heeft doet daar niets aan af, en is out of scope voor TLS.

      Al de scenarios waar het onderscheppen van TLS mogelijk is, zijn ofwel zeer onwaarschijnlijk, ofwel het gevolg van een probleem bij een van de twee (legitieme) partijen. TLS werkt dus prima.

  6. Hoe zit dit dan met Google Safe Browsing? Wat in bijna elke browser je website volledig blokkeert.

    Ik heb al een keer alles moeten omlinken en oude pagina’s moeten 404-en om van dit filter af te komen. Blokkade was compleet onterecht (onschuldige pagina’s achter login, die google dus niet eens kon scannen) en Google geeft geen gehoor.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.