AP: gebruik ssl 2.0 mogelijk in strijd met privacywet
Bedrijven die nog van ssl 2.0 gebruikmaken overtreden mogelijk de privacywet, zo heeft de Autoriteit Persoonsgegevens (AP) gewaarschuwd. Aanleiding voor de waarschuwing is de deze week aangekondigde DROWN-aanval, waardoor aanvallers versleutelde verbindingen kunnen kraken.
De DROWN-aanval maakt gebruik van het oude sslv2-protocol dat veel servers nog steeds ondersteunen, maar niet gebruiken voor het opzetten van een versleutelde verbinding. Daarvoor wordt tegenwoordig het tls-protocol gebruikt. Een aanvaller kan tls-verbindingen echter ontsleutelen door probes naar een server te sturen die sslv2 ondersteunt en dezelfde privésleutel gebruikt.
Ook loopt een server risico als de privésleutel op andere servers wordt gebruik die sslv2-verbindingen toestaan, ook al is het voor een ander protocol. De onderzoekers stellen dat veel bedrijven hetzelfde certificaat en sleutel voor hun web- en mailservers hergebruiken. Als bijvoorbeeld de e-mailserver sslv2 ondersteunt en de webserver niet, dan kan een aanvaller de e-mailserver gebruiken om de tls-verbindingen van de webserver te kraken. In totaal zou 33% van alle https-servers voor de DROWN-aanval kwetsbaar zijn.
Configuratie
De Autoriteit Persoonsgegevens wijst erop dat door het recent ontdekte lek het van groot belang is dat organisaties hun configuratie aanpassen. Daarvoor wordt gewezen naar de ict-beveiligingsrichtlijnen voor Transport Layer Security (tls) van het Nationaal Cyber Security Center van de Overheid. De Autoriteit Persoonsgegevens benadrukt ook dat als er van OpenSSL gebruik wordt gemaakt, de laatste beveiligingsupdates moeten worden geïnstalleerd. Servers die een kwetsbare versie van OpenSSL gebruiken kunnen op dezelfde manier worden aangevallen, ongeacht of ze ssl 2.0 ondersteunen.
Als organisaties de configuratie niet aanpassen en gebruik maken van configuraties die bekende kwetsbaarheden bevatten, overtreden zij mogelijk artikel 13 van de Wet bescherming persoonsgegevens (Wbp), aldus de privacytoezichthouder. De eisen die de Wbp stelt aan de beveiliging zijn hoger naarmate de gegevens een gevoeliger karakter hebben, of de context waarin deze worden gebruikt een grotere bedreiging voor de persoonlijke levenssfeer betekenen. De Autoriteit Persoonsgegevens heeft dan ook "verscherpte aandacht" voor het gebruik van sslv2.
Misschien is het een idee om eerst websiteeigenaren aan te pakken die helemaal geen https gebruiken bij het uitwisselen van PII (Personally Identifiable Information)?
Of websites waarvan het onduidelijk is met welke organisatie je daadwerkelijk te maken hebt, bijv. door het gebruik van waardeloze digitale certificaten (waardoor nepsites nauwelijks van de echte zijn te onderscheiden)?
Of websites waarbij allerlei derde partijen onzichtbaar kunnen meekijken?
Of PII die via e-mail wordt uitgewisseld met hooguit opportunistic encryption - op de verbindingen (dwz geen versleuteling op de servers zelf en waarbij MitM aanvallen niet gedetecteerd worden)?
Merkwaardig.
How I feel about AP: [X] ONGESCHIKT
De intentie van AP is goed, maar volgens mij snappen ze het niet helemaal. Je kan ontbrekende en zwakke versleuteling laakbaar en verwijtbaar noemen, maar 'in strijd met de privacywet' kun je het niet installeren (definieer: binnen afzienbare tijd) van een patch moeilijk noemen ...
https://www.ssllabs.com/ssltest/analyze.html
Geeft een mooi overzicht met aandachtspunten. Heb zelf SSL3 en RC4 eruit gegooid op m'n apache website naar aanleiding hiervan.
Volgens de Wet bescherming persoonsgegevens moeten verantwoordelijken "passende maatregelen" (laten) nemen om persoonsgegevens te beschermen, en daarbij ook rekening houden met de stand van de techniek.
Artikel 13
De verantwoordelijke legt passende technische en organisatorische maatregelen ten uitvoer om persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking. Deze maatregelen garanderen, rekening houdend met de stand van de techniek en de kosten van de tenuitvoerlegging, een passend beveiligingsniveau gelet op de risico's die de verwerking en de aard van te beschermen gegevens met zich meebrengen. De maatregelen zijn er mede op gericht onnodige verzameling en verdere verwerking van persoonsgegevens te voorkomen.
Het niet patchen / uitzetten SSLv2 kan vrij makelijk als het niet naleven van dit artikel worden beschouwd vind ik persoonlijk. Let wel WbP beperkt zich tot Persoonsgegevens.Niet alles wat je veilig over een lijntje wilt versturen is een persoonsgegeven.
https://www.ssllabs.com/ssltest/analyze.html
Geeft een mooi overzicht met aandachtspunten. Heb zelf SSL3 en RC4 eruit gegooid op m'n apache website naar aanleiding hiervan.
Echter, het venijn van DROWN is (als ik het goed begrijp) dat als je dezelfde private key (een bestandje meestal met extensie .key of .pem) ook voor andere doeleinden inzet (bijv. op je mailserver), en minstens 1 van die andere doeleinden (bij een cert met alternative names en/of een wildcart cert kunnen dat ook webservers zijn, denk aan test.example.com) nog wel SSLv2 ondersteunt, verbindingen met jouw weberver nog steeds gevaar lopen - zelfs als je op jouw webserver de laatste versie van OpenSSL gebruikt - of iets heel anders dan OpenSSL (MS IIS bijvoorbeeld).
Nb. het gaat bij DROWN niet persé om een hergebruikt certificaat, maar in de praktijk zal dat wel vaak het geval zijn. Ik hoop dat iedereen, bij elke certificaataanvraag, eerst altijd een nieuw (en uniek) sleutelpaar genereert (iets dat problemen kan geven als je public key pinning toepast).
Misschien is het een idee om eerst websiteeigenaren aan te pakken die helemaal geen https gebruiken bij het uitwisselen van PII (Personally Identifiable Information)?
Of websites waarvan het onduidelijk is met welke organisatie je daadwerkelijk te maken hebt, bijv. door het gebruik van waardeloze digitale certificaten (waardoor nepsites nauwelijks van de echte zijn te onderscheiden)?
Of websites waarbij allerlei derde partijen onzichtbaar kunnen meekijken?
Of PII die via e-mail wordt uitgewisseld met hooguit opportunistic encryption - op de verbindingen (dwz geen versleuteling op de servers zelf en waarbij MitM aanvallen niet gedetecteerd worden)?
Merkwaardig.
Nee is het niet; bij geen HTTPS weet je waar je aan toe bent, bij een SSLv2 verbinding weet je door de band genomen niet dat je zinloze encryptie gebruikt - vals gevoel van veiligheid.
download: https://chrome.google.com/webstore/detail/tracker-ssl/hgoabgkpjcbliklekfgepfdlmcnkjnao
Weet dat SSL versie 2.0 al sinds 2011 niet meer "kan/mag" worden gebruikt. Het is echt uit een vorige eeuw, mensen! Er is nu TLS. Maar het grootste gevaar schuilt in de inherent onveilige e-mail servers (zowel "by default" als "by design"). Te weinigen beseffen dit probleem nog ten volle. Zet SSL v.2/v.3 dus uit op je mailserver en je bent veilig voor de DROWn aanval.
Ben benieuwd hoeveel van de aanvankelijk 11 miljoen servers er nog zonder patch en dus kwetsbaar blijken te zijn?
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
