JoWa Posted August 5, 2013 Share Posted August 5, 2013 (edited) 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. Edited August 14, 2016 by JoWa 1 Quote Link to comment Share on other sites More sharing options...
essob Posted August 5, 2013 Share Posted August 5, 2013 Sammanfattningsvis kan sägas att 2013 ser ut att bli ett bra år för kryptering på Internet. Kan det ha att göra med Edward Snowden och hans avslöjanden? Quote Link to comment Share on other sites More sharing options...
JoWa Posted August 5, 2013 Author Share Posted August 5, 2013 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. Quote Link to comment Share on other sites More sharing options...
JoWa Posted August 21, 2013 Author Share Posted August 21, 2013 (edited) I dag skulle HTTPS som standard för inloggade användare ha aktiverats: HTTPS for logged in users on Wednesday August 21st Men det har flyttats en vecka, till 28 augusti, se länk nedan. Wikimedia Meta-Wiki: HTTPS Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted August 24, 2013 Author Share Posted August 24, 2013 Kan det ha att göra med Edward Snowden och hans avslöjanden? Jimmy Wales, Wikipedias grundare, var rätt tydlig. Quote Link to comment Share on other sites More sharing options...
JoWa Posted August 29, 2013 Author Share Posted August 29, 2013 (edited) 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. 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. 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 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”. Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
e-son Posted August 29, 2013 Share Posted August 29, 2013 Tack för lektionen! Quote Link to comment Share on other sites More sharing options...
JoWa Posted September 13, 2013 Author Share Posted September 13, 2013 (edited) 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: Vad blir nästa steg? En ”framåtsäker” nyckelutbytesmekanism? Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted September 17, 2013 Author Share Posted September 17, 2013 (edited) 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: Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted November 20, 2013 Author Share Posted November 20, 2013 (edited) EFF: Encrypt the Web Report: Who’s Doing What En genomgång av vilka säkerhetsfunktioner/-lösningar några större webbtjänster tillämpar. Under tabellen förklaras funktionerna (mer än i den infogade bilden). Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted November 23, 2013 Author Share Posted November 23, 2013 (edited) Twitter Blogs: Forward Secrecy at Twitter (2013-11-22) Twitter använder sedan några månader ECDHE_RSA som nyckelutbytesmekanism. Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted November 23, 2013 Author Share Posted November 23, 2013 (edited) 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). Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted December 5, 2013 Author Share Posted December 5, 2013 (edited) 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. Edited May 28, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted December 17, 2013 Author Share Posted December 17, 2013 (edited) 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? Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted April 3, 2014 Author Share Posted April 3, 2014 (edited) On 2013-11-20 at 07:08, JoWa sade: EFF: Encrypt the Web Report: Who’s Doing What Ö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. Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted April 4, 2014 Author Share Posted April 4, 2014 Törs man gissa att IE12 kommer att stödja HSTS? Det ser ut att bli så: Websites Must Use HSTS in Order to Be Secure (EFF) Quote Link to comment Share on other sites More sharing options...
JoWa Posted May 15, 2014 Author Share Posted May 15, 2014 (edited) 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). Adam Langley: SHA-256 certificates are coming Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted May 29, 2014 Author Share Posted May 29, 2014 (edited) 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 Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted June 5, 2014 Author Share Posted June 5, 2014 (edited) 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) Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted June 6, 2014 Author Share Posted June 6, 2014 (edited) 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. Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted June 20, 2014 Author Share Posted June 20, 2014 (edited) 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. Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted July 2, 2014 Author Share Posted July 2, 2014 (edited) 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. Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted July 9, 2014 Author Share Posted July 9, 2014 (edited) Wikimedias sidor stöder nu framåtsekretess genom att använda nyckelutbytesmekanismen ECDHE_RSA. Wikimedia Foundation: Tech/News/2014/27 EFF: Forward Secrecy Brings Better Long-Term Privacy to Wikipedia Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted August 10, 2014 Author Share Posted August 10, 2014 (edited) 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). Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
JoWa Posted August 22, 2014 Author Share Posted August 22, 2014 (edited) 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. Edited August 14, 2016 by JoWa Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.