Taggat med: Nginx

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.

httpoxy – Ny omfattande sårbarhet mot webbapplikationer

httpoxy attack

httpoxy är namnet på en nygammal säkerhetsbrist kan återfinnas i otroligt många ramverk för webbapplikationer. Denna nya bugg gör det möjligt för en angripare att styra om utgående trafik från en webbapplikation.

Buggen kan beskrivas lättast genom följande förfarande:

  1. Angriparen gör ett anrop mot en sårbar applikation och skickar med Proxy-http headern
  2. Applikationen gör en utgående förfrågan efter data och använder sedan uppgifter från angriparens Proxy-http header som proxy
  3. Angriparen kan sedan sätta sig i mitten och genomföra MITM-attack

Nedan listas några programspråk och dess uppsättning som kan vara sårbar för denna attack.

Programspråk Ramverk HTTP-klient
PHP php-fpm
mod_php
Guzzle 4+
Artax
Python wsgiref.handlers.CGIHandler
twisted.web.twcgi.CGIScript
requests
Go net/http/cgi net/http

Åtgärder

För att förhindra denna attack måste först och främst din applikation använda sig av ovan programspråk, ramverk och http-klient. Även så måste din webbapplikation göra utgående http-förfrågningar när en besökare gör sitt anrop.

För att ta bort HTTP_PROXY miljövariabeln som är boven i dramat så kan du som använder Nginx lägga till följande:

fastcgi_param HTTP_PROXY "";

Använder du Apache som webbserver bör du först och främst läsa denna advisory och sedan kan du använda följande direktiv för att ta bort Proxy http-headern:

RequestHeader unset Proxy

Och använder du Microsoft IIS tillsammans med PHP så bör du lägga in följande i din apphost.config:

<system.webServer>
    <rewrite>
        <rules>
            <rule name="Erase HTTP_PROXY" patternSyntax="Wildcard">
                <match url="*.*" />
                <serverVariables>
                    <set name="HTTP_PROXY" value="" />
                </serverVariables>
                <action type="None" />
            </rule>
        </rules>
    </rewrite>
</system.webServer>

Buggen har återkommit under flertalet år i olika ramverk och tyvärr så har den aldrig riktigt åtgärdats.

Säkerhetsbuggen har fått följande CVE-er:

  • CVE-2016-5385: PHP
  • CVE-2016-5386: Go
  • CVE-2016-5387: Apache HTTP Server
  • CVE-2016-5388: Apache Tomcat
  • CVE-2016-1000109: HHVM
  • CVE-2016-1000110: Python

Här hittar du mer information: httpoxy.org

Gratis SSL-certifikat från Let’s Encrypt

 

Let's Encrypt

Let’s Encrypt-projektet som vi skrivit tidigare om är ett projekt som stöttas av Mozilla, Facebook, ISOC, Akamai och Cisco och erbjuder gratis SSL-Certifikat (eller TLS-certifikat som är mer korrekt benämning).

Eftersom Let’s Encrypt nu finns i publik beta så tog vi tillfället i akt och testade hur det fungerar, och sammanfattat kan vi skriva att det fungerar helt ok. Statistiken visar även på att det utfärdats 80 000 certifikat under det få dagar som projektet varit i publik beta.

Så gör du med Let’s Encrypt

Först och främst så klonar vi hem det publika repo som finnes på Github direkt från vår webbserver och tittar på argumenten. Då kan det också hända att du måste installera extra beroenden som behövs, och då får du ange sudo-lösenord.

$ git clone https://github.com/letsencrypt/letsencrypt
$ cd letsencrypt
$ ./letsencrypt-auto --help
Bootstrapping dependencies for Debian-based OSes...
[sudo] password for x:

Sen kan du köra lite olika kommandon beroende på vilken webbserver du har. Eftersom vi har Nginx så väljer vi att skapa och installera certifikatet oberoende av webbserver ”certonly”:

$ ./letsencrypt-auto certonly --webroot -w /var/www/domän.se/docs/ -d www.domän.se -d domän.se

När vi först körde kommandot fick vi felmeddelandet:

- The following 'urn:acme:error:unauthorized' errors were reported by
 the server:
Error: The client lacks sufficient authorization

Vilket berodde på att vi i vår Nginx-konfigg ej tillät filer eller kataloger som börjar på punkt: ., vilket måste tillåtas pga att en katalog vid namn .well-known/acme-challenge/ skapas i webbrooten.

Du får även följande fråga:

Enter email address (used for urgent notices and lost key recovery)

Och om allt går som det ska skapas sedan certifikatet:

IMPORTANT NOTES:
 - If you lose your account credentials, you can recover through
 e-mails sent to [email protected] 
 - Congratulations! Your certificate and chain have been saved at
 /etc/letsencrypt/live/domän.se/fullchain.pem. Your cert will expire
 on 2016-03-07. To obtain a new version of the certificate in the
 future, simply run Let's Encrypt again.
 - If like Let's Encrypt, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
 Donating to EFF: https://eff.org/donate-le

Sedan får du själv lägga in ungefär följande rader i din Nginx-konfigg:

 ssl_certificate /etc/letsencrypt/live/domän.se/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/domän.se/privkey.pem;

När det fungerar ser det ut enligt följande i Chrome:

Skärmavbild 2015-12-08 kl. 15.09.18

Vid felsökning så är webbserverloggarna en viktig del, kolla dem om det inte fungerar.

90 dagars livstid

Då var det här med att certifikaten har så pass kort livslängd jämfört med dem från exempelvis GeoTrust eller Comodo. Och det beror på att projektet vill hålla hög säkerhet eftersom nycklar röjs samt att de vill uppmuntra automatisering. Efter 60 dagar så rekommenderar Let’s Encrypt att man skapar nya certifikat.

Faktum är att Firefox Telemetry visar på att 29% av alla TLS-transaktioner går över certifikat som har ju 90 dagars livslängd.

Vidare läsning

Och vi rekommenderar Mozilla SSL Config Generator samt följande läsning:

Vill du inte ha gratis TLS-certifikat från Let’s Encrypt så rekommenderar jag vår systersajt https.se