HTTPS- og SSL-sertifikater Gjør ditt nettsted sikkert (og hvorfor du bør)
Selv om ikke alle av dem forstår hvordan det fungerer, signaliserer den lille hengelåsen i adresselinjen til nettbrukere at de har en klarert tilkobling til et legitimt nettsted. Hvis besøkende ikke ser det i adressefeltet når de trekker opp nettstedet ditt, vil du ikke og bør ikke få sin virksomhet.
For å få den lille adresselinjen hengelås for nettstedet ditt, trenger du et SSL-sertifikat. Hvordan får du en? Les videre for å finne ut.
Artikkeloversikt:
- Hva er SSL / TLS?
- Slik bruker du HTTPS?
- Hva er et SSL-sertifikat og hvordan får jeg en?
- SSL-sertifikat Shopping Guide
- Sertifikatmyndighet
- Domain Validation vs Extended Validation
- Delt SSL vs Privat SSL
- Stol på seler
- Wildcard 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 hjelp av Hypertext Transfer Protocol. Det er derfor at alle webadresser 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 og serveren bruker til å snakke med hverandre. Dette språket er forstått universelt, noe som er praktisk, men det har også sine ulemper. Når data sendes mellom deg og en server via Internett, vil det gjøre noen stopp underveis før du når sitt endelige reisemål. Dette utgjør tre store farer:
- At noen kanskje tjuvlytte på samtalen din (slags som en digital wiretap).
- At noen kanskje ligne en (eller begge deler) av partene i hver ende.
- At noen kanskje tukle med meldingene overført.
Hackers og jerks bruker en kombinasjon av det ovennevnte for en rekke svindel og heists, inkludert phishing ploys, man-in-the-middle angrep, og god gammeldagse reklame. Ondsinnede angrep kan være like enkelt som å snuse ut Facebook-legitimasjon ved å fange opp ukrypterte cookies (avlytting), eller de kan være mer sofistikerte. For eksempel kan du tro at du fortalte banken din: "Vennligst overfør $ 100 til Internett-leverandøren min," men noen i midten kan endre meldingen til å lese: "Vennligst overfør $ 100 alle pengene mine til min ISP-Peggy i Sibir" (data manipulering og etterligning).
Så, det er problemene med HTTP. For å løse disse problemene kan HTTP lages med en sikkerhetsprotokoll, noe som resulterer i HTTP Secure (HTTPS). Vanligvis er S i HTTPS levert av SSL-protokollen (Secure Sockets Layer) eller den nyere TLS-protokollen (Transport Layer Security). Når distribuert, tilbyr HTTPS toveis kryptering (for å hindre avlyting), serveren godkjenning (for å hindre etterligning) og melding autentisering (for å forhindre data manipulering).
Slik bruker du HTTPS
Som et snakkespråk fungerer HTTPS bare hvis begge parter velger å snakke det. På klientsiden kan valget til å bruke HTTPS gjøres ved å skrive inn "https" i nettleserens adresselinje før nettadressen (f.eks. I stedet for å skrive http://www.facebook.com, skriv inn https: // www. facebook.com), eller ved å installere en utvidelse som automatisk styrker HTTPS, for eksempel HTTPS Everywhere for Firefox og Chrome. Når nettleseren din bruker HTTPS, ser du et hengelåsikon, en grønn nettleservindu, tommelen opp eller et annet beroligende tegn på at forbindelsen til serveren er sikker.
For å kunne bruke HTTPS må imidlertid webserveren støtte det. Hvis du er webmaster og du vil tilby HTTPS til web 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 webapps lar deg velge HTTPS i brukerinnstillingene dine. Les våre oppskrifter på Facebook, Gmail og Twitter.
Hva er et SSL-sertifikat og hvordan får jeg en?
For å kunne bruke HTTPS må webserveren ha et SSL-sertifikat eller TLS-sertifikat installert. Et SSL / TLS-sertifikat er liksom som bilde-ID for ditt nettsted. Når en nettleser som bruker HTTPS, får tilgang til websiden din, vil den utføre et "håndtrykk", der klientdatamaten ber om SSL-sertifikatet. SSL-sertifikatet blir deretter validert av en klarert sertifiseringsinstans (CA), som bekrefter at serveren er den som sier det er. Hvis alt sjekker ut, får din web besøkende det beroligende grønne merket eller låsikonet. Hvis noe går galt, får de advarsel fra nettleseren, og sier at identiteten til serveren ikke kunne bekreftes.
Shopping for et SSL-sertifikat
Når det gjelder å installere et SSL-sertifikat på nettstedet ditt, er det en mengde parametere å bestemme seg for. La oss gå over det viktigste:
Sertifikatmyndighet
Sertifikatmyndigheten (CA) er firmaet som utsteder SSL-sertifikatet ditt, og er det som vil validere sertifikatet hver gang en besøkende kommer til nettstedet ditt. Mens hver SSL-sertifikatleverandør vil konkurrere om pris og funksjoner, er nummer én ting å vurdere når vetting-sertifikatmyndighetene er om de har sertifikater som kommer forhåndsinstallert på de mest populære nettleserne. Hvis sertifikatautoriteten som utsteder SSL-sertifikatet, ikke er på listen, blir brukeren bedt om å varsle om at nettstedets sikkerhetssertifikat ikke er klarert. Selvfølgelig betyr dette ikke at nettstedet ditt er ulovlig - det betyr bare at CA ikke er på listen (ennå). Dette er et problem fordi de fleste brukere ikke vil plage å lese advarselen eller undersøke den ukjente CA. De vil sannsynligvis bare klikke unna.
Heldigvis er listen over forhåndsinstallerte CA'er på de store nettleserne ganske stor. Det inkluderer noen store merkenavn samt mindre kjente og mer overkommelige CA'er. Husholdningsnavn inkluderer Verisign, Go Daddy, Comodo, Thawte, Geotrust og Entrust.
Du kan også se i nettleserens innstillinger for å se hvilke sertifikatmyndigheter som er forhåndsinstallert.
- For Chrome, gå til Innstillinger -> Vis avanserte innstillinger ... -> Administrer sertifikater.
- For Firefox, gjør Valg -> Avansert -> Se sertifikater.
- For IE, Internett-alternativer -> Innhold -> Sertifikater.
- For Safari, gå inn i Finder og velg Gå -> Verktøy -> KeyChain Access og klikk System.
For hurtigreferanse, sjekk ut denne tråden, som viser de akseptable SSL-sertifikatene for Google Checkout.
Domain Validation vs Extended Validation
| Typisk utstedelsestid | Koste | Adresselinje | |
| Domain Validation | Nesten øyeblikkelig | Lav | Normal HTTPS (hengelåsikon) |
| Organisasjonsgodkjenning | Noen få dager | Mid | Normal HTTPS (hengelåsikon) |
| Utvidet validering | En uke eller mer | Høy | Grønn adressefelt, ID-verifikasjonsinformasjon for bedriften |
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 som de ikke kontrollerer riktig, vil en sertifiseringsinstans validere at personen som ber om sertifikatet, faktisk er eieren av domenenavnet. Vanligvis gjøres dette via en rask e-post- eller telefonsamtale validering, ligner når et nettsted sender deg en e-post med en kontobekreftelseslink. Dette kalles a domene valideres SSL-sertifikat. Fordelen med dette er at det tillater at SSL-sertifikater utstedes nesten umiddelbart. Du kan sikkert gå og få et domenevalidert SSL-sertifikat på kortere tid enn det tok deg til å lese dette blogginnlegget. Med et domenevalidert SSL-sertifikat får du hengelås og muligheten til å kryptere nettstedets trafikk.
Fordelene ved et domenevalidert SSL-sertifikat er at de er raske, enkle og billige å få. Dette er også deres ulempe. Som du kan forestille deg, er det lettere å hette et automatisert system enn en som drives av levende mennesker. Det er som om noen ungdomsbarn gikk inn i DMV og sa at han var Barack Obama og ønsket å få en offentlig utstedt ID. personen ved pulten ville ta en titt på ham og ringe Feds (eller loony bin). Men hvis det var en robot som jobber med et foto ID-kiosk, kan han ha lykke til. På samme 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 å svindle CAs 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 å få øye på. Men det automatiserte domenevalideringen manglet den nødvendige kontrollen for å hindre noe slikt.
Som svar på sikkerhetsproblemene til SSL og domenevaliderte SSL-sertifikater, har næringen innført Utvidet validering sertifikat. For å få et EV SSL-sertifikat, må din bedrift eller organisasjon gjennomgå streng vetting for å sikre at den står i god stand med regjeringen og kontrollerer domenet du søker om. Disse kontrollene krever blant annet et menneskelig element, og dermed ta lengre tid og er dyrere.
I enkelte bransjer er det nødvendig med et EV-sertifikat. Men for andre går fordelen bare så langt som de besøkende vil gjenkjenne. Til hverdags web besø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 nettsiden.
Her er et eksempel på et vanlig HTTPS-nettsted:
Og her er et eksempel på et EV-sertifisert HTTPS-nettsted:
Avhengig av bransjen din, kan et EV-sertifikat kanskje ikke være verdt det. I tillegg må du være en bedrift eller en organisasjon for å få en. Selv om store selskaper trending mot EV-sertifisering, vil du legge merke til at flertallet av HTTPS-nettsteder fremdeles har idrett utenom EV-smaken. Hvis det er bra nok for Google, Facebook og Dropbox, er det kanskje bra nok for deg.
En ting til: det er en midt på veien alternativet kalles en organisasjon bekreftet eller virksomheten valideres sertifisering. Dette er en grundigere vetting enn den automatiserte domenevalidering, men det går ikke så langt som å oppfylle bransjebestemmelsene for et utvidet valideringssertifikat (legge merke til hvor utvidet validering er aktivert og "organisatorisk validering" ikke er?). En OV eller virksomhetsvalidert sertifisering koster mer og tar lengre tid, men det gir deg ikke den grønne adresselinjen og bedriftsidentiteten bekreftet info. Helt ærlig, jeg kan ikke tenke på en grunn til å betale for et OV-sertifikat. Hvis du kan tenke på en, vennligst opplys meg i kommentarene.
Delt SSL vs Privat SSL
Noen webverter tilbyr en delt SSL-tjeneste, som ofte er rimeligere enn en privat SSL. Annet enn pris, er fordelen med en delt SSL at du ikke trenger å få en privat IP-adresse eller dedikert vert. Ulempen er at du ikke får bruke ditt eget domenenavn. I stedet vil den sikre delen av nettstedet ditt 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 nettsteder med offentlig opplæring, som e-handelsnettsteder og nettsamfunn for sosiale nettverk, er dette åpenbart en dra, siden det ser ut til at du har blitt omdirigert fra hovedsiden. Men for områder som vanligvis ikke er sett av allmennheten, slik en innersiden til et e-postsystem eller et administratorområde, så kan en delt SSL være en god avtale.
Stol på seler
Mange sertifikatmyndigheter lar deg plassere et tillitssel på nettsiden din etter at du har registrert deg for et av sertifikatene sine. Dette gir ganske mye samme informasjon som å klikke hengelåsen i nettleservinduet, men med høyere synlighet. Inkludering av tillitstetning er ikke nødvendig, og det forsterker ikke sikkerheten din, men hvis den gir dine besøkende de varme fuzziene som vet hvem som utstedte SSL-sertifikatet, må du kaste det opp der.
Wildcard SSL-sertifikater
Et SSL-sertifikat bekrefter identiteten til ett domene. Så, hvis du vil ha HTTPS på flere subdomaings-for eksempel, groovypost.com, mail.groovypost.com og answers.groovypost.com-du må kjøpe tre forskjellige SSL-sertifikater. På et bestemt tidspunkt blir et wildcard SSL-sertifikat mer økonomisk. Det vil si ett sertifikat for å dekke et domene og alle underdomener, dvs. * .groovypost.com.
garantier
Uansett hvor lenge selskapets gode rykte er, er det sårbarheter. Selv betrodde CA'er kan målrettes av hackere, som det fremgår av brudd på VeriSign som ble rapportert tilbake i 2010. Videre kan en CAs status på den betrodde listen raskt bli tilbakekalt, slik vi så med DigiNotar snafu tilbake i 2011. Ting skjer.
For å unngå enhver uro over potensialet for slike tilfeldige handlinger av SSL debauchery, tilbyr mange CA'er nå garantier. Dekningen varierer fra noen få tusen dollar til over en million dollar og inkluderer tap som skyldes misbruk av sertifikatet eller andre uhell. Jeg har ingen anelse om disse garantiene faktisk gir verdi eller ikke, eller hvis noen noensinne har vunnet et krav. Men de er der for din vurdering.
Gratis SSL-sertifikater og selvsignerte SSL-sertifikater
Det finnes to typer gratis SSL-sertifikater tilgjengelig. En selvsignert, brukt primært til privat testing og fullblåst offentlig mot SSL-sertifiseringer utstedt av en gyldig sertifiseringsinstans. Den gode nyheten er at i 2018 er det noen muligheter for å få 100% gratis, gyldige 90-dagers SSL-certs fra både SSL gratis eller La oss kryptere. SSL gratis er primært et GUI for Let's Encrypt API. Fordelen med SSL for Free Site er at det er enkelt å bruke som det har en fin GUI. La oss kryptere, men det er fint da du kan automatisere automatisk å be om SSL certs fra dem. Ideelt hvis du trenger SSL certs for flere nettsteder / servere.
Et selvsignert SSL-sertifikat er gratis for alltid. Med et selvsignert sertifikat, er du din egen CA. Men fordi du ikke er blant de betrodde CA-ene, som er bygd inn i nettlesere, vil besøkende få en advarsel om at autoriteten ikke er anerkjent av operativsystemet. Som sådan er det ingen garanti for at du er den du sier du er (det er som å gi deg et bilde-ID og prøver å overføre det til brennevinbutikken). Fordelen med et selvsignert SSL-sertifikat er imidlertid at det muliggjør kryptering for webtrafikk. Det kan være bra for intern bruk, hvor du kan få dine ansatte til å legge til organisasjonen som en klarert CA for å kvitte seg med advarselsmeldingen og jobbe med en sikker forbindelse via Internett.
For instruksjoner om hvordan du konfigurerer et selvsignert SSL-sertifikat, sjekk ut dokumentasjonen for OpenSSL. (Eller, hvis det er nok etterspørsel, skriver jeg opp en opplæring.)
Installere et SSL-sertifikat
Når du har kjøpt SSL-sertifikatet, må du installere det på nettstedet ditt. En god webverten 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 måten å gå, siden det forenkler fakturering og sikrer at den er riktig konfigurert for webserveren din.
Likevel har du alltid muligheten til å installere et SSL-sertifikat du kjøpte på egen hånd. Hvis du gjør det, kan du begynne å konsultere webvertenes kunnskapsbase eller ved å åpne en helpdesk-billett. De vil lede deg til de beste instruksjonene for å installere SSL-sertifikatet. Du bør også konsultere instruksjonene fra CA. Disse vil gi deg bedre veiledning enn noen generiske råd jeg kan gi deg her.
Du vil kanskje også sjekke ut følgende instruksjoner for å installere et SSL-sertifikat:
- Installer et SSL-sertifikat og sett opp domenet i cPanel
- Slik implementerer du SSL i IIS (Windows Server)
- Apache SSL / TLS-kryptering
Alle disse instruksjonene vil innebære opprettelse av en SSL-sertifikat-signeringsforespørsel (CSR). Faktisk trenger du en CSR bare for å få et SSL-sertifikat utstedt. Igjen kan webverten hjelpe deg med dette. For mer spesifikk DIY info om å skape en CSR, sjekk ut denne oppskrivningen fra DigiCert.
Fordeler og ulemper med HTTPS
Vi har allerede godt etablert fordelene til HTTPS: sikkerhet, sikkerhet, sikkerhet. Dette unngår ikke bare risikoen for brudd på data, det tillater også tillit og legger til anerkjennelse for nettstedet ditt. Kunnige kunder kan ikke engang bry seg om å registrere seg hvis de ser en "http: //" på påloggingssiden.
Det er imidlertid noen ulemper med HTTPS. Gitt nødvendigheten av HTTPS for bestemte typer nettsteder, er det mer fornuftig å tenke på disse som "ulemperiderations "heller enn negativer.
- HTTPS koster penger. For det første er det kostnaden for å kjøpe og forny SSL-sertifikatet for å sikre gyldighet fra år til år. Men det er også visse "systemkrav" for HTTPS, for eksempel en dedikert IP-adresse eller dedikert hostingplan, som kan være dyrere enn en delt hostingpakke.
- HTTPS kan redusere serverresponsen. Det er to problemer relatert til SSL / TLS som kan redusere sidens lasthastigheter. Først, for å begynne å kommunisere med nettstedet ditt for første gang, må brukerens nettleser gå gjennom håndtrykksprosessen, som hopper tilbake til sertifikatmyndighetens nettsted for å bekrefte sertifikatet. Hvis CAs webserver er svak, så blir det en forsinkelse med å laste inn 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 ditt for båndbredde og oppgradere maskinvaren på serveren din. CloudFare har et godt blogginnlegg om hvordan og hvorfor SSL kan redusere nettstedet ditt.
- HTTPS kan påvirke SEO innsats Når du går over fra HTTP til HTTPS; du flytter til et nytt nettsted. For eksempel vil https://www.groovypost.com ikke være det samme som http://www.groovypost.com. Det er viktig å sikre at du har omdirigert de gamle koblingene og skrevet de riktige reglene under hetten på serveren din for å unngå å miste noen verdifull link juice.
- Blandet innhold kan kaste et gult flagg. For noen nettlesere, hvis du har hoveddelen av en nettside lastet fra HTTPS, men bilder og andre elementer (for eksempel stilark eller skript) lastet fra en HTTP-nettadresse, kan det hende at en popup vises som advarsel om at siden inneholder usikkert innhold. Selvfølgelig har du noen sikkert innhold er bedre enn å ha ingen, selv om sistnevnte ikke resulterer i en popup. Men likevel kan det være verdt å 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 av Amazon håndtere betalingene dine. Hvis alle de ovennevnte ser ut som for mye å krangle, kan du la kundene dine bytte betalingsinformasjon på Paypals sikre nettsted eller Googles sikre nettsted og redde deg selv trøbbelene.
Har du andre spørsmål eller kommentarer om HTTPS- og SSL / TLS-sertifikater? La meg høre det i kommentarene.
