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.

Februari 2020 säkerhetsrundup

Välkommen till denna februari-utgåva av SSL.coms säkerhetsrundan. Det kan vara vår kortaste månad, men den var fortfarande full av utvecklingen inom SSL /TLS, digitala certifikat och nätverkssäkerhet. Den här månaden täcker vi:

Apple sätter ny tidsgräns för certifikat

Som vi redan har rapporteratHar Apple nyligen valt att begränsa SSL /TLS certifikat livslängd till lite över ett år. Vid forumet CA / Browser (CA / B) i februari i Bratislava, Slovakien, meddelade Apple att från och med den 1 september 2020 skulle deras enheter och Safari-webbläsare inte längre acceptera certifikat med en livstid på mer än 398 dagar. Det har ännu inte funnits något officiellt, skriftligt meddelande från Apple. (Uppdatering: Apple meddelade policyförändringen på sin webbplats den 3 mars 2020.) As Registret anteckningar:

Klippcertifikatets livstid har tappats av Apple, Google och andra medlemmar i CA / Browser i flera månader. Policyn har sina fördelar och nackdelar ... Målet med flytten är att förbättra webbplatsens säkerhet genom att se till att utvecklare använder certifikat med de senaste kryptografiska standarderna och att minska antalet gamla, försummade certifikat som potentiellt kan stulas och återanvändas för nätfiske och drive-by malware-attacker. Om boffins eller misreants kan bryta kryptografin i en SSL /TLS standard, kortlivade certifikat kommer att säkerställa att folk migrerar till säkrare certifikat inom ungefär ett år.

Att en så betydande förändring sker på detta sätt är något överraskande, men skiftet i sig är det inte. Kortera certifikat livslängd, som noterats av Registret, är något som branschen på allvar har övervägt nyligen. En omröstning med CA / B-forum i september kunde ha ändrat certifikatens maximala giltighetstid från den nuvarande 825-dagarsstandarden ett år, men den omröstningen misslyckades. Den här gången röstade det inte - ett företag så inflytelserikt som Apple kan ändra standarden på egen hand.

SSL.com: s takeaway: Även om att minska livslängden på certifikat har varit ett samtalspunkt, har det ännu inte skett en konsensusåtgärd för att göra det i hela branschen. Detta drag från Apple kan troligen tvinga det samförståndet och ändra standarden. Det är oklart vilken krusningseffekt halveringen kommer att ha, men det ser ut som vi alla ska ta reda på!

DNS via HTTPS Nu Firefox standard

Denna månad, Mozilla uppsättning DNS via HTTPS (DoH) som standard för amerikanska användare av Firefox-webbläsaren. För de som är nya i konceptet: DoH krypterar DNS-information som i allmänhet är okrypterad (även på säkra webbplatser) och förhindrar andra från att se vilka webbplatser folk besöker. För vissa enheter som gillar att samla in uppgifter om användare (som regeringen eller de som hoppas kunna tjäna på att sälja nämnda data) är det dåliga nyheter. Och vissa hävdar också att den ökade opaciteten förhindrar användbar spionering som spårar brottslingar och möjliggör föräldrakontroll vid surfning. Andra, som Mozilla (tydligt) och Electronic Frontier Foundation uppskattar fördelarna med DoH och betonar att kryptering av webbtrafik förbättrar integriteten för allmänheten och försvårar försök att spåra och censurera människor av regeringen. Mozillas Firefox är den första webbläsaren som antar standarden som standard.

SSL.com: s takeaway: Som anhängare av integritet och mer robust kryptering, slår denna förändring av Mozilla oss som en till stor del positiv sak som säkert kommer att motsättas av människor som tjänar på att samla in och sälja data som samlats in på intet ont om internetanvändare.

Firefox och Slack har haft det med TLS 1.0 och 1.1

På ett otvetydigt sätt att bli av med TLS 1.0 och 1.1 helt, Mozilla kräver nu en manuell åsidosättning från användare som försöker ansluta till webbplatser med protokollen. Förändringen är ett steg mot deras uttalade mål att helt blockera sådana webbplatser. Som Gränsen rapporter, förändringen betyder vad som är "verkligen slutetiderna" för TLS och 1.0 och 1.1, och Mozilla kommer att förenas av andra inom en snar framtid:

Komplett support kommer att tas bort från Safari i uppdateringar till Apple iOS och macOS från och med mars 2020. ' Google har sagt att det kommer att ta bort stödet för TLS 1.0 och 1.1 i Chrome 81 (förväntas 17 mars). Microsoft sade det skulle göra samma sak "under första halvåret 2020".

Mozilla är inte den enda stora mjukvaruförsäljaren som styr alla bort från TLS 1.0 och 1.1. Den här månaden, Slack slutade stöd för dem också; företaget säger att de gör förändringen "för att anpassa sig till branschens bästa praxis för säkerhet och dataintegritet."

SSL.com: s takeaway: Meddelandet här är ganska enkelt. Sluta använda TLS 1.0 och 1.1 på dina webbplatser och se till att hålla dina webbläsare uppdaterade.

Chrome för att blockera osäkra nedladdningar

Nyligen har webbläsare gjort flytten för att varna användare om blandat innehåll. Blandat innehåll inträffar när webbplatser länkar till osäkert HTTP-innehåll (som bilder och nedladdningar) från HTTPS-sidor, "blandar" de två protokollen på ett sätt som inte är uppenbart för användare utan en varning (vi har granskat konceptet djupare i den här artikeln). Nu tar Chrome saker ett steg längre och kommer att blockera blandat innehåll från att laddas ner. Som den tech Times rapporter:

Från och med Chrome 82, som kommer att släppas i april, varnar Chrome användare om de håller på att ladda ner körbara filer med blandat innehåll från en stabil webbplats ... När version 83 släpps kan de körbara nedladdningarna blockeras, och försiktigheten kan implementeras för att arkivera filer. PDF-filer och .Doc-filer får varningen i Chrome 84, med ljud-, bilder-, text- och videofiler som visar den med hjälp av den 85: e versionen. Slutligen kan alla nedladdningar av blandat innehåll - en icke-stabil fil som kommer från en stabil webbplats - blockeras från och med urladdningen av Chrome 86.

Här är ett praktiskt diagram från Google som visar deras varning / blockering tidslinje för olika typer av blandat innehåll:

Schema för att blockera blandat innehåll i Chrome

SSL.com: s takeaway: Om du har en webbplats som serverar HTTP-resurser från HTTPS-sidor, klipp ut den! Det kan få dig blockerad.
Tack för att du valde 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-SECURE, eller bara klicka på chattlänken längst ner till höger på denna sida.


Prenumerera på SSL.coms nyhetsbrev

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