mboost-dp1
Flickr - bongo vongo
HVIS de har fundet en "stor" fejl i TLS (SSL) så er det meget alvorligt, men hvis man læser hvad de rent faktisk selv har skrevet, så skriver de; "Our exploit abuses a vulnerability present in the SSL/TLS implementation of major Web browsers at the time of writing." - altså tyder det på at de 'bare' har fundet en fejl á la den null byte fejl der blev præsenteret på Black Hat '09 (og så er det langt fra lige så alvorligt).
Sårbarheden skulle gælde i alle versioner op til 1.0.Det viser jo bare at det ikke er for sjov at der til tider bliver lavet opdateringer af protokoller.
Hvis angrebet virker imod version 1.0 og ikke imod version 1.1, så tyder det jo på at det udnytter en svaghed der har været kendt da version 1.1 blev designet.
Det vil sige at man er blevet ved med at anvende en version med en kendt sårbarhed. Det er ganske enkelt sløseri.
Nyheden burde altså have fokuseret på at der sløses med at opdatere sårbar software, men desværre er det ingen nyhed.
Hvis stort set ingen browsere understøtter version 1.1 og 1.2, så siger det vel sig selv at store udbydere ikke skal opdatere deres websites? Især når man indtil nu har troet 1.0 var sikker nok.
Men mon ikke denne nyhed får browserproducenterne til at skynde sig lidt med 1.1+ understøttelse.
Men mon ikke denne nyhed får browserproducenterne til at skynde sig lidt med 1.1+ understøttelse.
Det ændrer intet på relevansen af mit udsagn. Jeg tog ikke stilling til hvem der har sløset, da jeg ikke ved det.fjols (5) skrev:Hvis stort set ingen browsere understøtter version 1.1 og 1.2, så siger det vel sig selv at store udbydere ikke skal opdatere deres websites?
Hvis det du siger er korrekt, så bærer browserproducenterne en stor del af ansvaret.
Når der bliver fundet en svaghed i en protokol og defineret en opdateret version, så bør producenterne af både klient og server software hurtigt implementere rettelsen.
Så længe rettelsen ikke er endeligt standardiseret bør den opdaterede version være disabled som default, men dog implementeret så man kan slå den til og teste den.
Hvis softwareproducenterne gør dette, så er der en chance for at når den endelige opdatering af standarden publiceres, så er der allerede support i softwaren, og det er kompatibelt mellem de forskellige implementationer. Dermed kan det slås til som default i den første release efter standarden er fuldendt.
På den måde kan den opdaterede version nå at være i brug for de fleste forbindelser før angreb bliver almindelige.
Hvornår man så skal disable support for ældre versioner er et lidt mere problematisk spørgsmål. Hvis ikke svagheder i den gamle version tillader downgrade attacks er det ikke nødvendigt at fjerne supporten. Men hvis der kan gennemføres et downgrade attack er man nødt til at disable den gamle version for at få en sikker forbindelse med den nye version. I den situation kan man ikke vente indtil alle har support for den nye version. Når man når op omkring 70% med support for den nye version mener jeg man bør disable den gamle version som default så de resterende kan få fingeren ud.
Men hvis sløseriet faktisk er så slemt at det mest udbredte software ikke supportere den opdaterede version efter 5 år, så står det skidt til.
Både producenter af klientsoftware og serversoftware bærer et ansvar. De kan ikke forsvare sig med at de ikke har noget software på den anden side at teste imod. Nu ved jeg selvfølgelig ikke hvordan supporten er på de udbredte servere, så dette udsagn er blot en hypotetisk konstatering.
Hvem har troet det? Dem som har designet version 1.1 og 1.2 og som åbenbart har præsteret at lukke hullet har vel ikke troet at version 1.0 var sikker nok.fjols (5) skrev:Især når man indtil nu har troet 1.0 var sikker nok.
kasperd (11) skrev:Hvem har troet det? Dem som har designet version 1.1 og 1.2 og som åbenbart har præsteret at lukke hullet har vel ikke troet at version 1.0 var sikker nok.fjols (5) skrev:Især når man indtil nu har troet 1.0 var sikker nok.
Hvem siger at version 1.1 og 1.2 blev udviklet med henblik på ekstra sikkerhed og ikke performence ?..
Hvad angår opdatering af browsere, så spekulerer jeg på hvor mange browsere der stadigvæk understøtter MD5 i certifikater.
Godt nok er der mig bekendt ikke længere nogen CA der udsteder MD5 certifikater. Men det er set med mine øjne en workaround, browsere burde afvise alle certifikater med MD5 signaturer (og det burde have afvist dem siden udgangen af 2007). Men jeg gætter på at der sikkert stadig findes mange browsere som ville acceptere at MD5 baseret certifikat hvis man viste den et.
Godt nok er der mig bekendt ikke længere nogen CA der udsteder MD5 certifikater. Men det er set med mine øjne en workaround, browsere burde afvise alle certifikater med MD5 signaturer (og det burde have afvist dem siden udgangen af 2007). Men jeg gætter på at der sikkert stadig findes mange browsere som ville acceptere at MD5 baseret certifikat hvis man viste den et.
Ikke nok med at han beskrev flere forskellige metoder til at lave mitm-angreb end jeg kunne holde tal på, han nævnte også to vidt forskellige svagheder som hver især kunne udnyttes til at få vilkårlig kode kørt på klienten. Den video var bestemt værd at se.CableCat (10) skrev:Så se denne video
Ifølge nyheden har de lukket hullet ved opdateringen fra 1.0 til 1.1. At de har lukket hullet betyder at der er ret stor sandsynlighed for at de har haft kendskab til det.bobolobo (12) skrev:Hvem siger at version 1.1 og 1.2 blev udviklet med henblik på ekstra sikkerhed og ikke performence ?..
kasperd (4) skrev:Det viser jo bare at det ikke er for sjov at der til tider bliver lavet opdateringer af protokoller.
Hvis angrebet virker imod version 1.0 og ikke imod version 1.1, så tyder det jo på at det udnytter en svaghed der har været kendt da version 1.1 blev designet.
Det vil sige at man er blevet ved med at anvende en version med en kendt sårbarhed. Det er ganske enkelt sløseri.
Nyheden burde altså have fokuseret på at der sløses med at opdatere sårbar software, men desværre er det ingen nyhed.
Det er ikke unormalt at man helt omskriver kode, eller vælger at gå helt nye veje.
Men brugte f.eks. en MD5 hash (med fejl) i 1.0 og i 1.1 gik man over til SHA. Ved sådan et skift ville ingen kigge den gamle kode igennem for fejl, men bare slette den og skrive SHA koden i stedet.
Så det er lang fra sikker at TLS udviklerne har været bevist om en fejl.
The stealthy piece of JavaScript works with a network sniffer to decrypt encrypted cookies a targeted website uses
bliver til :
Hackere bryder SSL-kryptering
Hvad har endnu en javascript-exploit at gøre med at 'bryde kryptering' ?
De har ikke 'brudt' en disse, de har bevist, endnu en gang, at det er
helt afgørende HVORDAN kryptering implementrres .
#16
Nej Robert, du har 100% misforstået det hele.
Sådan som jeg har forstået dette exploit, så fungerer det på denne måde.
Først, så bliver der lavet et angreb på en ikke SSL baseret http request.
Der injecter vi et javascript, der hvert 5 minut sender en get request til https://gmail.com med en known plaintext.
Det javascript passer fra nu af sig selv.
Så bliver der fyret op for en sniffer. Nu kan vi fordi at vi har kontrol over noget plaintext der bliver krypteret, med samme random symmetriske nøgle som passwordet til gmail, og fordi at der er dårlig shuffling, matematisk sjusse os tættere og tættere på den tilfældige symmetriske nøgle.
Der er ikke noget POC ude endnu, men det er sådan jeg forstår det- det er ihvertfald tættere på end Roberts.
tldr;
Javascript kommer kun ind i billedet for at få kontrol til at injecte noget plaintext vi selv styrer i den establishede ssl session.
Nej Robert, du har 100% misforstået det hele.
Sådan som jeg har forstået dette exploit, så fungerer det på denne måde.
Først, så bliver der lavet et angreb på en ikke SSL baseret http request.
Der injecter vi et javascript, der hvert 5 minut sender en get request til https://gmail.com med en known plaintext.
Det javascript passer fra nu af sig selv.
Så bliver der fyret op for en sniffer. Nu kan vi fordi at vi har kontrol over noget plaintext der bliver krypteret, med samme random symmetriske nøgle som passwordet til gmail, og fordi at der er dårlig shuffling, matematisk sjusse os tættere og tættere på den tilfældige symmetriske nøgle.
Der er ikke noget POC ude endnu, men det er sådan jeg forstår det- det er ihvertfald tættere på end Roberts.
tldr;
Javascript kommer kun ind i billedet for at få kontrol til at injecte noget plaintext vi selv styrer i den establishede ssl session.
^ sådan som jeg har forstået det (efter lidt søgning) så er det egentligt 'bare' en PoC af et koncept fra '06.
Det går ud på at ved at injecte js i et ukrypteret stream kan man lave en masse "custom" krypteret GET's hvor man tvinger ét tegn fra cookie'en og ellers en masse known-plantext i én "blok". Derfor skal man altså kun cracke ét tegn af gangen (når tegnet er cracket, man man tvinge cookie'en til at blive flyttet endnu et tegn ind i blokken).
Håber det giver mening - det er lidt svært at forklare :p
Det går ud på at ved at injecte js i et ukrypteret stream kan man lave en masse "custom" krypteret GET's hvor man tvinger ét tegn fra cookie'en og ellers en masse known-plantext i én "blok". Derfor skal man altså kun cracke ét tegn af gangen (når tegnet er cracket, man man tvinge cookie'en til at blive flyttet endnu et tegn ind i blokken).
Håber det giver mening - det er lidt svært at forklare :p
Det er rart at nogen er så venlige at arbejde videre på at finde dokumentation for påstande jeg sådan tillader mig at fremsætte uden at undersøge dem. Jeg går ud fra det er denne side du har kigget på http://www.theregister.co.uk/2011/09/21/google_chr... der skrives om et angreb der blev beskrevet i 2004 og igen i 2006.Nicolai (18) skrev:sådan som jeg har forstået det (efter lidt søgning) så er det egentligt 'bare' en PoC af et koncept fra '06.
Der udnyttedes en svaghed ved at fortsætte en CBC kryptering uden at starte igen med nyt IV. Det er en fejl jeg også selv har begået, jeg begik den i en beskrivelse af en metode til disk kryptering, som jeg udformede i 2003. På det tidspunkt var jeg dog klar over at jeg manglede en måde at analysere sikkerheden. I 2005 da jeg havde en metode til at analysere sikkerheden fandt jeg selv ud af at jeg havde begået den fejl og fandt en måde at udbedre den. Det er først i dag at jeg er blevet klar over at nøjagtigt samme fejl findes i en meget udbredt version af SSL.
Din forklaring gav mening for mig, men jeg kunne dog ikke finde den i nogen af de links jeg kiggede på.Nicolai (18) skrev:Håber det giver mening - det er lidt svært at forklare
Metoden du beskriver kunne sikkert sagtens kombineres med metoden fra 2006 artiklen, men jeg ved ikke om det er det de har gjort.
Hvor fandt du frem til at de skulle have anvendt den pågældende metode til at bryde det én byte ad gangen?
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund