Introduktion
I de senere år har vi set Internettet og sortimentet af industrier, der driver det (dvs. browsere, søgemaskiner osv.) Begynder at tage brugersikkerhed mere alvorligt. Chrome er nu advarer brugere mod HTTP-websteder med flere browsere, der er klar til at følge, mens Google Søgning har bekræftet, at de giver søgemaskinens rangordning boosts til HTTPS websteder.
Udviklingen som disse har motiveret en betydelig del af webstedsejere til at flytte deres servere væk fra gamle, usikre HTTP til det mere sikre alternative HTTPS. (HTTPS betragtes som mere sikkert, fordi det kræver, at servere skal autentificeres via SSL-certifikater som et middel til at beskytte brugere mod de fleste typer netværksangreb.)
De fleste websteder har dog kun implementeret HTTPS til deres mest kritiske komponenter, såsom login eller POST-anmodninger, men kan stadig bruge HTTP til andre “ikke-kritiske” funktioner.
Dette gav mening i de tidlige dage af HTTPS, da krypterede forbindelser er mere beregningsdygtige på grund af at skulle udføre håndtryk for hver ny forbindelse. Desuden var mange udbredte webudviklingsplatforme, biblioteker og miljøer på det tidspunkt ikke HTTPS-klar - en kendsgerning, der forårsagede administratorer og udviklere uendelig hovedpine i form af programnedbrud sent om natten eller uklare kørselsfejl.
Dette er naturligvis ikke længere sandt - faktisk, som denne artikel vil argumentere for, ikke ved hjælp af HTTPS til alle dit websteds forbindelser er faktisk dårlige for din virksomhed.
Blandet indhold
Websteder, der ikke serverer alt deres indhold via HTTPS, kaldes blandet indhold hjemmesider. En akademiker papir offentliggjort i 2015 fandt, at over 43% af deres prøve af Alexa's top 100,000 tjente mindst en type blandet indhold.
Selvom dette ikke lyder som en big deal, kan blandet indhold være ganske farligt for brugerne, men det kan også have negative effekter på websteder.
Sikkerhedsspørgsmål
Den vigtigste grund til at bruge HTTPS til hele dit websted er sikkerhed. En enkelt ubeskyttet HTTP-forbindelse er alle hackere har brug for. MITM-angribere kan erstatte ethvert HTTP-indhold på din side for at stjæle legitimationsoplysninger og sessioner, erhverve følsomme data eller starte browserudnyttelse og installere malware på dine besøgende 'computere.
At blive kompromitteret af dit websted vil naturligvis gøre dine brugere mistillige og undgå det i fremtiden, hvilket effektivt skader dit online omdømme.
Både Firefox og Chrome er startet at blokere blandet indhold som standard, så brugerne manuelt kan vælge at indlæse indhold via HTTP. Da blandet indhold er en sikkerhedsrisiko, viser begge browsere ikke desto mindre en advarsel om blandet indhold til brugerne, hvilket også kan påvirke dit websteds omdømme negativt.
Problemer med ydeevne
Udover sikkerhed er den stadigt stigende vedtagelse af HTTP / 2 af branchen har bragt adskillige opgraderinger til ydeevne og sikkerhed på Internettet.
Selvom stigningen i ydeevne forekommer intuitiv siden HTTP / 2 fungerer kun over krypterede HTTPS-forbindelser tillader protokollen browsere at bruge en enkelt krypteret forbindelse med en HTTPS-webserver til al deres kommunikation.
Genanvendelse af den samme forbindelse fjerner omkostningen ved gentagne gange at etablere nye (dvs. det håndtryk igen). Dette betyder, at spring fra krypterede HTTPS-forbindelser til ikke-krypteret HTTP på et websted med blandet indhold faktisk er langsommere og mere ressourcekrævende end at besøge et fuldstændigt beskyttet sted ved hjælp af en enkelt HTTPS-forbindelse.
HTTP / 2 implementerer også 0-RTT
session genoptagelsestilstand, hvilket gør det muligt for browsere at genoptage en pause med en HTTPS-webside, de har besøgt før, ved kun at bruge en enkelt anmodning (i stedet for et komplet håndtryk). Dette gør HTTP / 2 genoptagelse mindst lige så hurtig som en ikke-krypteret HTTP-forbindelse, mens den stadig giver alle fordelene ved HTTPS. At servere blandet indhold betyder, at dit websted ikke kan drage fuld fordel af dette eller nogen af de andre fantastiske funktioner i HTTP / 2.
I begge disse tilfælde forbedrer HTTP / 2 hastigheden på din besøgendes forbindelse til dit websted - og hastigheden betyder noget. Undersøgelser har vist gennem årene, at lydhørhed og sidehastighedshastighed er kritiske krav til brugergrænsefladesign. Jo langsommere et webstids responstid er, desto mindre sandsynligt er det for brugere at forblive engageret, og brugerengagement påvirker direkte dit websteds brugeroplevelse (og følgelig dine konverteringsfrekvenser).
Blandet indhold kan også påvirke ydeevnen i niveauet for de underliggende webteknologier, der bruges på dit websted. Browsere nu begræns javascript-funktioner såsom servicemedarbejdere og push-meddelelser for kun at sikre sammenhænge, fordi de ellers kunne misbruges af hackere til ondsindede formål. Dette betyder igen, at dit websted ikke kan drage fordel af nogen af disse teknologier, når der serveres blandet indhold.
SEO spørgsmål
Søgemaskineoptimering (SEO) er brød og smør fra online forretningsmarkedsførere. SEO henviser til praksis med at forbedre rangeringen af et websted i en søgeresultatsiden (SERP), der direkte påvirker mængden af webstedets trafik.
Google har bekræftet, at deres algoritme til søgeresultatrangering giver et lille rangforøg til websteder, der serveres via HTTPS. Da boostet er i realtid og pr. URL, vil betjening af et websted i sin helhed via HTTPS resultere i et SEO-boost for hele webstedet (i stedet for kun de URL'er, der serveres via HTTPS). Indrømmet, dette boost-signal boost er ret let sammenlignet med andre såsom kvalitetsindhold eller brugertrafik, det belønner stadig din investering i at fjerne blandet indhold.
Google har også for nylig annoncerede denne sidehastighed og generelle webstedsydelse tages med (tung) i betragtning, når der træffes afgørelse om placering. Dette betyder, at HTTP / 2s effektivitetsoptimeringer og fjernelse af blandet indhold kan arbejde sammen for at øge dit websteds synlighed på nettet.
Endelig, hvis du ønsker at drage fuld fordel af SSL i dit websteds SEO, kan du overveje SSL.coms EV-certifikater, der giver de højeste forsikringer til dine besøgende via sikkerhedsindikatorer (som den grønne bjælke i browseren) for at holde dem sikre og engagerede med dit indhold - og længere besøg har lige højere placeringer.
Browser Advarsler om blandet indhold
Besøgende på websteder beskyttet af SSL forventer (og fortjener) problemfri beskyttelse. Når et websted ikke fuldt ud beskytter alt indhold, viser en browser en advarsel om "blandet indhold". Når dine kunder ser denne advarsel, kan de reagere på to måder. Hvis de ikke tage sikkerhed alvorligt, de vil ignorere det, klikke igennem og formode, at alt vil være okay (meget dårligt). Hvis de do tage sikkerhed alvorligt, de vil være opmærksomme på det, gå ud af dit websted og antage det dig tag ikke sikkerhed alvorligt (endnu værre).
Desuden vil alle moderne browsere blokere for de mere ondsindede typer blandet indhold - og dermed kan det ødelægge dit websted.
Den bedste løsning er selvfølgelig at sørge for, at disse advarsler og / eller blokke ikke forekommer i første omgang ved korrekt at konfigurere dit websted til kun at tjene sikkert indhold.
Hvorfor ser jeg denne advarsel?
En advarsel med blandet indhold betyder, at både sikrede og usikrede elementer vises på en side, der skal være helt krypteret. Enhver side, der bruger en HTTPS-adresse, skal have alt indhold fra en sikret kilde. Enhver side, der linker til en HTTP-ressource betragtes som usikker og markeres af din browser som en sikkerhedsrisiko.
Advarsler med blandet indhold falder i to kategorier: blandet passivt indhold og blandet aktivt indhold.
Blandet passivt indhold
Passivt indhold refererer til emner, der kan erstattes eller ændres, men som ikke kan ændre andre dele af siden - for eksempel en grafik eller et fotografi. Den mest almindelige årsag til al advarsel om blandet indhold er sandsynligvis, når et (teoretisk) sikkert sted er konfigureret til at trække billeder fra en usikret kilde.
Passive HTTP-anmodninger serveres via disse tags:<audio>
(src
attribut)<img>
(src
attribut)<video>
(src
attribut)<object>
subresources (når en <object>
udfører HTTP-anmodninger)
Blandet aktivt indhold
Aktivt indhold kan ændre selve websiden. Et mand-i-midten-angreb kan tillade, at en anmodning om HTTP-indhold på enhver HTTPS-side opfanges og / eller omskrives. Dette gør ondsindet aktivt indhold meget farligt - brugerlegitimationsoplysninger og følsomme data kan blive stjålet eller malware installeret på brugerens system. For eksempel kunne lidt JavaScript på en side til oprettelse af en konto, der er designet til at hjælpe brugerne med at generere en tilfældig adgangskode, erstattes af kode, der i stedet giver en tilfældig, men prægenereret, eller til at levere en ellers sikker adgangskode i hemmelighed til en tredjepart .
Aktivt blandet indhold kan udnyttes til at kompromittere følsomme private data, men endda offentligt stillede websider, der synes uskadelige, kan stadig omdirigere besøgende til farlige websteder, levere uønsket indhold eller stjæle cookies til udnyttelse.
<script>
(src
attribut)<link>
(href
attribut) (dette inkluderer CSS-stilark)XMLHttpRequest
objektanmodninger<iframe>
(src
egenskaber)Alle tilfælde i CSS, hvor en url-værdi bruges (
@font-face
, cursor
, background-image
, Osv.)<object>
(data
attribut)Alle moderne browsere blokerer som standard aktivt blandet indhold (hvilket kan ødelægge et forkert konfigureret websted)
Hvorfor og hvordan man løser advarsler om blandet indhold
Ved at sikre dit websted kan dine besøgende stole på dig, hvilket er meget vigtigt. Fjernelse af alt usikkert indhold fra dit websted har en endnu større bonus ved at eliminere falske positive advarsler - hvis dit korrekt konfigurerede sted er kompromitteret, vil ethvert usikkert element, som en angriber indsætter, udløse advarslen om blandet indhold, hvilket giver dig en ekstra tripwire til at opdage og løse disse problemer.
Igen er den bedste måde at undgå problemer med blandet indhold at servere alt indhold via HTTPS i stedet for HTTP.
For dit eget domæne skal du tjene alt indhold som HTTPS og rette dine links. Ofte findes HTTPS-versionen af indholdet allerede, og det kræver bare at tilføje et "s" til links - http://
til https://
.
For andre domæner skal du bruge websteds HTTPS-version, hvis den er tilgængelig. Hvis HTTPS ikke er tilgængelig, kan du prøve at kontakte domænet og spørge dem, om de kan gøre indholdet tilgængeligt via HTTPS.
Alternativt kan browseren automatisk bruge HTTP eller HTTPS ved hjælp af "relative URL'er", afhængigt af hvilken protokol brugeren bruger. For eksempel i stedet for at linke til et billede ved hjælp af et link med den "absolutte sti" til:
Webstedet kan bruge en relativ sti:
Dette gør det muligt for browseren automatisk at tilføje enten http:
or https:
til start af URL'en efter behov. (Bemærk, at webstedet, der er knyttet til, bliver nødt til at tilbyde ressourcen over både HTTP og HTTPS for, at relative webadresser fungerer.)
Chrome
Firefox
Internet Explorer
Fremragende værktøjer til at opspore ikke-SSL-links i din kildekode er udviklerværktøjerne indbygget i Firefox og Chrome browsere. Oplysninger om at tvinge en Apache-server til kun at håndtere HTTPS kan være findes her.
Det første anmodningsproblem
Vi håber, at denne artikel op til dette punkt har lagt et par gode argumenter imod blandet indhold, selvom selvom du beslutter at migrere dit websted helt til HTTPS, er der stadig nogle forbedringer, du kan foretage.
Når brugere indtaster URL'et på dit websted i en browser, skriver de typisk aldrig fuldt ud protokolnavnet (dvs. https://
). Naturligvis ved browseren ikke, hvilken protokol dit websted serveres under, og er standard til HTTP.
Hvis dit websted er konfigureret korrekt, vil det omdirigere (via HTTP 301/302-svar) browseren til dens HTTPS-forekomst; selvom dette betyder, at browsere skal udføre to anmodninger i stedet for en enkelt HTTPS-anmodning, når de først besøger dit websted.
Dette kan være problematisk, fordi brugere kan opfatte forsinkelsen og få et dårligt førsteindtryk af webstedet. Som sådan er det mindre sandsynligt, at de klæber rundt, hvilket i sidste ende kan føre til nedsat besøgende trafik.
Desuden kan hackere opfange den første HTTP-anmodning om at læse eller ændre den, før de når serveren. En almindelig forekomst for denne type tilfælde er at udføre et opkaldt netværksangreb SSL-stripping hvilket tillader angriberen at erstatte en HTTPS-forbindelse med en ubeskyttet HTTP-forbindelse.
HTTP streng transportsikkerhed til redning
HTTP Streng Transport Sikkerhed or HSTS er et forsøg på at løse dette problem. Implementeret af Internet Engineering Task Force (IETF) i RFC 6797 er HSTS en HTTPS-header, som webservere kan inkludere i deres svar. Denne header instruerer kompatible browsere om altid at bruge HTTPS, når de besøger et websted. HSTS gælder for alle anmodninger, herunder billeder, CSS-stilark og enhver anden webressource.
Som du måske forestiller dig, skal browseren først se HSTS-overskriften for at ære den, hvilket betyder, at HSTS er afhængig af, at angriberen ikke kan opfange den første HTTP-anmodning. Som et resultat er HSTS i sig selv ikke en komplet løsning, men snarere en simpel løsning til SSL-stripping.
Forudindlæsning af HSTS
Heldigvis har Chromium-projektet fundet en løsning, de navngav Forudindlæsning af HSTS, som består af at opretholde en offentlig liste over websteder, der har anmodet om HSTS-forudindlæsningsfunktionalitet. Når de besøger et websted, vil Chromium-browsere konsultere listen, og hvis webstedet findes der, fortsætter de med at kommunikere med det via HTTPS (inklusive den første anmodning) uanset tidligere historie eller brugerinput.
Som en konsekvens kan forhåndsindlæsning forbedre både dit websteds ydelse og sikkerhed ved at fjerne den første HTTP-anmodning. Derudover kan det indirekte forbedre dit websteds SERP-placering og brugeroplevelse.
Alle større browsere (Googles Chrome, Microsofts IE / Edge, Apples Safari, Mozilla's Firefox og Opera) konsulterer også Chromiums HSTS-forudlæsseliste, hvilket betyder, at ved at blive medlem af denne liste giver de forhåndsindlæste fordele for dine besøgende, uanset hvilken browser de bruger.
Vi ville dog være afladende, hvis vi ikke nævnte, at der er bekymringer for skalerbarheden af HSTS-forudindlæsningslisten - Den kan ikke inkludere alle websteder på Internettet på grund af praktisk størrelse og begrænsninger i beregningskompleksiteten, og derfor kan adgang blive stadig vanskeligere efterhånden som tiden går, og HSTS-forudindlæsning bliver bredere vedtaget.
Hvordan kan jeg være med?
Hvis du er interesseret i at tilmelde dig HSTS-indlæsningsliste, skal du huske, at dit websted skal følge visse regler. Chromium-projektet har offentliggjort listen over krav til indsendelse af websteder, der ønsker at deltage i deres projekts websted. Kravene er ordret inkluderet i følgende liste, men du kan finde flere detaljer i HSTS RFC 6797.
For at blive accepteret på HSTS-indlæsningslisten skal dit websted:
- Server et gyldigt certifikat.
- Omdiriger fra HTTP til HTTPS på den samme vært, hvis du lytter på port 80.
- Server alle underdomæner via HTTPS. Du skal især understøtte HTTPS til
www
underdomæne, hvis der findes en DNS-post for det underdomæne. - Server en RFC 6797-kompatibel HSTS-header på basedomænet til HTTPS-anmodninger:
-
max-age
skal være mindst 31536000 sekunder (1 år). -
includeSubDomains
direktivet skal specificeres. -
preload
direktivet skal specificeres.
-
- Hvis du betjener en yderligere omdirigering fra dit HTTPS-sted, skal denne omdirigering også har en kompatibel HSTS-header (som også skal den side, den omdirigerer til).
Her er et eksempel på en gyldig HSTS-header.
Streng-transport-sikkerhed: max-age = 63072000; includeSubDomains; preload
Du kan teste dit websted for støtteberettigelse ved at besøge webstedet med indlæst liste og indtaste dit domæne i indtastningsfeltet. Webapplikationen der vil påpege, hvilke problemer (hvis nogen) du skal løse.
Desværre tillader kompleksiteten af moderne websteder ikke en at komme med en server-konfiguration i én størrelse, der passer til alle, så HSTS-forudindlæsning kan medtages i denne artikel. Der kan være problemer med driftstid med tredjepart eller andre brugerdefinerede komponenter, der skal løses individuelt.
Selvom Chromium-projektet har inkluderet nogle implementeringsanbefalinger på preload-webstedet, er vi altid glade for at hjælpe vores kunder med at forbedre deres kommunikationssikkerhed. Bare send os en e-mail kl support@ssl.com og en ekspert vil med glæde diskutere den bedste vej frem til dine sikkerhedsbehov.
Konklusion
HTTPS er ved at blive standardwebkommunikationsprotokollen, og fuldt forpligtelse til det kan kun have positive effekter for webstedsejere og besøgende. Vi anbefaler, at du fjerner alt blandet indhold fra dine websteder for at undgå unødvendige problemer (og utilfredse brugere).
Som altid tak for at have valgt SSL.com, hvor vi mener, at et mere sikkert internet er et bedre internet.