image

Interview: Google Chrome krijgt SSL-whitelist

dinsdag 14 juni 2011, 10:18 door Redactie, 4 reacties

Naast het filteren van verouderde plugins, maakt Chrome het ook mogelijk dat gebruikers straks SSL-certificaten gaan whitelisten, dat zegt Chris Evans in een persoonlijk interview met Security.nl. Evans is Security Engineer bij de zoekgigant en Chrome teamleider. In die rol was hij verantwoordelijk voor het filter dat de plugins van andere softwarebedrijven controleert. Op dit moment houdt hij zich bezig met SSL. De afgelopen maanden kwam SSL verder onder vuur te liggen. Zo was er het incident waarbij een gehackte certificaatuitgever (CA) werd gebruikt voor het aanvragen van certificaten in naam van Microsoft, Google, Skype, Mozilla en Yahoo. Later was er een incident waarbij een vervalst SSL-certificaat werd gebruikt voor het stelen van Facebook-gegevens van Syrische internetgebruikers. Een soortgelijke situatie deed zich begin dit jaar in Tunesië voor.

"Daar wil ik bescherming tegen bieden. Dit zijn gevaarlijke aanvallen voor gebruikers", aldus Evans. Zo is er een Force SSL lijst in de browser ingebouwd. Die zorgt ervoor dat alle verzoeken direct over SSL lopen en niet over HTTP. In het geval van de Tunesische-aanval werd er eerst via HTTP verbinding gezocht. Dat was genoeg voor het uitvoeren van een man-in-the-middle-aanval. Chrome kan dat straks voorkomen.

Pinnen
Een experiment waar Evans aan werkt en mogelijk in Chrome 13 aanwezig is, is het "pinnen" van SSL-certificaten voor sommige websites. Daarbij kunnen gebruikers per domein aangeven welke root CA's voor een domein een certificaat mogen uitgeven. Bij het opzetten van de verbinding, wordt de door de gebruiker aangemaakte lijst van ca's voor het domein gecontroleerd. Komt de uitgever niet overeen met de uitgever of uitgevers op de lijst, dan wordt de verbinding niet opgezet.

"Dat moet een goede bescherming bieden als er een groot incident met een CA plaatsvindt." Evans noemt het 'pinning', het verzamelen van public key fingerprints. De lijst met publieke sleutels moet dan in de certificaat chain voorkomen. "Je hebt verschillende opties. Je kunt een CA vertrouwen of helemaal geen CA's. Dan kun je het 'leaf certificate' vertrouwen. Dit is wel voor geavanceerde gebruikers." Zelfs als alle CA's gehackt worden, zouden gebruikers die deze leaf certificates hebben gepind geen gevaar lopen. De aanvaller kan nog steeds niet de verbinding onderscheppen, omdat de "pins" aan de publieke sleutel en niet aan de CA is gekoppeld. "Je maakt verbinding via de publieke sleutel van Facebook en niet via de CA", merkt Evans op.

Vanwege de problemen met verschillende regimes die Twitter blokkeerden of verkeer probeerden te onderscheppen, vroeg Google aan Twitter of het de microbloggingdienst standaard aan de HTTPS lijst van Chromebook toevoegen, zodat HTTPS standaard wordt gebruikt. Ook andere grote websites kunnen zo'n verzoek bij Google neerleggen. De optie zit nu alleen in het Chrome OS en niet in de browser.

Adblocker
Voor Firefox zijn er verschillende plugins als Perspectives en SSL Patrol, maar Evans merkt op dat hij graag aan dingen werkt die in de browser zitten. "Ik wil mijn schoonmoeder tegen allerlei dreigingen beschermen, maar ze weet niet genoeg om een plugin of extensie te downloaden en installeren. Ik wil dingen doen die haar beschermen." Door opties aan de browser toe te voegen zou beveiliging voor een grotere groep beschikbaar worden.

Een Adblocker zal Google, wat de inkomsten voornamelijk via advertenties verdient, niet standaard aan Chrome toevoegen. Toen de zoekgigant toestand dat gebruikers zelf extensies voor Chrome gingen ontwikkelen, was een Adblocker binnen een dag de meeste gedownloade uitbreiding. "Dat is iemands recht. Een van de Chrome filosofieën is dat de gebruiker eerst komt en daarbij worden er geen beperkingen opgelegd voor extensies die de pagina aanpassen. En als iemand advertenties wil blokkeren, dan is het hun recht om dat te doen, en we zijn blij om die feature in Chrome te hebben."

Sandbox
In Chrome werden vorig jaar meer dan honderd beveiligingslekken gepatcht. Dat zegt niets over de veiligheid van de browser, merkt Evans op. "Het tellen van bugs wordt steeds minder populair." Het houdt geen rekening met sandboxing. "Als de meeste bugs binnen de sandbox plaatsvinden en het lastig is om uit de sandbox te breken, dan verlaagt dat het risico." Volgens Evans speelt het snel patchen van lekken een belangrijkere rol. "Wat doe je als een onderzoeker een lek rapporteert. Blijf je er dan zes maanden op zitten?"

Steeds vaker worden lekken door meerdere onderzoekers gevonden. Soms ook door partijen met kwade bedoelingen die het vervolgens gebruiken om systemen te infecteren. "Wij meten onszelf door te kijken hoe snel we de lekken verhelpen die onderzoekers opsturen. Dat is iets dat we als industrie beter kunnen doen en wat gebruikers veiliger maakt."

Veilige browser
Evans wil Chrome niet de veiligste browser op de markt noemen. "Het is allemaal relatief. We hebben een aantrekkelijk verhaal, maar we doen geen claims over de veiligste browser. Er is niet zoiets als een veilige browser. Door naar andere problemen in het systeem te kijken en daarop te reageren, bijvoorbeeld door een PDF-lezer in te bouwen. Kan men verschillende risico's wegnemen. "Het draait in een redelijk sterke sandbox en we hebben ook naar het best van ons kunnen de bugs eruit gehaald, dus we zijn aardig in vorm."

Onlangs patchte Google verschillende kritieke lekken in Chrome, waardoor aanvallers het onderliggende systeem toch konden overnemen. Bij twee van deze lekken werd niet de gebruikelijk 3133,70 dollar uitbetaald. Dit is het hoogste bedrag dat Google externe onderzoekers betaalt, en is een 'leet-speak' verwijzing. Evans laat weten dat Google de problemen niet direct van de onderzoeker had vernomen. "We hebben hem toen toch benaderd en gezegd dat we hem graag duizend dollar wilden geven en dat hij de volgende keer ons direct benaderd."

En dit gebeurt vaker, gaat Evans verder. "We hebben een cultuur waar we excuses zoeken om iemand te betalen, in plaats van excuses om iemand niet te betalen. Soms worden er bugs gemeld waarvan de ontdekker niet weet dat het een beveiligingsprobleem is. Ook deze personen worden achteraf toch beloond."

Reacties (4)
14-06-2011, 15:55 door henkhooft
Je kunt zeggen wat je wil over google maar de beveiliging van chrome hebben ze beter voor elkaar dan de concurrentie.
14-06-2011, 20:17 door Anoniem
Daarbij kunnen gebruikers per domein aangeven welke root CA's voor een domein een certificaat mogen uitgeven. Bij het opzetten van de verbinding, wordt de door de gebruiker aangemaakte lijst van ca's voor het domein gecontroleerd.
Goed dat ze er over nadenken maar de vraag luidt of dit wel zo'n goed idee is.
Ik zie binnenkort malware voorbij komen dat deze lijst aanpast en een fake CA als default in stelt.
Niet om negatief te wezen maar een man in de middle is zometeen een koud kunstje.
15-06-2011, 10:41 door Anoniem
Door Anoniem:
Daarbij kunnen gebruikers per domein aangeven welke root CA's voor een domein een certificaat mogen uitgeven. Bij het opzetten van de verbinding, wordt de door de gebruiker aangemaakte lijst van ca's voor het domein gecontroleerd.
Goed dat ze er over nadenken maar de vraag luidt of dit wel zo'n goed idee is.
Ik zie binnenkort malware voorbij komen dat deze lijst aanpast en een fake CA als default in stelt.
Niet om negatief te wezen maar een man in de middle is zometeen een koud kunstje.

Zoals Evans ook zegt, is dit niet de ultieme oplossing. Het is een stap in het proces om zaken veiliger te maken. Het pinnen van een CA is een redelijke stap, maar het pinnen van de leaf is beter. Al zal dat, zoals hij zegt, niet voor iedereen weggelegd zijn. Want het klinkt wel leuk om de leaf te pinnen, maar de meeste certificaten worden maar voor een beperkte tijd uitgegeven. Dan werkt het na het verlopen van die termijn niet meer. Zijn schoonmoeder zal dat niet snappen. Die zal hooguit de CA pinnen. En tegen de tijd dat die certificaten verlopen, verwacht ik ook een veiligere methode om daarmee om te gaan.

Veel bedrijven die met beveililging bezig zijn, zien beveiliging als een product. Terwijl beveiliging een proces is. Je bent nooit 100% veilig. Maar ieder stapje in het proces maakt je iets veiliger. En ieder stapje van een aanvaller maakt je iets onveiliger. Je moet gewoon proberen jouw stapjes iets groter te maken dan die van de aanvaller.

Peter
15-06-2011, 11:52 door Anoniem
Door Anoniem:
Daarbij kunnen gebruikers per domein aangeven welke root CA's voor een domein een certificaat mogen uitgeven. Bij het opzetten van de verbinding, wordt de door de gebruiker aangemaakte lijst van ca's voor het domein gecontroleerd.
Goed dat ze er over nadenken maar de vraag luidt of dit wel zo'n goed idee is.
Ik zie binnenkort malware voorbij komen dat deze lijst aanpast en een fake CA als default in stelt.
Niet om negatief te wezen maar een man in de middle is zometeen een koud kunstje.

Het toevoegen van een (foute) CA kan nu ook door malware gedaan worden. Kwestie van de gebruiker op 'Ja' laten klikken.
Overigens is het idee niet nieuw: http://www.redelijkheid.com/blog/2007/8/14/do-you-trust-kozjegyzoi-tanusitvanykiado.html
Wel frappant dat het maar 4 jaar duurt voordat zoiets opgepikt wordt. Java/Linux omgevingen leveren standaard lege keystores waar je als gebruiker/beheerder je trustpoints moet definieren.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.