Taggat med: tls

DNStapir – Robust DNS

Jag tog ett snack under sommaren Olle E Johansson som är en av initiativtagarna bakom projektet DNSTapir. Olle berättar mer om projektet:

Fokus vad gäller DNS har varit mycket på hur man kan skydda sina frågor från insyn och hur vi kan lita på svaren. Vi såg att det finns mycket information i loggarna från DNS resolvers, dom som förmedlar svar, som är värd att analysera. Det görs idag, men i många fall av utländska aktörer som förser oss med gratis resolvertjänster. Vi vill se till att loggarna anonymiseras och att vi kan analysera data och se vad som händer, inte minst ur cybersäkerhetssynpunkt.

Med stöd av Sunet/Vetenskapsrådet bildade vi projektet Robust DNS som nu fått projektmedel av Post- och Telestyrelsen. Organisation: Vi är nu i en uppstartsfas av ett utvecklingsprojekt och ett Open Source-projekt. All utveckling kommer att ske öppet i vårt projekt ”DNStapir” på Github. Dagens gäng är initiativtagarna – däribland Lars Johan Liman på Netnod, Johan Stenstam på Internetstiftelsen, Jakob Schlyter på Kirei och Mikael Kullberg på Cat Herd. Leif Johansson på Sunet satte oss i samma rum och har fått igång projektet.

DNSTapir Robust DNS

Vi har också resurser från Sunet i projektet och kommer att utvidga vårt nätverk och bygga en långsiktig organisation. Jag har en sammahållande funktion i det hela.  Partners bakom projektet är idag PTS, Sunet/Vetenskapsrådet, Netnod och Internetstiftelsen. Vi kommer att söka samarbete med fler organisationer, både i näringslivet och i offentlig sektor. Framtidsplaner: Vi jobbar nu med steg 1: Utveckling av arkitektur och programvara.

Samtidigt planerar vi för kommande steg som innebär att bygga för drift och ge oss en stabil grund för vidare utveckling. Idéerna sprudlar och vi har många roliga diskussioner i arbetsgruppen. Målet är att vi ska bygga en plattform som olika operatörer – såväl privata som i offentlig sektor – har förtroende för. För att lyckas krävs ett samarbete, inte minst med Sveriges internetoperatörer. Vad gäller DNS generellt så är jag nog inte rätt person att svara, men har ju expertisen i projektet. Det pågår ju mycket arbete i IETF för att öka privacy i DNS och stärka infrastrukturen. Ett problem jag ser är ju att DNSSec inte har acceptans i alla kretsar och i viss mån motarbetas.

Personligen är jag ju intresserad av att förankra klient- och server-certifikat i DNS, vilket förutsätter DNSsec. Jag är med i arbetsgruppen DANCE som jobbar med klient-cert. Den lösningen handlar mer om TLS och applikationer än själva DNS, men förutsätter DNSsec.

Kontaktuppgifter: Om man har frågor får man gärna kontakta mig direkt. Som sagt, vi bygger upp en organisation inklusive web sajt och kommer att synas mer under hösten. Projektet DNStapir finns redan på GitHub och där kommer det löpande komma mer kod och ges möjlighet att medverka.

Två nya sårbarheter i OpenSSL

Den som följer mig på LinkedIn vet att jag flaggade upp för en eller flera nya sårbarheter i OpenSSL. Idag den 24:de Augusti så släpptes informationen om dessa.

Sårbarheterna återfinnes dels i ASN.1-hanteringen (no suprise) samt hanteringen av SM2-signaturer. SM2 är framtaget av Kina och återfinnes som standarden ISO/IEC 14888 (GM/T 0003-2012).

Gällande ASN.1 så skriver OpenSSL-projektet följande:

If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext).

Sårbara funktioner listas bl.a. X509_get1_email(), X509_REQ_get1_email() och X509_get1_ocsp().

Den allvarligaste är SM2-hanteringen som är en buffer-overflow, men troligtvis används av färre.

Varför är dessa två sårbarheterna allvarliga? Jo det är så att OpenSSL och dess olika forkar såsom BoringSSL återfinnes i många hundratals miljoner enheter och mjukvaror. Att patcha och åtgärda sårbarheter kommer att ta otroligt lång tid.

Mer information om sårbarheterna hittar du här: https://www.openssl.org/news/vulnerabilities.html

Krypterad SNI i TLS 1.3

Server Name Indication (SNI) är den del av TLS som berättar för servern till vilken webbserver du vill besöka. Detta behövs om din webbserver bara har en IP-adress men flertalet certifikat. Detta fält går i klartext och gör att någon som kan se din nätverkstrafik också kan se vilken webbserver du besöker.

För att göra det svårare har bl.a. Domain Fronting används av såväl Tor som skadlig kod för att försvåra analys av nätverkstrafik men detta är något som flertalet leverantörer såsom CloudFlare nu stängt ner.

Följande bild förevisar bra där server_name skickas i klartext under handskakningsprocessen:

Firefox släppte precis stöd för ESNI (encrypted SNI) i sin nightly build. Du kan testa att ESNI fungerar genom att surfa till följande URL. Och glöm inte att slå på DoH:

Att ta fram en lösning som krypterar SNI var inte helt trivialt eftersom det rör sig om ett ”hönan eller ägget”-problem. Men för att lösa detta problem så används en ny nyckel hos klienten samt en ESNIKeys-structure som placeras i DNS:

Givetvis bör krypterad DNS också användas:

Moreover, as noted in the introduction, SNI encryption is
less useful without encryption of DNS queries in transit via DoH or DPRIVE mechanisms.

För mer matnyttig läsning rekommenderas följande IETF-draft:

 

TLS 1.3 är nu ute som RFC 8446

Jag har tidigare skrivit om nya versionen av TLS som kommer att bli version 1.3. Denna nya version har nu fått en RFC (Request for Comments) vilket kan anses av många som en standard på internet. Det är ungefär 10 år sedan TLS 1.2 släpptes.

En av anledningarna till att det tagit så lång tid att få ut denna RFC beror på middleboxes (mellanliggande utrustning på internet) som lägger sig i TLS-kommunikationen. Och för att undersöka detta så behövs det data från hur det ser ut ute i nätverken.

RFC 8446 är på 160 sidor och min favorit är Appendix E som beskriver säkerhetskomponenterna i TLS 1.3.

För att citera Facebook som använder sitt eget bibliotek Fizz:

More than 50 percent of our internet traffic is now secured with TLS 1.3

ISOC samt IETF har även skrivit om TLS 1.3:

 

Mängder av svenska sajter sårbara för ROBOT-attacken

Uppdatering: Skatteverket var snabba och patchade redan i måndags. Så Kronofogden, Skatteverket samt E-legitimationsnämnden är ej längre sårbara.

Många kritiska och viktiga svenska sajter är sårbara för den senaste ROBOT-attacken: Jag har genomfört en skanning av sajter som återfinnes under .SE och som underlag använde jag denna domänlista. Skanningen av sajter som är sårbara för ROBOT-attacken är genomförd med hjälp av verktyget testssl.sh och på listan med sårbara sajter nedan ser vi många banker, myndigheter och kommuner.

Attacken är dock svår att utnyttja eftersom det kräver att du som angripare kan avlyssna https-surf samt så finns det ingen programkod för att utnyttja attacken publicerad än så länge.

För mer information om ROBOT-attacken, läs här.

Av 807 testade sajter så är 119 st sårbara, hela listan med sårbara sajter hittar du här:

agria.se
aklagare.se
alecta.se
almhult.se
ange.se
apl.se
apoteksgruppen.se
arboga.se
askersund.se
avanza.se
avesta.se
bergslagenssparbank.se
bgc.se
bilprovningen.se
bolagsverket.se
bollebygd.se
boras.se
botkyrka.se
bracke.se
bredbandsbolaget.se
burlov.se
comhem.se
coop.se
coresec.se
danskebank.se
ehalsomyndigheten.se
elegnamnden.se
enkoping.se
eskilstuna.se
fagersta.se
falun.se
forskarskattenamnden.se
gjensidige.se
glocalnet.se
gullspang.se
habo.se
hagfors.se
hallsberg.se
harryda.se
hassleholm.se
herjedalen.se
hudiksvall.se
ica.se
jarfalla.se
jonkoping.se
kmh.se
knowit.se
konj.se
koping.se
krokom.se
kronofogden.se
kungsbacka.se
kungsor.se
lansforsakringar.se
laxa.se
lekeberg.se
lessebo.se
lomma.se
lotteriinspektionen.se
ltv.se
ludvika.se
lul.se
lu.se
marginalen.se
mariestad.se
msb.se
norberg.se
nordea.se
norrkoping.se
norrtalje.se
nykoping.se
nykvarn.se
nynashamn.se
orebroll.se
orebro.se
overklagandenamnden.se
rattvik.se
riksrevisionen.se
sandviken.se
seb.se
sj.se
skane.se
skatteverket.se
skogsstyrelsen.se
skolinspektionen.se
skolverket.se
sll.se
smedjebacken.se
socialstyrelsen.se
sr.se
statensmedierad.se
stenungsund.se
stromstad.se
sundbyberg.se
svd.se
svenskaspel.se
sverigesradio.se
svk.se
svo.se
tanum.se
telenor.se
tillvaxtverket.se
tlv.se
toreboda.se
torsby.se
trafikverket.se
transportstyrelsen.se
trygghansa.se
uddevalla.se
umu.se
uppvidinge.se
varberg.se
varmdo.se
varnamo.se
vaxjo.se
vll.se
volvogroup.com
yhmyndigheten.se

Nyheterna i Transport Layer Security version 1.3 (TLS 1.3)

SSL och TLS har under lång tid säkrat upp en betydande del av den krypterade kommunikationen på Internet. Sedan SSL version 1.0 släpptes internt hos Netscape Communications år 1994 så har det hänt en hel del.

Den nya versionen som just nu håller på att utvecklas inom en arbetsgrupp hos IETF har versionsnumret 1.3 där målsättningen är högre prestanda samt tillhandahålla en ännu högre säkerhet. Man kan säga att designkriteriet för denna nya version är ”less is more” och det innebär att en hel del föråldrade krypton har fått stryka på foten:

  • RSA är borttaget – RSA tillhandahåller inte Forward Secrecy
  • Svaga Diffie-Hellman grupper kan inte användas (SSL_OP_SINGLE_DH_USE)
  • CBC är borta – Är orsaken till attacker såsom Lucky13 och BEAST
  • RC4 samt SHA1 får inte längre användas
  • Export-algoritmer (ansvarig för attacker såsom FREAK, LogJam etc)
  • Nytt är ChaCha-Poly1305 samt stöd för OCB-modes (tipstack till Joachim Strömbergson)
  • Algoritmen för RSA-padding är Probablilistic Signature Scheme (PSS)
  • Nytt meddelande av typen EncryptedExtension. Som nu är krypterat, tidigare skickades många okrypterat

När det gäller prestanda så har ett antal åtgärder införts:

  • 0-RTT samt 1-RTT

Genom att få ner antalet TCP-paket som måste skickas fram och tillbaka vid varje anslutning så kan snabbare TLS (och webbsidor etc) uppnås.

Här följer en bild hur 1-RTT ser ut där klienten skickar ett ClientHello direkt, samt så gissar klienten vilka krypton som kommer att användas:

När du sedan har en session etablerad så kan sedan 0-RTT användas vid senare tillfälle (Session Resumption) men detta möjliggör dock återuppspelningsattacker.

Vill du redan nu testa TLS 1.3 i Google Chrome så kan du göra följande:

  1. Skriv in ”chrome://flags/” i adressbaren och trycker enter
  2. Gå till ”Maximum TLS version enabled.” och välj ”TLS 1.3”
  3. Starta om Chrome

Och vill du testa med Firefox så behöver du ladda hem senaste nightly-build där TLS 1.3 är påslaget som standard.

Och nu när vi besöker kryptera.se och tar upp Developer Tools (DevTools) så synes följande:

Viktigt att tillägga är att TLS 1.3 inte är färdigt ännu och ändras löpande. Detta gör att mjukvara såsom OpenSSL är försiktiga med att göra förändringar. Den senaste uppdateringen till TLS 1.3 heter draft-19 och släpptes för cirka 2 veckor sedan.

För att exempelvis Nginx ska stödja TLS 1.3 så måste även OpenSSL stödja detta. Och OpenSSL kommer med stöd inom några veckor i version 1.1.1.

Uppdaterad 2017-12-27: Enligt Cloudflare är det bara %0.06 av webbläsarna som använder TLS 1.3 och detta beror främst på att många mellanlådor inte stödjer TLS 1.3.

Uppdaterad: 2017-06-06, användes internt hos Netscape. Inte Mozilla som grundades först många år senare.

Oberoende granskning av OpenVPN

OpenVPN är ett otroligt populärt verktyg för att skapa upp VPN-anslutningar och används av majoriteten av alla VPN-tjänster. Private Internet Access (PIA) med bl.a. Rick Falkvinge kommer att betala för en oberoende granskning av OpenVPN som leds av kryptologen Dr. Matthew Green. Matthew hade tidigare hand om den öppna granskningen av TrueCrypt. PIA är ett företag som tillhandahåller VPN-anslutningar och som använder OpenVPN

OpenVPN har funnits sedan 2001 och använder en variant på SSL/TLS som kanal för kommunikation och går att köra på operativsystem såsom Solaris, Linux, OpenBSD, FreeBSD, NetBSD, QNX, Mac OS X, iOS, Android och Windows från version XP.

PIA meddelar att efter granskningen är klar och OpenVPN åtgärdat eventuella brister så kommer rapporten att publiceras på deras hemsida.

Senast en sårbarhet uppdagades i OpenVPN var under 2016 då födelsedags-attacken Sweet32 som går mot 64-bits algoritmer såsom den som OpenVPN använder som standard, BF-CBC.

Och viktigt att notera är att OpenVPN används på både klienten och servern. Ett alternativ till OpenVPN är att köra stunnel eller IPSEC.

Uppdatering: Under tiden jag skrev denna artikel har två andra relaterade nyheter dykt upp:

  • Algo lyfts upp som ett nytt alternativ till IPSec och OpenVPN
  • OSTIF meddelar att de anlitar Quarks Lab för att också granska OpenVPN. Samma franska företag som tidigare granskade VeraCrypt

TLS/SSL-läget i Sverige

Företaget Kirei har nu lanserat en webbtjänst där de listar 788 svenska organisationer och deras tillhörande betyg från SSL Labs. Bakomliggande kod är öppen källkod och ligger på Github för den som vill komma med ändringar.

Generellt kan man se att det inte ser speciellt bra ut. Antalet organisationer som får sämsta betyg F är otroligt många och även antalet sajter som överhuvudtaget inte har TLS är ännu fler.

För den som vill erhålla högsta betyg, A+ så går det bl.a. att följa SSL Labs A+. Givetvis så saknar vi regeringen.se som tillhandahåller ett felaktigt certifikat via Akamai och som annars brukar vara bra att föregå med gott exempel:

Regeringen TLS Akamai

Skärmdump från TLS-kollen:

TLS/SSL i SverigeUppdatering: Emil Tullstedt tipsade mig på Twitter att en ny RFC har släppts som går ut på att fasa ut SSLv3: https://www.rfc-editor.org/rfc/rfc7568.txt

 

🔐 Microsoft gillar Forward Secrecy (PFS)

Microsoft

Nyligen så släppte Microsoft en relativt anonym säkerhetsuppdatering med nummer 3042058. Denna uppdatering kastar om ordningen samt lägger till nya krypteringsalgoritmer gällande Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, och Windows Server 2012 R2.

Att en så stor spelar som Microsoft gör denna ändring får så klart stora konsekvenser för IT-säkerheten i stort på internet, till det bättre om du frågar mig. För just Forward Secrecy (PFS) gör att temporära nycklar används för sessioner och således kan äldre information ej återskapas även om den privata nyckeln röjs som i fallet med Heartbleed-buggen. För TLS handlar det framförallt om Diffie-Hellman DHE och Diffie-Hellman med elliptiska kurvor, ECDHE.

Följande nya ciphersuites stödjer nu Microsofts ovan operativsystem (och framtida?):

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256

Och i Microsofts fall så är de Schannel som har hand om SSL/TLS och ovan nya algoritmer. Du kan även manuellt ändra ordningen på följande sätt:

  1.  At a command prompt, type gpedit.msc, and then press Enter. The Local Group Policy Editor is displayed.
  2. Expand Computer Configuration, expand Administrative Templates, expand Network, and then click SSL Configuration Settings.
  3. Under SSL Configuration Settings, click SSL Cipher Suite Order.
  4. In the SSL Cipher Suite Order pane, scroll to the bottom.
  5. Follow the instructions that are labeled How to modify this setting.

Kommentar från Henrick Hellström på Streamsec:

– Uppdateringen är ”anonym” främst eftersom den inte kommer att bli tillgänglig via Windows Update förrän fjärde kvartalet. ”Microsoft is initially offering the 3042058 update via the Microsoft Download Center only in order to give customers the opportunity to test the new features before making them a default part of their environments; the update will be available via Microsoft Update and WSUS in Q4 2015.”

– Jag håller med om att PFS borde vara standard, men tycker att din motivering kanske är lite överförenklad. I praktiken skulle en läckt privat nyckel (genom heartbleed eller på annat sätt) nog inte skydda gammal data det minsta. Lyckas du komma in som administrator på en server (t ex genom en MITM följd av selektiv blockering mot Remote Desktop när administratören försöker logga in) kan du förmodligen ganska enkelt återskapa det mesta som hänt på den servern genom att analysera loggfiler och auditrecords i databasfilerna, utan att behöva dekryptera någon gammal SSL/TLS-trafik.

– Omvänt, det stora problemet om någon lyckas kopiera din privata nyckel, är att du högst sannolikt aldrig kommer att få reda på det. Även om all gammal trafik kommer att förbli konfidentiell, kommer all framtida trafik från den tidpunkten att kunna dekrypteras av angriparen.

Faktorisera 512 bitar RSA SSL/TLS

Nyligen så uppdagades en ny attack mot SSL/TLS vid namn SMACK. Denna attack nyttjar det faktum att många webbsajter i dagsläget erbjuder gamla krypteringsalgoritmer där bl.a. RSA 512 bitar finns med samt en sårbarhet i klienter.

Att faktorisera 512 bitar RSA går relativt snabbt med hjälp av ett kluster hos exempelvis Amazon EC2. Och med hjälp av 75 st servrar hos Amazon tar det cirka 7h och kostar runt 800 SEK. Och verktyget som användes för detta är bl.a. cado-nfs (eller så kan även ggnfs + msieve användas).

Men hur utbrett är problemet eg. med dessa korta nyckellängder på serversidan? Jo, av 14 miljoner sajter som stödjer SSL/TLS så har 36.7% detta problem. Och problemet i detalj består i att om en klient såsom OpenSSL eller Apples SecureTransport får tillbaka ett svar som inkluderar export-grade RSA så kommer dessa klienter att acceptera svaret, även om de ej frågat efter export-grade RSA.

Förfarandet steg för steg:

  1. När klienten skickar sitt Hello-meddelande så frågar den efter standard RSA
  2. Angripare som sitter i mitten (MITM) ändrar detta svar till export RSA
  3. Servern svarar med sin 512-bitars export RSA-nyckel, signerad med sin nyckel för långa livslängder (long term key).
  4. Klienten sväljer detta svar på grund av OpenSSL/SecureTransport-buggen.
  5. Angriparen faktoriserar RSA för att hitta den privata nyckeln
  6. När klienter krypterar ’pre-master secret’ till servern så kan nu angriparen dekryptera TLS huvudhemlighet (master secret)
  7. Nu kan angriparen se klartext och injicera nytt innehåll

Demonstration av hur attacken kan nyttjas mot NSA (eller rättare skrivet, Akamai):

nsa-fake copy