JoWa

Wikimedia (och andra) förbättrar säkerheten

Recommended Posts

Förra veckan presenterade Wikimedia Foundation sina planer för förbättrad säkerhet vid anslutning till något av Wikimedia-projekten (Wikipedia, Wiktionary m.fl.):

The future of HTTPS on Wikimedia projects

Wikimedia-projekten har varit tillgängliga via HTTPS sedan 2011: Native HTTPS support enabled for all Wikimedia Foundation wikis

Nu höjer de säkerhetsnivån genom att steg för steg se till att HTTPS används som standard. Att det görs stegvis beror på att deras nuvarande arkitektur inte kan hantera HTTPS som standard för alla. De börjar därför med inloggningen och inloggade användare.

Tills HTTPS är aktiverat som standard på alla Wikimedia-sidor, rekommenderar Wikimedia att man använder HTTPS Everywhere (Chrome, Firefox; fungerar även med Opera 15+).

En förbättring som inte nämns i bloggen är det förbättrade stödet för kryptografiska protokoll. Nu stöds den senaste och säkraste protokollversionen, TLS 1.2, mot tidigare TLS 1.0 som bästa protokoll ([Wikitech-l] no TLS 1.1 and 1.2 support).

Dagen innan Wikimedia publicerade sina planer, presenterade Facebook sina ambitiösa planer för bättre säkerhet: Secure browsing by default 

Detta efter att ha erbjudit HTTPS som alternativ sedan början av 2011: A Continued Commitment to Security

Vidare kan nämnas att Myspace nu använder HTTPS som standard: https://myspace.com/

Att Yahoo! Mail i början av 2013 gjorde HTTPS användbart för hela sessionen (inte bara inloggning och kontohantering) har tidigare rapporterats: Yahoo! Mail och SSL/TLS

En del av Googles sedan länge pågående arbete med att förbättra säkerheten har också rapporterats: Krypterad Google-sökning

Sammanfattningsvis kan sägas att 2013 ser ut att bli ett bra år för kryptering på Internet. :) Men samtidigt dyker Breach upp.

Redigerad av JoWa
  • Like 1

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser

Det är förstås tacksamt att publicera dylika ”nyheter” nu, och Ryan Lane (Wikimedia) nämner inledningsvis “leaks of the NSA’s XKeyscore program”. Men det är inte mycket som har hänt sedan det första avslöjandet för drygt en månad sedan. Mycket påbörjades för flera år sedan, och annat är ännu inte genomfört. Fler satsningar på säkerhet och integritet kommer nog under hösten och vintern.

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser

Under onsdagskvällen meddelades att HTTPS nu är aktiverat på Wikimedia-projektens sidor för inloggade användare.

[Wikitech-l] HTTPS enabled for all logged-in users

HTTPS efter inloggning kan inaktiveras i kontoinställningarna.

Wikipedia Säker anslutning.png

Dock är den svenska översättningen fel. Den engelska texten lyder: ”Always use a secure connection when logged in”, men översättaren har tydligen läst det som ”when logging in”. Säker anslutning används nu alltid vid inloggning.

Felöversättningen rättad efter mitt påpekande.

Wikipedia-inställningar Säker anslutning.png

Samtidigt har EFF börjat att trycka på för användning av perfekt framtidssekretess:

Pushing for Perfect Forward Secrecy, an Important Web Privacy Protection

Google har använt det i snart två år, och Facebook har nyligen börjat använda det. Twitter och Opera använder det också. Microsoft använder det för närvarande inte för sin e-posttjänst Outlook.com, och det gör heller inte Yahoo! för Yahoo! Mail. Som framgår av länkarna i första inlägget överväger att Wikimedia Foundation att använda det.

Vad EFF inte nämner, är att användaren kan se om perfekt framtidssekretess används eller inte, åtminstone vid användning av en Chromium-baserad webbläsare. De kan nämligen visa detaljer om den anslutning som används. Såhär ser det ut i Opera 16 vid anslutning till https://www.eff.org

Opera16-ECDHE_RSA.png

Det inramade ”ECDHE_RSA” är en av de mekanismer för nyckelutbyte som kan användas för perfekt framtidssekretess; andra mekanismer är DHE_RSA och ECDHE_ECDSA. Står det däremot endast ”RSA” är krypteringen inte ”framåthemlig”.

Redigerad av JoWa

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser

I måndags lade Wikimedia till AES GCM som alternativ till RC4 för kryptering: [Wikitech-l] SSL security, part II.

Bakgrund: RC4 in TLS is Broken: Now What? | New RC4 Attack

Enligt SSL Labs använder IE11 i W8.1 AES CBC vid anslutning till wikimedia.org. Chrome använder AES GCM från och med version 31 (Revision 217716).

Bilder av Chrome 30 och 31:

Chrome30RC4.pngChrome31AES.png

Vad blir nästa steg? En ”framåtsäker” nyckelutbytesmekanism? :)

Redigerad av JoWa

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser

SSL Labs har uppdaterat SSL/TLS Deployment Best Practices, som nu bl.a. rekommenderar att RC4 inaktiveras. ECDSA som alternativ till RSA diskuteras. Google använder redan ECDHE_ECDSA. Jag har dock inte sett någon annan använda ECDSA. Den vanliga kombinationen är ECDHE_RSA (som bl.a. Facebook, Twitter och Opera använder) eller DHE_RSA (som bl.a. GMX och Ubuntu One använder). Wikimedia har ännu inte aktiverat ”framtidssäkert” nyckelutbyte. Vidare rekommenderas att 1024-bitnycklar uppgraderas omgående och att stöd för SSL 3 inaktiveras.

Updated SSL/TLS Deployment Best Practices Deprecate RC4

Såhär ser det ut i Chrome 31 när allt (som syns) är rätt:

ChromeTLSallträtt.png

Redigerad av JoWa

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser

Microsofts tur att förbättra säkerheten: Protecting customer data from government snooping

  • Customer content moving between our customers and Microsoft will be encrypted by default. 
  • All of our key platform, productivity and communications services will encrypt customer content as it moves between our data centers. 
  • We will use best-in-class industry cryptography to protect these channels, including Perfect Forward Secrecy and 2048-bit key lengths. 
  • All of this will be in place by the end of 2014, and much of it is effective immediately. 
  • We also will encrypt customer content that we store. In some cases, such as third-party services developed to run on Windows Azure, we’ll leave the choice to developers, but will offer the tools to allow them to easily protect data. 
  • We’re working with other companies across the industry to ensure that data traveling between services – from one email provider to another, for instance – is protected.

Den sista punkten tolkar jag som en planerad implementering av STARTTLS (se även EFF-artikeln). Förhoppningsvis innebär ”best-in-class industry cryptography” bl.a. TLS 1.2.

Redigerad av JoWa

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser
Citat
UPDATE, December 16, 2013: Microsoft has informed us that it is planning to support HSTS for public facing services that host or transmit email, personal or business documents and media, messaging, contacts, and credentials. This is an important step to make it more challenging for attackers to defeat security by bypassing encryption. In addition, Microsoft is planning to roll out STARTTLS in its outlook.com email service. This means that emails between outlook.com users and other email services that use STARTTLS, like Gmail, will be encrypted in transit.

UPDATE: Encrypt the Web Report: Who’s Doing What

Bra att e-post kommer att sändas krypterad mellan Outlook.com och Gmail. Yahoo! Mail nästa att börja använda STARTTLS?

Intressant att Microsoft planerar att stödja HSTS (RFC 6797) på serversidan, medan Microsofts egen webbläsare inte stöder HSTS (Chrome, Firefox och Opera stöder det sedan länge). Törs man gissa att IE12 kommer att stödja HSTS?

Redigerad av JoWa

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser
On 2013-11-20 at 07:08, JoWa sade:

Översikten har uppdaterats igen. 

Citat

UPDATE, April 2, 2014: Yahoo has announced a number of improvements to its security offerings, bringing it up to a full five checkmarks.

Mer i denna artikel: Yahoo Protects Users with Lots More Encryption (EFF).

Status Update: Encryption at Yahoo (Yahoo)

Chrome använder nu TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 vid anslutning till Yahoo!-sidor som https://login.yahoo.com/https://se-mg.mail.yahoo.com, https://se.yahoo.com/, https://search.yahoo.com/https://secure.flickr.com/ 

Med stöd för STARTTLS skickas e-post krypterad mellan Yahoo! Mail och andra tjänster som stöder det, t.ex. Gmail och GMX. Microsoft (Outlook.com) har ännu inte implementerat STARTTLS, men det är på gång.

Google meddelade nyligen en förändring för Gmail: Staying at the forefront of email security and reliability: HTTPS-only and 99.978% availability

Gmail har varit tillgängligt via https://mail.google.com sedan lanseringen för tio år sedan, men då måste användaren själv inkludera ”https” i adressen. 2008 lades en inställning, där man kunde välja att alltid använda https, till. I januari 2010 blev https standard, men det var fortfarande möjligt att via inställningarna välja att inte alltid använda https (utom i Chromium-baserade webbläsare, där alternativet var otillgängligt). Nu är inställningen borttagen, och det är bara https som gäller för Gmail.

Redigerad av JoWa

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser

Förbättringar av servercertifikaten är på gång.

I november 2013 meddelade Microsoft att de inte kommer att tillåta server- eller kodsigneringscertifikat med signaturalgoritmen SHA-1, som i dag är den vanliga för servercertifikat (ofta kallade ”SSL-certifikat” efter det äldre SSL-protokollet som nu sällan används), efter 1 januari 2016. Microsoft rekommenderar uppgradering till SHA-2, som omfattar bl.a. SHA-256.

Twitter (https://twitter.com) har redan bytt från SHA-1 till SHA-256. Google har ännu inte bestämt exakt när de skall genomföra förändringen, endast att det kommer att ske före 1 januari 2016. De har en testsida ( https://cert-test.sandbox.google.com/) där SHA-256 används.

Problemet är förstås gamla klienter, t.ex. Windows XP före SP3. Även gamla telefoner och inbyggda system kan få problem.

Även https://www.ssllabs.com/ använder SHA-256, liksom  https://sslanalyzer.comodoca.com. Den senare använder även certifikattransparens (Wikipedia).

Certifikatvisare-SHA256.png

Adam Langley: SHA-256 certificates are coming

Redigerad av JoWa

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser
On 2013-12-17 at 07:01, JoWa sade:

Intressant att Microsoft planerar att stödja HSTS (RFC 6797) på serversidan, medan Microsofts egen webbläsare inte stöder HSTS (Chrome, Firefox och Opera stöder det sedan länge). Törs man gissa att IE12 kommer att stödja HSTS?

HSTS i IE är nu ”In Development”: https://developer.microsoft.com/en-us/microsoft-edge/platform/status/httpstricttransportsecurityhsts :)

Redigerad av JoWa

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser

WordPress.com kommer senare i år att leverera alla *.wordpress.com-domäner över TLS: Reset the Net

Servern föredrar TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, ett utmärkt val, som Chrome och Firefox använder vid anslutning. Det är alltså TLS 1.2, chiffersviten AES-GCM (som inte har några kända svagheter) med 128 bitars kryptering, samt nyckelutbytesmekanismen ECDHE-RCA, som ger framåtsekretess utan att vara långsamt (DHE-RCA är långsammare). Signaturalgoritm (se tidigare inlägg): SHA-256. För att kunna erbjuda så snabb anslutning som möjligt, används SPDY 3.1 för klienter som stöder det.

Redigerad av JoWa

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser

En stor sida/tjänst som ligger långt efter med sitt säkerhetsarbete är LinkedIn. I förrgår visade Zimperium att de genom ”SSL Stripping” kan komma över LinkedIn-användares användarnamn, lösenord m.m.

Enligt LinkedIns blogg skall nu säker anslutning användas (för hela sessionen, inte endast vid inloggning) som standard för användare i USA och EU: Default HTTPS Update. Ett äldre inlägg om det pågående arbetet: Default HTTPS

Jag säger dock som Zimperium: ”Don’t trust Linkedin’s default settings – Turn ON HTTPS Manually”. Det görs på https://www.linkedin.com/settings/security-v2 Utöver ”Säker uppkoppling” kan man där aktivera tvåstegsverifiering, vilket också rekommenderas (för alla konton!).

Chrome-användare kan också lägga till linkedin.com (inkludera underdomäner) i chrome://net-internals/#hsts

Av övriga planerade förbättringar är det endast stöd för TLS 1.2 som har genomförts. Servern föredrar (= säger åt webbläsaren att använda) chiffersviten RC4 (!) och använder MD5 (!) för autentisering. Riktigt dåligt. RC4 är sårbart och anses vara den sämsta av de chiffersviter som har varit i omfattande bruk på senare år. MD5 är en enkel algoritm som länge har ansetts vara osäker. Nyckelutbytesmekanismen är alltjämt RSA, vilket ej ger framåtsekretess. De planerar dock att använda ECDHE (ECDHE-RSA eller ECDHE-ECDSA?). De experimenterar också med SPDY, för snabbare anslutning.

Redigerad av JoWa

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser

Matt Thomlinson (Trustworthy Computing Security, Microsoft): Advancing our encryption and transparency efforts

Där talas bl.a. om att Microsoft har aktiverat TLS för e-post som transporteras mellan Outlook.com och andra e-posttjänster. ”TLS” betyder där StartTLS, och för att det skall kunna användas måste förstås båda e-posttjänsterna stödja denna kryptering.

Vidare har HSTS aktiverats för https://onedrive.live.com/ vilket förhindrar ”stripping” (se förra inlägget). För några domäner har framåtsekretess (ECDHE_RSA) aktiverats, bl.a. https://onedrive.live.com/https://login.live.com/ och https://www.bing.com/. HSTS är ännu inte aktiverat för https://login.live.com/.

För nämnda domäner används sedan en tid TLS 1.2. Microsoft föredrar TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, medan AES_GCM, som inte har några kända svagheter, saknas helt. Märkligt. CBC kan ej användas med HTTP/2.

För mail.live.com (t.ex. https://dub127.mail.live.com/) är säkerheten f.n. sämre. Servern föredrar TLS_RSA_WITH_AES_128_CBC_SHA utan framåtsekretess, medan den säkrare chiffersviten TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (med framåtsekretess) är femte alternativ. Varken TLS 1.1 eller 1.2 stöds. Uppdatering: TLS 1.2 stöds, och TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 är nu förstavalet. HSTS är aktiverat. SSL3 stöds ej.

Redigerad av JoWa

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser
On 2014-06-20 at 07:51, JoWa sade:

En stor sida/tjänst som ligger långt efter med sitt säkerhetsarbete är LinkedIn. I förrgår visade Zimperium att de genom ”SSL Stripping” kan komma över LinkedIn-användares användarnamn, lösenord m.m.

Enligt LinkedIns blogg skall nu säker anslutning användas (för hela sessionen, inte endast vid inloggning) som standard för användare i USA och EU: Default HTTPS Update. Ett äldre inlägg om det pågående arbetet: Default HTTPS

Jag säger dock som Zimperium: ”Don’t trust Linkedin’s default settings – Turn ON HTTPS Manually”. Det görs på https://www.linkedin.com/settings/security-v2 Utöver ”Säker uppkoppling” kan man där aktivera tvåstegsverifiering, vilket också rekommenderas (för alla konton!).

Chrome-användare kan också lägga till linkedin.com (inkludera underdomäner) i chrome://net-internals/#hsts

Av övriga planerade förbättringar är det endast stöd för TLS 1.2 som har genomförts. Servern föredrar (= säger åt webbläsaren att använda) chiffersviten RC4 (!) och använder MD5 (!) för autentisering. Riktigt dåligt. RC4 är sårbart och anses vara den sämsta av de chiffersviter som har varit i omfattande bruk på senare år. MD5 är en enkel algoritm som länge har ansetts vara osäker. Nyckelutbytesmekanismen är alltjämt RSA, vilket ej ger framåtsekretess. De planerar dock att använda ECDHE (ECDHE-RSA eller ECDHE-ECDSA?). De experimenterar också med SPDY, för snabbare anslutning.

Jag har kollat https://www.linkedin.com under en tid, och sett att säkerheten har vacklat mellan ytterligheter: ibland TLS_RSA_WITH_RC4_128_MD5 och ibland TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. LinkedIn har två servrar:  https://www.ssllabs.com/ssltest/analyze.html?d=linkedin.com Ibland har 199.101.163.129 varit lika dålig som 216.52.242.86 alltjämt är. 199.101.163.129 stöder framåtsekretess (ECDHE_RSA) och HSTS är implementerat men inte aktiverat (max-age=0). Next Protocol Negotiation stöds, men SPDY är inte aktiverat (se https://spdycheck.org/#www.linkedin.com).

LinkedIn-Opera.png

Redigerad av JoWa

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser

Facebook rapporterar att deras användning av STARTTLS har ökat kraftigt under året, sedan även Microsoft och Yahoo! har börjat stödja det (Gmail stödde det redan i fjol). 95 % av all e-post som Facebook skickar är nu krypterad.

Massive Growth in SMTP STARTTLS Deployment

Konstigt nog stöder Yahoo! Japan (@yahoo.co.jp) inte STARTTLS.

Andra e-posttjänster som stöder STARTTLS inkluderar GMX, Telia och (något överraskande) QQ Mail.

För närvarande (lördag 16 aug.) är 76 % av all e-post som skickas från Gmail krypterad, och 65 % av e-posten som skickas till Gmail: https://www.google.com/transparencyreport/saferemail/

Andelen krypterad e-post som skickas till Gmail ökar rätt mycket under lördagar och söndagar.

Redigerad av JoWa

Dela detta inlägg


Länk till inlägg
Dela på andra webbplatser

Skapa ett konto eller logga in för att kommentera

Du måste vara medlem för att kunna kommentera

Skapa ett konto

Registrera ett nytt konto i våran gemenskap. Det är lätt!

Registrera ett nytt konto

Logga in

Redan medlem? Logga in här.

Logga in nu

  • Liknande innehåll

    • Av JoWa
      Secure Sockets Layer (SSL) utvecklades av Netscape, och lanserades (version 2.0) i februari 1995. SSL uppdaterades till version 3.0 1996. SSL är ett kryptografiskt protokoll som används för att skapa säkra (krypterade) förbindelser över Internet.
      Utvecklingen gick vidare, och SSL fick en efterträdare i Transport Layer Security (TLS). Version 1.0 av TLS lanserades i januari 1999, följd av TLS 1.1 (april 2006) och TLS 1.2 (april 2008).
      Alla dessa versioner kan ännu användas, men SSL 2.0 är en mycket osäker version, och väldigt får servrar stöder SSL 2.0. I ingen av dagens webbläsare är SSL 2.0 aktiverat, och endast Internet Explorer (t.o.m. version 10) har möjlighet att aktivera den osäkra protokollversionen.
      TLS 1.0 är den mest använda protokollversionen. Alla (?) servrar stöder den, och alla webbläsare har sedan länge stöd för TLS 1.0 aktiverat som standard.
      Internet Explorer i Windows 7 och 8 stöder även TLS 1.1 och 1.2, men dessa versioner är inte aktiverade som standard. För att aktivera, öppna Internetalternativ, fliken Avancerat, rubriken Säkerhet. Markera ”Använd TLS 1.1” och ”Använd TLS 1.2”. Markera inte ”Använd SSL 2.0”.

      Opera stöder även TLS 1. 1 och 1.2, men det är inte heller där aktiverat som standard. För att aktivera, gå till Inställningar, Avancerat, Säkerhet, Säkerhetsprotokoll.

      Eller skriv opera:config i adressfältet, tryck Retur. Skriv ”tls” i sökrutan och markera ”Enable TLS v1.1” och ”Enable TLS v1.2”.

      Firefox och Chrome använder Network Security Services (NSS), som stöder upp till TLS 1.1. I Chrome är TLS 1.1 aktiverat som standard, medan Firefox ännu (v. 18) endast stöder SSL 3.0 och TLS 1.0.
      I Opera och Chrome kan man lätt se vilket krypteringsprotokoll som används, se bifogade bilder.

      Läsning:
      Wikipedia: Transport Layer Security
      Wikipedia: Network Security Services
      Adam Langley (Google): New TLS versions
    • Av JoWa
      Att en kommande version av Internet Explorer skall stödja HTTP Strict Transport Security (HSTS) har varit känt en tid, bl.a. genom https://status.modern.ie/httpstricttransportsecurityhsts?term=hsts
       
      Nyligen publicerades ett inlägg på IEBlog som bekräftar stöd för HSTS i IE och senare Project Spartan i Windows 10: 
      HTTP Strict Transport Security comes to Internet Explorer Inte fem år för tidigt, men bättre sent än aldrig.
       
      IEBlog bekräftar även att Googles förladdningslista, med för närvarande drygt 1 500 förladdade domäner med läget force-https, används. Denna ”förladdning” (preload) av domäner är mycket värdefull, HSTS lämnar den allra första anslutningen till en HSTS-domän sårbar.¹ Det är nämligen först efter att en säker anslutning till en HSTS-domän har gjorts som webbläsaren vet att den endast skall ansluta säkert till den domänen i fortsättningen, under den tid som är angiven i HSTS-headern, och vanligen 180 dagar eller längre. Twitter har tagit i ordentligt, med hela 7 304 dagar (20 år).²
       
      ¹ https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#Limitations
      ² https://spdycheck.org/#twitter.com