Taggat med: Mozilla

Säkrare webbsurf med DNS över HTTPS (DoH)

Säkrare DNS med DoH

DNS över HTTPS eller DoH som det även kallas är en relativt ny IETF-draft som är skriven av Paul Hoffman på ICANN samt Patrick McManus på Mozilla. Målet med DoH är att skicka DNS-förfrågningar som vanligtvis går i klartext över internet i en krypterad tunnel över https. DoH är ett alternativ till DNSCrypt samt DNS över TLS.

Än så länge finns det stöd i webbläsarna Firefox och Chrome(?), dock inte aktiverat som standard.

Om du gillar risker i livet så kan du redan nu vill testa DoH. Har du en relativt ny version i Firefox kan du göra enligt följande:

  1. Skriv about:config i adressraden
  2. Godkänn ett eventuellt varningsmeddelande
  3. Sök efter network.trr som prefix i inställningsnamnet. TRR står för Trusted Recursive Resolver
  4. Ändra följande inställningar:
    1. Sätt network.trr.bootstrapAddress till 1.1.1.1
    2. Sätt network.trr.confirmationNS till kryptera.se
    3. Sätt network.trr.mode till 3
    4. Sätt network.trr.uri till https://mozilla.cloudflare-dns.com/dns-query
  5. Sedan är det klart. Du måste eventuellt starta om Firefox.

Skärmdump:

Och för att verifiera att DoH/TRR används så kan du göra enligt följande:

  1. Skriv about:networking i adressraden
  2. Godkänn eventuellt varningsmeddelande
  3. Tryck på DNS till vänster
  4. Titta på kolumnen där det står TRR. Där bör det stå true på majoriteten av genomförda uppslagningar:

Alternativt titta direkt på nätverkstrafiken med Wireshark eller tcpdump.

Skärmdump:

Några förklaringar: network.trr.mode kan sättas till något av följande lägen:

0 – Av (standard). Använd vanlig DNS
1 – Race native against TRR. Kör vanlig DNS och TRR och ta den som hinner först
2 – TRR first. Använd TRR enbart och använd DNS som backup
3 – TRR only. Kör bara TRR, använder enbart DNS för bootstrap (dvs hitta till DoH-servern)
4 – Shadow mode. Kör TRR hela tiden i bakgrunden men använd DNS. Bra för att undersöka svarstider etc
5 – Explicitly off. Välj att stänga av TRR

Funkar det dåligt med att köra mode 3 så kan du ändra till 2.

Även om DNS krypteras enligt ovan så läcker https klartext fortfarande om vart du surfar med fältet Server Name Indication (SNI). Men det finns hopp om kryperad SNI också.

Och för mer information om Firefox implementation av DoH kan jag rekommendera Daniel Stenbergs blogginlägg.

Daniel har även skrivit ett testprogram i C för att ställa doh-förfrågningar direkt från kommandotolken:

Det kan även vara bra att läsa Cloudflares privacy policy.

Ny integritetsfrämjande funktion i Mozilla

Mozilla inför från och med Firefox version 59 en intressant integritetsfrämjande åtgärd. Denna nya åtgärd begränsar den information som skickas till tredje-part via så kallade Referer-headers. Tidigare så skickades information såsom följande när du klickar på en länk som leder till en annan sajt:

Referer: https://www.reddit.com/r/privacy/comments/Preventing_data_leaks_by_stripping_path_information_in_HTTP_Referrers/

Vilket kan leda till känslig information kan läcka. Följande exempel är från healthcare.gov där information skickas vidare till ett antal leverantörer:

Även kan det förekomma sessions-information i URL:er. Men tittar vi på ovan information så har EFF rapporterat att följande URL läcker från healthcare.gov:

Referer: https://www.
healthcare.gov/see-plans/85601/results/?county=04019&age=40&smoker=1&pregnant=1&zip=85601&state=AZ&income=35000

Vilket kan vara typiskt obra. Men från Firefox version 59 så kommer enbart följande skickas vidare:

Referer: https://www.healthcare.gov/

Om du surfar i Private Browsing-mode. Sedan några år tillbaka finns även W3C standarden Referrer Policy där du som sajtadministratör själv kan välja hur Referer-headers ska fungera. Läs mer här:

Cure53 granskar cURL

curlTyska IT-säkerhetsföretaget Cure53 har nu släppt en rapport gällande granskning av cURL. Granskningen sponsrades av Mozillas Secure Open Source och identifierade 23 säkerhetsrelaterade problem i källkoden.

Koden granskades av fem personer under 20 dagar samt så var fokus på cURL version 7.50.1. Av dessa 23 identifierade problem så var 9 st klassade som sårbarheter och 14 st som generella svagheter.

Fyra sårbarheter kan troligtvis leda till RCE (Remote Code Execution). Men du kan dock vara lugn för samtliga dessa rapporterade brister har åtgärdats den 2:a November och en uppgradering 7.71.0 löser problemen.

För mer information se curls säkerhetssida här:

Eller loggen för åtgärder som finnes på Google Docs.

Samt så kan du ladda hem Cure53:s rapport som PDF i sin helhet här nedan. Som vanligt så är det alltid intressant att läsa andras granskningar och således själv lära och bli en bättre granskare.

Cure53 granskning av cURL

 

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]än.se. 
 - 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

Tails 1.7 nu ute

tailsDet anonyma och säkra operativsystemet Tails har nu släppts i version 1.7. Nyheter är bl.a. att E-postprogram håller på att övergå från Claws Mail till Icedove. Icedove är Linuxdisten Debians namn på Mozilla Thunderbird.

Nytt är även att det nu finns stöd för offline-länge där inga nätverksinterface aktiveras.

Tor Browser är uppdaterat till 5.0.4 samt Tor 0.2.7.4.

Här kan du ladda hem och testa Tails ISO-avbild:

Uppdatering: Även värt att skriva att denna version åtgärdar en mängd uppdagade säkerhetsbrister.

Gratis SSL/TLS med Let’s Encrypt

Let’s Encrypt är ett nytt initiativ av Internet Security Research Group som backas upp av en mängd stora företag där målet är att tillhandahålla TLS helt gratis.

Företagen som sponsrar satsningen är följande:

Gratis TLS

Även är ett av målen att det ska vara lätt att komma igång. Därför behöver du enbart skriva följande kommando för att komma igång:

$ sudo apt-get install lets-encrypt
$ lets-encrypt example.com

Underliggande säkra protokoll som används är nyutvecklat och går under namnet ACME (Automated Certificate Management Environment) och används för att underlätta verifiering av domännamn. Detta har varit krångligt tidigare då E-post och dylikt har används för SSL/TLS-certifikat.

Specifikationen är tillgänglig via Github här: https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.md

Projektet kommer att starta/fungera från sommaren 2015.

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.

Apple får en ny Director of Global Security

Apple har nyss anställt David Rice som Director of Global Security. David kommer senast från en anställning vid amerikanska myndigheten NSA. Det är i dagsläget oklart vad denna nya befattning innebär.

Apple har tidigare anställt ett antal IT-säkerhetsproffs såsom Window Snyder som var head of Security på Mozilla, Jon Callas  som var CTO på PGP.

Källa: H-Online