Gå till innehåll

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
Länk till kommentar
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.

Länk till kommentar
Dela på andra webbplatser

  • 3 veckor senare...

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
Länk till kommentar
Dela på andra webbplatser

  • 2 veckor senare...

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
Länk till kommentar
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
Länk till kommentar
Dela på andra webbplatser

  • 2 månader senare...

Mega har också bytt till ECDHE_RSA (vet ej när) för https://mega.co.nz, men inte i kombination med AES_GCM. Chrome använder TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA vid anslutning.

Tidigare stöddes ”forward secrecy” endast att API-servrarna. Se bloggen (2013-07-20).

Redigerad av JoWa
Länk till kommentar
Dela på andra webbplatser

  • 2 veckor senare...

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
Länk till kommentar
Dela på andra webbplatser

  • 2 veckor senare...
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
Länk till kommentar
Dela på andra webbplatser

  • 3 månader senare...
Postad (redigerade)
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
Länk till kommentar
Dela på andra webbplatser

  • 1 månad senare...
Postad (redigerade)

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
Länk till kommentar
Dela på andra webbplatser

  • 2 veckor senare...
Postad (redigerade)
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
Länk till kommentar
Dela på andra webbplatser

Postad (redigerade)

Användningen av STARTTLS ökar. E-postkryptering vid överföring visar hur många procent av inkommande och utgående e-post till/från Gmail som överförs mellan e-posttjänsterna i krypterad form.

New Gmail Data Shows the Rise of Backbone Email Encryption (EFF)

Redigerad av JoWa
Länk till kommentar
Dela på andra webbplatser

Postad (redigerade)

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
Länk till kommentar
Dela på andra webbplatser

  • 2 veckor senare...
Postad (redigerade)

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
Länk till kommentar
Dela på andra webbplatser

  • 2 veckor senare...
Postad (redigerade)

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
Länk till kommentar
Dela på andra webbplatser

  • 1 månad senare...
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
Länk till kommentar
Dela på andra webbplatser

  • 2 veckor senare...

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
Länk till kommentar
Dela på andra webbplatser

Delta i dialogen

Du kan skriva svaret nu och registrera dig senare, Om du har ett konto, logga in nu för att svara på inlägget.

Gäst
Svara i detta ämne...

×   Du har klistrat in innehåll med formatering.   Ta bort formatering

  Only 75 emoji are allowed.

×   Din länk har automatiskt bäddats in.   Visa som länk istället

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Skapa nytt...