Google: OpenSSL + NSS och SSL i Chrome + Native Client + Ratproxy

Att jag laddade ner och kompilerade senaste versionen av OpenSSL (och passade på att tipsa er i Appropå C och säkerhet) var först och främst för att vettigt kunna testa Chrome i olika situationer i kontext av SSL. Då behöver jag generera SSL-certifikat och kompilera ner en lämplig SSL-server som Chrome kan prata TLS med mig via.

Vidare och viktigt är OpenSSL trots sina problem extremt vanligt. Olika versioner finns i massor av legacy system och klienter som behövt SSL-stöd. Dessutom finns OpenSSL ofta under mer kompletta bibliotek med krypteringsstöd. Därför finns OpenSSL i riktigt mycket om man gräver sig ner tillräckligt.

Chrome bygger på öppenkällkod

Jag antog felaktigt från start att Google byggt Chrome legacy. Det är nog vad jag hade valt att göra med något av de väldigt moderna och mer säkra programmeringsmiljöerna som gör det möjligt att kraftigt kapsla in allt man återanvänder (t.ex. OpenSSL) samt få det man utvecklar nytt mycket säkrare. Vidare trodde jag att det inte skulle vara så himla mycket åldrad C-kod som låg under webbläsaren och att Google i stor omfattning hade satsat mer långsiktigt på att utveckla eget stöd.

Detta antagande byggde jag på att jag ser Chrome som en viktig del i det jag kallat the Google Cloud och uppfattar är Google:s framtidsstrategi. Nu upptäckte jag istället att Google valde att starta upp ett open-source project för plattformen: Chromium (code.google.com).

Är Chromium bra?

Troligen kommer det visa sig att Google gjort helt rätt i detta. De har ju vanligen (vilket jag tror är riktigt) aldrig bråttom med saker och ting. Då kan man ju ta att en ev. kortsiktigt ökad risk för säkerhetsproblem för att långsiktigt uppnå:

• Möjligen en stabilare och säkrare lösning.
• Större förtroende hos internetsamhället.
• Lägre utvecklingskostnad.

Den kortsiktiga risken reduceras ju genom att de troligen som vanligt kommer röra sig långsamt.

Vad är bra med att återanvända många gamla bibliotek?

Fördelarna är uppenbara:

• Snabb utveckling nu tidigt i Chromium.
• Stabila och snabba bibliotek där barnsjukdomarna är borta.
• Låga utvecklingskostnader.
• Möjlighet att stödja open-source-samhället som är mycket inflytelserikt på internet.
• Goda chanser att komma i nära kontakt med många av världens bästa arkitekter, systemutvecklare och programmerare när det gäller webben.
• Open-source inger förtroende.

Vad är problemet?

Att jag skriver att lösningen möjligen blir mindre säker kortsiktigt via ett open-source-projekt håller många säkert inte med om. Anledningen till att jag uttrycker mig så här är att Google verkligen har valt att återanvända ordentligt med gamla C-bibliotek i Chromium och därmed får man anta i Chrome. Även om C inte är bra säkerhetsmässigt (och det sitter långt inne för mig att säga för jag gillar verkligen C) har naturligtvis biblioteken blivit mycket stabila genom åren. Likväl poppar det upp problem regelbundet.

Vissa problem går bra att "kapsla in" i applikationer så att de inte påverkas om de visar sig finnas medan annat fortfarande är problematiskt rent "kodmässigt". Andra säkerhetsproblem kan påverka hur applikationen beter sig i protokoll och genom fel där öppna upp defekter. Det problemet finns givetvis även i stor utsträckning oavsett programmeringsmiljö men de gamla C-biblioteken som OpenSSL är väldigt "komplext" skrivna och inte direkt välstrukturerade för att uttrycka det milt. De skrevs för högprestanda och "C-utvecklar-status" man fick genom korta eleganta lösningar. Defensivprogrammering var (och är vanligen än idag) ingenting man tycker att själva implementationen av protokollet ska hantera trots att vissa problem måste tas redan där.

Kommer detta bli ett praktiskt problem för Chrome?

Nej det har jag väldigt svårt att tro. Här har vi ju historik för övriga webbläsare och jag tycker allt jag sett så här långt pekar på att Chrome och Chromium har en tydligt bättre säkerhetsarkitektur. Däremot hoppas jag givet de ambitioner jag uppfattar att Google har att man verkligen prioriterar säkerhetsarkitekturen på kodnivå i de delar av applikationen som binder samman delarna. Samt att man gärna engagerar sig i projekten och har egna testmiljöer av kritiska delar. Jag har inte sett över den här koden i Chromium än så vi får se längre fram hur det ser ut.

När det gäller proaktivt arbete på lägre nivå i kritiska delar verkar emellertid Google prioritera frågorna. I OpenSSL Security Advisory [07-Jan-2009]: Incorrect checks for malformed signatures ser vi att de som var först med att rapportera problemet till OpenSSL var "Google Security Team".

Problem med OpenSSL och krypteringsfolket

Den där säkerhetsdefekten är ganska kul för den pekar på ett problem hos samhället som använder OpenSSL. Det blir aldrig av för någon att göra ny dokumentation, se över saker och ting och ofta har många uppmärksammat säkerhetsproblem långt innan de rapporteras och patchar bort dem själva. Detta problem kring DSA och man-in-the-middle var nog inte direkt okänt innan.

Krypterings- och protokoll-samhället är inte så himla socialt runt säkerhetsproblem jämfört med egentligen något annat och många bryr sig inte som andra delar av säkerhetssamhället i status från att vara först med att rapportera ett problem. Just genom att sådant här ofta byggs in i egna legacy-lösningar behöver det inte kännas viktigt att rapportera och man kan rent av se en konkurrensfördel i vissa fall att avstå från det (när "alla" andra måste släppa patchar kan ditt företag rapportera att ni självklart är helt säkra mot angreppet därför att ni prioriterar kundernas säkerhet).

Hur vill Google Security Team att saker ska fungera?

De tycker att vi alla ska rapportera deras säkerhetsproblem till dom i god tid innan publicering:

"This process of notifying a vendor before publicly releasing information is an industry-standard best practice known as responsible disclosure. Responsible disclosure is important to the ecology of the Internet. It allows companies like Google to keep users safe by fixing vulnerabilities and resolving security concerns before they are brought to the attention of the bad guys. We strongly encourage anyone who is interested in researching and reporting security issues to observe the simple courtesies and protocols of responsible disclosure."
Från: Google Security and Product Safety

Där ska man ju i så fall rimligen kunna utgå från att Google själva har samma ambition när det gäller problem de upptäcker (t.ex. med Adsense eller stöld av material). Det är väl vad man kallar enkel artighet?

Själv har jag sett flera säkerhetsproblem Google har. Men inte ids jag e-posta dom. Vad som särskilt stör är att Google varit så dåliga i all annan kontakt.

SSL i Chrome

För publika klienter och servrar går det ofta men inte alltid att detektera om det är OpenSSL som används när det är fallet. Jag har emellertid inte försökt göra det för något tillhörande Google när det inte är känt. Vad som är intressant här är ju vad som används i Google Chrome. Det är inte OpenSSL utan NSS vilket är ett gammalt Mozilla.org projekt.

NSS finns under Mozilla Public License och GNU General Public License (kommer jag ihåg rätt även kanske fler GNU-licenser). Stödet är komplett för allt som krävs för att hantera SSL: X.509 v3 cert, TLS, SSL v2, SSL v3, PKCS #5, PKCS #7, PKCS #11, PKCS #12 m.m.

Skillnader mellan Network Security Services (NSS) och OpenSSL

Det stora problemet med OpenSSL är precis som jag pekat på att koden är ostrukturerad och komplex. Någon bra standardisering för kodning finns heller inte. NSS utvecklades av Netscape och var den första implementationen av SSL. Idag används det i Firefox, Sun Java produkter och mycket mer (om än inte lika många som valt OpenSSL istället). Standardisering och strukturering har hanterats bättre för NSS. För utvecklare är NSS därför lättare med fler vettiga högnivå-funktioner.

I övrigt är det inte så himla många skillnader mellan OpenSSL och NSS. De stödjer ungefär samma saker. OpenSSL tror jag dock har fler möjligheter till komprimering men det ligger nog utanför vad man kan använda i en webbläsare p.g.a. att standardisering egentligen saknas.

Är NSS bättre än OpenSSL i en webbläsare?

Det kan möjligen vara så att en fördel med NSS är att patchar av webbläsaren blir enklare p.g.a. bättre binärkompabilitet (tror jag det kallas d.v.s. att du kan byta ut mindre delar) medan man med OpenSSL säkrast kompilerar om stora delar. Men jag är väldigt osäker på om det har betydelse. Jag vet egentligen inte hur patchar normalt hanteras kring sådana här applikationer.

Fördelen OpenSSL har är att den går att få snabbare i en klient jämfört med NSS. Att skillnaden i prestanda är avgörande på något sätt har jag däremot svårt att tro. OpenSSL är dessutom mer flexibelt för utvecklaren och går därför bättre att ha till fler typer av klienter (men NSS går ofta lika bra). Någon särskild fördel här för just webbläsare finns emellertid inte och tvärtom är NSS troligen ett enklare val p.g.a. bättre strukturerad kod. Vidare tror jag nog NSS idag är säkrare än OpenSSL just därför att OpenSSL är så ostrukturerat och hård-optimerat. Därför menar jag att:

Google troligen gjorde rätt i att använda NSS.

Ett tredje alternativ hade varit GnuTLS men jag har ingen erfarenhet av det alls. Vet ingenting om det alls egentligen.

Native Client kanske används för att kapsla in kod i Chrome?

Jag såg precis nu att Google utvecklar något de kallar Native Client. Det verkar vara ungefär samma sak jag föreslog tidigare i bloggpostningen och antog / hoppades att de gjort i Chrome. De förklarar det så här:

"[...] Native Client, a technology that seeks to give Web developers the opportunity to make safer and more dynamic applications that can run on any OS and any browser. Today, we're sharing our technology with the research and security communities for their feedback to help make this technology more useful and more secure."
Från: Native Client: A Technology for Running Native Code on the Web (googleonlinesecurity.blogspot.com)

Vad det handlar om är att begränsa vad "native code" (vad kallar vi det på svenska?) får göra genom att kapsla in dem i objekt. Hur objekten får kommunicera in och ut bevakas och säkerhetskontroller går att göra. Detta är med andra ord ett angreppssätt för att göra säkerhetsproblem i begränsade delar ofarliga eller begränsa skadan de kan orsaka:

"[...]static analysis to detect security defects in untrusted x86 code."

En första version finns tillgänglig på code.google.com: Native Client. Där finns även en längre förklaring av funktionerna.

Jag har inte tittat på eller läst något mer om Native Client överhuvudtaget. Inte heller har jag kontrollerat om det används i Chrome. Det är mycket möjligt att det inte alls är tänkt att användas här utan att andra lösningar (befintliga finns) används. Istället kanske Native Client är något de vill ha till Google App Engine, Google Cache, widgets m.m. långsiktigt i det jag ofta kallar "the Google Cloud"?

Ratproxy

Ytterligare något jag såg nu för första gången var Ratproxy:

"We're happy to announce that we've just open-sourced ratproxy, a passive web application security assessment tool that we've been using internally at Google. This utility, developed by our information security engineering team, is designed to transparently analyze legitimate, browser-driven interactions with a tested web property and automatically pinpoint, annotate, and prioritize potential flaws or areas of concern."
Från: Meet ratproxy, our passive web security assessment tool

Denna tänker jag ta mig en titt på. Liknande saker finns emellertid redan innan.

Slutsats om Chrome?

Det går inte att dra någon slutsats. Här gjorde jag bara några anteckningar. Dock går det inte att komma ifrån att allt än så länge pekar på att Chrome är säkrare än alla övriga webbläsare jag känner till.

Sedan får vi se hur det blir i praktiken när jag låter Chrome prata SSL med mig via min server. Kanske hittar vi ändå något Google missade?