en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

HTTPS överallt: Ta bort blandat innehåll för att förbättra SEO

Beskrivning

Under de senaste åren har vi sett webben och sortimentet av branscher som driver den (dvs. webbläsare, sökmotorer etc.) börjar ta användarsäkerheten mer allvarligt. Chrome är nu varnar användare mot HTTP-webbplatser med fler webbläsare redo att följa, medan Google Sök har bekräftat att de ger sökmotorrankning höjer till HTTPS webbplatser.

Utvecklingar som dessa har motiverat en betydande del av webbplatsägare att flytta sina servrar bort från gamla, osäkra HTTP till det säkrare alternativet HTTPS. (HTTPS anses vara säkrare eftersom det kräver att servrar ska autentiseras via SSL-certifikat som ett sätt att skydda användare från de flesta typer av nätattacker.)

De flesta webbplatser har emellertid endast implementerat HTTPS för sina mest kritiska komponenter, till exempel inloggnings- eller POST-förfrågningar, men kan fortfarande använda HTTP för andra "icke-kritiska" funktioner.

Detta var vettigt under de första dagarna av HTTPS, eftersom krypterade anslutningar är mer beräkningsmässigt dyra på grund av att de måste utföra handskakningar för varje ny anslutning. Dessutom var vid den tiden många allmänt använda webbutvecklingsplattformar, bibliotek och miljöer inte HTTPS-redo - ett faktum som orsakade administratörer och utvecklare oändlig huvudvärk i form av programkrascher på sent på kvällen eller obskyra körtidsfel.

Naturligtvis är detta inte sant längre - faktiskt, som den här artikeln kommer att hävda, inte använder HTTPS för alla din webbplats anslutningar är faktiskt dåligt för ditt företag.

 

Blandat innehåll

Webbplatser som inte har allt innehåll via HTTPS kallas blandat innehåll webbplatser. En akademiker papper publicerad 2015 fann att över 43% av deras urval av Alexa 100,000 XNUMX topp serverade minst en typ av blandat innehåll.

Även om detta inte låter som en stor sak kan blandat innehåll vara ganska farligt för användare, men det kan också ha negativa effekter på webbplatser också.

Säkerhetsfrågor

Det viktigaste skälet till att använda HTTPS för hela webbplatsen är säkerhet. En enda oskyddad HTTP-anslutning är alla hackare behöver. MITM-angripare kan ersätta allt HTTP-innehåll på din sida för att stjäla referenser och sessioner, skaffa känslig information eller starta webbläsarutnyttjande och installera skadlig programvara på dina besökares datorer.

Att kompromitteras av din webbplats kommer naturligtvis att göra att dina användare misstro och undviker den i framtiden, vilket effektivt skadar ditt online rykte.

Både Firefox och Chrome har startat för att blockera blandat innehåll som standard, så att användare manuellt kan välja att ladda innehåll via HTTP. Eftersom blandat innehåll är en säkerhetsrisk visar båda webbläsarna dock en varning för blandat innehåll till användare, vilket också kan påverka webbplatsens rykte negativt.

 

Firefox blandat innehåll varning

Prestationsproblem

Förutom säkerhet, den ständigt ökande antagandet av HTTP / 2 av branschen har fört många prestanda och säkerhetsuppgraderingar på webben.

Även om prestationsökningen verkar motintuitiv sedan HTTP / 2 fungerar bara över krypterade HTTPS-anslutningar tillåter protokollet webbläsare att använda en enda krypterad anslutning med en HTTPS webbserver för all deras kommunikation.

Återanvändning av samma anslutning avlägsnar omkostnaderna som upprepas genom att upprepade gånger upprätta nya (dvs. handskakningen igen). Detta innebär att hoppa från krypterade HTTPS-anslutningar till okrypterad HTTP på en webbplats med blandat innehåll i själva verket är långsammare och mer resurskrävande än att besöka en helt skyddad webbplats med en enda HTTPS-anslutning.

HTTP / 2 implementerar också 0-RTT session-återupptagningsläge, vilket gör att webbläsare kan återuppta en pausad session med en HTTPS-webbplats som de har besökt tidigare, med bara en enda begäran (istället för en komplett handskakning) Detta gör HTTP / 2-återupptagning minst lika snabb som en okrypterad HTTP-anslutning, samtidigt som alla fördelar med HTTPS ger. Att servera blandat innehåll innebär att din webbplats inte kan dra full nytta av detta eller någon av de andra fantastiska funktionerna i HTTP / 2.

I båda dessa fall förbättrar HTTP / 2 hastigheten för din besökares anslutning till din webbplats - och hastigheten spelar roll. Studier har visat genom åren att lyhördhet och sidhastighetshastighet är kritiska krav på design av användargränssnitt. Ju långsammare en webbplats svarstid är, desto mindre troligt är det för användare att hålla sig engagerade och användarengagemang påverkar direkt din webbplats användarupplevelse (och följaktligen dina konverteringsgrader).

Blandat innehåll kan också påverka prestanda i nivån på de underliggande webbteknologier som används på din webbplats. Webbläsare nu begränsa JavaScript-funktioner till exempel servicearbetare och pushmeddelanden för att bara säkra sammanhang, eftersom de annars skulle kunna missbrukas av hackare för skadliga ändamål. Det betyder igen att din webbplats inte kan dra nytta av någon av dessa teknologier när du serverar blandat innehåll.

SEO-frågor

Sökmotoroptimering (SEO) är brödet och smöret för online-marknadsförare. SEO hänvisar till praxis att förbättra rankningen av en webbplats i en sökmotorens resultat sida (SERP), som direkt påverkar volymen på webbplatsens trafik.

Google har bekräftat att deras rankningsalgoritm för sökresultat ger en liten rankning till webbplatser som serveras via HTTPS. Eftersom boostet är i realtid och per webbadress, kommer en webbsida i sin helhet över HTTPS att resultera i en SEO-boost för hela webbplatsen (istället för endast de webbadresser som serveras via HTTPS). Beviljas att denna rankningssignaluppgång är ganska lätt jämfört med andra som kvalitetsinnehåll eller användartrafik, det belönar fortfarande din investering i att ta bort blandat innehåll.

Google har också nyligen meddelade att sidbelastningshastighet och allmän webbplatsprestanda beaktas (tung) vid beslut om rangordning. Detta innebär att HTTP / 2: s prestationsoptimeringar och borttagande av blandat innehåll kan fungera tillsammans för att öka din webbplats synlighet på webben.

Slutligen, om du vill dra full nytta av SSL i din webbplats SEO kan du överväga SSL.com: s EV-certifikat, som erbjuder de högsta försäkringarna för dina besökare via säkerhetsindikatorer (som det gröna fältet i webbläsaren) för att hålla dem säkra och engagerade med ditt innehåll - och längre besök lika högre ranking.

Varningar för webbläsare med blandat innehåll

Besökare på webbplatser som är skyddade av SSL förväntar sig (och förtjänar) sömlöst skydd. När en webbplats inte helt skyddar allt innehåll, visar en webbläsare en varning om "blandat innehåll". När dina kunder ser denna varning kan de reagera på två sätt. Om de inte ta säkerheten på allvar, de kommer att ignorera den, klicka igenom och antar att allt kommer att vara okej (väldigt dåligt). Om de do ta säkerhet på allvar, de kommer att ta hänsyn till det, gå tillbaka från din webbplats och anta att dig ta inte säkerheten på allvar (ännu värre).

Dessutom kommer alla moderna webbläsare att blockera de mer skadliga typerna av blandat innehåll - och genom att göra det kan du bryta din webbplats.

Den bästa lösningen är naturligtvis att se till att dessa varningar och / eller block inte kommer att inträffa i första hand genom att korrekt konfigurera din webbplats så att den endast serverar säkert innehåll.

Varför ser jag den här varningen?

En varning med blandat innehåll innebär att både säkrade och osäkrade element visas på en sida som borde vara helt krypterad. Varje sida som använder en HTTPS-adress måste ha allt innehåll som kommer från en säker källa. Varje sida som länkar till en HTTP-resurs betraktas som osäker och flaggas av din webbläsare som en säkerhetsrisk.

Varningar med blandat innehåll ingår i två kategorier: blandat passivt innehåll och blandat aktivt innehåll.

Blandat passivt innehåll

Passivt innehåll hänvisar till objekt som kan ersättas eller ändras men inte kan ändra andra delar av sidan - till exempel en grafik eller ett fotografi. Förmodligen den vanligaste orsaken till all varning om blandat innehåll är när en (teoretiskt) säker webbplats är konfigurerad för att hämta bilder från en osäker källa.

Passiva HTTP-förfrågningar visas via dessa taggar:<audio>(src attribut)
<img> (src attribut)
<video> (src attribut)
<object> subresources (när en <object> utför HTTP-förfrågningar)

Blandat aktivt innehåll

Aktivt innehåll kan ändra själva webbsidan. En man-i-mitten-attack kan tillåta att en begäran om HTTP-innehåll på vilken HTTPS-sida som helst kan fångas upp och / eller skrivas om. Detta gör skadligt aktivt innehåll mycket farligt - användaruppgifter och känslig data kan stulas eller skadlig programvara installeras på användarens system. Till exempel kan lite JavaScript på en sida för att skapa ett konto som är utformat för att hjälpa användare att generera ett slumpmässigt lösenord ersättas med kod som ger ett slumpmässigt utseende men förgenererat i stället, eller för att leverera ett annars säkert lösenord i hemlighet till en tredje part .

Aktivt blandat innehåll kan utnyttjas för att kompromissa med känsliga privata data, men även offentliga webbplatser som verkar oskadliga kan fortfarande omdirigera besökare till farliga webbplatser, leverera oönskat innehåll eller stjäla cookies för exploatering.

Aktiva HTTP-förfrågningar visas via:<script> (src attribut)
<link> (href attribut) (detta inkluderar CSS-formatmallar)
XMLHttpRequest objektförfrågningar
<iframe> (src attribut)
Alla fall i CSS där ett url-värde används (@font-face, cursor, background-image, Etc)
<object> (data attribut)

Alla moderna webbläsare blockerar aktivt blandat innehåll som standard (vilket kan bryta en felaktigt konfigurerad webbplats)

Varför och hur man fixar varningar med blandat innehåll

Att säkra din webbplats låter dina besökare lita på dig, vilket är mycket viktigt. Att eliminera allt osäkert innehåll från din webbplats har en ännu större bonus att eliminera falskt positiva varningar - om din korrekt konfigurerade webbplats är äventyrad, kommer alla osäkra element som en angripare infogar att utlösa varningen för blandat innehåll, vilket ger dig en extra tripwire att upptäcka och ta itu med dessa frågor.

Återigen är det bästa sättet att undvika problem med blandat innehåll att betjäna allt innehåll via HTTPS istället för HTTP.

För din egen domän, servera allt innehåll som HTTPS och fixa dina länkar. Ofta finns HTTPS-versionen av innehållet redan och detta kräver bara att ett "s" läggs till länkar - http:// till https://.

För andra domäner, använd webbplatsens HTTPS-version om tillgänglig. Om HTTPS inte är tillgängligt kan du försöka kontakta domänen och fråga dem om de kan göra innehållet tillgängligt via HTTPS.

Alternativt låter webbläsaren automatiskt välja HTTP eller HTTPS genom att använda ”relativa webbadresser”, beroende på vilket protokoll användaren använder. Till exempel istället för att länka till en bild med en länk med den "absoluta sökvägen" för:


Webbplatsen kan använda en relativ sökväg:


Detta gör att webbläsaren automatiskt lägger till endera http: or https: till början av webbadressen efter behov. (Observera att webbplatsen som är länkad till måste erbjuda resursen via både HTTP och HTTPS för att relativa webbadresser ska fungera.)

Följ dessa länkar för mer webbläsarspecifik information om varningar med blandat innehåll:
krom
firefox
Internet Explorer
Utmärkta verktyg för att spåra länkar som inte är SSL i din källkod är utvecklarverktygen inbyggda i firefox och krom webbläsare. Information om att tvinga en Apache-server att hantera endast HTTPS kan vara finns här.

Det första begäran problemet

Vi hoppas att den här artikeln har lagt fram några goda argument mot blandat innehåll, även om du väljer att migrera din webbplats helt till HTTPS finns det fortfarande några förbättringar du kan göra.

När användare skriver webbadressen till din webbplats i en webbläsare skriver de vanligtvis aldrig helt protokollnamnet (dvs. https://). Naturligtvis vet webbläsaren inte vilket protokoll din webbplats serveras under och är standard för HTTP.

Om din webbplats är korrekt konfigurerad kommer den att omdirigera (via HTTP 301/302-svar) webbläsaren till dess HTTPS-instans; men detta betyder att webbläsare måste utföra två förfrågningar istället för en enda HTTPS-begäran när de besöker din webbplats först.

Detta kan vara problematiskt eftersom användare kan uppleva förseningen och få ett dåligt första intryck av webbplatsen. Som sådan kommer de att vara mindre benägna att hålla sig kvar vilket i slutändan kan leda till minskad besökartrafik.

Dessutom kan hackare fånga den första HTTP-begäran om att läsa eller modifiera den innan de når servern. En vanlig förekomst för denna typ av fall är att utföra en nätverksattack som heter SSL strippning vilket tillåter angriparen att ersätta en HTTPS-anslutning med en oskyddad HTTP-anslutning.

HTTP strikt transportsäkerhet till undsättning

HTTP Strikt transportsäkerhet or HSTS är ett försök att lösa detta problem. Implementerad av Internet Engineering Task Force (IETF) i RFC 6797, är HSTS en HTTPS-rubrik som webbservrar kan inkludera i sina svar. Denna rubrik instruerar kompatibla webbläsare att alltid använda HTTPS när du besöker en webbplats. HSTS gäller för alla förfrågningar inklusive bilder, CSS-formatmallar och andra webbresurser.

Som du kanske föreställer dig måste webbläsaren först se HSTS-rubriken för att hedra den, vilket innebär att HSTS förlitar sig på att angriparna inte kan fånga den första HTTP-begäran. Som ett resultat är HSTS i sig inte en komplett lösning utan snarare en enkel lösning på SSL-strippning.

HSTS förbelastning

Lyckligtvis har Chromium-projektet kommit med en lösning som de namnger HSTS förbelastning, som består av att upprätthålla en offentlig lista över webbplatser som har begärt HSTS-förladdningsfunktionalitet. När de besöker en webbplats kommer Chromium-webbläsare att konsultera listan och om webbplatsen finns där kommer de att fortsätta med att kommunicera med den via HTTPS (inklusive den första begäran) oavsett tidigare historik eller användarinmatning.

Som en konsekvens kan förladdning förbättra din webbplats prestanda och säkerhet genom att ta bort den ursprungliga HTTP-begäran. Dessutom kan det indirekt förbättra din webbplats SERP-ranking och användarupplevelse.

Alla större webbläsare (Googles Chrome, Microsofts IE / Edge, Apples Safari, Mozillas Firefox och Opera) konsulterar också Chromiums HSTS-förbelastningslista, vilket innebär att om du går med i den här listan ger de förbelastade fördelarna för dina besökare oavsett vilken webbläsare de använder.

Vi skulle dock vara otrevliga om vi inte nämnde att det finns oro för skalbarheten i HSTS-förhandsladdningslösningen - Den kan inte inkludera alla webbplatser på Internet på grund av praktiska begränsningar och beräkningskomplexitetsbegränsningar, och följaktligen kan inträde bli allt svårare. när tiden går och HSTS-förinladdning blir bredare antagen.

Hur kan jag gå med?

Om du är intresserad av att gå med i HSTS-förladdningslistan, kom ihåg att din webbplats måste följa vissa regler. Chromium-projektet har publicerat listan över krav på inlämning för webbplatser som vill gå med på projektets webbplats. Kraven ingår ordet i följande lista, men du kan hitta mer information i HSTS RFC 6797.

För att accepteras i HSTS-förbelastningslistan måste din webbplats:

  1. Servera ett giltigt certifikat.
  2. Omdirigera från HTTP till HTTPS på samma värd om du lyssnar på port 80.
  3. Servera alla underdomäner via HTTPS. Du måste särskilt stödja HTTPS för www underdomän om det finns en DNS-post för det underdomänen.
  4. Servera en RFC 6797-kompatibel HSTS-rubrik på basdomänen för HTTPS-förfrågningar:
    • Du har nu möjlighet max-age måste vara minst 31536000 sekunder (1 år).
    • Du har nu möjlighet includeSubDomains direktiv måste anges.
    • Du har nu möjlighet preload direktiv måste anges.
  5. Om du visar en ytterligare omdirigering från din HTTPS-webbplats måste den omdirigeringen också ha en kompatibel HSTS-rubrik (liksom den sida den omdirigerar till).

Här är ett exempel på en giltig HSTS-rubrik.

Strikt-transport-säkerhet: max-age = 63072000; includeSubDomains; förbelastning

Du kan testa din webbplats för valbarhet genom att besöka webbplatsen för förbelastningslista och ange din domän i inmatningsrutan. Webapplikationen där kommer att påpeka vilka problem (om några) du behöver fixa.

HSTS förbelastnings behörighetsverktyg

Tyvärr tillåter inte komplexiteten på moderna webbplatser att en serverkonfigurering i en storlek passar alla för HSTS-förladdning att inkludera i den här artikeln. Det kan vara problem med driftstider med tredje part eller andra anpassade komponenter som måste lösas individuellt.

Även om Chromium-projektet har inkluderat en del implementeringsrekommendationer på förladdningswebbplatsen, hjälper vi alltid våra kunder att förbättra sin kommunikationssäkerhet. Släpp oss bara ett e-postmeddelande kl support@ssl.com och en expert kommer gärna att diskutera den bästa vägen framåt för dina säkerhetsbehov.

Slutsats

HTTPS håller på att bli standard-webbkommunikationsprotokollet och fullständigt åtagande av det kan bara ha positiva effekter för webbplatsägare och besökare. Vi rekommenderar att du tar bort allt blandat innehåll från dina webbplatser för att undvika onödiga problem (och missnöjda användare).

Som alltid, tack för att du valde SSL.com, där vi tror att ett säkrare internet är ett bättre internet.

Uppdatering (7 oktober 2019):  Den 3 oktober 2019, Chromium-bloggen meddelade att Chrome kommer att vara det blockering allt blandat innehåll, inklusive bilder, ljud och video, i en serie steg som börjar med Chrome 79 (december 2019) och fortsätter genom Chrome 81 i början av 2020. Detta steg från Google innebär att det är viktigare än någonsin att eliminera blandat innehåll från din hemsida.

SSL.com s EV Kodsignering certifikat hjälper till att skydda din kod från obehörig manipulering och kompromissa med den högsta nivån av validering, och är tillgängliga för så lite som $ 249 per år. Du kan också använd ditt EV Code Signing-certifikat i stor skala i molnet med eSigner. Med sitt automatiserade alternativ är eSigner lämplig för företagskodsignering.

BESTÄLL NU

Prenumerera på SSL.coms nyhetsbrev

Missa inte nya artiklar och uppdateringar från SSL.com