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"
8 kommentarer:
För mig verkar rimligt att kommunicera STS via DNS (skyddat med DNSSEC förstås) - på så sätt skyddar man mot det som draften kallas "Bootstrap MITM Vulnerability", dvs man blir inte sårbar för tidiga janusattacker. Har du sett mer några diskussioner om detta?
Att som i Firefox ha förkonfigurerade listor över webbplatser som har STS känns inte direkt skalbart...
Hej Jakob!
Ja, DNSer med DNSSec har ju föreslagits leverera det publika SSL-certet också (av dig!) så en sån här policy skulle säkert kunna skötas av DNS. Tillsammans blir de två åtgärderna väldigt slagkraftiga.
Det enda jag kommer att tänka på är ansvarsfördelning och driftsättningscykler. Här talar vi ju om utvecklare av en https-sajt, driftsättning av denna på en webb- och appserver och hantering av DNS-information för domänen inkl subdomäner. Ett beslut i ena änden kan påverka en massa saker under domänen och testningen kan riskera att fallera pga olika DNS internt och externt. Ofta är kontaktvägarna längre mellan utvecklare och DNS-ansvarig än mellan utvecklare och ansvarig för webb- och applikationsserver. Därför får man lov att vara ännu mera noga med sina rutiner om man ska leverera STS-info via DNS. Håller du med?
Det är nog Chromes "Preloaded HSTS" du menar med förkonfigurerade listor (http://sites.google.com/a/chromium.org/dev/sts). Men jag håller med. Känns som en amerikan som tänkte på ca 100 amerikanska domäner :).
Det här med ansvarsfördelning kommer ofta upp på tapeten, men som jag ser det är det inte mer konstigt än att MX-posterna måste peka på rätt mailserver, att A-posten t.ex. pekar på rätt webserver och att SRV-posterna pekar på rätt jabber-server. Dvs, DNS-adminstratören har redan ett stor ansvar och det måste bli rätt där också.
Å andra sådan kanske det inte skadar att deklarera STS på flera ställen, precis som att certifikat i DNS kompletterar EV-cert från en traditionell PKI.
(STS) som motmedel mot alla man-in-the-middle-attacker som presenterats mot SSL/HTTPS.
Nu har jag inte hunnit läsa allt om STS, men på vilket sätt skyddar STS mot MITM där attacker har en giltig SSL-cert "kopia"? De senaste attackerna har mig veterligen handlat om att skapa giltiga SSL-cert, endera via NULL-exploit eller via ssladmin@ svagheten, och i extrema fall via organisationer som sitter på godkända CA-cert och därefter kan generera giltiga SSL-cert i realtid. För att SSL skall motverka MITM krävs det nog betydligt mer än STS.
@Simson1
Helt rätt – STS skyddar inte mot alla MitM-attacker som presenterats mot SSL/TLS. Om en attackerare har ett godkänt cert så hjälper inte STS.
Han/hon kan få tag på ett godkänt cert på flera sätt. Dels de du nämner:
- Utnyttja buggar i webbläsarens hantering av certen (null-terminering, signera med icke-signeringscert, ...)
- Utnyttja svagheter hos CAs (@ssladmin ...)
- Beordra CAs att ställa ut giltiga cert/signeringscert
- Vara en betrodd CA och bete sig bedrägligt
Men förstås också på andra sätt såsom:
- Hashkollisioner för att återanvända giltiga signaturer
- Installation av betrott rot-cert hos klienter som med Forefront TMG
Jag har därför omformulerat meningen du kommenterade. Tack!
Jag har inte heller kollat in STS tidigare, men en sak slår mig: hur svårt är det att droppa STS-headern från servern när man reläar trafiken vidare till offret?
Antar att tanken är att de där 500 sekunderna skall skydda - isåfall får man hoppas att offret har varit uppkopplad på den legitima sajten inom tio minuter innan han kopplade upp sig på det osäkra nätverket där MITM sitter och lurar. Paypal kanske isåfall borde köra bortåt en vecka istället, minst...
@Martin
Jag håller med. Blev rätt förvånad när jag såg PayPals 500 sekunder. Andra sajter jag kollat har typ ett år eller så.
Numera en bank åtminstone...
curl -i https://internetbank.swedbank.se/SecurityServer/SecurityServer | grep "Strict-Transport-Security"
Strict-Transport-Security max-age=1200; includeSubDomains
Skicka en kommentar