Taggat med: chrome

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 Mozilla å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)

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.

Heartbleed dag sex

broken-heartbleedYtterligare ett antal dagar har nu passerat sedan OpenSSL-buggen Heartbleed offentliggjordes och det är dags att göra ett antal till reflektioner.

Det har visat sig att buggen går att nyttja till att erhålla den privata nyckeln, framförallt via Hearbleed Challenge.

The bad news is that [discovery] changes our recommendation from: reissue and revoke as a medium priority to reissue and revoke as a high priority.

Skrev Matthew Prince, CEO på CloudFlare till Ars Technica.

Akamai har släppt en patch för att säkra upp minnesallokeringen i OpenSSL. Deras implementation går under namnet secure_malloc (OpenSSL använder sig av OPENSSL_malloc). Läs även mer här av Alex Clemmer.

Även oklart huruvida denna sårbarhet nyttjas innan den blev offentligt känd. EFF hävdar dock att så är fallet och har bevis på detta.

Bra saker som händer efter Heartbleed

OpenSSL får mer donationer som går att granska kodbasen samt så kontrollerar generellt fler ögon OpenSSL efter buggar.

Revokeringen av certifikat ses över då exempelvis Chrome har revokeringskontroll avstängt som standard.

Forward-secrecy eller PFS som det också kallas blir mer använt.

Uppdatering: Bra blogginlägg av Einar Otto Stangvik om hur han gick till väga för att hitta den privata nyckeln.

Google lägger ner False Start SSL

Förra året i Maj så skrev vi om ett expriment som Google utförde vid namn False Start SSL där avsikten var att snabba upp SSL (https). Dock så visade det sig att False Start var inkompatibelt med ett antal SSL terminatorer och det Google gjorde då var att upprätta en svartlista med dessa men det visade sig vara ett hästjobb att hålla denna lista uppdaterad så nu lägger Google ner experimentet meddelar företaget.

Adam Langley som jobbar på Google skrev detta på sin privata blogg ImperialViolet:

The `servers’ with problems were nearly always SSL terminators. These hardware devices terminate SSL connections and proxy unencrypted data to backend HTTP servers. I believe that False Start intolerance is very simple to fix in the code and one vendor suggested that was the case. None the less, of the vendors who did issue an update, most failed to communicate that fact to their customers. (A pattern that has repeated with the BEAST fix.)

Dock så kommer Googles webbläsare Chrome stödja False Start mot servrar som stödjer TLS Next Protocol Negotiation (NPN).

MITM Attack mot Google-användare i Iran

En användare av webbläsaren Google Chrome har i Iran upptäckt ett felaktigt certifikat för Google-tjänster. Efter ytterligare undersökningar så visade det sig att någon på vägen mellan användaren i Iran och Google genomförde en såkallad man-i-mitten attack (man-in-the-middle /MITM ) mot krypterade anslutningar (https).

Att användaren i Iran kunde upptäcka attacken berodde på att Google lagt in fingerprints för dess tjänster hårdkodat i webbläsaren Chrome. Så oavsett om certifikatet ser ut att vara korrekt utfärdat för *.google.com så visas en varning till användaren.

En av bovarna i dramat är företaget DigiNotar som utfärdat ett certifikat felaktigt. Omfattningen av denna attack är i dagsläget oklar.

Google har gått ut med följande meddelande:

Today we received reports of attempted SSL man-in-the-middle (MITM) attacks against Google users, whereby someone tried to get between them and encrypted Google services. The people affected were primarily located in Iran. The attacker used a fraudulent SSL certificate issued by DigiNotar, a root certificate authority that should not issue certificates for Google (and has since revoked it).

Google Chrome users were protected from this attack because Chrome was able to detect the fraudulent certificate.

To further protect the safety and privacy of our users, we plan to disable the DigiNotar certificate authority in Chrome while investigations continue. Mozilla also moved quickly to protect its users. This means that Chrome and Firefox users will receive alerts if they try to visit websites that use DigiNotar certificates.

To help deter unwanted surveillance, we recommend that users, especially those in Iran, keep their web browsers and operating systems up to date and pay attention to web browser security warnings.

HTTPS Everywhere version 1.0

Webbläsarverktyget HTTPS Everywhere finns nu ute i version 1.0. HTTPS Everywhere är ett verktyg som gör att många av de vanligaste webbsajterna vi surfar till dagligen använder den krypterade versionen av webbsurf dvs https. I dagsläget så ligger runt 1000 sajter inlagda i verktyget att automatiskt gå över till https istället för http.

Tyvärr så fungerar HTTPS Everywhere enbart till Firefox i dagsläget. Begränsningar i API:t hos Safari och Chrome gör att det ej är möjligt att göra ett verktyg som HTTPS Everywhere. Vi hoppas så klart att både Apple och Google kommer att införa förändringar i dess webbläsare  som gör det möjligt att tvinga fram https.

HTTPS Everywhere kommer från frihetskämparorganisationen EFF som även står bakom verktyg såsom Tor.

Här kan du ladda hem verktyget: https://www.eff.org/https-everywhere

Snabbare https med SSL False Start

De smarta utvecklarna i Google Chrome teamet har skickat in en draft till IETF som beskriver en metod att snabba upp surfandet på krypterade https-sidor med hjälp av modifiering i SSL/TLS-protokollet.

Denna modifiering har fått namnet False Start av Google för att reflektera ändringarna som föreslagits i handskakningen. Googles tester visar på en ökning av hastigheten på upp till 30%.

IETF Draften kan hittas här: tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

Källa: Chrome Blog