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.

Februar 2020 sikkerhetsrunde

Velkommen til denne februarutgaven av SSL.coms Security Roundup. Det kan være vår korteste måned, men den var fortsatt full av utviklingen i SSL /TLS, digitale sertifikater og nettverkssikkerhet. Denne måneden vil vi dekke:

Apple setter ny tidsbegrensning på sertifikater

Som vi allerede har rapportert, Apple har nylig valgt å begrense SSL /TLS sertifikat levetid til litt over et år. På Forum CA / Browser (CA / B) i februar i Bratislava, Slovakia, kunngjorde Apple at fra 1. september 2020 vil enhetene deres og Safari-nettleseren ikke lenger godta sertifikater med levetid som er større enn 398 dager. Det har ikke kommet noen offisiell, skriftlig kunngjøring fra Apple ennå. (Oppdatering: eple annonsert policyendringen på sin hjemmeside 3. mars 2020.) As Registeret notater:

Kuttesertifikatets levetid har blitt betraktet av Apple, Google og andre medlemmer av CA / Browser i flere måneder. Politikken har sine fordeler og ulemper ... Målet med flyttingen er å forbedre nettsikkerheten ved å sørge for at devs bruker certs med de nyeste kryptografiske standardene, og å redusere antall gamle, forsømte sertifikater som potensielt kan bli stjålet og gjenbrukt til phishing og malware-angrep. Hvis boffins eller misreants er i stand til å bryte kryptografien i en SSL /TLS standard kortlivede sertifikater vil sikre at folk migrerer til sikrere sertifikater i løpet av omtrent et år.

At et så betydelig skifte skjer på denne måten er noe overraskende, men skiftet i seg selv er det ikke. Kortere sertifikat levetid, som bemerket av Registeret, er noe bransjen har vurdert alvorlig den siste tiden. En CA-B-stemmeseddel i september kunne ha endret den maksimale gyldighetsperioden for sertifikater fra gjeldende 825-dagers standard ett år, men den avstemningen mislyktes. Denne gangen tok det ikke avstemning - et selskap så innflytelsesrik som Apple kan skifte standarden på egen hånd.

SSL.coms takeaway: Selv om det har vært et samtale å redusere sertifikatets levetid, har det ennå ikke vært en enighet om å gjøre det på tvers av bransjen. Dette trekket fra Apple kan sannsynligvis tvinge den konsensus og endre standarden. Det er uklart hvilken ringvirkning halveringen vil ha, men det ser ut som vi alle er i ferd med å finne ut!

DNS over HTTPS Nå er Firefox standard

Denne måneden satt Mozilla DNS over HTTPS (DoH) som standard for amerikanske brukere av Firefox-nettleseren. For de som er nye i konseptet: DoH krypterer DNS-informasjon som vanligvis er ukryptert (selv på sikre nettsteder) og forhindrer andre i å se hvilke nettsteder folk besøker. For noen enheter som liker å samle inn data om brukere (som regjeringen, eller de som håper å tjene på å selge nevnte data), er det dårlige nyheter. Og noen hevder også at den økte opaciteten forhindrer nyttig spionasje som sporer kriminelle og gir mulighet for foreldrekontroll ved surfing. Andre, som Mozilla (tydelig) og Electronic Frontier Foundation fremhever fordelene med DoH, og understreker at kryptering av webtrafikk forbedrer privatlivet for publikum og motvirker forsøk på å spore og sensurere folk fra myndighetene. Mozillas Firefox er den første nettleseren som vedtar standarden som standard.

SSL.coms takeaway: Som tilhengere av personvern og mer robust kryptering, ser denne endringen av Mozilla oss som en i stor grad positiv ting som sikkert vil bli motarbeidet av folk som tjener på å samle og selge data samlet på intetanende internettbrukere.

Firefox og Slack har hatt det med TLS 1.0 og 1.1

I et entydig trekk å bli kvitt TLS 1.0 og 1.1 helt, Mozilla krever nå en manuell overstyring fra brukere som prøver å koble seg til nettsteder ved å bruke protokollene. Endringen er et skritt mot deres erklærte mål om å blokkere slike nettsteder helt. Som Randen rapporter, betyr endringen hva som er "virkelig sluttidene" for TLS og 1.0 og 1.1, og Mozilla får selskap av andre i løpet av en nær fremtid:

Fullstendig støtte vil bli fjernet fra Safari i oppdateringer til Apple iOS og macOS fra mars 2020. ' Google har sagt at det vil fjerne støtten for TLS 1.0 og 1.1 i Chrome 81 (forventet 17. mars). Microsoft sa det ville gjort det samme 'i første halvdel av 2020'.

Mozilla er ikke den eneste store programvareleverandøren som styrer alle bort fra TLS 1.0 og 1.1. Denne måneden, Slack endte oppslutningen for dem også; selskapet sier at de gjør endringen "for å samsvare med bransjens beste praksis for sikkerhet og dataintegritet."

SSL.coms takeaway: Meldingen her er ganske grei. Slutt å bruke TLS 1.0 og 1.1 på nettstedene dine, og sørg for å holde nettleserne oppdaterte.

Chrome for å blokkere usikre nedlastinger

Nylig har nettlesere gjort et trekk for å advare brukere om blandet innhold. Blandet innhold oppstår når nettsteder lenker til usikkert HTTP-innhold (for eksempel bilder og nedlastinger) fra HTTPS-sider, og "blander" de to protokollene på en måte som ikke er åpenbar for brukerne uten advarsel (vi har undersøkt konseptet dypere i denne artikkelen). Nå tar Chrome tingene et skritt videre, og vil blokkere blandet innhold fra å bli lastet ned. Som Tech Times rapporter:

Fra og med Chrome 82, som skal utgis i april, vil Chrome advare brukere hvis de er i ferd med å laste ned kjørbare filer med blandet innhold fra et stabilt nettsted ... Når versjon 83 blir utgitt, kan de nedlastbare nedlastningene blokkeres, og forsiktigheten kan implementeres for å arkivere filer. PDF-filer og .Doc-filer får advarselen i Chrome 84, med lyd-, bilder-, tekst- og videofiler som viser den ved hjelp av den 85. versjonen. Endelig kan alt nedlastet innhold av blandet innhold - en ikke-stabil fil som kommer fra et stabilt nettsted - bli blokkert etter utgivelsen av Chrome 86.

Her er et praktisk diagram fra Google som viser advarsel / blokkering av tidslinjen for forskjellige typer blandet innhold:

Planlegg for blokkering av blandet innhold i Chrome

SSL.coms takeaway: Hvis du har et nettsted som serverer HTTP-ressurser fra HTTPS-sider, kutt det ut! Det kan få deg blokkert.
Takk for at du valgte SSL.com! Hvis du har spørsmål, kan du kontakte oss via e-post på Support@SSL.com, anrop 1-877-SSL-SECURE, eller bare klikk på chat-koblingen nederst til høyre på denne siden.


Abonner på SSL.coms nyhetsbrev

Ikke gå glipp av nye artikler og oppdateringer fra SSL.com