SSL vs TLS: Kjenn dine protokoller for 2020

Google bryter ned på nettstedets sikkerhet. Fra Chrome versjon 62 trenger alle nettsteder med tekstinntastingsfelt et SSL-sertifikat, eller Google vil merke nettstedet som ikke sikkert med et rødt advarselsskilt ved siden av nettadressen.


Endringen kommer også på et interessant tidspunkt, med tanke på det nylige presset til nettlesere og servere som støtter TLS. Imidlertid, hvis du er ukjent med nettstedbyggingsspillet, kan det hende at alle disse forkortelsene er nok til å få hodet til å snurre.

Vi er her for å fjerne forvirringen rundt SSL og TLS og vise deg hvordan du kan holde nettstedet ditt i den grønne sonen. Vi sammenligner hva sikkerhetsprotokollene tar sikte på å oppnå, går over det siste innen krypterte tilkoblinger og tar deg gjennom å kjøpe et sertifikat for nettstedet ditt.

SSL vs TLS

SSL og TLS gjør det samme. De er krypterte protokoller for dataoverføring. De jobber ved å etablere et håndtrykk mellom to maskiner. Håndtrykket inkluderer chiffer, autentisering og nøkkelutveksling. Når det er gjort, åpnes en sikker forbindelse mellom maskinene.

Dataene som reiser mellom maskiner blir deretter kryptert og fragmentert til en viss størrelse, avhengig av chiffer, og sendt til nettverkets transportlag. Chifferet omhandler kryptering, ikke håndtrykk. SSL- og TLS-protokollene brukes ganske enkelt for å fullføre håndtrykk og avtale en krypteringsmodell.

Hva er SSL & TLS?

SSL står for “Secure Sockets Layer.” Den ble utviklet av Netscape og ble først utgitt for publikum i 1995. Offentlig utgivelse var versjon to og hackere fant raskt måter å bryte gjennom den. Et år senere ga Netscape ut versjon tre, som ble ansett som sikre i åtte år.

Netscape

I 2014 gjorde POODLE-angrepet SSL 3.0 usikker, men ingen visste det den gangen. TLS (Transport Layer Security), som er en sikrere versjon av SSL, ble utgitt i 1999 og kom med en fallback-mekanisme til SSL 3.0 for bakoverkompatibilitet.

Den kompatibiliteten var innebygd fordi POODLE-angrepet, en mann-i-midten utnyttelse, misbrukte den bakoverkompatibiliteten (for å lese mer om MitM-angrep, sjekk ut vår artikkel om farene ved offentlig WiFi).

TLS 1.1 kom ut i 2006 og 1.2 fulgte i 2008. TLS 1.2 er den nåværende og sikreste protokollen, selv om 1.3 ble godkjent tidligere i år. Vi forventer at nettlesere og servere vil støtte det snart.

Protokollene er forskjellige, men ikke mer enn de forskjellige versjonene av SSL. Den samme prosessen skjer, et håndtrykk mellom to maskiner, men versjonen av protokollen avgjør hvordan det skjer.

Problemet med bakoverkompatibilitet

Forvirringen rundt SSL og TLS kommer fra bakoverkompatibilitet. TLS 1.2 har rester av tidligere versjoner av SSL for å gjøre den kompatibel med utdaterte nettlesere. Som sådan har mange nettsteder ikke deaktivert funksjonene som gjør en protokoll som TLS 1.2 usikker.

Det er her TLS 1.3 kommer inn. Den er bygget for å deaktivere gamle funksjoner og fremskynde ytelsen på en sikker tilkobling. I stedet for å bli enige om en krypteringsmodell, gir serveren krypteringsnøkkelen med TLS 1.3. Det gjør teoretisk at flere nedgraderingsangrep, som tvinger serveren til å bruke en eldre protokoll, foreldes.

Den siste oppdateringen er et skyv mot det moderne internett, og forlater den utdaterte modellen som ble etablert av tidlige versjoner av SSL. Forhåpentligvis vil angrep som POODLE i løpet av få år ikke være så mye bekymring som de er i dag.

Bruke TLS på nettstedet ditt

TLS-protokollen som brukes på nettstedet ditt, er avhengig av serveren du er vert for. De beste webhotellleverandørene bruker TLS 1.1 og 1.2 utelukkende, med 1.0 generelt forbeholdt nettstedsbyggere som ikke inkluderer e-handel.

Den endelige versjonen av TLS 1.3 ble bare publisert for noen uker siden, så det vil ta tid før webhotellene støtter den. Kinsta har for eksempel allerede adressert utgivelsen av TLS 1.3 og tar skritt for å implementere det (les Kinsta-gjennomgangen vår).

Så lenge du bruker et SSL-sertifikat, vil den besøkende forbindelsen bli kryptert. Til tross for den utdaterte navneplanen, fungerer sertifikater fremdeles med de nyeste protokollene, til og med TLS 1.3. Selve sertifikatet krypterer ikke noe.

Sertifikater brukes ganske enkelt som en bekreftelsesmetode. Ulike former for SSL- og TLS-sertifikater viser nivået av tillit en nettleser har for domenet ditt. Vi vil gjennomgå dem i neste avsnitt.

Hvis du har et sertifikat, enten det er en gratis fra Dreamhost eller en betalt fra HostGator, kan nettstedet ditt koble seg til ved å bruke den siste protokollen som serveren din bruker (les vår Dreamhost-gjennomgang og HostGator-gjennomgang).

Det er et par måter å sjekke det på. Den første er gjennom kunnskapsbasen til webhotellet. GoDaddy har for eksempel en liten tabell som viser hvilken TLS-versjon serveren din støtter, avhengig av vertsplanen du er på (les GoDaddy-gjennomgangen).

Du kan også teste webserveren din ved hjelp av SSL-servertesten fra SSL Labs. Den viser deg hvilken protokoll serveren din bruker, i tillegg til krypteringsmetoden, og gir deg en samlet vurdering.

SSL- og TLS-sertifikattyper

Nok en gang er SSL-sertifikater bedre definert som “sertifikater som kan bruke SSL og TLS,” så vi kaller dem SSL-sertifikater for å unngå forvirring for denne delen. Uansett hvor du leser SSL eller TLS uten en protokollversjon, vil de være de samme tingene.

Domenet validerte sertifikater

Den mest grunnleggende formen for SSL-sertifikat er et domenekontrollert sertifikat, som sjekker mot domeneregisteret. I hovedsak bekrefter det at domenet en bruker prøver å få tilgang til poeng til riktig DNS-server.

Det er det billigste sertifikatet å få, ofte inkludert i pakker gratis. Jimdo, en av våre beste valg av nettstedsbygger, inkluderer et Let’s Encrypt DV-sertifikat gratis, og det samme gjør mange nettstedbyggere og webhoteller (les vår Jimdo-anmeldelse).

DV-sertifikater er imidlertid høyrisiko, da nettlesere ofte ikke kan validere hvis virksomheten på nettstedet er legitim. I Chrome ser du vanligvis https-protokollen med en rød lås med en skråstrek gjennom den til venstre.

DV-sertifikat

Hvis du driver en blogg eller et personlig nettsted, er et DV-sertifikat bra, men hvis du ber om personlig informasjon, spesielt kredittkortinfo, bør du bruke noe sterkere.

Organisasjon validerte sertifikater

Organisasjonsvaliderte sertifikater sjekker mot virksomheten eller organisasjonen. Agenter fra Certificate Authority vil sjekke registerdatabaser for å sikre at nettstedet er ekte. Alle dataene i et OV-sertifikat er legitime.

Hvis du driver en kommersiell virksomhet på nettet, er dette sertifikatet du trenger å bruke. URLen din bruker fortsatt https, men det vil være en lås ved siden av adressefeltet. I Chrome er det grønt med ordet “sikker” til høyre.

OV-sertifikat

Utvidet valideringssertifikat

OV-sertifikater er gode, men utvidede valideringssertifikater er bedre. OV-sertifikater krever en enkelt vetting fra CA, mens EV-sertifikater krever kontinuerlig overvåking basert på retningslinjene for utvidet validering.

Bekreftelsesprosessen er mye strengere, og prisen er mye høyere. For større nettbutikker kan imidlertid et EV-sertifikat forbedre forbrukernes tillit og øke salget på nettet.

For noe annet er sertifikatet stort sett unødvendig. Selv store nettsteder som ikke samler inn brukerinformasjon, bruker ikke EV-sertifikater. Hvis du bruker en, vil nettleseren vise en grønn adressefelt med en lås, sammen med navnet på firmaet ditt.

EV-sertifikat

Siste tanker

Det er ingen mangel på forvirrende akronymer når det gjelder cybersecurity, og endringen fra SSL til TLS hjelper ikke det. Selv om protokollene er forskjellige, oppnår de samme mål: en sikker forbindelse mellom serveren og brukeren.

Så langt som sertifikater går, er vilkårene utskiftbare, så ikke bekymre deg for å oppgradere et SSL-sertifikat til et TLS-sertifikat. De er de samme tingene.

Hvis du ser etter webhotellleverandører som kan lede deg gjennom prosessen, må du lese vår beste billige webhotell for å lære hvordan du gjør det uten mye mynt.

Er det noe annet du er nysgjerrig på med SSL- eller TLS-tilkoblinger? Gi oss beskjed i kommentarene nedenfor, og som alltid takk for at du leser.

Kim Martin
Kim Martin Administrator
Sorry! The Author has not filled his profile.
follow me