HTTPS og SSL-sertifikater: Gjør nettstedet ditt sikkert (og hvorfor du bør)

Hvordan

AvJack Busch

Sist oppdatert den20. april 2018

Når det gjelder sending av personlig informasjon over Internett - det være seg kontaktinformasjon, påloggingsinformasjon, kontoinformasjon, stedsinformasjon eller noe annet som kan misbrukes - offentligheten er stort sett paranoid om hackere og identitet tyver. Og med rette. Frykten for at informasjonen din kan bli stjålet, tuklet med eller feil brukt, er langt fra irrasjonell. Overskriftene om lekkasjer og sikkerhetsbrudd de siste tiårene beviser det. Men til tross for denne frykten, fortsetter folk å logge seg for å drive bank, shopping, journalføring, dating, sosialt samvær og annen personlig og profesjonell virksomhet på nettet. Og det er en liten ting som gir dem tillit til å gjøre dette. Jeg viser deg det:

Selv om ikke alle av dem forstår hvordan det fungerer, signaliserer den lille hengelåsen i adressefeltet til nettbrukere at de har en pålitelig forbindelse til et legitimt nettsted. Hvis besøkende ikke ser det i adressefeltet når de henter nettstedet ditt, vil du ikke - og burde ikke - få virksomheten deres.

For å få den lille adresselinjens hengelås til nettstedet ditt, trenger du et SSL-sertifikat. Hvordan får du en? Les videre for å finne ut av det.

Artikkeloversikt:

• Hva er SSL / TLS?
• Hvordan bruke HTTPS?
• Hva er et SSL-sertifikat, og hvordan får jeg et?
• SSL Certificate Shopping Guide
• • Certificate Authority
  • Domenevalidering vs. Utvidet validering
  • Delt SSL vs. Privat SSL
  • Tillit seler
  • Jokertegn SSL-sertifikater
  • garantier
  • Gratis SSL-sertifikater og selvsignerte SSL-sertifikater
• Installere et SSL-sertifikat
• HTTPS Fordeler og ulemper

Hva er SSL / TLS?

På nettet overføres data ved bruk av Hypertext Transfer Protocol. Det er grunnen til at alle nettadressene til websiden har " http://” eller “https://" foran dem.

Hva er forskjellen mellom http og https? Den ekstra lille S har store implikasjoner: Sikkerhet.

La meg forklare.

HTTP er "språket" som datamaskinen din og serveren bruker for å snakke med hverandre. Dette språket er universelt forstått, noe som er praktisk, men det har også sine ulemper. Når data sendes mellom deg og en server via Internett, vil det ta noen stopp underveis før den når det endelige målet. Dette utgjør tre store risikoer:

• At noen kan tjuvlytte på samtalen (som en digital wiretap).

• At noen kan opptre en (eller begge) av partene i begge ender.

• At noen kan sabotasje med meldingene som blir overført.

Hackere og rykk bruker en kombinasjon av det ovennevnte for en rekke svindel og heists, inkludert phishing-plotter, mann-i-midten-angrep og god, gammeldags reklame. Ondsinnede angrep kan være så enkle som å snuse ut Facebook-legitimasjon ved å fange opp ukrypterte informasjonskapsler (avlytting), eller de kan være mer sofistikerte. Du kan for eksempel tro at du sa banken din: "Overfør 100 dollar til Internett-leverandøren min," men noen i midten kan endre meldingen for å lese: "Vennligst overfør $100alle pengene mine til Internett-leverandøren minPeggy i Sibir”(Tampering og etterligning av data).

Så dette er problemene med HTTP. For å løse disse problemene kan HTTP lagdeles med en sikkerhetsprotokoll, noe som resulterer i HTTP Secure (HTTPS). Oftest er S i HTTPS levert av SSL-protokollen (Secure Sockets Layer) eller den nyere protokollen Transport Layer Security (TLS). Når den er distribuert tilbyr HTTPS toveiskjøring kryptering (for å forhindre avlytting), serverengodkjenning (for å forhindre etterligning) og meldingsgodkjenning (for å forhindre manipulering av data).

Slik bruker du HTTPS

Som et talespråk fungerer HTTPS bare hvis begge parter velger å snakke det. På klientsiden kan du velge å bruke HTTPS ved å skrive inn "https" i nettleserens adresselinje før URL-adressen (f.eks. I stedet for å skrive http://www.facebook.com, type https://www.facebook.com), eller ved å installere en utvidelse som automatisk tvinger HTTPS, for eksempel HTTPS Everywhere for Firefox og Chrome. Når nettleseren din bruker HTTPS, vil du se et hengelåseikon, en grønn nettleserlinje, tommelen opp eller noe annet betryggende tegn på at forbindelsen din til serveren er sikker.

For å bruke HTTPS, må webserveren imidlertid støtte den. Hvis du er en webansvarlig og ønsker å tilby HTTPS til besøkende, trenger du et SSL-sertifikat eller TLS-sertifikat. Hvordan får du et SSL- eller TLS-sertifikat? Fortsett å lese.

Videre lesing: Noen populære webapper lar deg velge HTTPS i brukerinnstillingene. Les våre anmeldelser Facebook, Gmail, og Twitter.

Hva er et SSL-sertifikat, og hvordan får jeg et?

For å kunne bruke HTTPS, må webserveren ha et SSL-sertifikat eller TLS-sertifikat installert. Et SSL / TLS-sertifikat er på samme måte som foto-ID for nettstedet ditt. Når en nettleser som bruker HTTPS får tilgang til websiden din, vil den utføre et "håndtrykk", der klientdatamaskinen ber om SSL-sertifikatet. SSL-sertifikatet blir deretter validert av en klarert sertifikatmyndighet (CA), som bekrefter at serveren er den den sier at den er. Hvis alt sjekker ut, får web besøkende den betryggende grønne haken eller låseikonet. Hvis noe går galt, vil de få en advarsel fra nettleseren som sier at identiteten til serveren ikke kunne bekreftes.

Handler etter et SSL-sertifikat

Når det gjelder installering av et SSL-sertifikat på nettstedet ditt, er det en mengde parametere å bestemme deg for. La oss gå over det viktigste:

Certificate Authority

Sertifikatmyndigheten (CA) er selskapet som utsteder SSL-sertifikatet ditt, og er det som vil validere sertifikatet ditt hver gang en besøkende kommer til nettstedet ditt. Mens hver SSL-sertifikatleverandør vil konkurrere om pris og funksjoner, er det den viktigste tingen å ta hensyn til når du skal bestemme sertifikatmyndighetene er om de har sertifikater som kommer forhåndsinstallert på det mest populære nettet lesere. Hvis sertifikatmyndigheten som utsteder SSL-sertifikatet ikke er på listen, blir brukeren bedt om en advarsel om at nettstedets sikkerhetssertifikat ikke er klarert. Dette betyr selvfølgelig ikke at nettstedet ditt er uekte - det betyr bare at din CA ikke er på listen (ennå). Dette er et problem fordi de fleste brukere ikke gidder å lese advarselen eller forske på den ukjente CA. De vil sannsynligvis bare klikke seg bort.

Heldigvis er listen over forhåndsinstallerte CAer på de store nettleserne ganske betydelig. Det inkluderer noen store merkenavn samt mindre kjente og rimeligere CA-er. Husholdningsnavn inkluderer Verisign, Gå pappa, Comodo, Thawte, Geotrust, og Entrust.

Du kan også se i innstillingene til din egen nettleser for å se hvilke sertifikatmyndigheter som er forhåndsinstallert.

• For Chrome går du til Innstillinger -> Vis avanserte innstillinger... -> Administrer sertifikater.
• For Firefox, gjør du Valg -> Avansert -> Vis sertifikater.
• For IE, Internett-alternativer -> Innhold -> sertifikater.
• For Safari, gå inn i Finder og velg Go -> Verktøy -> KeyChain Access og klikk System.

For rask referanse, sjekk ut denne tråden, som viser listen over akseptable SSL-sertifikater for Google Checkout.

Domenevalidering vs. Utvidet validering

Et SSL-sertifikat er ment å bevise identiteten til nettstedet du sender informasjon til. For å sikre at folk ikke tar ut falske SSL-sertifikater for domener de ikke med rette kontrollerer, a sertifikatmyndighet vil validere at personen som ber om sertifikatet faktisk er eieren av domenet Navn. Dette gjøres vanligvis gjennom en rask e-post eller en validering av telefonsamtaler, på samme måte som når et nettsted sender deg en e-post med en bekreftelseslink. Dette kalles a domenet validert SSL-sertifikat. Fordelen med dette er at det gjør det mulig å utstede SSL-sertifikater nesten umiddelbart. Du kan sannsynligvis gå og få et domenevaluert SSL-sertifikat på kortere tid enn det tok deg å lese dette blogginnlegget. Med et domenekontrollert SSL-sertifikat får du hengelåsen og muligheten til å kryptere nettstedets trafikk.

Fordelene med et domenekontrollert SSL-sertifikat er at de er raske, enkle og billige å få. Dette er også deres ulempe. Som du kan forestille deg, er det enklere å skruve sammen et automatisert system enn ett av levende mennesker. Det er liksom om en ungdomsskoleunge gikk inn i DMV og sa at han var Barack Obama og ønsket å få en myndighetsutstedt ID. personen ved pulten ville se på ham og ringe Feds (eller loony bin). Men hvis det var en robot som jobber med en foto-ID-kiosk, hadde han kanskje litt hell. På lignende måte kan phishers få "falske IDer" for nettsteder som Paypal, Amazon eller Facebook ved å lure domenevalideringssystemer. I 2009 publiserte Dan Kaminsky et eksempel på en måte å gjøre det på svindel CAer for å få sertifikater som ville få et phishing-nettsted til å se ut som om det var en sikker, legitim forbindelse. For et menneske ville denne svindelen være lett å oppdage. Men den automatiserte domenevalideringen den gang manglet de nødvendige kontrollene for å forhindre noe som dette.

Som svar på sårbarhetene til SSL og domenet validerte SSL-sertifikater, har bransjen introdusert Utvidet validering sertifikat. For å få et EV SSL-sertifikat, må selskapet eller organisasjonen din gjennomgå en streng vurdering for å sikre at det har god regjering med regjeringen din og med rette kontrollerer domenet du bruker til. Disse kontrollene krever blant annet et menneskelig element, og tar dermed lengre tid og er dyrere.

I noen bransjer kreves det et EV-sertifikat. Men for andre går fordelen bare så langt som det besøkende vil gjenkjenne. For hverdagens nettbesøkende er forskjellen subtil. I tillegg til hengelåsikonet, blir adressefeltet grønt og viser navnet på firmaet ditt. Hvis du klikker for mer informasjon, ser du at identiteten til selskapet er verifisert, ikke bare nettstedet.

Her er et eksempel på et vanlig HTTPS-nettsted:

Og her er et eksempel på et EVT-sertifikat HTTPS-nettsted:

Avhengig av bransje, kan det hende at et EV-sertifikat ikke er verdt det. I tillegg må du være en virksomhet eller organisasjon for å få en. Selv om store selskaper ser etter EV-sertifisering, vil du merke at flertallet av HTTPS-nettsteder fremdeles har den ikke-EV-smaken. Hvis det er bra nok for Google, Facebook og Dropbox, er det kanskje godt nok for deg.

En ting til: det er en midt på veien som kalles en organisasjon validert eller virksomhet validert sertifisering. Dette er en grundigere kontroll enn den automatiserte domenevalideringen, men det går ikke så langt som å møte bransjen forskrifter for et utvidet valideringssertifikat (legg merke til hvordan utvidet validering aktiveres og "organisatorisk validering ”er det ikke?). En OV eller virksomhet som er validert sertifisering koster mer og tar lengre tid, men den gir deg ikke den grønne adressefeltet og verifisert informasjon om bedriften. Helt ærlig kan jeg ikke tenke på en grunn til å betale for et OV-sertifikat. Hvis du kan tenke på en, kan du opplyse meg i kommentarene.

Delt SSL vs. Privat SSL

Noen webverter tilbyr en delt SSL-tjeneste, som ofte er rimeligere enn en privat SSL. Bortsett fra pris er fordelen med en delt SSL at du ikke trenger å få en privat IP-adresse eller en dedikert vert. Ulempen er at du ikke får bruke ditt eget domenenavn. I stedet vil den sikre delen av nettstedet være noe som:

https://www.hostgator.com/~yourdomain/secure.php

Kontrast det til en privat SSL-adresse:

https://www.yourdomain.com/secure.php

For publikumsvendte nettsteder, for eksempel e-handelsnettsteder og sosiale nettverksnettsteder, er dette åpenbart et drag, siden det virker som om du har blitt omdirigert fra hovedsiden. Men for områder som vanligvis ikke blir sett av allmennheten, for eksempel innersiden til et postsystem eller et administratorområde, kan en delt SSL være en god del.

Tillit seler

Mange sertifikatmyndigheter lar deg plassere et tillitsforsegling på hjemmesiden din etter at du har registrert deg for et av sertifikatene deres. Dette gir stort sett den samme informasjonen som å klikke på hengelåsen i nettleservinduet, men med større synlighet. Å inkludere et tillitsforsegling er ikke nødvendig, og det forsterker heller ikke sikkerheten din, men hvis det gir besøkende dine varme fuzzies å vite hvem som har utstedt SSL-sertifikatet, må du for all del kaste det opp der.

Jokertegn SSL-sertifikater

Et SSL-sertifikat bekrefter identiteten til ett domene. Så hvis du vil ha HTTPS på flere underdomener - f.eks. Groovypost.com, mail.groovypost.com og answers.groovypost.com- Du må kjøpe tre forskjellige SSL-sertifikater. På et bestemt tidspunkt blir et jokertegn SSL-sertifikat mer økonomisk. Det vil si ett sertifikat for å dekke ett domene og alle underdomener, dvs. * .groovypost.com.

garantier

Uansett hvor langvarig bedriftens gode rykte er, er det sårbarheter. Selv pålitelige CA-er kan målrettes av hackere, noe det fremgår av brudd på VeriSign som ble rapportert tilbake i 2010. Videre kan en CA-status på den pålitelige listen raskt oppheves, slik vi så med DigiNotar snafu tilbake i 2011. Ting skjer.

For å berolige enhver uro over potensialet for slike tilfeldige handlinger med SSL-utskytning, tilbyr mange myndigheter nå garantier. Dekningen varierer fra noen få tusen dollar til over en million dollar og inkluderer tap som følge av misbruk av sertifikatet ditt eller andre uhell. Jeg aner ikke om disse garantiene faktisk tilfører verdi eller ikke, eller om noen noen gang har vunnet et krav. Men de er der for din vurdering.

Gratis SSL-sertifikater og selvsignerte SSL-sertifikater

Det er to typer gratis SSL-sertifikater tilgjengelig. En selvsignert, brukt hovedsakelig til privat testing og fullblåst offentlig ansikt SSL Certs utstedt av en gyldig Certat Authority. Den gode nyheten er at det i 2018 er noen få alternativer for å få 100% gratis, gyldige 90 dagers SSL-sertifikater fra begge SSL gratis eller La oss kryptere. SSL for Free er først og fremst et GUI for Let's Encrypt API. Fordelen med SSL for Free-siden er at den er enkel å bruke, ettersom den har en fin GUI. La oss kryptere er imidlertid bra, siden du fullstendig kan automatisere forespørsel om SSL-sertifikater fra dem. Ideelt hvis du trenger SSL-sertifikater for flere nettsteder / servere.

Et selvsignert SSL-sertifikat er gratis for alltid. Med et selvsignert sertifikat er du din egen CA. Fordi du ikke er blant de pålitelige CA-ene som er innebygd i nettlesere, vil besøkende få en advarsel om at autoriteten ikke er anerkjent av operativsystemet. Som sådan er det egentlig ingen garanti for at du er den du sier du er (det er liksom å utstede deg en foto-ID og prøve å gi den i vinmonopol). Fordelen med et selvsignert SSL-sertifikat er imidlertid at det muliggjør kryptering for nettrafikk. Det kan være bra for intern bruk, hvor du kan la de ansatte legge til organisasjonen din som en pålitelig CA for å bli kvitt advarselsmeldingen og jobbe med en sikker tilkobling over Internett.

For informasjon om hvordan du setter opp et selvsignert SSL-sertifikat, sjekk dokumentasjonen for OpenSSL. (Eller hvis det er nok etterspørsel, skriver jeg opp en tutorial.)

Installere et SSL-sertifikat

Når du har kjøpt SSL-sertifikatet ditt, må du installere det på nettstedet ditt. En god webvert vil tilby å gjøre dette for deg. Noen kan til og med gå så langt som å kjøpe det for deg. Ofte er dette den beste veien å gå, siden det forenkler fakturering og sikrer at den er konfigurert riktig for webserveren din.

Fortsatt har du alltid muligheten til å installere et SSL-sertifikat som du kjøpte på egen hånd. Hvis du gjør det, kan det være lurt å begynne å konsultere kunnskapsbasen til webhotellet eller ved å åpne en helpdesk-billett. De vil henvise deg til de beste instruksjonene for å installere SSL-sertifikatet ditt. Du bør også se instruksjonene fra CA. Disse vil gi deg bedre veiledning enn noen generiske råd jeg kan gi deg her.

Det kan også være lurt å sjekke ut følgende instruksjoner for å installere et SSL-sertifikat:

• Installer et SSL-sertifikat og sett opp domenet i cPanel
• Hvordan implementere SSL i IIS (Windows Server)
• Apache SSL / TLS-kryptering

Alle disse instruksjonene vil innebære opprettelse av en SSL Certificate Signing Request (CSR). Du trenger faktisk en CSR bare for å få utstedt et SSL-sertifikat. Igjen kan webhotellet hjelpe deg med dette. For mer spesifikk DIY-informasjon om hvordan du oppretter en CSR, sjekk ut denne oppskrivningen fra DigiCert.

Fordeler og ulemper med HTTPS

Vi har allerede etablert fordelene med HTTPS: sikkerhet, sikkerhet, sikkerhet. Dette reduserer ikke bare risikoen for datainnbrudd, det gir også tillit og gir omdømme til nettstedet ditt. Kyndige kunder gidder kanskje ikke engang å registrere seg hvis de ser en “ http://” på innloggingssiden.

Det er imidlertid noen ulemper med HTTPS. Gitt nødvendigheten av HTTPS for visse typer nettsteder, er det mer fornuftig å tenke på disse som "ulemperiderasjoner ”i stedet for negativer.

• HTTPS koster penger. For det første koster det å kjøpe og fornye SSL-sertifikatet ditt for å sikre gyldighet år til år. Men det er også visse "systemkrav" for HTTPS, for eksempel en dedikert IP-adresse eller dedikert hostingplan, som kan være mer kostbart enn en delt hostingpakke.
• HTTPS kan redusere serverresponsen. Det er to problemer relatert til SSL / TLS som kan redusere sidehastigheten. For det første, for å begynne å kommunisere med nettstedet ditt for første gang, må brukerens nettleser gå gjennom håndtrykkprosessen, som spretter tilbake til sertifikatmyndighetens nettsted for å bekrefte sertifikat. Hvis CAs webserver blir treg, vil det være en forsinkelse i lastingen av siden din. Dette er stort sett utenfor din kontroll. For det andre bruker HTTPS kryptering, som krever mer prosessorkraft. Dette kan løses ved å optimalisere innholdet for båndbredde og oppgradere maskinvaren på serveren din. CloudFare har et godt blogginnlegg om hvordan og hvorfor SSL kan bremse nettstedet ditt.
• HTTPS kan påvirke SEO-innsatsen Når du går over fra HTTP til HTTPS; du flytter til et nytt nettsted. For eksempel, https://www.groovypost.com ville ikke være det samme som http://www.groovypost.com. Det er viktig å forsikre deg om at du har omdirigert de gamle koblingene dine og skrevet de riktige reglene under panseret på serveren din for å unngå å miste kostbar lenkesaft.
• Blandet innhold kan kaste et gult flagg. For noen nettlesere, hvis du har hoveddelen av en webside lastet fra HTTPS, men bilder og andre elementer (for eksempel stilark eller skript) lastet fra en HTTP-URL, så kan det hende at det vises en popup som advarer om at siden inkluderer ikke-sikker innhold. Selvfølgelig å ha noen sikkert innhold er bedre enn å ha ingen, selv om sistnevnte ikke resulterer i en popup. Men likevel kan det lønne seg å sikre at du ikke har noe "blandet innhold" på sidene dine.
• Noen ganger er det lettere å få en tredjeparts betalingsprosessor. Det er ingen skam å la Google Checkout, Paypal eller Checkout fra Amazon håndtere betalingene dine. Hvis alt dette virker som for mye å krangle, kan du la kundene dine utveksle betalingsinformasjon på Paypals sikre side eller Googles sikre nettsted og spare deg selv for problemet.

Har du andre spørsmål eller kommentarer om HTTPS og SSL / TLS sertifikater? La meg høre det i kommentarene.