"SSL-certificaten zijn dood, tijd om ze te begraven"
SSL is een goed idee, maar het werk niet, de hoogste tijd dus om dit "kadaver" uit z'n lijden te verlossen, dat zegt beveiligingsonderzoeker Amitai Aviram. Hij reageert naar aanleiding van de onlangs gepresenteerde aanval, waardoor het mogelijk is om met MD5 gegenereerde SSL-certificaten te vervalsen. Het probleem met SSL is dat het controleren van iemand z'n identiteit niet veel voorstelt. Voorheen duurde het vrij lang voordat bedrijven een certificaat kregen, maar tijden zijn veranderd.
"Vandaag de dag is het lastig om te bewijzen wie "je" bent. Bedrijven hebben voor verschillende doelen talloze websites, en het is lastig om ze op dezelfde logica een certificaat te ontzeggen. Maar het wordt erger: SSL-certificaten zijn zo misbruikt, dat het gebruikers niets meer kan schelen." Aviram merkt op dat gebruikers de foutmeldingen met certificaten massaal negeren.
"SSL-certificaten zijn al lang stuk, en niet vanwege een slimme aanval. Het feit dat er een effectieve crypto-aanval is, helpt misschien bij het begraven van dit kadaver en zorgt ervoor dat er een andere oplossing verschijnt."
Reacties (18)
05-01-2009, 17:40 door
SirDice
"SSL-certificaten zijn al lang stuk, en niet vanwege een slimme aanval. Het feit dat er een effectieve crypto-aanval is, helpt misschien bij het begraven van dit kadaver en zorgt ervoor dat er een andere oplossing verschijnt."
Zoals? Welk alternatief is er? SSL geheel afschrijven en maar wachten op een oplossing werkt natuurlijk niet. Wat moet je in de tussentijd dan?
05-01-2009, 17:53 door
Martijn Brinkers
Ik vind dat weer zo'n domme opmerking. Er is helemaal niets mis met SSL er is alleen wat mis met de manier waarop commerciele partijen certificaten verkopen. Je moet het ongeveer zo zien, stel dat Frankrijk (een willekeurige keus) ineens paspoorten uitgeeft zonder de identiteit van de ontvanger te controleren, moeten we dan ineens alle paspoorten afschaffen? Nee, we moeten alleen dan de paspoorten van Franse burgers niet meer vertrouwen.
Welke alternatieve methode voor SSL je ook verzint je zal dezelfde problemen moeten oplossen. Dit probleem is geen technisch probleem maar een beleidsprobleem waar geen technische oplossingen voor zijn.
Welke alternatieve methode voor SSL je ook verzint je zal dezelfde problemen moeten oplossen. Dit probleem is geen technisch probleem maar een beleidsprobleem waar geen technische oplossingen voor zijn.
05-01-2009, 18:16 door
sjonniev
Ik hoef niks meer te zeggen, Martin heeft het al gezegd.
05-01-2009, 18:31 door
[Account Verwijderd]
[Verwijderd]
05-01-2009, 20:36 door
[Account Verwijderd]
[Verwijderd]
05-01-2009, 21:35 door
wimbo
Met Martijn.
Voor de grote certificaat-schuivers is het relatief eenvoudig om bestaande klanten te benaderen met een aanbod om (gratis) het huidige certificaat te vervangen voor een nieuw met sterkere algoritmen e.d.
Op die manier zorgen ze zelf ook wel dat ze bij blijven bij de laatste standaarden. Doen ze dat niet, dan kost ze dat geld/inspanning om klanten op te laten waarderen.
Laten we wel wezen; voor 600-1300 euro per commercieel (top) certificaat mag je ook wel wat verwachten. Daarnaast moet er ook iets verzonnen worden om gebruikers op wildcard certificaten te wijzen.
En voor landen (lees: CA's) die het niet goed doen; intrekken en meteen uit alle browsers/OS'en verwijderen (of op non-actief zetten) totdat ze bewezen hebben het beter te doen. Vertrouwen is nml iets waar je zorgvuldig mee overweg moet gaan. Is dat vertrouwen geschaad, dan kost het ook in real life een hoop tijd (en geld) om dat te herstellen. Waarom niet in de CA wereld?
Voor de grote certificaat-schuivers is het relatief eenvoudig om bestaande klanten te benaderen met een aanbod om (gratis) het huidige certificaat te vervangen voor een nieuw met sterkere algoritmen e.d.
Op die manier zorgen ze zelf ook wel dat ze bij blijven bij de laatste standaarden. Doen ze dat niet, dan kost ze dat geld/inspanning om klanten op te laten waarderen.
Laten we wel wezen; voor 600-1300 euro per commercieel (top) certificaat mag je ook wel wat verwachten. Daarnaast moet er ook iets verzonnen worden om gebruikers op wildcard certificaten te wijzen.
En voor landen (lees: CA's) die het niet goed doen; intrekken en meteen uit alle browsers/OS'en verwijderen (of op non-actief zetten) totdat ze bewezen hebben het beter te doen. Vertrouwen is nml iets waar je zorgvuldig mee overweg moet gaan. Is dat vertrouwen geschaad, dan kost het ook in real life een hoop tijd (en geld) om dat te herstellen. Waarom niet in de CA wereld?
06-01-2009, 00:05 door
[Account Verwijderd]
[Verwijderd]
06-01-2009, 07:24 door
_Peterr
Gelijk heeft hij. Begraven en niet meer gebruiken. Net als auto rijden, fietsen en vliegen. Ze zijn gevaarlijk en moeten niet meer gebruikt worden.
Maar is er een alternatief dat wel 100% veilig is? Nee, en die komt er ook niet. Niet nu, niet straks en ook niet over 100 jaar.
Maar is er een alternatief dat wel 100% veilig is? Nee, en die komt er ook niet. Niet nu, niet straks en ook niet over 100 jaar.
Door wimboEn voor landen (lees: CA's) die het niet goed doen; intrekken en meteen uit alle browsers/OS'en verwijderen (of op non-actief zetten) totdat ze bewezen hebben het beter te doen. Vertrouwen is nml iets waar je zorgvuldig mee overweg moet gaan. Is dat vertrouwen geschaad, dan kost het ook in real life een hoop tijd (en geld) om dat te herstellen. Waarom niet in de CA wereld?
Juist omdat het veel geld kost om het vertrouwen te herstellen zullen browser leveranciers geen CA's verwijderen. Wie bepaalt of een CA niet meer te vertrouwen is? Als de browser leverancier dat doet, krijgt hij een aanklacht van de CA over zich heen wegens smaad of iets dergelijks.
Met paspoorten wordt per land besloten of ze het paspoort van een ander land accepteren. Of dat personen uit een dergelijk land een visa nodig hebben. Die soevereiniteit hebben browser fabrikanten niet. Die hebben het liefst zo veel mogelijk CA's en iedere CA wil in zo veel mogelijk browsers.
Peter
06-01-2009, 11:31 door
Jan-Hein
Het MD5 incident illustreert niet dat SSL "kapot" is, maar dat een global PKI in de praktijk niet te managen is.
Voor online gebruik is er sinds enige tijd een alternatief voor PKI's: de LKI's.
De LKI is ontworpen met globaal cooperatief onderhoud als leidend doel, en maakt een snelle vloeiende overgang van hash en cypher implementaties mogelijk zonder krankzinnig veel menselijk ingrijpen met de bijbehorende problemen en kosten.
Een PKI kan nog steeds nuttig zijn voor kleine private configuraties en voor toepassingen waarbij online verificaties technisch niet haalbaar zijn, maar SSL hoort niet bij die toepassingen.
Voor online gebruik is er sinds enige tijd een alternatief voor PKI's: de LKI's.
De LKI is ontworpen met globaal cooperatief onderhoud als leidend doel, en maakt een snelle vloeiende overgang van hash en cypher implementaties mogelijk zonder krankzinnig veel menselijk ingrijpen met de bijbehorende problemen en kosten.
Een PKI kan nog steeds nuttig zijn voor kleine private configuraties en voor toepassingen waarbij online verificaties technisch niet haalbaar zijn, maar SSL hoort niet bij die toepassingen.
06-01-2009, 14:04 door
Kukel
Met paspoorten wordt per land besloten of ze het paspoort van een ander land accepteren. Of dat personen uit een dergelijk land een visa nodig hebben. Die soevereiniteit hebben browser fabrikanten niet. Die hebben het liefst zo veel mogelijk CA's en iedere CA wil in zo veel mogelijk browsers.
Dit zelfde kan je bereiken met de perspectives plugin voor Firefox. Wie neemt het initiatief om voor Nederland een 'notary' op te zetten? Liefst meer dan één natuurlijk om te voorkomen dat die ene partij weer de klos is als er iets mis gaat.
LKI.... leuke afkorting, maar na 20 minuten in google heb ik nog geen documenten gevonden.... een linkje a.j.b.?
Wat betreft de overgang van Ciphers is het bij PKI ook niet echt moeilijk. Certificaten zijn over het algemeen 1-2 jaar geldig. In die twee jaar heb je een vloeiende overgang zonder krankzinnig veel menselijk ingrijpen en/of kosten.... Ja, nu het 'plotseling' urgent wordt (hoewel, urgent....) is het idd in totaal een flinke hoeveelheid werk maar zeeeeeer verspreid en met een zwaartepunt bij de 'foute' ca's. Met deze laatste heb ik geen medelijden.
Door Kukel
Dit zelfde kan je bereiken met de perspectives plugin voor Firefox. Wie neemt het initiatief om voor Nederland een 'notary' op te zetten? Liefst meer dan één natuurlijk om te voorkomen dat die ene partij weer de klos is als er iets mis gaat.
Met paspoorten wordt per land besloten of ze het paspoort van een ander land accepteren. Of dat personen uit een dergelijk land een visa nodig hebben. Die soevereiniteit hebben browser fabrikanten niet. Die hebben het liefst zo veel mogelijk CA's en iedere CA wil in zo veel mogelijk browsers.
Dit zelfde kan je bereiken met de perspectives plugin voor Firefox. Wie neemt het initiatief om voor Nederland een 'notary' op te zetten? Liefst meer dan één natuurlijk om te voorkomen dat die ene partij weer de klos is als er iets mis gaat.
Dat werkt dus alleen in Firefox en niet in andere browsers. En dan hebben we het al helemaal niet over al die andere applicaties waarbij gebruik gemaakt wordt van SSL-certificaten voor de controle van identiteit.
We hebben trouwens in Nederland een club die zoiets (mag) doen. Ik kom niet zo op de naam, maar ik geloof wel dat ze iets met "notaries" te maken hebben. 'Notary" is trouwens een (in Nederland) beschermde beroepsgroep. De bescherming van notarissen geldt namelijk ook voor de niet-Nederlandse benamingen daarvoor.
Als notary^Wvertrouwenspersoon voor CAcert en Thawte WOT ben ik daar al eens over op de vingers getikt toen ik die term gebruikte in bijzijn van een rechter.
Peter
06-01-2009, 17:20 door
Kahits
Door Jan-HeinVoor online gebruik is er sinds enige tijd een alternatief voor PKI's: de LKI's.
Verklaar je nader svp.
06-01-2009, 21:41 door
Jan-Hein
@Kahits; Verklaar je nader svp:
Een PKI heeft 4 cryptografische basistechnieken nodig:
- randomizer
- hash
- cypher
- public key encryption
Een LKI heeft geen public key encryption nodig, omdat het zich beperkt tot directe interacties: het is niet nodig om bij on-line transacties voor het creeren van een relatie afhankelijk te zijn van informatie uit een ver verleden waarin een unieke eenheid in twee unieke delen werd opgesplitst.
Omdat een LKI zich beperkt tot randomizer, hash, en cypher, kan het directe terugkoppeling van afwijkend gedrag in de infrastructuur realiseren.
Een PKI is daar om begrijpelijke redenen significant trager in.
Ik geef toe dat de huidige implementaties van PKI's bedroevend zijn, dus dat er ook langs die weg nog best veel verbetering mogelijk is, maar ik heb zelf mijn hoop gevestigd op LKI's, en dan bij voorkeur een enkele.
Ik zeg er ook direct bij dat PKI's gebieden dekken die ik LKI's nog niet zie doen, dus dat ik PKI's zelf ook gebruik in bepaalde ontwerpen.
Een voorbeeld van een LKI wordt beschreven in http://home.tiscali.nl/jhvdburg/gcim-proj.pdf.
Een PKI heeft 4 cryptografische basistechnieken nodig:
- randomizer
- hash
- cypher
- public key encryption
Een LKI heeft geen public key encryption nodig, omdat het zich beperkt tot directe interacties: het is niet nodig om bij on-line transacties voor het creeren van een relatie afhankelijk te zijn van informatie uit een ver verleden waarin een unieke eenheid in twee unieke delen werd opgesplitst.
Omdat een LKI zich beperkt tot randomizer, hash, en cypher, kan het directe terugkoppeling van afwijkend gedrag in de infrastructuur realiseren.
Een PKI is daar om begrijpelijke redenen significant trager in.
Ik geef toe dat de huidige implementaties van PKI's bedroevend zijn, dus dat er ook langs die weg nog best veel verbetering mogelijk is, maar ik heb zelf mijn hoop gevestigd op LKI's, en dan bij voorkeur een enkele.
Ik zeg er ook direct bij dat PKI's gebieden dekken die ik LKI's nog niet zie doen, dus dat ik PKI's zelf ook gebruik in bepaalde ontwerpen.
Een voorbeeld van een LKI wordt beschreven in http://home.tiscali.nl/jhvdburg/gcim-proj.pdf.
LKI, zoals in de Mifare Classic Jan-Hein?
Je hebt die asymmetrische crypto nodig om je symmetrische sleutel veilig te kunnen versturen. En tussen een website en jezelf kun je die symmetrische sleutel niet vooraf delen. Daar is PKI juist voor!
Je hebt die asymmetrische crypto nodig om je symmetrische sleutel veilig te kunnen versturen. En tussen een website en jezelf kun je die symmetrische sleutel niet vooraf delen. Daar is PKI juist voor!
07-01-2009, 14:26 door
Jan-Hein
"LKI, zoals in de Mifare Classic Jan-Hein?
Je hebt die asymmetrische crypto nodig om je symmetrische sleutel veilig te kunnen versturen. En tussen een website en jezelf kun je die symmetrische sleutel niet vooraf delen. Daar is PKI juist voor!"
Dat was vroeger nodig, en ik heb het zelf vroeger ook in de nodige ontwerpen opgenomen.
In een LidoKey infrastructuur is public key encryptie werkelijk overbodig (kijk maar naar het ontwerp), en is er dus ook geen PKI nodig.
Je hebt die asymmetrische crypto nodig om je symmetrische sleutel veilig te kunnen versturen. En tussen een website en jezelf kun je die symmetrische sleutel niet vooraf delen. Daar is PKI juist voor!"
Dat was vroeger nodig, en ik heb het zelf vroeger ook in de nodige ontwerpen opgenomen.
In een LidoKey infrastructuur is public key encryptie werkelijk overbodig (kijk maar naar het ontwerp), en is er dus ook geen PKI nodig.
Reageren
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.
