Bevezetés
Az utóbbi években láttuk, hogy a web és az iparágak választéka (pl. Böngészők, keresőmotorok stb.), Amelyek azt hajtják, komolyabban veszik a felhasználók biztonságát. A Chrome most már a felhasználók figyelmeztetése a HTTP webhelyek ellen több böngésző készen áll a követésre, míg a Google Keresés megerősítette, hogy a keresőmotorok rangsorolását növelik HTTPS honlapok.
Az ilyen fejlesztések arra ösztönözték a webhelytulajdonosokat, hogy szervereiket távolítsák el a régi, nem biztonságos HTTP-től a biztonságosabb alternatív HTTPS-re. (A HTTPS biztonságosabbnak tekinthető, mert megköveteli a szerverek hitelesítését SSL tanúsítványokon keresztül, hogy megvédje a felhasználókat a legtöbb hálózati támadástól.)
A webhelyek többsége azonban a HTTPS-t csak a legkritikusabb összetevőire, például a bejelentkezésre vagy a POST-kérelmekre telepítette, de továbbra is használhatja a HTTP-t más „nem kritikus” funkciókhoz.
Ennek értelme volt a HTTPS korai napjaiban, mivel a titkosított kapcsolatok számítási szempontból drágábbak, mivel végre kell hajtaniuk kézfogás minden új kapcsolatért. Ráadásul abban az időben sok széles körben használt webfejlesztő platform, könyvtár és környezet nem volt HTTPS-kész - ez a tény az adminisztrátoroknak és a fejlesztőknek végtelen fejfájást okozott késő esti alkalmazások összeomlása vagy homályos futásidejű hibák formájában.
Természetesen ez már nem igaz - sőt, amint ez a cikk érvelni fog, nem a HTTPS használatával minden a webhely kapcsolata valójában káros az Ön vállalkozása számára.
Vegyes tartalom
Azokat a webhelyeket hívják, amelyek teljes tartalmát nem szolgálják fel a HTTPS-en keresztül kevert tartalom weboldalak. Egy tudományos papír A 2015-ben közzétett közlemény megállapította, hogy az Alexa top 43 100,000 mintájának több mint XNUMX% -a szolgált legalább egy típusú vegyes tartalommal.
Bár ez nem tűnik nagy ügynek, a vegyes tartalom meglehetősen veszélyes lehet a felhasználók számára, ám negatív hatással lehet a weboldalakra is.
Biztonsági kérdések
A HTTPS használatának legfontosabb oka az egész webhelyén a biztonság. Egyetlen védetlen HTTP-kapcsolat szükséges minden hackerek számára. Középső támadók (MITM) bármilyen HTTP-tartalmat helyettesíthet az oldalán annak érdekében, hogy ellopja a hitelesítő adatokat és a munkameneteket, érzékeny adatokat szerezzen, vagy böngészőt indítson, és malware programokat telepítsen a látogatók számítógépére.
Ha webhelye veszélybe kerül, akkor természetesen a felhasználók bizalmatlanná válnak és elkerülhetik a jövőben, ezáltal ténylegesen károsíthatja online hírnevét.
Mind a Firefox, mind a Chrome elkezdődött alapértelmezés szerint blokkolja a vegyes tartalmat, lehetővé téve a felhasználók számára, hogy manuálisan választhassák meg a tartalom betöltése HTTP-n keresztül. Mindazonáltal, mivel a vegyes tartalom biztonsági kockázatot jelent, mindkét böngésző vegyes tartalommal kapcsolatos figyelmeztetést jelenít meg a felhasználók számára, ami szintén negatívan befolyásolhatja webhelyének hírnevét.
Teljesítménybeli problémák
A biztonság mellett a HTTP / 2 az iparág számos teljesítmény- és biztonsági frissítést hozott az internetre.
Bár a teljesítmény növekedése ellentmondásosnak tűnik a HTTP / 2 óta csak működik A titkosított HTTPS kapcsolatokon keresztül a protokoll lehetővé teszi a böngészők számára, hogy egyetlen titkosított kapcsolatot használhassanak a HTTPS webszerverrel az összes kommunikációhoz.
Ugyanazon kapcsolat újbóli felhasználása eltávolítja a fölött levő fölött az ismételt újak létrehozásával (azaz a kézfogás ismét). Ez azt jelenti, hogy a titkosított HTTPS-kapcsolatokról a titkosítatlan HTTP-re való áttérés egy vegyes tartalmú webhelyen valójában lassabb és erőforrásigényesebb, mint egy teljesen védett webhely látogatása egyetlen HTTPS-kapcsolat használatával.
A HTTP / 2 a 0-RTT munkamenet-folytatási mód, amely lehetővé teszi a böngészők számára, hogy egy szüneteltetett munkamenetet folytathassanak egy korábban meglátogatott HTTPS-webhel, csak egyetlen kéréssel (teljes kézfogás helyett). Ez a HTTP / 2 folytatását legalább olyan gyorsan teszi lehetővé, mint a titkosítatlan HTTP-kapcsolatot, miközben a HTTPS összes előnyeit biztosítja. A vegyes tartalom kiszolgálása azt jelenti, hogy webhelye nem tudja teljes mértékben kihasználni a HTTP / 2 ezen vagy bármely más nagyszerű tulajdonságát.
Mindkét esetben a HTTP / 2 javítja a látogató webhelyéhez való kapcsolódás sebességét - és a sebesség is számít. Tanulmányok az évek során megmutatták, hogy a reagálhatóság és az oldalbetöltési sebesség kritikus felhasználói felület-tervezési követelmények. Minél lassabb a webhely válaszideje, annál kisebb a valószínűsége annak, hogy a felhasználók továbbra is elköteleződjenek, és a felhasználói elkötelezettség közvetlenül befolyásolja webhelyének felhasználói élményét (és következésképpen az Ön konverziós arányát).
A vegyes tartalom befolyásolhatja a webhelyen használt mögöttes technológiák teljesítményét is. Böngészők most korlátozza a javascript funkciókat mint például a szolgáltató dolgozók, és az értesítéseket csak a biztonságos kontextus érdekében továbbítja, mert a hackerek rosszindulatú célokra felhasználhatják őket. Ez ismét azt jelenti, hogy webhelye nem használhatja ki ezen technológiák egyikét sem vegyes tartalom kiszolgálásakor.
SEO kérdések
Keresőoptimalizálás (SEO) az online üzleti marketingszakemberek kenyere és vaja. A SEO a webhely rangsorolásának javításának gyakorlatát jelenti keresőmotor eredményoldalán (SERP), amely közvetlenül befolyásolja a webhely forgalmának mértékét.
A Google megerősítette, hogy a keresési eredmények rangsorolási algoritmusa kis rangfokozást ad azoknak a webhelyeknek, amelyeket HTTPS-en keresztül szolgáltatnak. Mivel a lökés valós idejű és URL-enkénti, egy webhely teljes HTTPS-en keresztüli kiszolgálása SEO-lendületet eredményez az egész weboldal számára (csak azoknak az URL-eknek a helyett, amelyeket HTTPS-en keresztül nyújtanak). Igaz, ez a rangsori jelerősítés meglehetősen könnyű, összehasonlítva másokkal, például a minőségi tartalommal vagy a felhasználói forgalommal, mégis megtéríti a vegyes tartalom eltávolításába való befektetését.
A Google a közelmúltban is bejelentés az oldal betöltési sebességét és a weboldal általános teljesítményét (nehéz) figyelembe veszik a rangsorolás során. Ez azt jelenti, hogy a HTTP / 2 teljesítményének optimalizálása és a vegyes tartalom eltávolítása együttesen javíthatja webhelye láthatóságát az interneten.
Végül, ha teljes mértékben ki szeretné használni az SSL előnyeit webhelye SEO-jában, fontolja meg Az SSL.com EV tanúsítványai, amelyek biztonsági mutatókon keresztül biztosítják a látogatók számára a legnagyobb biztosítékokat (például a böngésző zöld sávja), hogy biztonságban tudják tartani őket és elkötelezzék magukat a tartalommal kapcsolatban - és hosszabb látogatások esetén is magasabb rangúak.
Böngésző vegyes tartalmú figyelmeztetések
Az SSL által védett webhelyek látogatói zökkenőmentes védelmet várnak (és meg is érdemelnek). Ha egy webhely nem védi teljes mértékben az összes tartalmat, a böngésző „vegyes tartalmú” figyelmeztetést jelenít meg. Amikor az ügyfelek látják ezt a figyelmeztetést, kétféle módon reagálhatnak. Ha ők nem komolyan veszik a biztonságot, figyelmen kívül hagyják, átkattintanak és feltételezik, hogy minden rendben lesz (nagyon rossz). Ha ők do komolyan veszik a biztonságot, figyelni fognak rá, visszatérnek az Ön webhelyére, és ezt feltételezik te ne vegye komolyan a biztonságot (még rosszabb).
Ezenkívül az összes modern böngésző blokkolja a vegyes tartalom rosszindulatúbb típusait - és ezzel megsértheti webhelyét.
A legjobb megoldás természetesen az, hogy megbizonyosodjon arról, hogy ezek a figyelmeztetések és / vagy blokkok eleve nem fordulnak elő, ha helyesen konfigurálja webhelyét csak biztonságos tartalom kiszolgálására.
Miért látom ezt a figyelmeztetést?
A vegyes tartalmú figyelmeztetés azt jelenti, hogy a biztonságos és a nem biztonságos elemeket egy oldalon teljes titkosítás mellett kiszolgálják. A HTTPS-címet használó oldalak összes tartalmának biztonságos forrásból kell származnia. Minden olyan oldal, amely egy HTTP erőforrásra hivatkozik, nem biztonságosnak tekinthető, és a böngésző biztonsági kockázatként megjelöli.
A vegyes tartalmú figyelmeztetések két kategóriába sorolhatók: vegyes passzív tartalom és a vegyes aktív tartalom.
Vegyes passzív tartalom
A passzív tartalom olyan elemekre vonatkozik, amelyek kicserélhetők vagy módosíthatók, de nem változtathatják meg az oldal egyéb részeit - például grafikát vagy fényképet. Valószínűleg a vegyes tartalmú figyelmeztetések leggyakoribb oka az, amikor egy (elméletileg) biztonságos webhelyet úgy konfigurálnak, hogy képeket vegyen fel nem biztonságos forrásból.
A passzív HTTP kéréseket a következő címkéken keresztül szolgálják ki:<audio>(src tulajdonság)<img> (src tulajdonság)<video> (src tulajdonság)<object> alforrások (ha egy <object> HTTP kéréseket hajt végre)
Vegyes aktív tartalom
Az aktív tartalom megváltoztathatja magát a weboldalt. Egy ember a közepén támadás lehetővé teheti bármely HTTPS-oldal HTTP-tartalom iránti kérelmének elfogását és / vagy átírását. Ez nagyon veszélyesvé teszi a rosszindulatú aktív tartalmat - ellophatják a felhasználó hitelesítő adatait és érzékeny adatait, vagy rosszindulatú programokat telepíthetnek a felhasználó rendszerére. Például egy olyan JavaScript-et egy fiók létrehozó oldalon, amelynek célja a felhasználók véletlenszerű jelszó előállítása, helyettesíthetik egy véletlenszerűnek tűnő, de előre létrehozott kóddal, vagy más módon titokban továbbíthatnak egy egyébként biztonságos jelszót .
Az aktív vegyes tartalom kihasználható az érzékeny magánadatok veszélyeztetésére, de még az ártalmatlannak tűnő, nyilvános oldalak is átirányíthatják a látogatókat veszélyes oldalakra, nem kívánt tartalmat szállíthatnak vagy cookie-kat lophatnak kizsákmányolás céljából.
<script> (src tulajdonság)<link> (href attribútum) (ez magában foglalja a CSS stíluslapokat)XMLHttpRequest objektum kérések<iframe> (src attribútumok)A CSS-ben szereplő összes olyan eset, amikor egy url értéket használnak (
@font-face, cursor, background-imageStb)<object> (data tulajdonság)Minden modern böngésző alapértelmezés szerint blokkolja az aktív vegyes tartalmat (ami megtörheti a helytelenül konfigurált webhelyet)
Miért és hogyan javíthatjuk a vegyes tartalomú figyelmeztetéseket
Webhelyének biztonságával a látogatók megbízhatnak benned, ami létfontosságú. Ha azonban az összes nem biztonságos tartalmat kiküszöböli a webhelyéről, még nagyobb bónuszt jelent a hamis pozitív figyelmeztetések kiküszöbölése - ha a helyesen konfigurált webhelye sérül, akkor a támadó által beillesztett bármelyik bizonytalan elem kiváltja a vegyes tartalmú figyelmeztetést, ami extra útvonalat nyújt Önnek és kezelni ezeket a kérdéseket.
A vegyes tartalmi problémák elkerülésének legjobb módja az, hogy az összes tartalmat HTTPS-en keresztül szolgálja ki, és nem HTTP-n keresztül.
Saját domainjéhez az összes tartalmat HTTPS-ként tálalja, és javítsa a linkeket. Gyakran a tartalom HTTPS-verziója már létezik, és ehhez csak egy s-t kell megadni a linkekhez - http:// nak nek https://.
Más domainek esetén használja a webhely HTTPS verzióját, ha elérhető. Ha a HTTPS nem érhető el, megpróbálhatja megkeresni a domaint és megkérdezni tőlük, hogy elérhetővé tehetik-e a tartalmat a HTTPS-en keresztül.
Alternatív megoldásként a „relatív URL-ek” használatával a böngésző automatikusan választhatja a HTTP vagy a HTTPS protokollt, attól függően, hogy a felhasználó melyik protokollt használja. Például ahelyett, hogy egy képhez linkelne egy linket az „abszolút elérési útjával”:
A webhely használhat relatív utat:
Ez lehetővé teszi, hogy a böngésző bármelyiket automatikusan hozzáadja http: or https: szükség szerint az URL elejére. (Vegye figyelembe, hogy a linkelt webhelynek az erőforrást mind a HTTP, mind a HTTPS-en keresztül felajánlnia kell a relatív URL-ek működéséhez.)
króm
Firefox
Internet Explorer
Kiváló eszközök a nem SSL-hivatkozások felkutatásához a forráskódban a fejlesztő eszközei, amelyek beépülnek a Firefox és a króm böngészők. Az Apache kiszolgáló csak HTTPS kezelésére kényszerítéséről szóló információk lehetnek itt található.
Az első kérés problémája
Reméljük, hogy e cikkig eddig a cikk néhány jó érvet adott fel a vegyes tartalom ellen, bár még ha úgy dönt, hogy a webhelyét teljes egészében a HTTPS-re telepíti, még mindig vannak néhány javítás.
Amikor a felhasználók beírják az Ön webhelyének URL-jét egy böngészőben, általában soha nem írják be teljesen a protokoll nevét (azaz https://). Természetesen a böngésző nem tudja, hogy melyik protokoll alatt szolgálja az Ön webhelyét, és alapértelmezés szerint HTTP.
Ha webhelye helyesen van konfigurálva, akkor a böngészőt (HTTP 301/302 válaszok útján) átirányítja a HTTPS példányára; bár ez azt jelenti, hogy a böngészőknek két kérést kell végrehajtaniuk egyetlen HTTPS-kérelem helyett, amikor először látogatják meg az Ön webhelyét.
Ez problémás lehet, mivel a felhasználók érzékelhetik a késést, és rossz első benyomást kelthetnek a webhelyről. Mint ilyenek, kevésbé valószínű, hogy ragaszkodnak, ami végül csökkent látogatói forgalmat eredményezhet.
Sőt, a hackerek elfoghatják az első HTTP kérést annak elolvasására vagy módosítására, mielőtt eljutnának a kiszolgálóra. Az ilyen típusú esetekben gyakran előfordul, hogy egy hálózati támadást hajtanak végre SSL sztrippelés amely lehetővé teszi a támadó számára, hogy a HTTPS-kapcsolatot nem védett HTTP-vel cserélje le.
HTTP szigorú szállítási biztonság a mentéshez
HTTP szigorú közlekedésbiztonság or HSTS egy kísérlet a probléma megoldására. Az Internet Engineering Task Force (IETF) által az RFC 6797-ben végrehajtott HSTS egy HTTPS fejléc, amelyet a webszerverek felvehetnek a válaszaiba. Ez a fejléc arra utasítja a kompatibilis böngészőket, hogy mindig használják a HTTPS-t, amikor egy webhelyet látogatnak. A HSTS az összes kérésre vonatkozik, beleértve a képeket, a CSS stíluslapokat és minden egyéb webes erőforrást.
Mint gondolhatja, először a böngészőnek kell lennie lát a HSTS fejléc annak tiszteletben tartása érdekében, ami azt jelenti, hogy a HSTS arra hivatkozik, hogy a támadók nem képesek elfogni az első HTTP-kérést. Ennek eredményeként a HSTS önmagában nem teljes megoldás, hanem egyszerű megoldás az SSL-sztrippelésre.
A HSTS előzetes betöltése
Szerencsére a Chromium projekt megoldást talált az általuk megnevezett A HSTS előzetes betöltése, amely a HSTS előtöltési funkciót igénylő webhelyek nyilvános listájának vezetéséből áll. Egy webhely látogatásakor a Chromium böngészői konzultálnak a listával, és ha a webhelyet ott találják, akkor a HTTPS-en keresztül kommunikálnak vele (beleértve az első kérést is), függetlenül a korábbi előzményektől vagy a felhasználói bemenetektől.
Következésképpen az előtöltés javíthatja a webhely teljesítményét és biztonságát azáltal, hogy eltávolítja a kezdeti HTTP kérést. Ezenkívül közvetett módon javíthatja webhelye SERP rangsorolását és felhasználói élményét.
Az összes főbb böngésző (a Google Chrome, a Microsoft IE / Edge, az Apple Safari, a Mozilla Firefox és az Opera) szintén konzultál a Chromium HSTS előterhelési listájával, ami azt jelenti, hogy ehhez a listához való csatlakozás előzetes előnyt jelent a látogatók számára, függetlenül attól, hogy melyik böngészőt használják.
Sajnálnánk azonban, ha nem említenénk, hogy aggályok merülnek fel a HSTS előterhelési lista megoldás méretezhetőségével kapcsolatban - A gyakorlati méret és a számítási bonyolultság korlátai miatt nem tartalmazhat minden weboldalt az interneten, következésképpen a belépés egyre nehezebbé válik az idő múlásával és a HSTS előzetes feltöltése szélesebb körűvé válik.
Hogyan csatlakozhatok?
Ha érdekli a HSTS előterhelési listájához való csatlakozás, ne feledje, hogy webhelyének bizonyos szabályokat kell követnie. A Chromium projekt közzétette azoknak a weboldalaknak a benyújtási követelményeinek listáját, amelyek csatlakozni kívánnak a projektük webhelyéhez. A követelményeket szó szerint tartalmazza a következő lista, ám további részletek megtalálhatók a HSTS-ben RFC 6797.
Ahhoz, hogy a webhely felkerüljön a HSTS előterhelési listájára, a következőknek kell megfelelniük:
- Szolgáljon érvényes tanúsítványt.
- Átirányítás a HTTP-ről a HTTPS-re ugyanazon a gépen, ha a 80-as porton hallgat.
- Az összes aldomaint kiszolgálja a HTTPS-en keresztül. Különösen támogatnia kell a HTTPS-t a
wwwaldomain, ha létezik az aldomain DNS-rekordja. - Szolgáltasson egy RFC 6797-kompatibilis HSTS fejlécet az alaptartományban a HTTPS kérésekhez:
- A
max-agelegalább 31536000 másodperc (1 év) legyen. - A
includeSubDomainsaz irányelvet meg kell határozni. - A
preloadaz irányelvet meg kell határozni.
- A
- Ha további átirányítást szolgáltat a HTTPS-webhelyről, akkor ezt az átirányítást is meg kell tennie Is rendelkezzen megfelelő HSTS fejléccel (mint az oldalnak is, amelyre átirányítja).
Itt található egy példa egy érvényes HSTS fejlécre.
Szigorú szállítás-biztonság: maximális életkor = 63072000; includeSubDomains; előtöltés
Tesztelheti webhelyének alkalmasságát az előtöltési lista webhelyének felkeresésével, és beírhatja a domainjét a beviteli mezőbe. Az ott található webalkalmazás rámutat arra, milyen problémákat (ha vannak) meg kell javítani.
Sajnos a modern webhelyek összetettsége nem teszi lehetővé, hogy mindenki számára egységes kiszolgálókonfigurációt hozzanak létre a HSTS előtöltése érdekében, amelyet e cikk tartalmaz. Előfordulhat, hogy futásidejű problémák vannak a gyártótól származó egyéb vagy más egyedi komponensekkel, amelyeket külön kell megoldani.
Bár a Chromium projekt néhány telepítési ajánlást tartalmazott az előtöltő webhelyen, örömmel segítünk ügyfeleinknek kommunikációs biztonságának javításában. Csak küldjön nekünk egy e-mailt a support@ssl.com és egy szakértő szívesen megvitatja a biztonsági igényeinek legmegfelelőbb útját.
Következtetés
A HTTPS lesz az alapértelmezett webes kommunikációs protokoll, és annak teljes elkötelezettsége csak pozitív hatással lehet a webhelyek tulajdonosaira és a látogatókra. Javasoljuk, hogy távolítson el minden kevert tartalmat a webhelyeiről, hogy elkerülje a felesleges problémákat (és a boldogtalan felhasználókat).
Mint mindig, köszönöm a választást SSL.com, ahol úgy gondoljuk, hogy a biztonságosabb internet jobb internet.
