Visar inlägg med etikett SSL. Visa alla inlägg
Visar inlägg med etikett SSL. Visa alla inlägg

onsdag 2 februari 2011

Ny RFC om server-autentisering vid SSL/TLS

I dagarna kom en mycket intressant RFC som precis nått Proposed Standard RFC inom IETF.

Drakoniskt namn: Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)

Men den specar hur SSL-cert bör se ut och hur server-autentisering med X.509-cert ska gå till.

Tre intressanta saker som är med:
  • Sluta ange domännamn i certifikatets Common Name
  • Börja ange domännamn i subjectAlternativeName dNSName
  • Sluta med joker-certifikat, t ex *.owasp.org
Här länken: http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14

måndag 20 december 2010

Hänglåset borta i FF4

Mozilla har tagit bort hänglåset som symbol för https i Firefox 4. Istället lanserar de en site identity button. Bra eller dåligt? Diskussionen går varm på mejlinglistor och bloggar.

Läs om det hela här:
https://support.mozilla.com/en-US/kb/Site%20Identity%20Button

tisdag 26 oktober 2010

Firesheep, så funkar det

Jag blev idag intervjuad av TV4-nyheterna om cookie-sniffaren Firesheep, en plug-in till Firefox som sniffar upp sessionskakor för populära tjänster på det nätverk man är kopplad till. Intervjun var med som ett inslag i 19-nyheterna också.

Installera och testa Firesheep
Det var lite trassel att få Firesheep att funka så jag tänkte jag postar det här för er som vill testa. Observera att jag inte går i god för programmet. Det kan visa sig vara en elak bakdörr.
  1. Se till att du har Firefox 3.6.* och minst 3.6.10, t ex 3.6.11. Inte 4 beta om du inte vill experimentera.
  2. Ladda hem Firesheep från GitHub.
  3. Öppna xpi-filen med Firefox och installera.
  4. Starta om Firefox om den kräver det.
  5. Nu ska du ha en Firesheep-vy som en kolumn i vänsterkanten. Om inte så Visa -> Sidofält -> Firesheep.
  6. Under Inställningar -> Sekretess: Stäng av ev privat surfningsläge, tillåt cookies och tilllåt tredjeparts-cookies.
  7. Slå på Firesheep med knappen "Start Capturing".
  8. Öppna en annan webbläsare, t ex Chrome.
  9. Logga in på Facebook, Twitter eller Flickr i Chrome.
  10. Kolla Firesheep-vyn i Firefox. Där ska dina olika konton ha dykt upp.
  11. Dubbelklicka på något av dina konton i Firesheep och vips så har du genomfört en session hijacking.
Om du nu suttit på ett öppet trådlöst nät så hade alla andra aktiva sessioner dykt upp i din Firesheep-kolumn. Notera att det är olagligt att utnyttja andras sessioner utan tillstånd. Att avlyssna nätverket och titta på listan är dock helt OK.

Förkonfigurerade tjänster som Firesheep sniffar
Följande tjänster/domäner är förkonfigurerade i Firesheep:
  • Amazon.com
  • Basecamp
  • bit.ly
  • Cisco
  • CNET
  • Dropbox
  • Enom
  • Evernote
  • Facebook
  • Flickr
  • Foursquare
  • GitHub
  • Google (dock ej GMail numer)
  • Gowalla
  • Hacker News
  • Harvest
  • Windows Live
  • New York Times
  • Pivotal Tracker
  • ToorCon: San Diego
  • Slicehost SliceManager
  • tumblr.com
  • Twitter
  • Wordpress
  • Yahoo
  • Yelp

Den underliggande sårbarheten
Vad är då sårbarheten? Jo, tjänster såsom Facebook krypterar bara trafiken vid inloggning (ditt lösenord är alltså skyddat). Efter det så går Facebook tillbaka till okrypterad trafik. Din sessions-cookie är det som Facebook identifierar dig med efter inloggning och den skickas i klartext vid varje anrop till Facebook. Det är den trafiken som Firesheep avlyssnar och plockar upp sessions-info från.

Med din sessions-cookie i min webbläsare så är jag lika inloggad som du är.


PS.
Eftersom det valsat runt så mycket felaktig information så vill jag poängtera två saker:
  1. Firesheep är en plugin till Firefox, dvs ett tilläggsprogram. Det hela handlar alltså inte om något säkerhetshål i Firefox. Det vore lika dumt som att påstå att Windows har problem för att någon skrivit en nätverksskanner som körs på Windows.
  2. Offret kan surfa med valfri webbläsare – Safari, Internet Explorer, Opera, Firefox, Chrome och så vidare. Session hijacking med hjälp av cookies är inte begränsat till en viss webbläsare.
DS.


/John Wilander, chapter co-leader

fredag 24 september 2010

Mozillaprojekt om CA-cert-policy

I kölvattnet av alla SSL-/PKI-skandaler kring hantering av CA-cert (bloggpost 1, bloggpost 2, bloggpost 3) så har nu Mozilla startat ett projekt för att uppdatera sin certifikatspolicy för Firefox, Thunderbird med mera. Mozilla har som bekant en egen lista på godkända CA-cert och förlitar sig inte på operativsystemet som andra webbläsare. Det här kan vara chansen att göra något åt ett av de stora problemen med SSL.

Jag har gått med på mejlinglistan där det hela kommer att hanteras. Gör det ni med! Notera att Mailman i vanlig ordning skickar ut ditt valda lösenord i klartext i välkomstmejlet så använd ett slasklösen.

Föredrar man newsgroups så finns det med:

lördag 21 augusti 2010

Säkrare SSL med Strict-Transport-Security

En riktig säkerhetssnackis har varit Strict-Transport-Security (STS) som motmedel mot ett flertal av de man-in-the-middle-attacker som presenterats mot SSL/HTTPS. Nu var det till och med tema i veckans Steve Gibson-podcast "Security Now!" så det är hög tid att skriva om det här.

Användarna accepterar varningar
Vem har inte sett sin webbläsare varna för ett felaktigt SSL-cert? Och vem har inte klickat vidare i övertygelse om att det ligger slarv bakom, dvs att driften inte köpt och driftsatt nytt cert i tid?

Jag har faktiskt bara träffat en IT-människa som verkligen bromsat in vid den där varningssidan och han var inte någon säkerhetskille. Det var en utvecklare "på andra sidan" mitt projekt som mejlade oss och cc:ade beställare och chefer för att påtala denna "show stopper". Han skulle göra ett anrop till vår testmiljö där vi självklart inte körde med ett skarpt cert. Vi fick mejla honom plus alla chefer och förklara att han fick göra ett säkerhetsundantag.

Men om vi bortser från denna enda person så är beteendet där ute att klicka sig förbi varningen. Folk i gemen har vant sig vid att webbsidor kan orsaka varningar men fungera bra. Så vad säger att internetbanken inte ska kunna uppvisa en sån varning? Vips så har vi sänkt ribban rejält för man-in-the-middle. Attackeraren behöver inte skapa ett SSL-cert signerat av en godkänd CA om offret ändå godkänner hans/hennes fulcert.

Strict-Transport-Security lovar "Inga fulcert"
Idén bakom Strict-Transport-Security är att webbservern kan publicera en header som säger:
"Jag levererar bara sidor över https och garanterar att jag inte kommer köra med ett ogiltigt certifikat. Om du skulle få svar på den här adressen med ett ogiltigt certifikat så ska du på inga villkor tillåta användaren att klicka sig vidare. Detta gäller i X sekunder framåt."

Formellt ser svaret från servern ut så här (verkligt exempel från https://www.paypal.com/se):

shell> curl -i https://www.paypal.com/se

HTTP/1.1 200 OK
Date: Sat, 21 Aug 2010 19:47:14 GMT
Server: Apache
Cache-Control: private
Pragma: no-cache
Expires: Thu, 05 Jan 1995 22:00:00 GMT
Set-Cookie: [snip/]; domain=.paypal.com; path=/; Secure; HttpOnly
(... fler cookies ...)
Vary: Accept-Encoding
Strict-Transport-Security: max-age=500
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

Servern kan också lägga till information om att regeln ska gälla alla subdomäner. Grammatiken ser ut så här:

Strict-Transport-Security =
"Strict-Transport-Security" ":" "max-age" "=" delta-seconds [ ";" "includeSubDomains" ]

Webbläsaren tillåter inga fulcert
Grunden till STS-funktionen är att en STS-medveten webbläsare (just nu bara Chrome och Firefox med NoScript) måste avbryta kommunkationen med en STS-sajt om certifikatet är ogiltigt. Det får inte finnas en chans för användaren att klicka sig förbi någon sorts varning. Tuffa tag helt enkelt.

Ett annat krav på en webbläsare som förstår STS är att den automatiskt gör om alla HTTP-anrop till HTTPS-anrop om det är en STS-sajt med giltig tidsstämpel. Det hindrar attacker i stil med SSLStrip.

Webbläsaren noterar servern som STS
När en STS-medveten webbläsare får en STS-header så måste den:
  • Lägga till servern till sin lista över kända STS-servrar
  • Uppdatera informationen om max-age och includeSubDomains om dessa fält skiljer sig från vad som sparats tidigare för den servern
Om webbläsaren får en HTML-kodad HTTP-header med STS, t ex ...

<META HTTP-EQUIV="Strict-Transport-Security" VALUE="max-age:0">

... så får den taggen inte användas. Annars skulle en attackerare kunna injicera STS-direktiv.

Server-konfiguration
Om man överväger att använda STS på sin server så är det några saker man ska tänka igenom.

Först är förstås hur bra man är på att sköta sina SSL-certifikat eftersom en STS-sajt helt enkelt inte kommmer att fungera om certet är ogiltigt. Har man ett kalendarium? Som fler än en person har ansvar för? Med rutiner som fortfarande funkar om tre år när certet går ut? Jag har mött alltför många organisationer som har dåligt samvete över sin obefintliga hantering av SSL-certifikat.

Sen måste man bestämma sig för en strategi för tidsstämplarna. Ska man alltid svara med ett fast tidsspann, t ex en vecka eller ska man svara med antal sekunder kvar tills certet går ut?

Svenska internetbanker kör inte STS. Än.
OK, tämligen få webbläsare har ännu stöd för STS men inget hindrar seriösa tjänsteleverantörer att implementera STS på sina HTTPS-servrar. Jag kollade de fyra stora internetbankerna. Ingen av dem kör STS. Än.

Tomma resultat för följande curl-anrop:

curl -i https://internetbank.swedbank.se/SecurityServer/SecurityServer | grep "Strict-Transport-Security"

curl -i https://internetbanken.privat.nordea.se/nsp/engine | grep "Strict-Transport-Security"

curl -i https://taz.vv.sebank.se/cgi-bin/pts3/wow/wo10.c1010.f001?I= | grep "Strict-Transport-Security"

curl -i https://secure.handelsbanken.se/bb/glss/servlet/prelogon?id=seprivsv | grep "Strict-Transport-Security"

lördag 29 maj 2010

Dödskalle vid trasigt SSL-cert

Google Chrome börjar visa en röd dödskalle vid felaktigt SSL-cert.


Chris Evans (en av talarna på sommarens konferens) skriver följande:

"The great thing about red skull + crossbones is that it highlights the site is broken and creates pressure to fix it."

Andra involverade i Chromium är tveksamma:

"Users have no control over the site, and they do have choices in browsers, so unless all browsers do it, most users will believe the browser is broken, not the site."

Det riktigt intressanta är att man överväger att visa dödskallen vid allvarliga varianter av mixat http/https-innehåll, ett vanligt problem vid mashups.
  • Varning vid mixat innehåll med ex. <img> ger "spökhänglås" + grå https-text
  • Fel vid mixat innehåll med ex. <script> ger dödskalle + röd https-text

fredag 21 maj 2010

Forefront TMG gör MitM på din SSL

Ni kanske läste mitt inlägg om hur myndigheter och säkerhetstjänster kan avlyssna SSL genom proxies och utfärdande av korrekta SSL-certifikat on the fly?

Det är precis samma sak som Microsoft Forefront Threat Management Gateway gör.

Microsoft Forefront TMG gör Man-in-the-Middle
Microsoft beskriver själva sin teknik på Technet:

"In order to inspect outgoing HTTPS traffic, Forefront TMG breaks the HTTPS connection and then acts as an intermediary or "man in the middle" between the client that initiated the connection and the secure Web site."

Det går till så här:
  1. Sysadmin på arbetsplatsen ser till att ett så kallat HTTPS inspection certificate finns installerat i alla klientdatorers Trusted Root Certification Authorities certificate store
  2. Klienten gör ett anrop till en https-sajt
  3. TMG går in och bryter anropet
  4. TMG sätter upp en egen SSL-koppling till den begärda sajten och kontrollerar det SSL-cert som sajten autentiserar sig med
  5. TMG kopierar webbsajtens SSL-certifikat, skapar ett nytt SSL-certifikat med samma uppgifter, och signerar det med HTTPS inspection certificate
  6. TMG sätter upp en https-koppling till klienten mha det nya SSL-certifikatet
  7. Klienten accepterar det nya certet som korrekt för den begärda sajten eftersom HTTPS Inspection-certet finns bland de betrodda CA-certen
Det är så din arbetsgivare kan spionera på din SSL-trafik.

torsdag 29 april 2010

Köp SSL-cert till nån annans domän

I raden av "det går dåligt för SSL"-inlägg har vi nu kommit till ännu en CA-fadäs.

Kurt Seifried skriver i sin artikel Impersonating secure web servers -- Breach of Trust (pdf) om hur han har lyckats köpa äkta SSL-cert till flera leverantörer av e-post på nätet. Hur? Jo, flera CAs vill verkligen sälja många cert. Så de underlättar för kunden.

Att göra det lätt för kunden
Vad är jobbigast i att köpa ett cert? Ptja, kanske att generera nycklar och ett certificate signing request (CSR). Därför har CAs sett till att beskriva det steg för steg på sina sajter, t ex RapidSSLs beskrivning för Apache.

Sen då? Ja, det är väl att bevisa att man äger domänen i fråga eller åtminstone har rätt att köpa cert till den. Att faktiskt legitimera sig var nog tanken en gång i tiden men nu köper man cert på distans så en e-postadress till domänägaren får duga.

Ofta brukar det vara någon chef som står som registrator. Den publika informationen på Whois har i mångt och mycket försvunnit pga risken för spam så CAs har försökt komma på andra sätta att mejla domänägaren. webmaster@domänen.se borde väl duga? Och root@domänen.se. Och admin@domänen.se. Och ... ja, listan har blivit rätt lång för t ex RapidSSL:
  • admin@
  • administrator@
  • hostmaster@
  • info@
  • is@
  • it@
  • mis@
  • postmaster@
  • root@
  • ssladmin@
  • ssladministrator@
  • sslwebmaster@
  • sysadmin@
  • webmaster@
Håller e-postleverantörerna koll?
Nu kan man ju fråga sig om e-postleverantörerna på nätet har reserverat alla de här adresserna? Svaret är förstås nej. Kurt fick tag på ssladministrator@-adresser på:
  • Inbox.com
  • Excite
  • Lavabit
  • Mail2World
  • Ovi (Nokia)
... och då var det bara att köpa SSL-cert till de domänerna!

John är nu ssladmin@spray
Kul, tänkte jag, och registrerade mig snabbt som ssladmin@spray.se (ni når mig där numer :). Jag försökte köpa ett SSL-cert till spray.se* men RapidSSL hade skurit ner till betydligt färre tillåtna e-postadresser efter Kurts artikel. Dessutom kändes det lite dumt trots att min avsikt var att skänka certet till Spray tillsammans med lite upplysning.

Slutsatser
Så vad kan vi säga efter det här? Jo, att ...
  • CAs återigen visar sitt ointresse för säkerhet
  • Vi har inga globala identiteter på nätet och en e-postadress är ett dåligt substitut för det när det handlar om säkerhet
  • SSL fortsätter att ta stryk vilket borde skicka en varningssignal till alla som satsat allt på "Military grade encryption, 128 bit"

* Jag upptäckte sen att Spraymail inte kör https alls, inte ens på inloggningsformuläret. Tjena.

söndag 11 april 2010

Övervakning trots SSL

SSL/TLS har fått mycket stryk på sistone. För ett par veckor sedan var det dags igen. Christopher Soghoian från Indiana University och Sid Stamm med kopplingar till säkerhet på Mozilla släppte en draft på sin artikel "Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL" (pdf).

Snabbt om PKI och SSL
Jag misstänker att de flesta som läser här har koll på infrastrukturen bakom PKI men låt oss rekapitulera snabbt.

För att din webbläsare ska kunna avgöra att https://internetbanken.privat.nordea.se verkligen tillhör Nordea så verifierar den Nordeas certifikat. Certifikatet ska vara signerat av en betrodd certifikatsutfärdare (certificate authority, CA). Den signerande utfärdaren kan i sin tur vara signerad av en annan certifikatsutfärdare och på så vis uppstår en förtroendekedja. Högst upp i kedjan finns ett så kallat rot-certifikat. Ungefär så här:



Många rot-certifikat blir det
Men hur vet webbläsaren att den ska lita på rot-certifikatet? Jo, den har en förinstallerad lista på vilka rot-certifikat den ska lita på. Man skulle kunna tro att det är en någorlunda kort lista som alla världens webbläsare litar på. Så är det emellertid inte.
  • Windows: Litar automatiskt på 264 rot-certifikat
  • Mac OS: Litar automatiskt på 166 rot-certifikat
  • Firefox: Litar automatiskt på 144 rot-certifikat (bortser från operativsystemets lista)
Din webbläsare godkänner alltså att 150-250 olika organisationer utfärdar ett godkänt certifikat för https://internetbanken.privat.nordea.se. Eller för den skull https://mail.google.com och https://dittföretag.se. I webbläsaren kommer det se likadant ut oavsett vilken organisation som utfärdat det.

Många stater har rot-certifikat
OK, vilka är då dessa hundratals organisationer som vi alla litar på? Ptja, många stater finns med, t ex litar Windows på staten i:
  • Brasilien
  • Finland
  • Frankrike
  • Hong Kong
  • Indien
  • Japan
  • Korea
  • Lettland
  • Macao
  • Mexiko
  • Nederländerna
  • Portugal
  • Serbien
  • Slovenien
  • Spanien
  • Schweiz
  • Taiwan
  • Tunisien
  • Turkiet
  • USA
  • Uruguay
  • Österrike
Myndigheterna i de länderna kan alltså utfärda godkända certifikat för https://mail.google.com och avlyssna din trafik dit. Du kommer inte märka någonting.

Hur avlyssna i praktiken?
Hur skulle då staten göra i praktiken? Det är inte så smart av t ex spanska staten att direkt utfärda bluffcertifikat för avlyssning. Bluffen går att härleda till dem och webbläsartillverkarna skulle nog ta bort deras rot-certifikat ganska snabbt. Nej, istället så tvingar man, ofta med laglig rätt, en privat rot-CA att skapa en intermediär certifikatsutfärdare åt den myndighet som vill avlyssna. Det motsvarar en mittenlänk i kedjan ("subCA" i bilden ovan). Med en sådan intermediär utfärdare kan myndigheten skapa godkända certifikat på löpande band!

Nu gäller det bara att befinna sig någonstans mellan offret som ska avlyssnas och den server offret surfar till med https. När uppkopplingen sker så skapas ett godkänt bluffcertifikat direkt (om det inte redan finns från tidigare avlyssning) och allt ser bra ut hos offret. Det fungerar så här:


Men sånt händer väl inte?
Nu har väl John halkat för långt ner i konspirationsteorierna i alla fall? Nope. Författarna till artikeln började nämligen rota i det här efter att de på en mässa om övervakningssystem kommit i kontakt med Packet Forensics, ett företag från Arizona i USA.

I sin monter marknadsförde Packet Forensics små övervakningsenheter för nätverk. Deras "turnkey intercept solution" möjliggör "packet modification, injection and replay capabilities" i Gb/s-hastighet. Vidare säger de:

"To use our product in this scenario, users have the ability to import a copy of any legitimate key they obtain (potentially by court order) or they can generate ‘look-alike’ keys designed to give the subject a false sense of confidence in its authenticity."

Företaget berättar att "government customers have compelled CAs into issuing certificates for use in surveillance operations". Känns ... så där.

Tänkvärt
I ljuset av ovanstående ger jag bara en liten lista på tänkvärda ämnen:
  • Kinas övervakning av oppositionella
  • USA vs EU i industrispionage, inkl Echelon
  • FRA-debatten
  • Förinstallerade företagsinterna rot-certifikat
  • Alla organisationer man möter på som svarar "SSL!" på alla frågor om säkerhet ...