Mozilla waarschuwt SSL-uitgevers die overheden helpen
Organisaties die SSL-certificaten uitgeven waarmee overheidsinstanties of inlichtingendiensten versleuteld internetverkeer kunnen afluisteren zijn door Mozilla gewaarschuwd. In het geval de Firefox-ontwikkelaar dit misbruik ontdekt, kunnen alle SSL-certificaten die deze uitgever heeft uitgegeven in Firefox en andere Mozilla-producten als ongeldig worden beschouwd.
Certificate Authorities (CA) zijn partijen die SSL-certificaten uitgeven. Met een SSL-certificaat kan een website het verkeer tussen de bezoeker en server versleutelen. Daarnaast kunnen gebruikers via het certificaat controleren dat de website die ze bezoeken ook daadwerkelijk de website is die het beweert te zijn.
Diginotar
Firefox en andere Mozilla-producten bevatten een overzicht van legitieme CA's. Zodra de browser een SSL-certificaat tegenkomt, kan het controleren of die van een bekende en betrouwbare CA afkomstig is.
In het geval een CA is gecompromitteerd, zoals bij Diginotar, kan Mozilla de certificaten van deze CA uitschakelen of verwijderen. Gebruikers krijgen dan een waarschuwing als ze een website bezoeken die een SSL-certificaat van deze CA gebruikt.
Man-in-the-middle-aanval
Mozilla heeft nu versie 2.2 van de 'CA Certificate Policy' aangekondigd. In dit beleid staan verschillende regels waar een CA aan moet voldoen. De belangrijkste toevoeging in het beleid is echter voor CA's die één of meerdere certificaten, bijvoorbeeld op verzoek van een overheid, uitgeven.
Hiermee is het namelijk mogelijk om man-in-the-middle-aanvallen op internetgebruikers uit te voeren. Afhankelijk van de browser krijgen die dan geen waarschuwing en kan het versleutelde SSL-verkeer probleemloos worden ontsleuteld. Mozilla wil nu aan CA's het risico duidelijk maken als ze zich met dit soort praktijken bezighouden.
"Met deze beleidsupdate en CA Communicatie, herhalen we onze mening dat elke CA die aan Mozilla's programma is toegevoegd, uiteindelijk voor elk certificaat dat het uitgeeft verantwoordelijk is, zowel direct of via ondergeschikte CA's", zegt Mozilla's Kathleen Wilson.
Precies, de browsermakers, met Netscape voorop.
Mozilla kan dit soort eisen wel stellen en bijvoorbeeld een CA verwijderen als geconstateerd is
dat er een afluistercertificaat is uitgegeven, maar wat bereiken ze daar mee? Het enige wat er
dan gebeurt is dat mensen na het updaten van Firefox niet meer bij een serie sites kunnen komen,
en dan stappen ze over naar een andere browser ("mijn Firefox werkt niet meer") of ze concluderen
dat je auto-updates beter kunt uitschakelen.
Is de wereld dan zoveel beter af?
Een dergelijke actie heeft alleen zin als alle major browser bouwers hierin dezelfde stap nemen,
zodat het de gebruikers duidelijk is dat het probleem niet de browser is.
Tegen dommerikken die koste wat het kost een website willen bezoeken terwijl ze gewaarschuwt worden dat het niet veilig is kan niemand op. Het oude verhaal van wat doe je 'als je vriend in de put springt'. Minstens tot 10 tellen voordat je erachteraan gaat.
Precies, de browsermakers, met Netscape voorop.
Wat ik pas echt vreemd vond was dat ze later vele landen, inclusief "de staat der Nederlanden", ook de status van CA
gegeven hebben!
Die kwamen aan met allerlei plausibele argumenten in de richting van het opzetten van systemen zoals DigiD, maar
hebben niet aangetoond dat het nodig is dat ze daar zelf CA voor moeten zijn.
Gecombineerd met de makke in SSL dat je als domeinnaamhouder nergens kunt laten registreren door welke CA
de certificaten voor jouw domein worden uitgegeven, betekent dit dat "de staat der Nederlanden" voor iedere willekeurige
domeinnaam een certificaat kan uitgeven en man-in-the-middle kan spelen.
Dat lijkt me toch geen gewenste situatie.
Zo is het in elk geval een begin wanneer het algemeen gebruik wordt dat DNS-records van een certificaat voorzien worden, zodat je ook dat moet vervalsen om bij een "verkeerde server" terecht te komen.
Nu zijn er uiteraard nog andere manieren waarop je een man-in-the-middle attack kunt uitvoeren, maar het begin is er dan.
Uiteraard moet je proberen dit bij meerdere CA's te regelen, puur als extra moeite.
Neemt niet weg dat eigenlijk het enige wat nog een beetje te vertrouwen was dus eigenlijk niet zo betrouwbaar blijkt te zijn.
Zo is het in elk geval een begin wanneer het algemeen gebruik wordt dat DNS-records van een certificaat voorzien worden, zodat je ook dat moet vervalsen om bij een "verkeerde server" terecht te komen.
Nu zijn er uiteraard nog andere manieren waarop je een man-in-the-middle attack kunt uitvoeren, maar het begin is er dan.
Uiteraard moet je proberen dit bij meerdere CA's te regelen, puur als extra moeite.
Ongeacht de soort crypto (je hebt voor iedere site dan minimaal 2 certificaten nodig van 2 verschillende partijen), gaat dat de latency natuurlijk niet bepaald ten goede komen, enorme hoeveelheden extra data genereren en zeker bij verbindingen die al wat trager zijn, een "onwerkbare" verbinding opleveren. De enorme netwerkbelasting gecombineerd met de extra cpu-kracht voor de cliënt die nodig is voor iedere individuele DNS-query gaat je idee toch tot toekomst-muziek maken (stroomverbruik).
Om het voor elkaar te krijgen moet je bij de chef zijn, niet bij CA's. De chefs in deze zijn ICANN (baas DNS) en vooral IETF (baas Internet), samen gaan ze dan praten, en misschien komen ze dan met een nieuwe RFC.
Leuk voorbeeld van een RFC is deze: "A Standard for the Transmission of IP Datagrams on Avian Carriers" (in de volksmond een postduif, wel zo veilig!) https://www.ietf.org/rfc/rfc1149.txt
Zo is het in elk geval een begin wanneer het algemeen gebruik wordt dat DNS-records van een certificaat voorzien worden, zodat je ook dat moet vervalsen om bij een "verkeerde server" terecht te komen.
Nu zijn er uiteraard nog andere manieren waarop je een man-in-the-middle attack kunt uitvoeren, maar het begin is er dan.
Uiteraard moet je proberen dit bij meerdere CA's te regelen, puur als extra moeite.
Ongeacht de soort crypto (je hebt voor iedere site dan minimaal 2 certificaten nodig van 2 verschillende partijen), gaat dat de latency natuurlijk niet bepaald ten goede komen, enorme hoeveelheden extra data genereren en zeker bij verbindingen die al wat trager zijn, een "onwerkbare" verbinding opleveren. De enorme netwerkbelasting gecombineerd met de extra cpu-kracht voor de cliënt die nodig is voor iedere individuele DNS-query gaat je idee toch tot toekomst-muziek maken (stroomverbruik).
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
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?