en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Juni 2020 säkerhetsrundup

Välkommen till denna juni-utgåva av SSL.coms Security Roundup. Sommaren är här, pandemin fortsätter, och det gör också nyheterna om digital säkerhet! Den här månaden tittar vi på:

Om du letar efter en SSL /TLS certifikat för din webbplats, ta en titt på SSL.coms prisvärda, höga värde alternativ.

Senaten ska överväga mandatkryptering bakdörrar

Den här är typ av yikes-y. Medan många av landet överväger att skala tillbaka brottsbekämpningens kraft, har tre senatorer infört en Drakonisk räkning som kommer att tvinga tekniska företag att skapa krypteringsschema "bakdörrar" som gör det möjligt för brottsbekämpning att få åtkomst till data under transitering och på enheter. Som Vice Magazine Moderkort lägg den kortfattat in deras rubrik, "Republikaner som inte förstår kryptering introducerar Bill för att bryta den."

Lagförslaget från senatorerna Lindsey Graham (R-South Carolina), Tom Cotton (R-Arkansas) och Marsha Blackburn (R-Tennessee) har kritiserats brett och grundligt av teknikindustrin, medborgerliga rättighetsförespråkare och många med sunt förnuft. Som Thomas Claburn Artikeln i registret förklarar:

Räkningen kräver att alla företag som har en garanti - "enhetstillverkare, en operatörsleverantör, en leverantör av fjärrdatatjänst eller annan person" - ska hjälpa myndigheterna att "få tillgång till information som är lagrad på en elektronisk enhet eller att få tillgång till fjärrlagrad elektronisk information. ”

 Det anger inte hur kryptering ska hanteras, bara att det ska kunna ångras när det är obekvämt för myndigheter ...

 ... Kryptering, bör det sägas, förhindrar också en hel del brott genom att hålla saker som bankkonton online och surfa rimligt säkert. Mandaterar en bakdörr, vilket matematiskt vem som helst kunde hitta, kanske inte det klokaste draget.

Tyvärr är detta försök till lagstiftning inte ens särskilt nytt, bara den senaste lata iterationen av ett försök att kringgå digital säkerhet för att göra det lättare för Powers That Be.

SSL.com: s takeaway: SSL.com stöder inte regeringsuppdragad osäkerhet - när end-to-end-kryptering är förbjuden kommer endast outlaws att ha end-to-end-kryptering. Observera också detta citat från vice-artikeln: 'Den enda varningen är "om inte en oberoende enhets oberoende handlingar gör det tekniskt omöjligt att göra det", vilket verkar utesluta den nuvarande verkligheten, det vill säga att teknikföretag själva har gjort det omöjligt att dekryptera data lagrad på en telefon krypterad med ett lösenord eller meddelanden som utbyts i krypterade appar från slut till slut. '

USA: s regering planerar att använda HTTPS på alla .gov-webbplatser

I goda försenade nyheter, den amerikanska regeringen har meddelat dess avsikt att lägga till ".gov" -domänen till HTTP Strict Transport Security (HSTS) -förbelastningslistan. För tillfället kommer vissa statliga webbplatser att fortsätta erbjuda HTTP för att hålla dem tillgängliga för användare, med avsikt att nå den punkt där alla .gov-webbserver kommer att använda HTTPS som standard.

Men detta är den federala regeringen, och det är viktigt att notera att inget av detta kommer att äga rum över en natt. Snarare arbetar USA för att sätta .gov-domänen på HSTS-förbelastningslistan, som så småningom kommer omdirigera användare att kommunicera via HTTPS som standard.

Från regeringens annonsörert:

Observera att vi tillkännager en avsikt att förbelasta TLD, men inte faktiskt förladda den idag. Om vi ​​gjorde det skulle vissa statliga webbplatser som inte erbjuder HTTPS bli otillgängliga för användare, och vi vill inte påverka tjänsterna negativt på vårt sätt att förbättra dem! Faktiskt förbelastning är ett enkelt steg, men att komma dit kommer att kräva en samlad ansträngning bland de federala, statliga, lokala och stammande regeringsorganisationer som använder en gemensam resurs, men fungerar inte ofta tillsammans i det här området ... Med en samlad ansträngning kan vi ladda om. gov inom några år.

Under tiden, enligt samma tillkännagivande, kommer regeringen att förbereda enskilda webbplatser för övergången, hålla presentationer och lyssnande sessioner, och automatiskt ladda om alla ny .gov-domäner börjar i september. De har också skapat en ny listserv för feedback från myndigheter om utmaningar de förväntar sig att möta.

SSL.com: s takeaway:  Alla webbplatser överallt bör använda HTTPS nu, så det här är en bra idé, men en långsam rörelse. Vi tar vad vi kan få!

Comcast och Mozilla Strike Firefox DoH Deal

Comcast är den första Internetleverantören till samarbeta med Mozilla för att tillhandahålla krypterade DNS-uppslag i Firefox. Affären mellan de två företagen kommer efter en tvist över ISP-integritet och om DNS via HTTPS tar bort ISP: s förmåga att spåra användare och underhålla saker som föräldrakontroll.

Jon Brodkin i Ars Technica förklarar att Comcast kommer att vara den första Internetleverantören som går med i Firefox: s Trusted Recursive Resolver-program och går med i Cloudflare och NextDNS. Programmet, enligt den artikeln, "kräver krypterade DNS-leverantörer att träffas kriterier för integritet och öppenhet och lovar att inte blockera eller filtrera domäner som standard 'såvida det inte specifikt krävs enligt lag i den jurisdiktion där resolvern verkar'. "

Tidigare var de två nu-partnerna oeniga om DNS över HTTPS, vilket förhindrar människor från att se vad DNS-sökningar som gör webbläsare gör, vilket gör ISP: s övervakning ganska svår. Från Ars Technica-artikeln:

Partnerskapet Comcast / Mozilla är anmärkningsvärt eftersom Internetleverantörer har kämpat mot planer på att distribuera DNS över HTTPS i webbläsare, och Mozillas arbete med tekniken är i stor utsträckning avsedd att förhindra ISP: er från att snoka på sina användares surfning. I september 2019 skrev branschgrupper inklusive NCTA-kabellobbyn som Comcast tillhör a brev till kongressen motsätter sig Googles planer för krypterat DNS i Chrome och Android. Comcast gav medlemmar av kongressen a lobbypresentation som hävdade att den krypterade DNS-planen skulle "centralisera [e] en majoritet av globala DNS-data med Google" och "ge en leverantör kontroll över dirigering av internettrafik och stora mängder ny data om konsumenter och konkurrenter." Comcasts lobbypresentation klagade också över Mozillas plan för Firefox.

Mozilla i november anklagade internetleverantörer att ljuga för kongressen för att sprida förvirring om krypterad DNS. Mozilla brev till kongressen kritiserade Comcast och pekade på en incident 2014 där Comcast "injicerade annonser till användare som är anslutna till sina offentliga Wi-Fi-hotspots, vilket kan skapa nya säkerhetsproblem på webbplatser." Mozilla sa att ”Vi tror att sådana proaktiva åtgärder [för att implementera krypterad DNS] har blivit nödvändiga för att skydda användare mot bakgrund av den omfattande informationen om ISP-missbruk av personuppgifter på grund av Comcast-incidenten och andra som involverar Verizon och AT&T. Mozilla påpekade också landets brist på regler för integritetsskydd för bredband dödad av kongressen under 2017 på begäran av Internetleverantörer.

Men det verkar nu vara i det förflutna, med ett tecknat avtal mellan de två företagen från och med mars, och en förväntning att Comcasts krypterade DNS kommer till Chrome tillräckligt snart också.

SSL.com: s takeaway: Det är bra att se en ISP komma ombord med krypterad DNS, men du bör fortfarande läsa Comcasts Xfinity integritetspolicy om du är kund.

AddTrust External CA Rotcertifikatet har löpt ut

Vårt AddTrust External CA root certifikat löpt ut i maj 30, 2020. Även om de flesta användare inte kommer att påverkas av denna utgång, är det fortfarande anmärkningsvärt. Vissa certifikat utfärdade tidigare av SSL.com-kedjan till Sectigos USERTrust RSA CA-rot via en mellanliggande korssignerad av AddTrust-roten. Detta gjordes för att säkerställa kompatibilitet med äldre enheter som inte inkluderar USERTrust-roten.

Lyckligtvis enheter som do inkludera USERTrust-roten, som är de allra flesta, kommer inte att påverkas av utgången. I så fall, vilket kommer att vara sant för alla moderna webbläsare, operativsystem och mobila enheter, väljer programvaran helt enkelt en tillförlitlig väg som leder till USERTrust och ignorerar det utgångna AddTrust-certifikatet. Vi förklarade allt detta i början av månaden, så om du letar efter mer information kanske du vill gå över till vårt 2 juni-blogginlägg. För att upprätthålla kompatibilitet med äldre enheter kan webbplatsägare med SSL.com USERTrust-certifikat ladda ner ersättning mellancertifikat och rootcertifikat via knapparna nedan:

NEDLADDA INDIVIDUELLA CERTIFIKATER

NEDLADDA BUNDLEDA CERTIFIKATER

Användare som förlitar sig på äldre SSL /TLS klienter, inklusive OpenSSL 1.0.x och GnuTLS, bör ta bort det löpt ut AddTrust-certifikatet från deras OS-rotlager. Se vår blogginlägg för länkar till fixar för Red Hat Linux och Ubuntu.

SSL.com: s takeaway: Om du har USERTrust-certifikat utfärdat av SSL.com kan du (och borde!) Ladda ner ett nytt CA-paket från vår webbplats och installera dem på din server.
Tack för att du besöker SSL.com! Om du har några frågor, vänligen kontakta oss via e-post på Support@SSL.com, ring upp 1-877-SSL-SECUREeller klicka bara på chattlänken längst ned till höger på den här sidan. Du kan också hitta svar på många vanliga supportfrågor i vår kunskapsbas.


Prenumerera på SSL.coms nyhetsbrev

Missa inte nya artiklar och uppdateringar från SSL.com