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.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.