Moet mijn contactformulier SSL-beveiligd zijn?

https-secure-secuur-netwerkEen lezer vroeg me:

Op mijn site wil ik een contactformulier toevoegen. Nu las ik dat je dan verplicht een SSL-verbinding (https) toe te passen, dat is nogal een dure grap voor mij. En toen zag ik dat jij op je blog geen SSL-verbinding hanteert, niet bij je contactformulier en niet bij het plaatsen van reacties. Dus mag ik dan concluderen dat het niet hoeft?

Met een contactformulier sturen mensen persoonsgegevens in. De wet eist dat je die persoonsgegevens ‘adequaat’ beveiligt tegen misbruik en ongeautoriseerde toegang. Een SSL-beveiliging is de meest voor de hand liggende en simpelste manier om dit te doen, vandaar dat vrijwel iedereen dat middel toepast bij bestel- en contactformulieren.

De wet zegt echter nergens létterlijk dat SSL-beveiliging verplicht is. Sterker nog de wet bepaalt eigenlijk nergens überhaupt letterlijk welke maatregelen genomen moeten worden. Je moet als beheerder/exploitant van een site zelf bepalen welke maatregelen gepast zijn gezien de aard van de informatie en het mogelijk misbruik daarvan.

Bij een bestelformulier op een website stuur je allerlei gegevens op waarmee je een juridisch bindende bestelling plaatst, vaak inclusief betaalgegevens (creditcardnummer). Die kunnen worden gesnift en hergebruikt, en dat is wel ernstig genoeg om beveiliging bij het verzenden te vereisen.

Maar bij een blogcommentaarformulier? Oké stel iemand zit in hetzelfde internetcafé als jij, monitort het draadloze netwerk en onderschept je naam en reactie. En dan? Dan kan hij ook reageren op mijn blog. En de reactie te weten komen, drie seconden voordat deze online gaat voor de hele wereld. Nou en?

Het enige stukje echt vertrouwelijke informatie is het e-mailadres, dat ik als beheerder wel zie maar de andere reageerders niet. Tsja. Is de kans op misbruik van dat e-mailadres groot genoeg om een SSL verbinding op dat formulier te rechtvaardigen?

Arnoud

28 reacties

  1. Er zijn ook verschillende providers van gratis SSL certificaten, zoals bijvoorbeeld StartSSL; Comodo en anderen bieden gratis trials (maar ik geloof dat er nog een paar zoals StartSSL zijn). Natuurlijk kan je ook je eigen certificaten signen, hoewel dat (specifieke use-cases uitgezonderd) meestal niet zo zinvol is (tenzij het voor eigen gebruik is, en je bijvoorbeeld certificate patrol gebruikt).

    1. Maar welk probleem los je daarmee op? Je versleutelt zo het netwerkverkeer naar die site. Is de dreiging dat iemand dat verkeer snift dan wérkelijk zo groot?

      Zeker bij een blogcomment vraag ik me zeer af wat er te sniffen valt. Je publiceert immers je reactie, dus beschouw je niets uit je reactie als privé. Nou ja, je e-mailadres maar is dat zó belangrijk en privé?

      1. In de huidige wereld is authenticatie (zeker weten dat je niet op de nep-blog van Arnoud reageert) een belangrijker toepassing van SSL dan encryptie. Sniffen is simpelweg te lastig en te duur voor end-user aanvallen.

        Een Comodo PositiveSSL certificaat kost 10 euro per jaar dus iedereen die over de kosten zeurt, is wel heel verkeerd bezig. Een meer verbreid argument is dat je toch nog een dedicated IP nodig hebt, want al die host-extensies van SSL werken nog niet onder XP en dat is toch een te groot deel van het publiek.

        1. Dus als je een certificaat koopt van 10 euro, is je site gelijk beveiligd? Nee, dus. De jaarlijks terugkerende kosten kunnen veel hoger liggen dan 10 euro. Verder is emailverkeer vaak ook onbeveiligd. De gevaren van een onbeveiligd contactformulier zijn wel erg hypothetisch.

          1. Dus als je een certificaat koopt van 10 euro, is je site gelijk beveiligd? Nee, dus. De jaarlijks terugkerende kosten kunnen veel hoger liggen dan 10 euro.

            Zou je deze twee boude statements ook kunnen onderbouwen?

            Voorzetje: – een SSL certificaat van 10 euro garandeert in ieder geval dat degene die het certificaat heeft geinstalleerd, ook toegang had tot een administratief e-mail adres van het betreffende domein. Dit beveiligt in ieder geval je site tegen eenvoudige DNS-spoofing. – Comodo bij SSLCertificaten.nl eerste jaar een tientje, volgende jaren 9 euro

            1. – een SSL certificaat van 10 euro garandeert in ieder geval dat degene die het certificaat heeft geinstalleerd, ook toegang had tot een administratief e-mail adres van het betreffende domein. Dit beveiligt in ieder geval je site tegen eenvoudige DNS-spoofing.

              Edwin doelt erop dat de gemiddelde website-eigenaar waarschijnlijk nog kosten maakt om het certificaat te laten installeren door zijn webhoster, al dan niet op een dedicated IP, iets dat vaak extra kosten met zich meebrengt (dit stelde Richard al, immers ondersteunen Windows XP noch oude Androidversies SNI).

              Overigens is een website met ‘enkel’ een certificaat ook niet heilig (afhankelijk van je attacker model). Ik durf in ieder geval te stellen dat het de gemiddelde gebruiker slechts zeer beperkt beschermt tegen ‘eenvoudige DNS-spoofing’. Immers browsed de ‘gemiddelde gebruiker’ toch echt eerst naar de non-https versie van je site; een attacker die DNS kan spoofen stript dan gewoon alle SSL references.

              – Comodo bij SSLCertificaten.nl eerste jaar een tientje, volgende jaren 9 euro

              Tja, of 0,- bij StartSSL. Dat het certificaat zelf weinig hoeft te kosten wordt volgens mij door niemand betwist.

              1. Edwin doelt erop dat de gemiddelde website-eigenaar waarschijnlijk nog kosten maakt om het certificaat te laten installeren door zijn webhoster, al dan niet op een dedicated IP, iets dat vaak extra kosten met zich meebrengt
                Edwin had het over ‘jaarlijks terugkerende kosten’ en installatiekosten zijn dat volgens mij niet.

                1. Edwin had het over ‘jaarlijks terugkerende kosten’ en installatiekosten zijn dat volgens mij niet.

                  Veel SSL certificaten zullen ieder jaar vervangen moeten worden. Als iemand dit voor je moet doen zijn daar mogelijk jaarlijkse kosten aan verbonden.

                  1. Veel SSL certificaten zullen ieder jaar vervangen moeten worden. Als iemand dit voor je moet doen zijn daar mogelijk jaarlijkse kosten aan verbonden.
                    Het is 2013 hoor, zo’n certificaat gaat gewoon 5 jaar mee.

                      1. Weet je, mijn opmerking was in beginsel een reactie op de eerste reactie, die van Rens, over gratis en self-signed certificaten. Punt was dat je je niet hoeft te ‘verlagen’ tot gratis of self-signed certificaten omdat certificaten tegenwoordig niet zoveel meer kosten. Je kan er dan allerlei extra kosten en moeilijke dingen bij gaan verzinnen maar die heb je bij self-signed of gratis certificaten ook. Dus dat maakt helemaal geen verschil.

                        Daarnaast zijn en blijven dergelijke kosten peanuts ten opzichte van ontwikkeling, exploitatie en hosting.

          2. Iemeelverkeer lijkt me inderdaad veel onveiliger dan een contactformulier, want de afzender is gemakkelijk te vervalsen, en ook een typ-fout is zo gemaakt. En meestal natuurlijk niet versleuteld. (En dan nu een stukje reclame voor PGP…)

      2. Een email adres kan enorm handig zijn voor spammers. Als deze ook nog eens aan accountnamen of zelfs echte namen te koppelen zijn dan kan dit gebruikt worden om veel meer extra informatie over een bepaalde persoon terug te vinden. Persoonlijk vind ik een email adres behoorlijk prive, waardoor ik gewoon een complete domeinnaam gebruik voor mijn mailbox. En voor ieder bedrijf waar ik contact meemaak gebruik ik een aparte alias, zoals ik ook hier gebruik. Zodoende kan ik controleren vanuit welke bron ik word gespamd zodat ik die bron erop aan kan spreken en de betreffende alias direct aan mijn prullenbak kan doorverbinden. Dat werkt perfect!

  2. Wat is de waarde van een SSL-certificaat als hackers (DigiNotar) en overheden die ook kunnen (laten) genereren? (Het is een extra barriere die genomen moet worden voor het onderscheppen van gegevens.) Beveiliging is een afweging van doel en middelen; het bespreken van middelen zonder de beveiligingsdoelen in het oog te houden leidt tot dure en ineffectieve maatregelen. Het gebruik van versleuteling voor data die toch gepubliceerd wordt is overbodig, behalve wanneer de versleuteling gebruikt wordt om de lezer of commentaarplaatser te beschermen tegen zijn overheid. (Ik ga niet verder in op mogelijke correlatie-aanvallen, valt buiten het topic van de blog.)

    Een ander issue: het gebruik van SSL voor een bestelformulier is mooi, maar als de bestelsite een SQL-injectie gat heeft waarmee de creditkaartgegevens alsnog op straat komen te liggen, dan heeft de encryptie van de communicatie maar een beperkte waarde gehad. Op een blog als iusmentis zou ik de administratieve interface met versleuteling beschermen, over een paar uur weet toch iedereen dat ik dit bericht heb ingetikt!

  3. SSL certificaten voorzien van DANE (vereist DNSSEC) geven de meeste veiligheid/garantie voor de website bezoeker. Zonder DANE weet je nog niet 100% zeker dat je op de juiste website zit als er een SSL certificaat aanwezig is (Diginotar).

    1. Zelfs DANE en DNSSEC geven je geen 100% garantie. Het is voor een overheid niet zo moeilijk om een paar records in nationale root-DNS te laten aanpassen (laat ze naar de AIVD-DNS-server wijzen.) Voeg daarbij een certificaat dat die overheid door de locale CA op maat heeft laten maken en je hebt een 100% https hack. Een en ander is wat lastiger voor criminele hackers, maar het illegaal overnemen van domeinen is gebeurd. Wanneer je de mail server hebt is het CA-certificaat niet meer zo moeilijk.

      1. Het geeft meer garantie. Je systeem dat DNSSEC validatie doet moet gewijzigd worden door een overheid om, zonder dat je het merkt, de nationale root DNS aan te kunnen passen. Het enige alternatief waar het ook bij kan is het geval dat de root keys bekend zijn bij de overheid. Zodra de validatie niet lokaal gedaan wordt, maar door de ISP is het al makkelijker voor een overheid om de DNS te kunnen wijzigen zonder dat het opvalt.

  4. Vergelijk het met je hand uisteken voor je afslaat met de fiets. Dat heeft alleen zin als er ander verkeer is. Voor de zekerheid hebben we afgesproken dat je het altijd moet doen. Dan hoef je ook niet na te denken of er ander verkeer is.

    Zo kun je ook met SSL omgaan. Als je niet zeker weet of je het nodig hebt dan kun je het maar beter wel gebruiken. Ook ben je dan voorbereid als er in de toekomst nog wordt toegevoegd die wel privacygevoelig is.

    1. @casper: je hand uitsteken, niet kijken en dan vervolgens platgereden worden door de auto die 5 meter achter je zat (en niet op tijd kan remmen omdat je te abrupt afslaat) lijkt me nou niet de meest verstandige oplossing. Zo is ’t ook met IT: nadenken, niet blind copypasten.

  5. Als je voor een SSL-beveiliging gaat, denk er dan aan dat je contactformuliersysteem het ingevulde bericht vervolgens niet onversleuteld naar je e-mailt. Anders kan het alsnog onderschept worden op een ander punt in de keten.

    1. Ik blijf moeite houden met het idee dat mensen mail in transit gaan onderscheppen. Waarom hacken ze niet gewoon de database? Die slaat alles onversleuteld op (hoi /var/lib/mysql of /var/mail/arnoud) en dat vinden we doodnormaal geloof ik. Dus waarom dan wél versleuteling voor die 1.5 milliseconde dat het per mail onderweg is?

      1. Het hangt er helemaal van af hoe ver je email het netwerk over gaat; welke route volgt het mailbericht over Internet en kun je alle tussenliggende routers vertrouwen. Als je mail naar “localhost” of een andere machine op je eigen server netwerk verstuurt is transport-encryptie zinloos; maar wanneer het bericht over het “open” internet gaat kan het door een “routing incident” via China langs de NSA gaan (en twee keer getapt worden.) Dan kun je beter geen onversleutelde creditkaartgegevens in het bericht hebben staan.

      2. Ik heb een VPS bij een internationaal opererend bedrijf (is vrij onbekend in Nederland). Laatst ontdekte ik dat toen ik wat met de firewall aan ’t spelen was, en verkeer aan het dumpen was dat zij nagenoeg geen ARP-filtering doen. Er kwam per uur ongeveer 2.5 Gib aan ARP verkeer bij/langs mijn VPS.

        Als ik had gewild had ik vrij simpel ARP responses kunnen spoofen, en daarmee een deel van het traffic van dit datacenter naar mij toe kunnen laten routeren. Om het vervolgens bijvoorbeeld af te tappen. Dat is veel minder moeite dan een mailserver hacken of iets dergelijks. Ook zouden andere VPS-eigenaren hier niets van merken – wat bij een hack mogelijk wel het geval zou zijn.

        Verder vind ik dat ook een blog als deze een SSL-certificaat zou moeten hebben. Ik versleutel zelf /al/ mijn verkeer middels een VPN-verbinding. Maar stel dat ik dat niet zou hebben; als ik dan op een hotspot hier een reactie plaats heeft iemand die het wifi-signaal afluistert mijn naam en email adres. Dit aftappen is bijzonder simpel voor wifi, en kan ook onopgemerkt (volgens mij heb je hiervoor ook applicaties voor noobs die alleen bijv. formdata er uit vissen – speciaal voor de noob ;)). Dan heeft iemand mijn naam, emailadres, en weet hoe ik er uit zie: een mooi begin voor identiteitsfraude.

        Ook het inloggedeelte van WP is niet met een SSL-certificaat beveiligd. Wat als jij Arnoud een keer (per ongeluk) op een onbeveiligde hotspot inlogt en iemand tapt dat af?

        Nee, ik denk dat de minimaal benodigde investering om dit goeddeels te verhelpen (hierboven omschreven als ‘vanaf 10 euro’) absoluut opweegt tegen de – kleine, maar niet geheel verwaarloosbare – risico’s die je bezoekers lopen…

        1. Daarom ben ik eigenlijk een voorstander van OpenID, zodat een site zelf gebruikers-beheer kan bevatten maar toch heel weinig SSL nodig zal hebben. Het inloggen gebreurt via b.v. Google, Twitter, Facebook of andere OpenID provider en die kunnen de betreffende account ook goed veilig houden. Daarnaast krijg je bij OpenID als bezoeker ook de vraag of je het eens bent met dat je gegevens worden gedeeld en geven ze vaak aan wat er wordt gedeeld. En in het algemeen is een naam en email adres meer dan voldoende. De bezoeker hoeft hierdoor minder wachtwoorden te onthouden en de site hoeft zich minder druk te maken over beveiliging. Het legt bovendien de belangrijkste beveiligings-problemen neer bij de OpenID providers, die daar veel meer kennis van zullen hebben (hoop ik) dan de gemiddelde site-bouwer.

          Risico’s blijven er altijd maar als je ziet hoeveel mensen zich met site-bouwen bezig houden en hoeveel van hen daar steeds fouten bij maken, dan is het onbegonnen werk om iedereen zelf hun beveiliging te laten aanleggen.

          Daarnaast is ook SSL geen 100% veilige oplossing. Er zijn al meerdere hack-pogingen gedaan waarbij hackers een “officieel” certificaat hebben bemachtigd waarmee ze zich als een ander bedrijf kunnen voordoen. Met de blamage van DigiNotar in gedachten levert SSL alleen maar een gevoel van schijnveiligheid…

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.