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


Recommended Posts

CloudFlare har tagit ett steg som leder till att mer webbtrafik blir krypterad:

How CloudFlare Moved the Web Toward Ubiquitous HTTPS (EFF)

EFF uttrycker sig inte helt korrekt: “we need to completely replace the insecure HTTP protocol with HTTPS”. HTTP är inte ett osäkert protokoll, och ”HTTPS” är inte ett annat protokoll, det är HTTP över TLS (sällan över SSL), och HTTP är ”säkert” (beror förstås på hur servern är konfigurerad) då det används över TLS. ;)

På tal om protokoll, har CloudFlare länge använt SPDY (över TLS) som alternativ till HTTP/1.1, både för egna och distribuerade sidor. Nu använder de SPDY/3.1, och jag hoppas att de ”hänger på låset” när HTTP/2 är klart.

Edited by JoWa
Link to comment
Share on other sites

  • 2 weeks later...

I fredags inaktiverade Wikimedia SSL3.

[Wikitech-l] SSL 3.0 disabled on Wikimedia sites

Protecting users against POODLE by removing SSL 3.0 support

TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks används nu, för att förhindra nedgradering till ett mindre säkert protokoll.

Edited by JoWa
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
On 2013-11-23 at 08:28, JoWa sade:

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).

De har för länge sedan bytt tillbaka till RSA.

I går blev jag förvånad då https://mega.co.nz/ bara var en tom sida, med ”follow us” (länk till Twitter) som enda innehåll. Det var dock endast i Chrome. Sidan öppnades normalt i Opera och Firefox. Då slog det mig att det kunde bero på att jag startade Chrome med  --cipher-suite-blacklist=0x0005,0x0004. Detta inaktiverar de osäkra chiffersviterna TLS_RSA_WITH_RC4_128_SHA och TLS_RSA_WITH_RC4_128_MD5.

Öppnade Chromes Verktyg för programmerare, som visade att innehåll från https://eu.static.mega.co.nz/ blockerades. Öppnar jag den adressen får jag felmeddelandet ”ERR_SSL_VERSION_OR_CIPHER_MISMATCH”. Här är det fråga om ”cipher mismatch”. Analys visar att de två servrar som levererar eu.static.mega.co.nz är extremt undermåligt konfigurerade:  https://www.ssllabs.com/ssltest/analyze.html?d=eu.static.mega.co.nz

Endast SSL_CK_RC4_128_WITH_MD5 och TLS_RSA_WITH_RC4_128_MD5 stöds. Den förra chiffersviten alltså med SSL (ej TLS), den senare med TLS. TLS 1.0, SSL 3.0 och SSL 2.0 (!!!) stöds. RC4 har ansetts mycket osäkert sedan våren 2013. MD5 för meddelandeautentisering är alldeles för svagt.

:(

IE på Windows (och WP) 8.1 skall inte kunna öppna https://eu.static.mega.co.nz/. Kan någon bekräfta?

Edited by JoWa
Link to comment
Share on other sites

Cecilia, den 31 Oct 2014 - 5:31 PM, skrev: Cecilia, den 31 Oct 2014 - 5:31 PM, skrev:

Händer inget när jag försöker med det i alla fall.

 

Fungerar utmärkt här. (ie på 8.1) kan använda tjänsten.

Edited by si3rra
Link to comment
Share on other sites

Tack Cecilia. :) Inget felmeddelande? Och https://mega.co.nz/ är tom, så när som på texten ”follow us”?

Helt tomt med båda länkarna i IE.

 

Men nu kollade jag lite mer och det är snarare att inget händer alls i IE, för om jag har alltomwindows.se framme i fönstret så fortsätter IE att visa samma sida, ibland står det "Väntar på mega.co.nz" som flikrubrik. Förut startade jag bara upp IE med en tom sida och klistrade in länken i adressfältet.

Går bra i FF.

 

Fungerar utmärkt här. (ie på 8.1) kan använda tjänsten.

Då beror det nog på att jag har ändrat någon inställning för att förhoppningsvis höja säkerheten.

 

Fast Mega krypterar väl informationen på datorn innan den skickas upp så att den är krypterad även på servern, eller?

Och då borde krypteringen i webbläsaren inte vara särskilt viktig.

https://mega.co.nz/#help/security

Link to comment
Share on other sites

Konstigt att det alls fungerar (för Si3rra) i IE på W8.1, som inte stöder RC4, se https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%208.1

Microsoft har också skrivit om RC4: 

Jo, filerna krypteras innan de skickas, så filinnehållet påverkas inte av osäker serverkonfiguration. Man kan inaktivera TLS för filöverföringar i Megas inställningar.

Jag tror dock inte att filerna skickas till https://eu.static.mega.co.nz/, som ser ut att användas endast för att leverera sidinnehållet. Kanske till https://gfs270n035.userstorage.mega.co.nz/ Den servern är inte mycket bättre konfigurerad. TLS 1.1 och 1.2 stöds, SSL 2.0 (som inte stöds av någon modern webbläsare) stöds inte. Den enda chiffersvit som stöds är TLS_RSA_WITH_RC4_128_MD5. Skräp!

Undrar varför Mega är så förtjust i det osäkra RC4. RC4 är förvisso hyfsat snabbt, men med modern hård- och mjukvara är AES_128_GCM snabbare, och säkert! Och med AES_128_GCM används SHA-256 för verifiering. (AES_256_GCM använder SHA-384, men stöds endast av IE.)

Hoppas att lösenordet (och konversationerna i den ännu ej officiellt lanserade meddelandetjänsten) skickas till https://mega.co.nz/, som har en hyfsad konfiguration. Även där saknas dock framåtsekretess.

Oavsett vilken information det är som skickas till vilken server, finns det ingen ursäkt för undermåligt konfigurerade servrar. Det enda som duger är det bästa som finns, för tillfället.

Tillägg: Har rapporterat som bugg.

Edited by JoWa
Link to comment
Share on other sites

Jag har haft kontakt med Mathias Ortmann, som är Megas systemarkitekt. Anledningen till att de använder RC4 är prestandan. Medan AES_128_GCM är mycket snabbare än RC4 om man har moderna processorer med kryptoinstruktioner¹, är det inte fallet med Megas servrars processorer.

Försvinnande stöd för RC4 i webbläsare kommer dock förr eller senare att tvinga bort RC4 från alla servrar. Tidigare har här talats om Microsofts inställning till RC4, och i Issue 375342² talas om att ta bort stöd för RC4 i Chrome. RC4 accepteras heller inte i HTTP/2.

Någon som kan kolla Mega-domänerna med IE på Windows 10?

Det vore också intressant att se vad https://www.ssllabs.com/ssltest/viewMyClient.html rapporterar, särskilt under  Cipher Suites.

¹ https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pdf (PDF)

² https://code.google.com/p/chromium/issues/detail?id=375342

Edited by JoWa
Link to comment
Share on other sites

Anledningen till att de använder RC4 är prestandan. Medan AES_128_GCM är mycket snabbare än RC4 om man har moderna processorer med kryptoinstruktioner¹, är det inte fallet med Megas servrars processorer.

Om jag förstår det rätt har processorstöd för krypteringen funnits längre än Mega vilket väcker frågan om det är ovilja, okunskap eller pengar som satt dem i det läget.

Link to comment
Share on other sites

Mathias avslöjade inga detaljer om Megas hård- och mjukvara, men det krävs också att mjukvaran utnyttjar instruktionsuppsättningen. T.ex. lades stöd för Intels AES-NI och AVX till i NSS 3.14.2, som släpptes i våras: ”NSS will now make use of the Intel AES-NI and AVX instruction sets for hardware-accelerated AES-GCM on 64-bit Linux systems.”¹ Den uppdateringen minskade antalet CPU-cykler per byte till 1/20.

¹ https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.14.2_release_notes

Edited by JoWa
Link to comment
Share on other sites

Mega använder AES-NI närhelst de använder AES (AES_GCM och AES_CBC används för https://mega.co.nz/), men med deras kombination av hård- och mjukvara är RC4 snabbare, vilket innebär lägre elförbrukning och lägre kostnader.

Så till mysteriet med IE på Windows 8.1, som kan ansluta till https://eu.static.mega.co.nz/ och https://gfs270n035.userstorage.mega.co.nz/ där TLS_RSA_WITH_RC4_128_MD5 är den enda användbara chifferviten, utan att stödja RC4.

Då en server föredrar RC4, men även erbjuder andra chiffersviter, t.ex. www.paypal.com, väljer IE på W8.1 bort RC4, och använder, i sagda fall, istället serverns tredje alternativ, TLS_RSA_WITH_AES_256_CBC_SHA.¹ Detta fick mig att misstänka att IE döljer sitt stöd för RC4. Vid anslutning till en server görs en s.k. handskakning, med ett ”Client Hello”, där webbläsaren meddelar servern vilka chiffersviter den stöder. Det är denna lista över chiffersviter som SSL Labs använder i sitt klienttest, och i ”Handshake Simulation”, som är en del av deras servertest.

Då jag i går läste om en artikel från 2013, fick jag detta bekräftat: ”IE11 does not offer RC4-based cipher suites during the initial TLS/SSL handshake. In this way, most connections successfully use non-RC4 cipher suites.”² SSL Labs rapporterar därför inkorrekt ”Protocol or cipher suite mismatch” för IE på W8.1 vid anslutning till https://eu.static.mega.co.nz/.³

Det finns ett relaterat IETF-utkast, från Microsoft: Prohibiting RC4 Cipher Suites, draft-ietf-tls-prohibiting-rc4.⁴

Jag förväntar mig att stöd för RC4 kommer att inaktiveras helt i flera webbläsare under 2015, förhoppningsvis under första halvan.

¹ https://dev.ssllabs.com/ssltest/analyze.html?d=paypal.com&s=23.64.114.13

² http://blogs.msdn.com/b/ie/archive/2013/11/12/ie11-automatically-makes-over-40-of-the-web-more-secure-while-making-sure-sites-continue-to-work.aspx

³ https://dev.ssllabs.com/ssltest/analyze.html?d=eu.static.mega.co.nz&s=154.53.224.130

⁴ https://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4

Edited by JoWa
Link to comment
Share on other sites

  • 2 weeks later...

Statistik från HTTP Archive och Google (G+) visar att andelen anslutningar som är säkra ökar.

I oktober 2012 var ca 27 % av alla ”navigeringar” som gjordes med Chrome säkra, och i oktober 2014 var ca 58 % säkra! Allra högst var andelen i juli 2014: ca 60 %, men det slås nog snart. ;)

https.png

För att använda säker anslutning så ofta som möjligt (långt ifrån alla sidor som erbjuder säker anslutning använder HSTS eller en 301-omdirigering från http till https), kan man använda tillägget HTTPS Everywhere, som finns för Chrome, Opera och Firefox (även för Android).

Edited by JoWa
Link to comment
Share on other sites

  • 2 weeks later...
  • 2 months later...

CloudFlare har i dag meddelat att de i dag har inaktiverat RC4 på sina servrar. Samtidigt meddelar de att de introducerar en ny, snabb och säker chiffersvit, ChaCha20-Poly1305.

ChaCha20-Poly1305 stöds av Chromium och har använts av Google en tid. Poängen med ChaCha20-Poly1305 är att det är snabbt också utan hårdvara med speciella kryptoinstruktioner. Många mobila processorer saknar sådana instruktioner, och det gör även äldre processorer från Intel och AMD. Firefox kommer att få stöd för ChaCha20-Poly1305 när NSS har det. (Chromium för Windows och OS X har en modifierad version av NSS, men modifieringen har ännu inte antagits uppströms, emedan ChaCha20-Poly1305 ännu inte har standardiserats.¹)

¹ Uppdateringdraft-irtf-cfrg-chacha20-poly1305-10 har antagits för standardisering. :)

Edited by JoWa
Link to comment
Share on other sites

  • 4 weeks later...

Läser i WMF TechOps Q2 2014-15 Quarterly Review (WMF = Wikimedia Foundation), sidan 25:

  • Objective: Encryption (IPsec) on cross-data centre links for private data
  • Expected impact: Unhappy NSA

  :D

Läser vidare:

  • Objective: Prepare HTTPS infrastructure to handle full traffic
  • Expected impact: Slight increase in page load time
  • ETA: 2015-03-30

Det kan tolkas som en förberedelse för att säker anslutning kommer att användas automatiskt för alla besökare, inte endast för inloggade (och inloggande) användare. För närvarande används varken omdirigering (301) från http till https, eller HSTS. Att dessa säkerhetshöjande åtgärder dröjer beror på att säker anslutning till Wikipedia blockeras i vissa länder. I The future of HTTPS on Wikimedia projects, punkt 6, diskuteras det kort, och Kina nämns som exempel. Enligt GreatFire.org är läget bättre nu (värst var det augusti–december 2013), och att använda en säker anslutning i Kina är ett sätt att kringgå censuren av vissa Wikipedia-sidor. Även Iran blockerar, se Wikimedia Meta-Wiki: HTTPS.

I redovisningen, sidan 10, talas även om HTTP/2 och SPDY, med status ”Deferred. Insufficient staff time available.” Sedan det skrevs, har, som jag tidigare har rapporterat i annan tråd, SPDY/3.1 aktiverats. Det kan också ses som en förberedelse för utökad användning av ”HTTPS” (SPDY/3.1 över TLS), då det leder till snabbare laddning av sidor.

Edited by JoWa
Link to comment
Share on other sites

Både omdirigering från http till https, och HSTS har redan aktiverats för de ryskspråkiga Wikimedia-sidorna, som https://ru.wikipedia.org/ (se https://spdycheck.org/#ru.wikipedia.org och https://www.ssllabs.com/ssltest/analyze.html?d=ru.wikipedia.org) och https://ru.wiktionary.org/ (se https://spdycheck.org/#ru.wiktionary.org).

På HTTPS-by-default Workboard kan man följa arbetet med HSTS, SPDY och annat, som skall leda fram till att säker anslutning används överallt och för alla. Några planer på HTTP Public Key Pinning har jag inte sett.

Edited by JoWa
Link to comment
Share on other sites

  • 3 weeks later...

EFF kommenterar USA:s regerings ”The HTTPS-Only Standard”: The Federal HTTPS-Only Standard: Necessary and Overdue

Även The Internet Architecture Board (IAB) har kommenterat: IAB Comments on The HTTPS-Only Standard

The HTTPS-Only Standard inleds med följande mening: ”The American people expect government websites to be secure and their interactions with those websites to be private.”

Verkligen? Vem ligger bakom den mest omfattande massövervakningen någonsin? USA:s regering, och det har varit känt i nära två år.

Men mer kryptering är förstås välkommet, och varför inte citera Edward Snowden:

Edward Snowden sade:

Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it.

Som denna tråd ger flera exempel på, har många förbättringar gjorts, som försvårar eller t.o.m. omöjliggör övervakning. Alltfler webbsidor erbjuder säker anslutning, fler har omdirigering till säker anslutning, fler använder HSTS, fler använder efemärt nyckelutbyte (= framåtsekretess), nyare och säkrare krypteringsprotokoll (TLS 1.2) och chiffer (AES-GCM, ChaCha20) används, data krypteras innan den sänds från ett datacenter till ett annat, alltfler e-posttjänster stöder STARTTLS (e-post krypteras innan den sänds mellan e-posttjänster), arbete med att göra PGP-kryptering (End-To-End) av e-post mer lättanvänd pågår, m.m.

Edited by JoWa
Link to comment
Share on other sites

The future of HTTPS on Wikimedia projects, augusti 2013, rekommenderar Wikimedia webbläsartillägget HTTPS Everywhere.

Nu har rekommendationen aktualiserats igen, i Wikitech-l: Wikitech-l Digest, Vol 141, Issue 24, där det föreslås en policy att råda alla Wikipedia-användare att installera HTTPS Everywhere. Detta som ett svar på Kinas ”Great Cannon”.

Edited by JoWa
Link to comment
Share on other sites

Uppdatering om Wikimedias arbete:

Scale up HTTPS infrastructure to be able to serve HTTPS-by-default Done

Citat
With the completion of the scaling work, whether and when we flip the switch to force HTTPS for more (or all) wikis is mostly an analysis and decision-making issue now rather than a technical one. I believe we’re currently still trying to gather some insightful/useful data on user impact (in terms of latency, mostly) to inform those decisions. Of course there’s always a risk that the data could lead us back to something like “more software changes are needed before the tradeoffs are acceptable to turn this on globally.”

https://phabricator.wikimedia.org/T49832#1214665

Samtidigt skriver Google om krypterade annonser: Ads Take a Step Towards “HTTPS Everywhere”

Edited by JoWa
Link to comment
Share on other sites

  • 1 month later...

Äntligen…

Wikimedia Blog: Securing access to Wikimedia sites with HTTPS by default

Det är dock inte helt genomfört än. T.ex. har sv.wikipedia.org varken omdirigering till https eller HSTS. en.wikipedia.org har omdirigering men inte HSTS och HSTS med en dags varaktighet. zh.wikipedia.org har omdirigering och HSTS (om än den korta varaktigheten, en dag, gör HSTS rätt värdelöst om man inte besöker sidan dagligen).

Det sista exemplet är extra intressant, då säker anslutning till Wikipedia är av extra stor vikt i Kina, där vissa artiklar annars censureras. Sedan mitten av maj är dock kinesiskspråkiga Wikipedia sorgligt nog helt blockerat i Kina, både via säker och osäker anslutning. Engelskspråkiga Wikipedia är dock för närvarande tillgängligt.

Edited by JoWa
Link to comment
Share on other sites

I Meta-wikin kan man följa migreringen till https, som nu är nära slutmålet.

https://meta.wikimedia.org/wiki/HTTPS#2015

Den 13 juni var CA, EL, EN, HE, IT, RU, UG, ZH ”konverterade”. Ett steg återstår dock för dessa språk, att förlänga ”max-age” för HSTS. Den är nu en dag (86 400 sekunder). Undantag är RU (ryska), som tidigt konverterades till endast https (se ett tidigare inlägg), och har en ”max-age” på 15 768 000 sekunder (182,5 dagar).

Edited by JoWa
Link to comment
Share on other sites

As of this writing (June 15, 2015), the following language: CA, DE, EL, EN, FR, HE, JA, IT, RU, UG, ZH, bg, cs, eo, fi, id, nl, no, pl, pt, sv, th, tr as well as Wikimediafoundation.org, and Wikidata converted to HTTPS only.

För sv.wikipedia.org är omdirigering aktiverad, men ännu inte HSTS: https://spdycheck.org/#sv.wikipedia.org, och detsamma tycks gälla de flesta nya språk som nämns.

Link to comment
Share on other sites

Enligt https://meta.wikimedia.org/wiki/HTTPS#2015 är alla wikier nu konverterade till https. En del arbete återstår dock med HSTS. Först skall tiden förlängas. För de flesta wikisidor har HSTS en ”max-age” på ett eller tre dygn. Sedan skall preload läggas till, och domänerna läggas till i Googles lista¹, som används av Chromium, Firefox, Safari samt IE och Edge på Windows 10.

Angående Bing, som nämns i förra inlägget, har omdirigering till https inte aktiverats än, men den kanoniska adressen (som man kan se i sidans källkod) är https://www.bing.com:443/, där 443 är portens nummer. (Port 443 används för HTTP över TLS; port 80 används för HTTP utan kryptering.) Det innebär bl.a. att sökresultatet för bing ger en länk till https://www.bing.com/ Här en Google-sökning som exempel: https://www.google.se/search?q=bing

¹ https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json

Edited by JoWa
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

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

Loading...
 Share