Taggat med: Diffie-Hellman

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 – 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-06-06, användes internt hos Netscape. Inte Mozilla som grundades först många år senare.

NSA varnar för kvantdatorer

 

NSA Kvantdatorer

Eller rättare skrivet så gick den amerikanska myndigheten NSA ut för några dagar sedan och varnade för att många av nutidens algoritmer som används bör uppgraderas för att motstå beräkningar utförda av kvantdatorer.

Det rör framförallt RSA där nyckelstorlekar  är under 4096 bitar, men även elliptiska kurvor kan ligga dåligt till eftersom en variant av Shors algoritm kan användas. Eller som NSA uttrycker det:

Minimum 3072 bit-modulus to protect up to TOP SECRET.

Intressant också är gällande hashalgoritmer så rekommenderas minst SHA384, vilket i praktiken innebär SHA512.

Nu innebär detta inte att alla måste byta över en natt utan NSA rekommenderar att leverantörer slutar att leverera och tillverka produkter eller mjukvaror som implementerar algoritmer som ej kan motstå beräkningar utförda av kvantdatorer.

Och förutom RSA och SHA så rekommenderas ECDH (Elliptic Curve Diffie–Hellman) med med minst 384 bitar.

Personligen så föredrar jag Curve25519 av Daniel J Bernstein etc, se SafeCurves. Bitcoin exempelvis använder sig av secp256k1.

The RSA-2048 Challenge Problem would take 1 billion years with a classical computer. A quantum computer could do it in 100 seconds

– Dr. Krysta Svore, Microsoft Research

🔐 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.