mboost-dp1
PBS A/S
Ole (1) skrev:Betyder det så at man ikke kan benytte NEMID på Windows RT?
Mig bekendt er der ingen klassisk desktop på denne udgave.
Du har helt ret i at NemID ikke virker på en WinRT tablet. Der er også et "desktop" i WinRT men du kan ikke installere programmer uden for Metro så selv om du har en desktop IE i WinRT så kan du ikke installere Java og er derfor lige vidt :P
Glæder mig til et plugin frit Internet uden flash, silverlight og Java! Det bliver hurtigere og mere sikkert. Og det er da skandale at Nemid har valgt at bruge Java i deres løsning. Det er forældet teknologi i en browser og kan ikke bruges i de fleste smartphones og tablets.
Typisk dansk stupiditet fra Nets.
De har været klar over at det kunne være et problem med java i lang tid, og alligevel vælger man at fortsætte med et forældet og usikkert plugin.
Hvorfor har de ikke droppet java endnu ?
Simpelt hen for åndsvagt. De tror da vel ikke Microsoft tilretter Windows efter dem ?
De har været klar over at det kunne være et problem med java i lang tid, og alligevel vælger man at fortsætte med et forældet og usikkert plugin.
Hvorfor har de ikke droppet java endnu ?
Simpelt hen for åndsvagt. De tror da vel ikke Microsoft tilretter Windows efter dem ?
#5 "...forældet og usikkert plugin..."
Hvad er der da galt med Java plugins, og hvad mener du er problemet med det ? Mener du at Java i sig selv er forældet, eller hvordan?
Det at Microsoft udelukker plugins fra deres 'Metro Browser', er egentligt fint - så harmonisere man hjemmeside oplevelsen for brugere mm. i Metro. ( Hvis nogen overhovedet vil bruge det ) Men hvis man kan 'linke' til en desktop udgave af browseren fra en hjemmeside vil det da virke fornuftigt.
WinXP er stadigt den bedste windows til dato :D
Hvad er der da galt med Java plugins, og hvad mener du er problemet med det ? Mener du at Java i sig selv er forældet, eller hvordan?
Det at Microsoft udelukker plugins fra deres 'Metro Browser', er egentligt fint - så harmonisere man hjemmeside oplevelsen for brugere mm. i Metro. ( Hvis nogen overhovedet vil bruge det ) Men hvis man kan 'linke' til en desktop udgave af browseren fra en hjemmeside vil det da virke fornuftigt.
WinXP er stadigt den bedste windows til dato :D
#5 Så du mener altså at det er NemID's skyld at Microsoft vælger ikke at køre plugins i deres metro udgave af IE?
Hvaa... hvor meget benzin har du sniffet her til morgen, alfred?
Hvaa... hvor meget benzin har du sniffet her til morgen, alfred?
Nok nærmere at det er NemID's skyld at man ikke kan bruge det i IE10 Metro eftersom de har valgt at bruge Java. Det er vel også korrekt.HerrMansen (7) skrev:#5 Så du mener altså at det er NemID's skyld at Microsoft vælger ikke at køre plugins i deres metro udgave af IE?
Hvaa... hvor meget benzin har du sniffet her til morgen, alfred?
Lyder som om de bare overlader problemet til tjenesterne, der bruger NemID, i stedet for selv faktisk at gøre noget.
#9
Nej, fordi en HTTP header kan ikke indsættes af en java applet......
Tjenesteudbydere indsætter et <applet> tag der først bliver loadet efter at http headerne er sendt, så det er kun tjeneste udbyderne der kan gøre det, og det er en simpel change.
Nej, fordi en HTTP header kan ikke indsættes af en java applet......
Tjenesteudbydere indsætter et <applet> tag der først bliver loadet efter at http headerne er sendt, så det er kun tjeneste udbyderne der kan gøre det, og det er en simpel change.
De har monopol hvilket betyder at de ikke har nogen risiko for at miste kunder. Havde der været fri konkurrence på markedet ville situationen have set meget anderledes ud. Alt hvad vi kan med NemID i dag kunne lade sig gøre uden Java før det blev besluttet at Danid skulle have monopol.Dali_lb (5) skrev:Hvorfor har de ikke droppet java endnu ?
#11
Hvad med problemet at i Java kan man lave pinned SSL connections, hvorimod med normal SSL skal man stole på alle CA´s , og set i lyset af indbrudene af comodohacker ved 3 CA´s , og at en af CA´erne er kinesisk kan jeg godt forstå hvorfor de vil have java til at stå for SSLen hvor de selv kan specificere CA etc.
Hvad vil din tekniske løsning være på det problem?
Hvad med problemet at i Java kan man lave pinned SSL connections, hvorimod med normal SSL skal man stole på alle CA´s , og set i lyset af indbrudene af comodohacker ved 3 CA´s , og at en af CA´erne er kinesisk kan jeg godt forstå hvorfor de vil have java til at stå for SSLen hvor de selv kan specificere CA etc.
Hvad vil din tekniske løsning være på det problem?
Ok. Så når Apple ikke understøtter flash er Apple nogle idioter, men når Microsoft ikke understøtter java er alle andre nogle idioter fordi de ikke fluks tilpasser sig Microsoft?
Der er nu ikke noget som dobbeltmoral. :)
Der er nu ikke noget som dobbeltmoral. :)
#8: Vi kan sagtens blive enige om at det er NemID's problem og at de skal arbejde sig udenom det - men det kan da ikke være dem der skal tage skylden for at en browser udvikler vælger at ændre på deres regler.
Du har ret i at det er et reelt problem. Danid har intet gjort for at løse det problem. Tværtimod har de gjort problemet lidt større end det var tidligere.Mamad (moveax1ret) (12) skrev:hvorimod med normal SSL skal man stole på alle CA´s
Før i tiden brugte man et enkelt https domæne til hele sin kommunikation. Et certifikat fra en kompromitteret CA ville kunne narre de fleste brugere. Men en lille andel af de allermest opmærksomme brugere ville opdage angrebet. Altså ville et systematisk angreb af den pågældende type meget hurtigt blive opdaget.
I dag er man afhængig af 2-3 forskellige SSL certifikater plus et kodecertifikat. Jeg har ikke set nogen browser hvor man nemt kan se certifikatkæden for alle certifikaterne før man logger ind. Et angreb imod det certifikat som er sværest at inspicere i browseren vil sandsynligvis kunne foregå ubemærket i længere tid end man kunne før i tiden.
Der er intet en Java applet kan gøre for at forhindre problemet af den simple grund at problemet er til stede allerede før denne Java applet bliver downloadet. Et angreb på SSL kan bruges til at erstatte den autentiske applet med en anden applet.
Du vil måske prøve at argumentere med at den autentisk applet har en signatur, men det hjælper intet. Har man godkendt den autentiske applet vil man ikke længere blive præsenteret for signaturen når man kører den autentiske applet i fremtiden. En anden applet behøver ikke have nogen signatur, så vil brugeren heller ikke blive præsenteret for nogen signatur når den forfalskede applet køres.
Det betyder selvfølgelig at den forfalskede applet ikke opnår de rettigheder som den autentiske applet er blevet tildelt. Men det er underordnet. Et angreb imod Nemid har ikke brug for de rettigheder. Den eneste grund til at den autentiske applet har de rettigheder er for at den kan køre Danids spyware på brugernes computere. Der er intet af den legitime funktionalitet i NemID som kræver de ekstra rettigheder.
Den forfalskede applet kunne for den sags skyld være lavet i et andet sprog. Jeg er ganske overbevist om at man kunne lave en NemID lookalike i flash. Man kunne sandsynligvis gøre det med ren html og javascript, jeg tror et baggrundsbillede, en form, lidt css og javascript kunne lave en lookalike.
Alt dette betyder at SSL er den eneste garanti du har for en autentisk applet.
Browsere kan vise nationaliteten i URL baren. Jeg ved ikke hvad det præcise krav er for at det sker, men jeg formoder det kræver at hele kæden har samme nationalitet. Det kræver at det autentiske certifikat er sat op så brugerne vil se at det er dansk, dernæst skal man lære brugerne at lade være med at logge ind, hvis ikke nationaliteten af certifikatet er verificeret.Mamad (moveax1ret) (12) skrev:en af CA´erne er kinesisk
Certifikater beskyttet med DNSSEC er det bedste bud. En beskyttelse imod en kompromitteret CA er umulig at opnå med browsere som vi har dem i dag. Danid ville være nødt til at arbejde sammen med browserproducenterne for at drive udviklingen på det punkt fremad.Mamad (moveax1ret) (12) skrev:Hvad vil din tekniske løsning være på det problem?
Det ville kræve åbenhed og samarbejdsvilje, begge dele noget som Danid tilsyneladende ikke har.
Alt hvad Danid har gjort hidtil er at levere en løsning der er mindre sikker end det den skulle erstatte, stukket fingrene i ørerne hver gang der har været konstruktiv kritik af deres løsning, og prøvet at gage æren for den indsats andre har gjort for sikkerheden før NemID blev lanceret.
kasperd (15) skrev:Det betyder selvfølgelig at den forfalskede applet ikke opnår de rettigheder som den autentiske applet er blevet tildelt. Men det er underordnet. Et angreb imod Nemid har ikke brug for de rettigheder. Den eneste grund til at den autentiske applet har de rettigheder er for at den kan køre Danids spyware på brugernes computere.
Og på grund af det, vil sådan et angreb kunne detekteres, da appletten vil køre på en anden computer, pga. det "spyware" der er i appletten vil det kunne ses ved danIDS interne systemer, og en bankoverførsel vil kunne trækkes tilbage.
kasperd (15) skrev:Certifikater beskyttet med DNSSEC er det bedste bud.
Vil du hellere give monopol til dk hostmaster til at sikre identiteten af den du kommunikerer med? Ved CA systemet idag kan browser producenterne i det mindre annulere en hel CA som er blevet kompromiteret, og alle websider kan så købe et nyt certifikat.
Jeg ville ikke bryde mig om at dk hostmaster var single point of failure.
Det må da være DanID's ansvar at de har valgt et programmeringssprog og platform som det er åbenlyst vil give problemer med portabiliteten. Java-plugins blev anvendt omkring årtusindskiftet til browser plugins, men har aldrig fået fodfæste som andet end et niche-plugin.
iPhone udkom i 2007 og havde hverken Java eller Flash. Skfiten var tydelig på væggen, og alligevel spenderede man millioner på at udvikle det i Java frem for med mere tidssvarende og portable HTML5-teknologier.
Epic fail i min verden.
iPhone udkom i 2007 og havde hverken Java eller Flash. Skfiten var tydelig på væggen, og alligevel spenderede man millioner på at udvikle det i Java frem for med mere tidssvarende og portable HTML5-teknologier.
Epic fail i min verden.
Appletten vil ingenting se, hvis ikke den bliver kørt. Et angreb som det jeg beskrev ville aldrig køre den autentiske applet på brugerens computer.Mamad (moveax1ret) (16) skrev:Og på grund af det, vil sådan et angreb kunne detekteres, da appletten vil køre på en anden computer, pga. det "spyware" der er i appletten vil det kunne ses ved danIDS interne systemer, og en bankoverførsel vil kunne trækkes tilbage.
Vil man udnytte angrebet til at kommunikere med et site der bruger autentifikation vha. NemID er man nok nødt til enten at køre appletten eller simulere den. Men den vil i så fald køre under omgivelser kontrolleret af den der angriber systemet. Den vil blive fordret med lige præcist de oplysninger den forventer at se.
Man kunne gå så vidt som at køre den på en faktisk fysisk computer hvor man indtaster oplysningerne på tastaturet manuelt. Det er blevet demonstreret. Så er det blot et spørgsmål at tage det som udgangspunkt og automatisere så meget som muligt.
Om det er nemmest at simulere appletten eller om det er nemmest at køre den autentiske applet i passende omgivelser ved jeg ikke. Men begge dele er muligt for en part som vil gøre en seriøs indsats for at angribe systemet.
Det har de allerede. Det er dk-hostmaster der bestemmer, hvem der har retten til et givet .dk domæne.Mamad (moveax1ret) (17) skrev:Vil du hellere give monopol til dk hostmaster til at sikre identiteten af den du kommunikerer med?
Hvis dk-hostmaster beslutter sig for at tage et domæne fra dig og tildele til en anden part, så kan den anden part helt legitimt gå til en vilkårlig CA og få tildelt et certifikat. Man behøver ikke kompromittere nogen, og certifikatet vil være ægte.
Stoler du ikke på dk-hostmaster, så skal du ikke være afhængig af et dk domæne.
Der kan laves en teknisk løsning som giver bedre sikkerhed. Jeg synes et SSL certifikat burde sikres med to forskellige kæder. En kæde op gennem hierarkiet til man når en CA, en anden kæde som går tilbage gennem ældre certifikater tilbage til det første certifikat for domænet. Derudover burde oplysninger om certifikatet gemmes i DNS og beskyttes med DNSSEC. HTML burde udvides med en ekstra attribut på alle tags med links til https sites, som kan indeholde oplysninger om certifikatet. Endeligt burde browsere cache oplysninger om det seneste certifikat den har set for et givent domæne.
Kæden tilbage til en CA skal stadig verificeres præcist som hidtil. Hvis alle de andre oplysninger til at verificere certifikatet er tilgængelige kan man dog acceptere SSL certifikater som er self-signed uden en CA.
Oplysninger om sitets certifikat fra browserens cache, fra linket man fulgte og fra DNSSEC sammenlignes så med kæden gennem gamle certifikater fra sitet frem til det nuværende. Hvis alt er korrekt skal browseren så cache det nye certifikat.
Pointen er at oplysninger i browserens cache og i links nemt kan have et certifikat som er en eller flere generationer ældre end det der bruges nu. Men hvis der er en kæde fra det gamle certifikat til det nye kan hverken CA eller DNS udbyder forfalske oplysningerne, det kan kun ske hvis sitets hemmelige nøgle er lækket.
Hvis et domæne legitimt skifter ejer og den gamle ejer ikke vil signere den nye ejers certifikat, så vil brugere få en advarsel om at domænet ikke længere har samme ejer. Den advarsel vil forhåbentlig få brugere til at tænke sig om en ekstra gang inden de godkender det.
Muligheden for at acceptere et nyt certifikat hvor kæden er brudt skal dog kun være til stede hvis det nye certifikat er underskrevet af en kendt CA og det eneste der er i modstrid med det nye certifikat er browserens cachede certifikat. Hvis DNS eller attributten på linket ikke stemmer overens med det nye certifikat skal brugeren have en fejlmelding i stedet for en advarsel som kan godkendes.
Hvis f.eks. min banks website ikke er kompromitteret, men brugte et link til https://nemid.nu/ til noget af loginprocessen, så kunne alle links til https://nemid.nu/ indeholde en oplysning om det forventede certifikat. Hvis nemid.nu i mellemtiden var blevet overført til en anden part, som ville betale mere for det, så kunne denne part få et gyldigt SSL certifikat.
Ved at bruge en linkattribut som jeg beskrev, så ville det ikke være nok at man fik overført nemid.nu og fik et SSL certifikat for det. Man ville også være nødt til at få min bank til at opdatere linkene på deres site. Denne løsning ville være meget mere sikker til systemer som involverer flere https domæner.
Links fra https til http URLer burde samtidigt give fejl med mindre de var blevet udvidet med en attribut som indeholder en kryptografisk hash af det der linkes til. På den måde kan statisk indhold hentes over http, man vil kun være nødt til at bruge https til den første side brugeren kommer ind på og dynamisk indhold.
Nogle af idéerne ovenfor er mine egne, andre er bare god idéer jeg har hørt andre steder. Jeg synes alle idéerne bør kombineres. Derudover bør passwords sendes på en anden måde end de gør i dag. SSL er lidt bedre end at sende passwords i klartekst. Men der kan laves bedre løsninger som ikke kræver at man skal stole på serveren. SCRAM er et stort skridt i den rigtige retning. En endnu bedre løsning ville være at bruge en sigma protokol. Jeg overvejer om de bedste idéer fra SCRAM kunne genbruges og så erstatte enkelte elementer af SCRAM med en sigma protokol.
Der er mange muligheder. Fælles for dem alle er, at de kræver samarbejde med browserproducenterne. At vælge en proprietær løsning som ingen browser har direkte support for men i alle tilfælde kræver tredjepartssoftware og så brokke sig når en enkelt browserproducent ikke længere understøtter dine tredjepartsplugins er ikke det jeg forstår ved samarbejde med browserproducenterne. Og de idéer jeg skitserede er for fundamentale til at kunne laves som plugins.
Folk ser ud til at tro at HTML5 på magisk vis gør alting muligt for programmørerne. HTML5 er altså en relativ tynd udvidelse af HTML4. Udover en temmelig teknisk ændring i lexer-definitionen, så gør HTML5 det muligt at lave en masse brugerflade-ting som var besværlige eller så godt som umulige tidligere.mnmr (18) skrev:iPhone udkom i 2007 og havde hverken Java eller Flash. Skfiten var tydelig på væggen, og alligevel spenderede man millioner på at udvikle det i Java frem for med mere tidssvarende og portable HTML5-teknologier.
MEN NemID bruger først og fremmest Java til at kontrollere at sessions ikke bliver flyttet mellem maskiner (altså cookie-stealing). Grunden til at du kun skal logge ind med dit papkort når du starter din netbank (og derefter kun skal skrive adgangskode for at overføre penge/underskrive mv) er at NemIDs app samler en masse data fra OS'et som bruges til at identificere maskinen. Dermed kan den kontrollere at kodeordet ved overførslen bliver skrevet på fysisk samme maskine som den hvor papkortet blev brugt lidt tidligere.
Det er altså ikke noget HTML5 gør muligt selvom det (urelateret) er cool med drag and drop, canvas, video-element osv...
kasperd (19) skrev:t. Et angreb som det jeg beskrev ville aldrig køre den autentiske applet på brugerens computer.
Jah, det var dét der var min pointe- inde ved danID kan de se at en bank transfer kommer fra en maskine med et andet serial nummer på ram blokkene etc. hvilket vil gøre at et MITM i det mindste kan opdages bagefter.
Dine ideér er ganske gode, men de kræver alle at browser producenterne kommer med på vognen, hvilket nok er urealitisk.
kasperd (19) skrev:Hvis dk-hostmaster beslutter sig for at tage et domæne fra dig og tildele til en anden part, så kan den anden part helt legitimt gå til en vilkårlig CA og få tildelt et certifikat.
Jeg tænkte mere på MITM angreb.
For det første kan tilstanden af en Java VM også kopieres mellem maskiner, næsten lige så let som en cookie. For det andet er det underordnet da et angreb kan gennemføres uden nogensinde at køre appletten på brugerens computer. Hvis appletten kun kører på forbryderens computer, så vil NemID netop ikke kunne detektere at den bliver flyttet.mathiass (20) skrev:MEN NemID bruger først og fremmest Java til at kontrollere at sessions ikke bliver flyttet mellem maskiner (altså cookie-stealing).
Jeg tvivler på at NemID er stand til at få adgang til de oplysninger.Mamad (moveax1ret) (21) skrev:Jah, det var dét der var min pointe- inde ved danID kan de se at en bank transfer kommer fra en maskine med et andet serial nummer på ram blokkene etc.
Hvis appletten kun kører på forbryderens computer, i omgivelser hvor forbryderen kan kontrollere præcist hvad den ser af oplysninger, så er der intet at afsløre bagefter.Mamad (moveax1ret) (21) skrev:hvilket vil gøre at et MITM i det mindste kan opdages bagefter.
Det er kun urealistisk pga. manglende vilje hos Danid. En løsning baseret på lag-på-lag af security-through-obscurity vil forhåbentlig bliver afvist af browserproducenterne. Et sådan samarbejdet ville kræve at Danid var villig til at lave en kvalitetsløsning og ikke blot bruge deres monopol til at gennemtrumfe en løsning som resten af branchen er modstandere af.Mamad (moveax1ret) (21) skrev:Dine ideér er ganske gode, men de kræver alle at browser producenterne kommer med på vognen, hvilket nok er urealitisk.
Hvis Danid var villig til at lave en åben løsning og skrive en RFC draft der beskriver løsningen, og hvis de var villige til at bruge resurserne på at lave en teknisk god løsning, så ser jeg ingen grund til at browserproducenterne ikke ville være med. Hvis Danid tog skridtet videre og selv implementerede det til de tre største opensource browsere og den største open source webserver, så ville de implementationer nok dække 60% af markedet på både klient og server siden.
Hvis Danid leverede så meget selv, så ville det demonstrere et så højt niveau af samarbejdsvilje at resten af branchen ikke med rimelighed ville kunne ignorere det. Det er ingen garanti for at koden faktisk kom ud på alle installationer af betydning, men det ville betyde at så ville fingrene pege den anden vej, når det ikke virker sammen.
Hvis samtidigt de valgte at bibeholde den nuværende Java løsning som workaround for brugere af browsere, der ikke vil implementere den nye standard, så ville Danid have gjort hvad de kunne.
Det ville måske være fuldstændigt urealistisk at se det niveau af samarbejdsvilje fra Danid. Men hvis de faktisk gjorde den indsats ville det overhovedet ikke være urealistisk at se det blive til en officiel standard implementeret i alle browsere og servere af betydning.
Og måske behøver Danid ikke engang gøre så meget af arbejdet selv, som jeg har redegjort for at de kunne. Danid kunne også henvende sig til passende interessenter på området og foreslå et samarbejde omkring design og implementering af en passende standard. På den måde kunne de nok få andre til at tage en del byrden mht. implementering.
Aarhus ville være et oplagt center for sådan et samarbejde, da en del af udviklingen af NemID allerede foregår i Aarhus, og en del af udviklingen af Chrome foregår også i Aarhus, og Aarhus Universitet har en anerkendt gruppe af kryptologer.
Så må du lige forklare hvordan du vil gennemføre et MITM angreb imod DNSSEC. Det bliver ikke nemt da DNSSEC er designet til offline signering.Mamad (moveax1ret) (21) skrev:Jeg tænkte mere på MITM angreb.
kasperd (22) skrev:Jeg tvivler på at NemID er stand til at få adgang til de oplysninger.
Joh, det er dét som at de executeables der er skjult som gif filer sender til danID. De kan så sammenlignes med dem fra tidligere transmissioner.
kasperd (22) skrev:Så må du lige forklare hvordan du vil gennemføre et MITM angreb imod DNSSEC. Det bliver ikke nemt da DNSSEC er designet til offline signering.
Hvis at dk hostmaster CA bliver hacket ligesom Comodo, diginotar, etc.
kan angriberen lave MITM, og hele .dk er på røven.
Med det eksisterende CA system kan browserne i det mindste revoke en hel CA. og brugerne kan skifte til en anden.
Jeg siger ikke det er perfekt CA systemet(langt fra), men jeg bryder mig heller ikke om at putte alle mine æg i en kurv.
Altså ingen ændring i forhold til i dag.Mamad (moveax1ret) (23) skrev:Hvis at dk hostmaster CA bliver hacket ligesom Comodo, diginotar, etc.
kan angriberen lave MITM, og hele .dk er på røven.
Nuværende system har omkring 1500 virksomheder der kan angribes for at opnå et certifikat. Det er nok at angribe en for at opnå et certifikat. Baserede man sikkerheden på DNSSEC ville antallet reduceres til blot en håndfuld, og ville stadigvæk være nok at angribe blot en enkelt.Mamad (moveax1ret) (23) skrev:Med det eksisterende CA system kan browserne i det mindste revoke en hel CA. og brugerne kan skifte til en anden.
Hvorfor synes du det er nemmere at sikre 1500 virksomheders systemer i forhold til at sikre blot en håndfuld?
Browserproducenterne kan revoke en hel CA. Men de gør det praktisk taget aldrig.
Men det vigtigste at indse er, at selv hvis der ikke var noget sikkerhedshul hos en eneste CA, så ville DNSSEC stadigvæk være mere sikkert end det nuværende system. Og det ville det være fordi når en CA skal undersøge om du faktisk har ret til at for udstedt et certifikat, så bruger de DNS systemet til at sikre at de kommunikerer med den rigtige part.
kasperd (24) skrev:Altså ingen ændring i forhold til i dag.
Jo, i forhold til at rydde op, hvis at DK Hostmasters CA ryger, så er hele .dk uden SSL indtil de bliver klar igen. Ved det nuværende system kan man i det mindste revoke CA´en, og købe nye certififikater.
kasperd (24) skrev:Hvorfor synes du det er nemmere at sikre 1500 virksomheders systemer i forhold til at sikre blot en håndfuld?
Det tror jeg heller ikke jeg har sagt.....
kasperd (24) skrev:Browserproducenterne kan revoke en hel CA. Men de gør det praktisk taget aldrig.
De gjorde det ved Comodo.
Jeg siger ikke det nuværende system er perfekt- men jeg bryder mig heller ikke om at putte alle æg i én kurv ved DKHostmaster.
Jeg så helllere at man kunne købe flere certifikater til ét domæne fra flere CA´s og hvis at én CA så bliver hacket, vil kun ét ud af f.eks. 5 certifikater være forkert, og browseren vil så rejecte det. Så skal hackeren hacke 5 CA´s.
Det problem har du jo allerede med det nuværende system.Mamad (moveax1ret) (25) skrev:jeg bryder mig heller ikke om at putte alle æg i én kurv ved DKHostmaster.
Hvis man kan kompromittere dk-hostmaster, så kan man ændre alle de DNS oplysninger som en CA checker. Når man har gjort det kan man få udstedt lige så mange certifikater man vil have for domænet fra forskellige CAer.
Man behøver ikke engang kompromittere dk-hostmaster. Det er nok at lave et passende DNS poisoning angreb for at få de ønskede CAer til at se forfalskede DNS opslag længe nok til at få udstedt et certifikat.
Det er så et problem med lavpris CA´s der gør et dårligt job- en løsning på det er Extended Validation Certificates, det kunne være et første skridt at browsere kun accepterer dem.
Det kræver at CA skal slå op i whois databasen for at finde ud af hvem domænet er registreret til. Men hvis man allerede er i stand til at gennemføre DNS poisoning, så kan man også dirigere whois opslag til sin egen whois server. Igen er man afhængig af dk-hostmaster.Mamad (moveax1ret) (28) skrev:en løsning på det er Extended Validation Certificates
Du kan ikke fjerne afhængigheden af dk-hostmaster så længe det er dk-hostmaster der afgør hvem der har retten til et domæne.
Så skal man DNS poisene CA´en og ikke bare den bruger af nemID man vil angribe. Det er væsenligt sværere.
Ja, men det er stadigvæk nemmere end at forfalske DNSSEC records der er blevet signeret offline.Mamad (moveax1ret) (30) skrev:Så skal man DNS poisene CA´en og ikke bare den bruger af nemID man vil angribe. Det er væsenligt sværere.
Det jeg beskriver er angreb som kan udføres imod den nuværende CA infrastruktur som ikke ville være muligt, hvis man brugte DNSSEC.
Alle de hypotetiske angreb imod dk-hostmaster, som du mener man ville kunne bruge imod DNSSEC ville allerede kunne udnyttes i dag.
Sandt, men ikke desto mindre er det så vidt jeg ved det man gør. Det er relativt trivielt at snige en cookie ud af en maskine hvis der fx er en XSS sårbarhed som man kan udnytte. Det er trods alt noget sværere at snige Java VM'ens tilstand ud af maskinen med noget JavaScript kode. Man har jo ikke direkte adgang til Java-hukommelsen gennem JavaScript... I praksis har denne beskyttelse tilsyneladende været nok til at forbyderne har valgt en anden metode til at angribe NemID services/netbanker.kasperd (22) skrev:For det første kan tilstanden af en Java VM også kopieres mellem maskiner, næsten lige så let som en cookie. For det andet er det underordnet da et angreb kan gennemføres uden nogensinde at køre appletten på brugerens computer. Hvis appletten kun kører på forbryderens computer, så vil NemID netop ikke kunne detektere at den bliver flyttet.
Hvis appletten (alene) kører på en forbryders maskine, så er det en anden type angreb som der skal en anden type beskyttelse for at besværliggøre.
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