Jeg giver ikke meget for den undersøgelse. Ved at scanne hele IPv4 får de en masse selvsignerede certifikater, som er sat op per default på services som aldrig har været tiltænkt at skulle tilgås over https/tls. De er ret ligegyldige. Browserproducenterne har længe forbudt certifikatautoriteterne at udstede SHA-1 certifikater, og der er kun givet ganske få undtagelser. Så hvis man begrænser undersøgelsen til CAs som din browser vil stole på, vil der nok kun være nogle få håndfulde SHA-1 certifikater, som ikke er udløbet. At sige at det er hver femte hjemmeside er helt meningsløst.
Jeg er enig med Mogens i at browserproducenterne fokuserer for meget på certifikater i forhold til cipher suites og protokolversioner. Men de gør det nok fordi det er nemt. Hver gang de skal fjerne noget vil de ende med at blokere en masse websider, som ikke har opgraderet til noget bedre. Og hvis brugerne ikke kan komme ind på disse websider, vil de skifte browser. Browserproducenterne vil gøre alt for at holde på brugerne, selvom det betyder at de skal understøtte mindre sikre metoder. Med certifikater har browserproducenterne dog et andet alternativ: I stedet for at skrive begrænsningen ind i produktet, kan de skrive det ind i deres root store policy, som certifikatautoriteterne skal overholde. Derved har de med et pennestrøg flyttet hele omkostningen fra dem selv over på certifikatautoriteterne, som ikke kan gøre andet end at makke ret. Jeg tror det er derfor browserproducenterne er langt mere ivrige efter at udrydde mindre sikre teknologier i certifikater end de er tilsvarende i cipher suites og protokolversioner.
Ifølge den refererede mail validerer GoDaddy ejerskab af et domænenavn fx "example.com" ved at udstede en kode fx "12345678", og bede brugeren oprette en side på adressen "https://example.com/12345678.html" som indeholder koden "12345678". Problemet er så at mange sites har fejlsider med en tekst i formatet "Siden 12345678.html findes ikke". Hvis et domæne har sådanne fejlsider vil GoDaddys validering altid være successfuld, selvom du ikke har kontrol over domænet. GoDaddy har derfor lavet nogle tjek for at detektere og ignorere sådanne fejlsider. Disse ekstra tjek er ved en fejl blevet slået fra i det seneste halve år, og GoDaddy har så rettet fejlen ved at slå tjeksne til igen.
Det virker ikke som en solid validering. I stedet for at lave ekstra tjeks på om svaret de får tilbage ligner en automatisk genereret fejlside, burde de ændre deres validering, så der var to forskellige koder til henholdsvis adressen og indholdet. Så ville de helt undgå problemer med sider der automatisk gengiver adressen i indholdet. Det er bekymrende at en betroet CA ikke selv opdager sådan et problem. Men det er da altid noget at de nu helt har fjernet denne valideringsmetode, efter den oprindelige mail blev skrevet, nu hvor Mozilla har gjort dem opmærksom på det.
"Udstedte 8.850 falske certifikater" -> nej, ud af alle de certifikater de har udstedt, var der 8850, som GoDaddy ikke kunne re-verificere om var falske eller ej, fordi disse kunder havde fjernet verifikationskoden fra deres domæner efterfølgende.
"I praksis betød det, at adskillige hjemmesider har kørt i godt en uge med et certifikat, der ikke var udstedt uden at være blevet godkendt på den korrekte måde." -> For det første har i vidst en negation for meget i sætningen. For det andet er tidsskalaen en lidt anden. 29. juli 2016 til 6. januar 2017 er en smule længere end en uge. Den uge der omtales er fra GoDaddy modtog en mail om fejlen, til at en medarbejder hos GoDaddy læste mailen.
"Mange af hjemmesiderne virkede ifølge GoDaddy stadig med en begrænset funktionalitet." -> Hvor har i fundet den information? Den ser ikke ud til at have nogen relation til virkeligheden. Siderne har virket fuldt ud ind til nu, hvor GoDaddy har tilbagekaldt certifikaterne.
CPR tilbyder at man kan abonnere på adressematch, så man kan få oplysninger om adresseændringer og dødsfald, uden at man behøver kende kundens CPR-nummer. Man skal blot kende kundens navn og adresse. Man kan få et mere præcist match, hvis man også kender fødselsdatoen. Det er ikke så nemt som DAWA, da man skal sende filer frem og tilbage i et gammelt obskurt format en gang i døgnet, men det virker nogenlunde. Jeg kender ikke deres priser.
Ifølge GlobalSigns incident report var problemet at deres OCSP software havde en bug, så da de tilbagekaldte et certifikat, genererede softwaren tilbagekaldelser for alle certifikater der havde en række attributter til fælles med det tilbagekaldte certifikat.
Ville man som GlogalSign-kunde ikke kunne have undgået problemet, ved at implementere OCSP Stapling? (og gjort det rigtigt, https://gist.github.com/sleevi/5efe9ef98961ecfb4da8 ) Derved kunne man selv sikre at det tilbagetrukne OCSP-svar blev filtreret fra.
HTML blev lavet en gang man ikke kendte til alle disse sikkerheds-issues, og da det skal være bagudkompatibelt, har man lukket de fleste af sikkerhedshullerne med opt-ins.
Husker du at sætte rel="noopener" på alle dine eksterne links, at sætte Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy og Strict-Transport-Security headersne på alle responses (også fejlsiderne), at navngive alle dine cookies så de starter med __Host- eller __Secure-, at sørge for at alle dine JSON API'er har et objekt som top-level (modsat fx en array), at kræve xsrf-token på alle relevante handlinger og billeder, at levere bruger-uploadede filer fra et separat domæne, osv?
Listen over små obskure ting man skal huske er lang, endda inden man når til de klassiske nødvendige sikkerhedsdyder som fx input validering, encoding og adgangskontrol.
Dejlig nyhed, men jeg synes artiklen misser den mest interessante pointe, som man kan læse, hvis man klikker sig videre til kilden. Mange sites virker med og uden Flash, hvor man får Flash-versionen, hvis sitet detekterer at man har Flash. Det betyder at hvis man har Flash click to play eller en lignende Flash blocker får man den dårligst mulige oplevelse. Man får versionen af siden der kræver Flash, og den bliver blokeret. Googles forslag involverer at forsøge at snyde sitets feature detection til at tro at Flash slet ikke er installeret, så man får versionen uden Flash frem for en fejlbesked, hvis man vælger ikke at aktivere Flash på siden.
Hvis man downloader og kører noget kode med fuld brugeradgang, så er det alment kendt at denne kode kan gøre noget du ikke vil have og samtidigt obfuskeres så dit antivirusprogram ikke kan genkende det.
At påstå at Noscript, Greasemonkey og Firebug er "sårbare" fordi andet kode kan obfuskeres til at ligne en af dem, giver bare ikke mening.
Læs i øvrigt Noscripts svar på historien: https://hackademix.net/2016/04/08/crossfud-an-analysis-of-inflated-research-and-sloppy-reporting/
Ja, CA-systemet er sygt, men vi har stadig ikke et bedre alternativ.
TOFU (Trust On First Use) som artiklen foreslår dur ikke i praksis. Det hører til Blame The Victim-kategorien. Langt de fleste ville ikke ane hvad de skulle svare på spørgsmål om certifikater, og dem som gør vil ikke have tid til at sætte sig ind i alle detaljerne for hver eneste https websted de besøger. Og selv hvis vi antog at brugere på magisk vis var i stand til at forstå detaljerne i TLS og PKI, så ville udsigten til sikkerhedsdialogbokse få en masse websteder, der burde være på https, til at skifte til http, for at undgå dialogboksene.
DANE mangler en metode til at levere den nødvendige information til klienten, på en måde der ikke ligger milevidt under browsernes standarder for tilgængelighed, pålidelighed, performance og privatliv (standarder der i forvejen er ret lave). Browserne har de samme problemer i mindre grad i dag med certifikattilbagekaldelse. Se fx https://wiki.mozilla.org/CA:RevocationPlan og https://www.imperialviolet.org/2014/04/19/revchecking.html
DNSSEC (og dermed DANE) mangler også en fornuftig incitamentstruktur. Alle de entiteter du er afhængig af er officielle monopoler og mangler derfor enhver form for incitament for at varetage dine interesser.
I det nuværende CA-system er der stærk konkurrence mellem browsere, som derfor har incitament til at vedligeholde deres root stores på fornuftig vis, og fjerne CA'er, der ikke gør det godt nok. CA'erne har et incitament til at agere forsvarligt, for at undgå at blive smidt ud af root storesne. Det har de kun fordi der er flere CA'er i disse stores. Det har tidligere knebet med en reel trussel fra browserproducenternes side, da de har haft svært ved at sikre både kompatibilitet og sikkerhed på samme tid. Men de er efterhånden ved at komme efter det, blandt andet ved hjælp af Certificate Transparency, selvom der nok er et stykke vej endnu.
Nogen vil have nationale myndigheder til at vedligeholde root stores, men hvad skulle gøre dem bedre til det end browserproducenterne? Politikere og myndigheder har ikke ligefrem brilieret med deres evne til at forstå kryptering, og en del vil endda mene at det er disse myndigheder der er fjenden.
Convergense har de samme problemer med tilgængelighed, pålidelighed, performance og privatliv som DANE, bare i større udstrækning.
De eneste alternativer der har en chance for at gøre en forskel inden for en overskuelig fremtid er teknikker der bygger videre på CA-modellen som HPKP og Certificate Transparency. HPKP skal man dog lade være med at bruge, med mindre man virkelig ved hvad man laver, da det ellers er alt for nemt at begå pinning suiside.
Den sidste sætning er forkert. PerimeterX var ifølge deres egen beskrivelse i stand til at få udvidede privilegier, men ikke administratorprivilegier. De var heller ikke i stand til at se listen over alvorlige sikkerhedssårbarheder, men påpeger, at det ville have været muligt, hvis den pågældende Bugzilla-installation var konfigureret anderledes. Listen over privilegier de fik adgang til ser dog stadig alvorlig ud. Den ser blandt andet ud til at indeholde data om fortrolige aftaler med Mozillas forretningspartnere.
Jeg har meget svært ved at forestille mig at Java (eller ethvert andet traditionelt plugin) kan implementeres på PPAPI. PPAPI var oprindeligt tænkt som en erstatning til NPAPI, men endte med at blive noget helt andet (en del af NaCl). Det bidrager til forvirringen at Chrome implementerer Flash i en teknologi, som indeholder komponenter fra PPAPI, så man nemt kan komme til at tro at de har implementeret Flash på PPAIP. PPAPI har ingen relevans i denne diskussion, så jeg undrer mig over hvorfor det overhovedet er nævnt i artiklen.
"Derfor har den amerikanske regering bedt Icann om at udarbejde en plan for, hvordan kontrollen skal overgå til et udvalg af private virksomheder samt repræsentanter fra forskellige regeringer."
Er det ikke en fejloversættelse? Som jeg læser det vil de have kontrollen over DNS til at overgå til et udvalg af private virksomheder, og de vil ikke acceptere hvis udvalget består af repræsentanter fra forskellige regeringer.
Svjv er det pepperAPI der bruges under chrome åbent dokumenteret ie det er mest fordi firefox kun implementere, chromium er rapportertet til at virke med pepper-flash, så der er opensource kode at læne sig op ad. ved ikke hvordan firefox windows snakker til flash.</p>
<p>Mozilla's attitude har lidt været yeah flash er døende vi gider ikke kaste resourcer efter et nyt api bare for at kunne afspille flash. Hvad der ligger af problemer mellem adobe of mozilla tør jeg ikke udtale mig om.</p>
<p>Så vidt jeg ved kommer der stadigvæk sikkerhedsopdateringer til den sidste version der virkede med firefox under linux. Det er mere at nye features kun dukker op i den udgave der bruger google's pepperapi.</p>
<p>svjv er det kun manglen på et brugbart standadiseret video format der får flash til at overleve(html5 definere ikke et video format), og selvfølgeligt at drm kun virker med lukkede plugins.
Jeg tror ikke PPAPI (Pepper) versus NPAPI har del i årsagen til at Flash kun vedligeholdes til Chrome. Det er nok snarere en konsekvens.
Adobe besluttede at de ikke længere gad vedligeholde Flash til Android, og senere hen til Linux. Google tilbød selv at stå for og betale for vedligeholdelsen til Linux, og Adobe gav dem kildekoden og tilladelse til at gøre det. Google har ingen interesse i at vedligeholde Flash til andet end Chrome, og da Chrome bruger PPAPI til flash, har Google ingen grund til at vedligeholde NPAPI-versionen af Flash til Linux. Selv hvis Flash i Chrome stadig brugte NPAPI, ville den sandsynligvis stadig kun virke i Chrome.
Pepper i Chrome er flere ting. For det første er det en del af PPAPI der bruges til at køre Flash i Chrome. For det andet er det en del af PNaCl, som er et komplet alternativ til den eksisterende web-platform. Google har flere gange forsøgt at erstatte hele web-platformen med varierende ikke-kompatible proprietære teknologier (bland andet PNaCl og Dart). Det har mange andre, herunder Mozilla været meget imod.
Hvis Mozilla skulle bruge Pepper alene som plugin-API uden at implementere PNaCl-delen, ville det ikke give mening at bruge så mange ressourcer på at implementere det. Specielt når den eneste reelle feature PPAPI har over for NPAPI er sandboxing, og Firefox endnu ikke understøtter sandboxing.
Det er højest usandsynligt at Mozilla vil indgå en aftale med Adobe som den Google har, hvor Mozilla skulle stå for vedligeholdelsen af Flash til Firefox. I stedet satser Mozilla på at bygge deres egen Flash-implementering, som ikke er baseret på Adobes kode. Den hedder Shumway. https://mozilla.github.io/shumway/
Ok, jeg kan godt se det var upræcist hvad jeg skrev. Browseren kan stadig foretage mange optimeringer, men der er nogen den ikke kan bruge, når man bruger direct eval eller with. Her er en simpel kode med en memory leak. Men den er noget større med direct eval i forhold til indirect eval (testet i Firefox og Chrome).
[html]
<script> var counter = document.getElementById("counter"); var count = 0; var list = []; setInterval(function() { var a = []; for (var i = 0; i < 1000000; i++) a.push(i); count++; counter.textContent = count; list.push(function() { var b = eval("1+1"); //var b = (1,eval)("1+1"); }); }, 0); </script> [/html]Jeg synes faktisk ikke dit eksempel er så interessant. Eval er noget skidt (både funktionen og operatoren) og det eneste man skal vide om den er at man aldrig skal bruge den, og hvis man ser noget kode der bruger den skal man skrive den om. Hvis man skal eksekvere en tekststreng som JavaScript, kan man bruge Function-constructoren.
Hvis man bruger "eval" eller "with" stopper browseren al JIT-optiomering, så det er relativt nemt at huske, at man bare skal lade være med at bruge dem.
Det er langt "sjovere" når det kommer til mærkværdigheder, som man faktisk kan støde på i reel kode.
Her er et af mine yndlings-eksempler: [html]
<script>var open = "hello"</script>A
<script>document.getElementById('x').onclick = function() { alert(open); };</script>BC[/html]
Her overskriver vi browserens indbyggede window.open()-funktion, og prøver at læse værdien af den på tre forskellige måder. Hvis man klikker på A får man som forventet den overskrevne værdi, men hvis man klikker på B, får man på mystisk vis den oprindelige værdi. Et klik på C giver igen den overskrevne værdi. Det kan være en udfordring når en browser begynder at implementere en ny standard, som tilfældigvis bruger samme navn som en af dine globale variable.
https://wtfjs.com/ har også en lang række eksempler.
@Karsten Hansen:
Hvis du læser nærmere på den kilde du nævner, vil du se at din liste er opgjort efter antallet af offentliggjorte sårbarheder, hvilket er et rimeligt ubrugeligt tal.
Tallene i artiklen omhandler andelen af brugere, der har en gammel version installeret med en af disse sårbarheder, hvilket er et langt mere relevant tal.
De to lister kan sagtens være forskellige, da ikke alle leverandører er lige gode til at få distribueret opdateringerne.
Samtidig ændrer selskabet på Javas sikkerhedsindstillinger, så de nu sættes til 'High' i stedet for 'Medium' som standard. Det er endnu en hovedpine for de it-kriminelle, fordi brugeren dermed bliver tvunget til at godkende usignerede Java-appletter, der kører i browseren.
Wow. Det kan diskuteres om det øger eller mindsker sikkerheden at brugere nu skal klikke OK til endnu en uforståelig sikkerhedsboks for at komme videre. Men der er noget meget mere interessant i den ændring. Så vidt jeg ved har Oracle ikke før meldt offentligt ud at Java i browseren er en forældet teknologi, som de gerne vil udfase. At sætte forhindringer op for brugere, som vil bruge Java i browseren, betragter jeg som at Oracle nu endeligt har erklæret Java i browseren for døende. Det må da være dagens gode nyhed.
Det er rigtigt at Mozilla har haft projekter før som Prism til at køre webapplikationer i deres eget vindue uden browser chrome og med genveje i operativsystemet. Men Mozilla har aldrig haft en tilhørende Marketplace, hvor man kan finde applikationerne, rate dem og betale for dem.
Marketplace lanceres i første omgang til desktoppen, men det er ikke desktoppen den egentligt er lavet til. Den er lavet til Mozillas kommende mobiloperativsystem.
Mozilla er ved at lave Firefox til Metro, men det er kun til x86 (+64) maskiner. Den kan ikke køre på en ARM Metro. Browseren får lov integrere med Metro, selvom det er en traditionel desktop-applikation. Men på ARM har man så vidt jeg har forstået slet ikke adgang til desktop-udgaven af Windows.
Jeg kan ikke se noget problem i at MS begrænser ARM Metro til IE. Situationen er en helt anden end den MS blev dømt for på desktoppen. For det første var browseren den gang ikke en lige så integreret del af styresystemet. For det andet havde Windows et monopol på desktop-styresystemer. Windows har langt fra et monopol på Tablet-styresystemer i dag, og det vil undre mig hvis de får det inden for den næste korte tid.
Nogle har nævnt at Apple laver samme nummer, men de er ikke de eneste:
Windows RT fra Microsoft kan kun køre Internet Explorer iOS fra Apple kan kun køre Safari Chrome OS fra Google kan kun køre Chrome B2G fra Mozilla kan kun køre Firefox
Er det ikke lidt misvisende at kalde det spil "i browseren"? I mine ører dækker begrebet over noget der virker eller vil komme til at virke i flere forskellige browsere. Men der er tale om en Google-specifik teknologi (Native Client), der kun virker i Google Chrome, og ikke har nogen udsigt til at komme til at virke i andet end Google Chrome, hvis den overhovedet overlever der.
Jesper Kristensen