Introduksjon
I løpet av de siste årene har vi sett at nettet og sortimentet av bransjer som driver det (dvs. nettlesere, søkemotorer osv.) Begynner å ta brukersikkerhet mer alvorlig. Chrome er nå advarer brukere mot HTTP-nettsteder med flere nettlesere klare til å følge, mens Google Søk har bekreftet at de gir rangering av søkemotorer HTTPS nettsteder.
Utvikling som disse har motivert en betydelig del av nettstedseiere til å flytte serverne sine bort fra gammel, usikker HTTP til det mer sikre alternativet HTTPS. (HTTPS regnes som sikrere fordi det krever at servere godkjennes via SSL-sertifikater som et middel til å beskytte brukere mot de fleste typer nettverksangrep.)
Imidlertid har de fleste nettsteder bare implementert HTTPS for sine mest kritiske komponenter, for eksempel påloggings- eller POST-forespørsler, men kan fortsatt bruke HTTP for andre "ikke-kritiske" funksjoner.
Dette var fornuftig i de første dagene av HTTPS, siden krypterte tilkoblinger er mer beregningsdyktige på grunn av å måtte utføre håndtrykk for hver nye tilkobling. Videre var på den tiden mange mye brukte plattformer, biblioteker og miljøer for nettutvikling ikke HTTPS-klare - et faktum som førte til at administratorer og utviklere fikk uendelig hodepine i form av programkrasj på sen kveld eller uklare kjøretidsfeil.
Dette stemmer selvfølgelig ikke lenger - faktisk, som denne artikkelen vil hevde, ikke bruker HTTPS for alle nettstedets tilkoblinger er faktisk dårlige for bedriften din.
Blandet innhold
Nettsteder som ikke serverer alt innholdet via HTTPS, blir kalt blandet innhold nettsteder. En akademiker papir publisert i 2015 fant at over 43% av utvalget av Alexa 100,000 topp serverte minst en type blandet innhold.
Selv om dette ikke høres ut som en big deal, kan blandet innhold være ganske farlig for brukere, men det kan også ha negative effekter på nettsteder også.
Sikkerhetsspørsmål
Den viktigste grunnen til å bruke HTTPS for hele nettstedet ditt er sikkerhet. En enkelt ubeskyttet HTTP-tilkobling er alle hackere trenger. MITM-angripere kan erstatte alt HTTP-innhold på siden din for å stjele legitimasjon og økter, skaffe sensitive data eller starte nettleserutnyttelse og installere skadelig programvare på de besøkende datamaskiner.
Å bli kompromittert av nettstedet ditt vil naturlig nok gjøre brukerne mistillit og unngå det i fremtiden, og effektivt skade ditt online omdømme.
Både Firefox og Chrome har startet for å blokkere blandet innhold som standard, slik at brukere manuelt kan velge å laste inn innhold via HTTP. Ikke desto mindre, siden blandet innhold er en sikkerhetsrisiko, viser begge nettleserne en advarsel om blandet innhold til brukere, noe som også kan påvirke nettstedets omdømme negativt.
Ytelsesproblemer
Foruten sikkerhet, den stadig økende adopsjonen av HTTP / 2 av bransjen har brakt en rekke ytelses- og sikkerhetsoppgraderinger på nettet.
Selv om økningen i ytelse virker motintuitiv siden HTTP / 2 fungerer bare over krypterte HTTPS-tilkoblinger, lar protokollen nettlesere bruke en enkelt kryptert forbindelse med en HTTPS webserver for all kommunikasjon.
Å gjenbruke den samme forbindelsen fjerner overhead som blir pålagt ved gjentatte ganger å etablere nye (dvs. at håndtrykkene igjen). Dette betyr at hopping fra krypterte HTTPS-tilkoblinger til ukryptert HTTP på et nettsted med blandet innhold faktisk er tregere og mer ressurskrevende enn å besøke et fullstendig beskyttet nettsted ved hjelp av en enkelt HTTPS-tilkobling.
HTTP / 2 implementerer også 0-RTT
sesjons gjenopptaksmodus, slik at nettlesere kan gjenoppta en midlertidig økt med et HTTPS-nettsted de har besøkt før, bare ved å bruke en enkelt forespørsel (i stedet for et komplett håndtrykk). Dette gjør at HTTP / 2 gjenopptas minst like raskt som en ukryptert HTTP-tilkobling, samtidig som den gir alle fordelene med HTTPS. Å servere blandet innhold betyr at nettstedet ditt ikke kan dra full nytte av dette eller noen av de andre gode funksjonene i HTTP / 2.
I begge disse tilfellene forbedrer HTTP / 2 hastigheten på den besøkendes tilkobling til nettstedet ditt - og hastigheten betyr noe. Studier har vist gjennom årene at responsivitet og sidehastighet er kritiske krav til design av brukergrensesnitt. Jo saktere et nettsted har svartid, desto mindre sannsynlig er det at brukere forblir engasjert, og brukermedvirkning påvirker nettstedets brukeropplevelse (og følgelig konverteringsfrekvensene) direkte.
Blandet innhold kan også påvirke ytelsen i nivået til de underliggende webteknologiene som brukes på nettstedet ditt. Nettlesere nå begrense javascript-funksjoner for eksempel servicemedarbeidere og push-varsler for å sikre sammenhenger bare fordi de ellers kan misbrukes av hackere for ondsinnede formål. Dette betyr igjen at nettstedet ditt ikke kan dra nytte av noen av disse teknologiene når du serverer blandet innhold.
SEO problemer
Søkemotoroptimalisering (SEO) er brød og smør for online bedriftsmarkedsførere. SEO viser til praksisen med å forbedre rangeringen av et nettsted på en søkemotorresultatside (SERP), som direkte påvirker volumet på nettstedets trafikk.
Google har bekreftet at deres søkeresultatrangeringsalgoritme gir et lite rangforhøyelse til nettsteder som serveres via HTTPS. Siden boost er sanntid og per URL, vil betjening av et nettsted i sin helhet over HTTPS resultere i en SEO boost for hele nettstedet (i stedet for bare de URLene som serveres over HTTPS). Gitt, denne rangeringen av signalforsterkningen er ganske lett sammenlignet med andre som kvalitetsinnhold eller brukertrafikk, det belønner fortsatt investeringen din i å fjerne blandet innhold.
Google har også nylig annonsert at sidehastighet og generell ytelse på nettstedet tas i betraktning (tung) når du bestemmer rangering. Dette betyr at HTTP / 2s ytelsesoptimaliseringer og fjerning av blandet innhold kan samarbeide for å øke nettstedets synlighet på nettet.
Til slutt, hvis du ønsker å dra full nytte av SSL i nettstedets SEO, kan du vurdere SSL.coms EV-sertifikater, som gir de høyeste forsikringene til dine besøkende via sikkerhetsindikatorer (som den grønne linjen i nettleseren) for å holde dem sikre og engasjerte med innholdet ditt - og lenger besøk like høyere rangeringer.
Nettleser Advarsler om blandet innhold
Besøkende på nettsteder beskyttet av SSL forventer (og fortjener) sømløs beskyttelse. Når et nettsted ikke fullt ut beskytter alt innhold, vil en nettleser vise en advarsel om "blandet innhold". Når kundene dine ser denne advarselen, kan de reagere på to måter. Hvis de ikke ta sikkerhet på alvor, de vil ignorere den, klikke gjennom og anta at alt vil være i orden (veldig dårlig). Hvis de do ta sikkerhet på alvor, vil de ta hensyn til det, gå ut av nettstedet ditt og anta det du ikke ta sikkerhet på alvor (enda verre).
Videre vil alle moderne nettlesere blokkere de mer ondsinnede typene av blandet innhold - og på den måten kan det ødelegge nettstedet ditt.
Den beste løsningen er selvfølgelig å sørge for at disse advarslene og / eller blokkeringene ikke vil forekomme i utgangspunktet ved å konfigurere nettstedet ditt slik at det kun serverer sikkert innhold.
Hvorfor ser jeg denne advarselen?
En advarsel med blandet innhold betyr at både sikrede og usikrede elementer blir servert på en side som skal være fullstendig kryptert. Alle sider som bruker en HTTPS-adresse, må ha alt innhold som kommer fra en sikret kilde. Enhver side som lenker til en HTTP-ressurs blir ansett som usikker og flagget av nettleseren din som en sikkerhetsrisiko.
Advarsler med blandet innhold faller inn i to kategorier: blandet passivt innhold og blandet aktivt innhold.
Blandet passivt innhold
Passivt innhold refererer til elementer som kan erstattes eller endres, men som ikke kan endre andre deler av siden - for eksempel en grafikk eller et fotografi. Sannsynligvis er den vanligste årsaken til all advarsel om blandet innhold når et (teoretisk) sikkert nettsted er konfigurert til å hente bilder fra en usikret kilde.
Passive HTTP-forespørsler blir servert via disse kodene:<audio>
(src
Egenskap)<img>
(src
Egenskap)<video>
(src
Egenskap)<object>
subresources (når en <object>
utfører HTTP-forespørsler)
Blandet aktivt innhold
Aktivt innhold kan endre selve websiden. Et mann-i-midten-angrep kan tillate at en forespørsel om HTTP-innhold på hvilken som helst HTTPS-side blir fanget opp og / eller omskrevet. Dette gjør skadelig aktivt innhold veldig farlig - brukerlegitimasjon og sensitive data kan bli stjålet eller skadelig programvare installert på brukerens system. For eksempel kan litt JavaScript på en kontoopprettingsside designet for å hjelpe brukere med å generere et tilfeldig passord erstattes av kode som gir et tilfeldig, men forhåndsgenerert i stedet, eller for å levere et ellers sikkert passord i hemmelighet til en tredjepart .
Aktivt blandet innhold kan utnyttes for å kompromittere sensitive private data, men til og med offentlige sider som virker uskyldige kan fortsatt omdirigere besøkende til farlige nettsteder, levere uønsket innhold eller stjele informasjonskapsler for utnyttelse.
<script>
(src
Egenskap)<link>
(href
attributt) (dette inkluderer CSS-stilark)XMLHttpRequest
objektforespørsler<iframe>
(src
egenskaper)Alle tilfeller i CSS der en url-verdi brukes (
@font-face
, cursor
, background-image
, Etc.)<object>
(data
Egenskap)Alle moderne nettlesere blokkerer aktivt blandet innhold som standard (noe som kan ødelegge et feilkonfigurert nettsted)
Hvorfor og hvordan fikser jeg advarsler om blandet innhold
Ved å sikre nettstedet ditt kan de besøkende stole på deg, noe som er veldig viktig. Å eliminere alt usikkert innhold fra nettstedet ditt har en enda større bonus ved å eliminere falske positive advarsler. Hvis det riktig konfigurerte nettstedet ditt er kompromittert, vil ethvert usikkert element en angriper setter inn utløse advarselen om blandet innhold, noe som gir deg en ekstra tripwire å oppdage. og ta tak i disse problemene.
Igjen er den beste måten å unngå problemer med blandet innhold å tjene alt innhold via HTTPS i stedet for HTTP.
For ditt eget domene, server alt innhold som HTTPS og fikse koblingene dine. Ofte eksisterer HTTPS-versjonen av innholdet allerede, og dette krever bare å legge til en "s" i lenker - http://
til https://
.
For andre domener, bruk nettstedets HTTPS-versjon hvis tilgjengelig. Hvis HTTPS ikke er tilgjengelig, kan du prøve å kontakte domenet og spørre dem om de kan gjøre innholdet tilgjengelig via HTTPS.
Alternativt kan nettleseren automatisk bruke HTTP eller HTTPS, avhengig av hvilken protokoll brukeren bruker, ved å bruke “relative URLer”. For eksempel, i stedet for å koble til et bilde ved hjelp av en lenke med den "absolutte banen" til:
Nettstedet kan bruke en relativ bane:
Dette lar nettleseren automatisk legge til en av http:
or https:
til starten av URLen etter behov. (Merk at nettstedet som er lenket til, må tilby ressursen over både HTTP og HTTPS for at relative URL-er skal fungere.)
Chrome
Firefox
Internet Explorer
Utmerkede verktøy som hjelper med å spore ikke-SSL-lenker i kildekoden din, er utviklerverktøyene innebygd i Firefox og Chrome nettlesere. Informasjon om å tvinge en Apache-server til å håndtere bare HTTPS kan være funnet her.
Det første forespørselsproblemet
Vi håper at frem til dette punktet har denne artikkelen lagt noen gode argumenter mot blandet innhold, selv om du bestemmer deg for å migrere nettstedet ditt helt til HTTPS, det fremdeles er noen forbedringer du kan gjøre.
Når brukere skriver inn nettadressen til nettstedet ditt i en nettleser, skriver de vanligvis aldri protokollnavnet fullt ut (dvs. https://
). Naturligvis vet ikke nettleseren hvilken protokoll nettstedet ditt serveres under, og som standard er HTTP.
Hvis nettstedet ditt er konfigurert riktig, vil det omdirigere (via HTTP 301/302-svar) nettleseren til sin HTTPS-forekomst; selv om dette betyr at nettlesere må utføre to forespørsler i stedet for en enkelt HTTPS-forespørsel når de først besøker nettstedet ditt.
Dette kan være problematisk fordi brukere kan oppfatte etterslepet og få et dårlig førsteinntrykk av nettstedet. Som sådan vil det være mindre sannsynlig at de holder seg rundt, noe som til slutt kan føre til redusert besøkstrafikk.
Dessuten kan hackere avskjære den første HTTP-forespørselen om å lese eller endre den før de når serveren. En vanlig forekomst for denne typen saker er å utføre et nettverksangrep som heter SSL -stripping som lar angriperen erstatte en HTTPS-forbindelse med en ubeskyttet HTTP.
HTTP Streng transportsikkerhet til unnsetning
HTTP Strenge transportsikkerhet or HSTS er et forsøk på å løse dette problemet. Implementert av Internet Engineering Task Force (IETF) i RFC 6797, er HSTS en HTTPS-header som webservere kan inkludere i svarene sine. Denne overskriften instruerer kompatible nettlesere om å alltid bruke HTTPS når du besøker et nettsted. HSTS gjelder alle forespørsler, inkludert bilder, CSS-stilark og andre nettressurser.
Som du kanskje forestiller deg, må nettleseren først se HSTS-overskriften for å ære den, noe som betyr at HSTS er avhengig av at angriperne ikke klarer å fange opp den første HTTP-forespørselen. Som et resultat er HSTS i seg selv ikke en komplett løsning, men snarere en enkel løsning på SSL-stripping.
HSTS forhåndsinnlasting
Heldigvis har Chromium-prosjektet kommet med en løsning de navngav HSTS forhåndsinnlasting, som består av å opprettholde en offentlig liste over nettsteder som har bedt om HSTS forhåndsinnlastingsfunksjonalitet. Når du besøker et nettsted, vil Chromium-nettlesere konsultere listen, og hvis nettstedet finnes der, vil de fortsette å kommunisere med det via HTTPS (inkludert den første forespørselen) uavhengig av tidligere historie eller brukerinput.
Som en konsekvens kan forhåndsinnlasting forbedre nettstedets ytelse og sikkerhet ved å fjerne den første HTTP-forespørselen. I tillegg kan det indirekte forbedre nettstedets SERP-rangering og brukeropplevelse.
Alle større nettlesere (Googles Chrome, Microsofts IE / Edge, Apples Safari, Mozillas Firefox og Opera) konsulterer også Chromiums HSTS forhåndsinnlastingsliste, noe som betyr at å bli medlem av denne listen vil gi forhåndsinnlastede fordeler for de besøkende, uansett hvilken nettleser de bruker.
Vi ville imidlertid være avslappet hvis vi ikke nevnte at det er bekymringer for skalerbarheten til HSTS-forhåndslasteløsningen - Den kan ikke inkludere alle nettsteder på Internett på grunn av praktisk størrelse og begrensninger i beregningskompleksitet, og følgelig kan oppføring bli stadig vanskeligere ettersom tiden går og HSTS-forhåndslasting blir bredere adoptert.
Hvordan kan jeg være med?
Hvis du er interessert i å bli med på HSTS forhåndsinnlastingsliste, må du huske at nettstedet ditt må følge visse regler. Chromium-prosjektet har publisert listen over innleveringskrav for nettsteder som ønsker å bli med på prosjektets nettsted. Kravene er inkludert ordrett i følgende liste, men du kan finne flere detaljer i HSTS RFC 6797.
For å bli akseptert i HSTS-forhåndsinnlastingslisten, må nettstedet ditt:
- Server et gyldig sertifikat.
- Omdiriger fra HTTP til HTTPS på samme vert, hvis du lytter på port 80.
- Server alle underdomener over HTTPS. Spesielt må du støtte HTTPS for
www
underdomen hvis det finnes en DNS-post for det underdomenet. - Server en RFC 6797-kompatibel HSTS-header på basedomenet for HTTPS-forespørsler:
- De
max-age
må være minst 31536000 sekunder (1 år). - De
includeSubDomains
direktiv må spesifiseres. - De
preload
direktiv må spesifiseres.
- De
- Hvis du serverer en ekstra viderekobling fra HTTPS-siden, må denne viderekoblingen også ha en kompatibel HSTS-topptekst (det samme må siden den omdirigerer til).
Her er et eksempel på en gyldig HSTS-topptekst.
Streng-transport-sikkerhet: max-age = 63072000; includeSubDomains; forspenning
Du kan teste nettstedet ditt for å være kvalifisert ved å gå til nettstedet med forhåndsinnlasting og oppgi domenet ditt i inntastingsboksen. Nettapplikasjonen der vil påpeke hvilke problemer (om noen) du trenger å fikse.
Dessverre tillater ikke kompleksiteten til moderne nettsteder en å opprette en server-konfigurasjon i én størrelse som passer til alle for HSTS-forhåndsinnlasting til å inkludere i denne artikkelen. Det kan være problemer med kjøretid med tredjeparter eller andre tilpassede komponenter som må løses individuelt.
Selv om Chromium-prosjektet har inkludert noen distribusjonsanbefalinger på forhåndsinnlastingsnettstedet, er vi alltid glade for å hjelpe kundene våre med å forbedre kommunikasjonssikkerheten. Bare send oss en e-post kl support@ssl.com og en ekspert vil gjerne diskutere den beste veien videre for dine sikkerhetsbehov.
konklusjonen
HTTPS er i ferd med å bli standard nettkommunikasjonsprotokoll, og fullstendig forpliktelse til det kan bare ha positive effekter for nettstedseiere og besøkende. Vi anbefaler å fjerne alt blandet innhold fra nettstedene dine for å unngå unødvendige problemer (og ulykkelige brukere).
Som alltid, takk for at du valgte SSL.com, der vi mener et tryggere internett er et bedre internett.