Microsoft Azure: SSL-problem (igen)

2/24/2013

Det blir lätt komiskt när åtminstone en tämligen kreativ tolkning av vår ordlek med Microsoft produktnamn relaterat up diskuterades som ett ex. (lika bra som något annat man antagligen kan hitta) rörande en del potentiella möjliga problem tycks uppvisa "nuhet" eller "horoskop-kvalitet":



Jag kände dock inte ens till tjänsten och även om jag tycker konceptet molntjänster generellt verkar lovande är min allmänna princip kring nytt inom IT att när det blivit tråkigt och är en 8 - 12 år inkört börjar det bli lagom att pröva på (Ubuntu var jag i brott mot mina principer cirka 1 år tidig på - endast sju år gammalt - men då bygger det ju ändå till 98% på allt i övrigt runt Linux förutom lite extra-stöd runt installationen och configuration management: Första release "20 October 2004; 8 years ago" enligt Wikipedia).


Egentligen hade jag inte tänkt skriva något om det därför att jag inte vill utesluta att läsare felaktigt kunde tolka Är Microsofts DataUp bättre eller sämre än verklighetens DataDown? (2013-02-22) lite personlig, och i så fall denna p.s.s. Nu har jag emellertid senaste väldigt många år ett särskilt intresse av SSL liksom liknande lösningar som SPKM (och lite längre ut Kerberos), och vill allmänt gärna följa "security events" relaterat SSL som tycks beröra större infrastruktur. I kontext av att spara sådana händelser är den lösning som fungerar enklast och mest kostnadseffektivt att blogga det. Korrekt här ser man det som jag egentligen inte bryr mig om det är Microsoft eller något annat IT-företag. En korrekt förtroendeingivande lista av ett mindre urval i form av vad publicerat just Hans Husman om Information Warfare finns sist i Relaterat: SSL, och ger också en del konkretiserade exempel för vad som berörs i slutet ytterst kortfattat (nu när Microsoft säkert redan är ganska nedstämda och ledsna över det här problemet vill jag inte att dom ska känna att jag mobbar dem).


Predikterbarheten om den alls finns som utomstående har vi dock i diverse tidigare problem att hantera certifikaten både Microsoft och andra haft, och rent av för samma tjänst:



Om Microsoft haft större problem än andra generellt inom t.ex. molntjänster vet jag inte men om så verkar det kanske inte orimligt genom att jag har för mig att de har egen katalog-hantering som är tämligen varierad i plattformarna den är implementerad på. Alla X.500-standarderna liksom X.509 (att för den tidsrika- och över-ambitiösa läsaren laborera med via OpenSSL) är inte helt triviala i representation (ASN.1) vilket egentligen just för certifikat idag inte ska behöva vara ett problem men kanske lättare blir det ju mer av lösningen man själv tagit ansvar för och därmed kanske lättare anpassar av och till när det upplevs nödvändigt eller praktiskt för att möjliggöra något vilket ju inte sällan åtminstone när jag programmerar tenderar att ge underliga fel.


Uppgifter från användarna tycks i alla fall indikera att det är just server-certifikaten som gått ut även om jag inte klarade att hitta någon information från Microsoft:



Oavsett problemet med tillgänglighet när en molntjänst (för vilka den poäng jag kan se är att man ska slippa bry sig i allt som annars av och till orsakar problem - inte minst att saker går ner p.g.a. slarv - genom standardiserat arbete och quality assurance som når en längre genom att väldigt många användare delar utvecklingskostnaden för plattformen samtidigt som nersidan för leverantören blir så mycket större när en mängd kunder drabbas samtidigt istället för ett fåtal) ska säkerhetsproblemet heller inte underskattas enligt t.ex. nedan:


"According to Microsoft, the outage that affected Azure was due to something as minor as an expired SSL certificate."

[Red. Referensen till Microsoft tror jag inte stämmer utan är nog snarare användarnas diskussion.]

Från: Expired SSL certificate causes Microsoft Azure outages | Slashgear.com

Om vi börjar utanför den specifika instansen av problem indikerar det att man inte har kontroll över sina server-certifikat där andra problem inte lika uppenbara möjligt också kan vara fallet. Att dom nya certifikaten endast tycks vara giltigt ett fåtal månader indikerar kanske att man insett detta problem utan att åtminstone rörande alla kompetenser varit medvetna om det. De kortare certifikaten kanske just nu får kort giltighet för att ge tid att verifiera att de i övrigt är sunda (rörande hashfunktioner-använda, asymmetriskt lösning och associerat generering av nonsen resp. symmetriska nycklar för resp. session). Alternativt att man inte vill utesluta att CA-server i den egna infrastrukturen en bit upp vidrörts av något som inte borde ha varit i närheten av dom.


För det specifika fallet gäller det ju verkligen för att någon säkerhet över en större population klienter ska bibehållas att tjänsten korrekt gick ner direkt när certifikaten gick ut. Om inte generellt finns ju alltid risken - genom att dom här lösningen när så inte är fallet låter klienten göra ett avgörande - risken och problemet att klienten just kan välja att acceptera ett certifikat som gått ut. Kan de verifiera att en mängd andra användare har problem samtidigt är det ett ganska enkelt beslut att fatta potentiellt felaktigt om man har behov av att komma åt något. Någon god möjlighet att verifiera certifikatet man accepterar finns inte på det sätt som de flesta kommer göra det och därmed kan sessionen vara öppen för vad helst som befann sig framför en viss tjänst.


Även om så ev. kanske inte var möjligt om tjänsten stängde ner korrekt ska man inte utesluta att sådant här kan ske prospekterande mot givna användare. Det kan tyckas lite underligt särskilt om vi går så långt att vi inte utesluter att själva hanteringen av certifikaten server-side tagits ner som del av ett riktigt angrepp. Emellertid om säkerhetsarkitekturen för molntjänsten är något så när vettigt gjord ska den vara avgränsad och utan att access till en viss del av lösningen öppnar upp allt över alla användare. Just här behöver det ju inte vara mer än att underordnad katalogserver klarats att kanske isolerats i nätet. En känsla jag har är att ganska mycket skett riktat prospekterande över en mängd företag och tjänster sista 10 - 11 veckorna (om inte mer). Det här tycks väl kanske inte lika troligt vara en del av det men det återstår att se om nu Microsoft kommer ge mer information när deras utredning är klar av orsakerna.


Lämnar vi Microsoft och ser mer allmänt på detta problem och liknande är känslan att det i mycket har att göra med att SSL ofta egentligen inte ses som del av säkerhetsarkitektur med förståelse och hantering av aktuella grupper av problem på det sätt som krävs för att man ska få säkerhet i nivå med det förtroende man vill att SSL ska kommunicera till användarna. Både hur SSL-sessioner parametriseras, server-stöd aldrig uppdateras avseende protokoll, underliga fallback till "mindre" säkra konfigurationer, ständiga problem med server-certifikat lite överallt o.s.v. är det om inte så vad vi åtminstone behöver förklara med att för mycket ansvar för säkerhetslösningen ligger där den idag för ofta inte hanterats bra. Tråkigt räcker det knappast helt även om det började skötas exemplariskt på server-sidan. Lösningen för boot-strapping av betrodda certifikat hos klienten är inte direkt helt optimala inte sällan byggande på principen att man laddar ner en webbläsare eller helt operativsystem utan SSL eller får på ej betrott medium i vilken server-certifikaten vi litar kommer med.


SSL-branschen har dock alltid varit mycket förtroende i vad som går att göra och kan visas upp. Ex. väldigt säker hosting för några enstaka centrala certifikat-server väldigt högt upp i nätverken medan det mesta under mycket verkligare för säkerheten oftare sköts lite hur som helst. Och det är överhuvudtaget på många sätt både en väldigt framgångsrik och värdefull säkerhetsprimitiv såväl som en lösning på alla sätt mindre bra än vad som egentligen är önskvärt. Praktiskt igång och vad folk använder kontra något som skulle vara ett större djävulskap likt föga annat att få ut och nå acceptans för hos både användare och "servrar". Ungefär som väldigt mycket annat i vår vardag (ex. cigarett-filter: fortfarande massor av lungcancer, hjärt- och kärlsjukdomar o.s.v. men påminner i alla fall rökarna dagligen om att röken är farlig nog att "kräva" filtrering).


Relaterat: SSL





Cloud computing Microsoft Microsoft Azure Molntjänster OpenSSL SSL
0 kommentarer

Kommentera