Inleiding
In de afgelopen jaren hebben we gezien dat het web en het assortiment industrieën die het aansturen (zoals browsers, zoekmachines, enz.) Gebruikersbeveiliging serieuzer gaan nemen. Chrome is nu gebruikers waarschuwen tegen HTTP-websites met meer browsers klaar om te volgen, terwijl Google Zoeken heeft bevestigd dat ze de ranking van zoekmachines een boost geven HTTPS websites.
Dergelijke ontwikkelingen hebben een aanzienlijk deel van de website-eigenaren gemotiveerd om hun servers te verplaatsen van oude, onveilige HTTP naar het veiligere alternatieve HTTPS. (HTTPS wordt als veiliger beschouwd omdat het vereist dat servers worden geverifieerd via SSL-certificaten als een middel om gebruikers te beschermen tegen de meeste soorten netwerkaanvallen.)
De meeste websites hebben echter alleen HTTPS geïmplementeerd voor hun meest kritieke componenten, zoals inloggen of POST-verzoeken, maar kunnen nog steeds HTTP gebruiken voor andere 'niet-kritieke' functies.
Dit was logisch in de begindagen van HTTPS, omdat gecodeerde verbindingen rekenkundig duurder zijn omdat ze moeten presteren handdrukken voor elke nieuwe verbinding. Bovendien waren in die tijd veel veelgebruikte webontwikkelingsplatforms, bibliotheken en omgevingen niet HTTPS-ready - een feit dat beheerders en ontwikkelaars eindeloze kopzorgen bezorgde in de vorm van laat op de avond crashes van applicaties of obscure run-time fouten.
Dit is natuurlijk niet meer waar - in feite, zoals dit artikel zal beweren, niet HTTPS gebruiken voor allen de verbindingen van uw website zijn eigenlijk slecht voor uw bedrijf.
Gemengde inhoud
Websites die niet al hun inhoud via HTTPS aanbieden, worden genoemd gemengde inhoud websites. Een academicus papier gepubliceerd in 2015 bleek dat meer dan 43% van hun steekproef van Alexa's top 100,000 ten minste één type gemengde inhoud diende.
Hoewel dit niet als een groot probleem klinkt, kan gemengde inhoud behoorlijk gevaarlijk zijn voor gebruikers, maar het kan ook negatieve effecten hebben op websites.
Veiligheidsvraagstukken
De belangrijkste reden om HTTPS voor uw hele website te gebruiken, is beveiliging. Een enkele onbeschermde HTTP-verbinding is alles wat hackers nodig hebben. Man-in-the-middle (MITM) -aanvallers kan alle HTTP-inhoud op uw pagina vervangen om inloggegevens en sessies te stelen, gevoelige gegevens te verzamelen of browser-exploits te starten en malware op de computers van uw bezoekers te installeren.
Gecompromitteerd raken door uw website zal uw gebruikers natuurlijk wantrouwen en in de toekomst vermijden, waardoor uw online reputatie effectief wordt geschaad.
Zowel Firefox als Chrome heb gestart om gemengde inhoud standaard te blokkeren, zodat gebruikers handmatig kunnen kiezen om inhoud via HTTP te laden. Niettemin, aangezien gemengde inhoud een beveiligingsrisico is, tonen beide browsers een waarschuwing voor gemengde inhoud aan gebruikers, wat ook een negatieve invloed kan hebben op de reputatie van uw website.
Prestatieproblemen
Naast beveiliging, de steeds toenemende adoptie van HTTP / 2 door de industrie heeft tal van prestatie- en beveiligingsupgrades op het web gebracht.
Hoewel de prestatieverhoging contra-intuïtief lijkt sinds HTTP / 2 werkt alleen via versleutelde HTTPS-verbindingen stelt het protocol browsers in staat om voor al hun communicatie één versleutelde verbinding met een HTTPS-webserver te gebruiken.
Door dezelfde verbinding opnieuw te gebruiken, wordt de overhead opgeheven door herhaaldelijk nieuwe te maken (dwz die handdruk opnieuw). Dit betekent dat het springen van versleutelde HTTPS-verbindingen naar niet-versleutelde HTTP op een site met gemengde inhoud in feite langzamer en veeleisender is dan het bezoeken van een volledig beveiligde site met een enkele HTTPS-verbinding.
HTTP / 2 implementeert ook de 0-RTT
sessie hervattingsmodus, waardoor browsers een onderbroken sessie kunnen hervatten met een HTTPS-website die ze eerder hebben bezocht, met slechts één verzoek (in plaats van een volledige handdruk). Dit maakt HTTP / 2-hervatting minstens zo snel als een niet-versleutelde HTTP-verbinding, terwijl het toch alle voordelen van HTTPS biedt. Het aanbieden van gemengde inhoud betekent dat uw website niet volledig kan profiteren van deze of een van de andere geweldige functies van HTTP / 2.
In beide gevallen verbetert HTTP / 2 de snelheid van de verbinding van uw bezoeker met uw site - en snelheid is belangrijk. ONDERZOEK hebben in de loop der jaren aangetoond dat reactievermogen en laadsnelheid van de pagina essentiële ontwerpvereisten voor de gebruikersinterface zijn. Hoe langzamer de reactietijd van een website is, hoe kleiner de kans dat gebruikers betrokken blijven en de betrokkenheid van gebruikers heeft een directe invloed op de gebruikerservaring van uw website (en bijgevolg op uw conversieratio's).
Gemengde inhoud kan ook van invloed zijn op de prestaties op het niveau van de onderliggende webtechnologieën die op uw website worden gebruikt. Browsers nu JavaScript-functies beperken zoals Servicemedewerkers en pushmeldingen om alleen contexten te beveiligen, omdat ze anders zouden kunnen worden misbruikt door hackers voor kwaadaardige doeleinden. Dit betekent wederom dat uw website geen gebruik kan maken van een van deze technologieën bij het weergeven van gemengde inhoud.
SEO-problemen
Zoekmachine optimalisatie (SEO) is het brood en de boter van online zakelijke marketeers. SEO verwijst naar de praktijk van het verbeteren van de ranking van een website in een zoekmachine resultatenpagina (SERP), die rechtstreeks van invloed is op het volume van het websiteverkeer.
Google heeft bevestigd dat hun algoritme voor het rangschikken van zoekresultaten een kleine rangschikking geeft aan websites die via HTTPS worden bediend. Omdat de boost realtime en per URL is, zal het bedienen van een website in zijn geheel via HTTPS resulteren in een SEO-boost voor de hele website (in plaats van alleen die URL's die via HTTPS worden bediend). Toegegeven, deze ranking-signaalboost is vrij licht in vergelijking met andere, zoals kwaliteitsinhoud of gebruikersverkeer, maar het beloont nog steeds uw investering in het verwijderen van gemengde inhoud.
Google heeft ook recentelijk aangekondigd dat de laadsnelheid van de pagina en de algemene prestaties van de website in overweging worden genomen bij het bepalen van de ranking. Dit betekent dat de prestatie-optimalisaties van HTTP / 2 en het verwijderen van gemengde inhoud kunnen samenwerken om de zichtbaarheid van uw website op internet te vergroten.
Als u ten slotte optimaal gebruik wilt maken van SSL in de SEO van uw website, kunt u overwegen EV-certificaten van SSL.com, die uw bezoekers de hoogste zekerheid bieden via beveiligingsindicatoren (zoals die groene balk in de browser) om ze veilig te houden en betrokken te houden bij uw inhoud - en langere bezoeken staan gelijk aan een hogere ranglijst.
Browser Mixed-Content-waarschuwingen
Bezoekers van sites die worden beschermd door SSL verwachten (en verdienen) naadloze bescherming. Wanneer een site niet alle inhoud volledig beschermt, geeft een browser een waarschuwing "gemengde inhoud" weer. Wanneer uw klanten deze waarschuwing zien, kunnen ze op twee manieren reageren. Als zij niet neem de beveiliging serieus, ze zullen het negeren, doorklikken en aannemen dat alles in orde is (erg slecht). Als zij do neem beveiliging serieus, ze zullen er aandacht aan schenken, terug naar uw site en gaan ervan uit dat helpen neem beveiliging niet serieus (erger nog).
Bovendien blokkeren alle moderne browsers de meer kwaadaardige soorten gemengde inhoud - en daardoor kan uw site kapot gaan.
De beste oplossing is natuurlijk om ervoor te zorgen dat deze waarschuwingen en / of blokkades in de eerste plaats niet voorkomen door uw site correct te configureren om alleen beveiligde inhoud weer te geven.
Waarom zie ik deze waarschuwing?
Een waarschuwing voor gemengde inhoud betekent dat zowel beveiligde als onbeveiligde elementen worden weergegeven op een pagina die volledig moet worden versleuteld. Elke pagina die een HTTPS-adres gebruikt, moet alle inhoud hebben die afkomstig is van een beveiligde bron. Elke pagina die naar een HTTP-bron linkt, wordt als onveilig beschouwd en wordt door uw browser gemarkeerd als een beveiligingsrisico.
Waarschuwingen voor gemengde inhoud vallen in twee categorieën: gemengde passieve inhoud en gemengde actieve inhoud.
Gemengde passieve inhoud
Passieve inhoud verwijst naar items die kunnen worden vervangen of gewijzigd, maar die andere delen van de pagina niet kunnen veranderen, bijvoorbeeld een afbeelding of foto. Waarschijnlijk de meest voorkomende oorzaak van alle waarschuwingen voor gemengde inhoud is wanneer een (theoretisch) beveiligde site is geconfigureerd om afbeeldingen van een onbeveiligde bron op te halen.
Passieve HTTP-verzoeken worden via deze tags weergegeven:<audio>
(src
attribuut)<img>
(src
attribuut)<video>
(src
attribuut)<object>
subbronnen (wanneer een <object>
voert HTTP-verzoeken uit)
Gemengde actieve inhoud
Actieve inhoud kan de webpagina zelf wijzigen. Bij een man-in-the-middle-aanval kan een verzoek om HTTP-inhoud op een HTTPS-pagina worden onderschept en / of herschreven. Dit maakt kwaadaardige actieve inhoud erg gevaarlijk - gebruikersreferenties en gevoelige gegevens kunnen worden gestolen of malware kan op het systeem van de gebruiker worden geïnstalleerd. Een stukje JavaScript op een pagina voor het aanmaken van een account, ontworpen om gebruikers te helpen bij het genereren van een willekeurig wachtwoord, kan bijvoorbeeld worden vervangen door code die in plaats daarvan een willekeurig lijkt, maar vooraf gegenereerd, of om in het geheim een anderszins veilig wachtwoord aan een derde partij te bezorgen. .
Actieve gemengde inhoud kan worden misbruikt om gevoelige privégegevens in gevaar te brengen, maar zelfs publiek gerichte webpagina's die onschuldig lijken, kunnen bezoekers nog steeds omleiden naar gevaarlijke sites, ongewenste inhoud leveren of cookies stelen voor misbruik.
<script>
(src
attribuut)<link>
(href
attribuut) (dit omvat CSS-stylesheets)XMLHttpRequest
object verzoeken<iframe>
(src
attributen)Alle gevallen in CSS waar een url-waarde wordt gebruikt (
@font-face
, cursor
, background-image
Enz.).<object>
(data
attribuut)Alle moderne browsers blokkeren standaard actieve gemengde inhoud (wat een onjuist geconfigureerde site kan breken)
Waarom en hoe u waarschuwingen voor gemengde inhoud kunt oplossen
Door uw website te beveiligen, kunnen uw bezoekers u vertrouwen, wat van vitaal belang is. Het verwijderen van alle onveilige inhoud van uw site heeft echter een nog grotere bonus door het elimineren van vals-positieve waarschuwingen - als uw correct geconfigureerde site wordt aangetast, zal elk onveilig element dat een aanvaller invoegt, de waarschuwing voor gemengde inhoud activeren, waardoor u een extra struikelblok krijgt om te detecteren en deze problemen aanpakken.
Nogmaals, de beste manier om problemen met gemengde inhoud te voorkomen, is door alle inhoud via HTTPS weer te geven in plaats van HTTP.
Serveer voor uw eigen domein alle inhoud als HTTPS en repareer uw links. Vaak bestaat de HTTPS-versie van de inhoud al en hiervoor hoeft u alleen een 's' aan links toe te voegen - http://
naar https://
.
Gebruik voor andere domeinen de HTTPS-versie van de site, indien beschikbaar. Als HTTPS niet beschikbaar is, kunt u proberen contact op te nemen met het domein en hen te vragen of ze de inhoud beschikbaar kunnen maken via HTTPS.
Als alternatief laat het gebruik van "relatieve URL's" de browser automatisch HTTP of HTTPS kiezen, afhankelijk van het protocol dat de gebruiker gebruikt. Bijvoorbeeld, in plaats van te linken naar een afbeelding met behulp van een link met het 'absolute pad' van:
De site kan een relatief pad gebruiken:
Hierdoor kan de browser automatisch een van beide toevoegen http:
or https:
naar het begin van de URL indien nodig. (Merk op dat de site waarnaar wordt gelinkt de bron moet aanbieden via zowel HTTP als HTTPS om relatieve URL's te laten werken.)
Chrome
Firefox
internet Explorer
Uitstekende tools om niet-SSL-links in uw broncode op te sporen, zijn de ontwikkelaarstools die zijn ingebouwd in de Firefox en Chrome browsers. Informatie over het dwingen van een Apache-server om alleen HTTPS te verwerken kan zijn: hier gevonden.
Het eerste verzoekprobleem
We hopen dat tot nu toe dit artikel enkele goede argumenten heeft aangevoerd tegen gemengde inhoud, hoewel er, zelfs als u besluit uw website volledig naar HTTPS te migreren, er nog enkele verbeteringen zijn die u kunt aanbrengen.
Wanneer gebruikers de URL van uw website in een browser typen, typen ze doorgaans nooit de protocolnaam (dwz https://
). Uiteraard weet de browser niet onder welk protocol uw website wordt aangeboden en staat standaard op HTTP.
Als uw website correct is geconfigureerd, wordt de browser (via HTTP 301/302-antwoorden) omgeleid naar zijn HTTPS-instantie; hoewel dit betekent dat browsers bij het eerste bezoek aan uw website twee verzoeken moeten uitvoeren in plaats van één HTTPS-verzoek.
Dit kan problematisch zijn omdat gebruikers de vertraging kunnen waarnemen, waardoor ze een slechte eerste indruk van de site krijgen. Als zodanig zullen ze minder snel blijven hangen, wat uiteindelijk kan leiden tot minder bezoekersverkeer.
Bovendien kunnen hackers dat eerste HTTP-verzoek onderscheppen om het te lezen of te wijzigen voordat ze de server bereiken. In dit soort gevallen komt het vaak voor dat een netwerkaanval wordt uitgevoerd SSL-strippen waarmee de aanvaller een HTTPS-verbinding kan vervangen door een onbeschermde HTTP-verbinding.
HTTP Strict Transport Security schiet te hulp
HTTP Strict Transport Security or HSTS is een poging om dit probleem op te lossen. HSTS is geïmplementeerd door de Internet Engineering Task Force (IETF) in RFC 6797 en is een HTTPS-header die webservers kunnen opnemen in hun antwoorden. Deze koptekst instrueert compatibele browsers om altijd HTTPS te gebruiken wanneer ze een website bezoeken. HSTS is van toepassing op alle verzoeken, inclusief afbeeldingen, CSS-stylesheets en andere webbronnen.
Zoals je je misschien kunt voorstellen, moet de browser eerst zien de HSTS-header om deze te eren, wat betekent dat HSTS erop vertrouwt dat de aanvallers dat eerste HTTP-verzoek niet kunnen onderscheppen. Als gevolg hiervan is HSTS op zichzelf geen complete oplossing, maar eerder een eenvoudige oplossing voor SSL-stripping.
Vooraf laden van HSTS
Gelukkig heeft het Chromium-project een oplossing bedacht die ze hebben genoemd Vooraf laden van HSTS, dat bestaat uit het bijhouden van een openbare lijst met websites die HSTS-preloading-functionaliteit hebben aangevraagd. Bij het bezoeken van een website zullen Chromium-browsers de lijst raadplegen en als de site daar wordt gevonden, zullen ze ermee doorgaan te communiceren via HTTPS (inclusief dat eerste verzoek), ongeacht eerdere geschiedenis of invoer van gebruikers.
Als gevolg hiervan kan vooraf laden zowel de prestaties als de beveiliging van uw website verbeteren door het initiële HTTP-verzoek te verwijderen. Bovendien kan het de SERP-ranking en gebruikerservaring van uw site indirect verbeteren.
Alle grote browsers (Google's Chrome, Microsoft's IE / Edge, Apple's Safari, Mozilla's Firefox en Opera) raadplegen ook de HSTS-preloadlijst van Chromium, wat betekent dat deelname aan deze lijst de preload-voordelen biedt aan uw bezoekers, ongeacht welke browser ze gebruiken.
We zouden echter nalatig zijn als we niet zouden vermelden dat er bezorgdheid bestaat over de schaalbaarheid van de HSTS-preload-lijstoplossing - Het kan niet alle websites op internet bevatten vanwege beperkingen in de praktische omvang en rekenkundige complexiteit, en bijgevolg kan toegang steeds moeilijker worden naarmate de tijd verstrijkt en HSTS-preloading breder wordt toegepast.
Hoe kan ik meedoen?
Als u geïnteresseerd bent om lid te worden van de HSTS-preloadlijst, houd er dan rekening mee dat uw website bepaalde regels moet volgen. Het Chromium-project heeft de lijst met inzendingsvereisten gepubliceerd voor websites die willen deelnemen aan de website van hun project. De vereisten zijn letterlijk opgenomen in de volgende lijst, maar u kunt meer details vinden in HSTS RFC 6797.
Om te worden geaccepteerd in de HSTS-preloadlijst, moet uw website:
- Dien een geldig certificaat.
- Redirect van HTTP naar HTTPS op dezelfde host, als je luistert op poort 80.
- Serveer alle subdomeinen via HTTPS. U moet met name HTTPS ondersteunen voor de
www
subdomein als er een DNS-record voor dat subdomein bestaat. - Serveer een RFC 6797-compatibele HSTS-header op het basisdomein voor HTTPS-verzoeken:
- De
max-age
moet minimaal 31536000 seconden zijn (1 jaar). - De
includeSubDomains
richtlijn moet worden gespecificeerd. - De
preload
richtlijn moet worden gespecificeerd.
- De
- Als u een extra omleiding vanaf uw HTTPS-site aanbiedt, moet die omleiding ook een compatibele HSTS-header hebben (net als de pagina waarnaar deze wordt omgeleid).
Hier is een voorbeeld van een geldige HSTS-header.
Strikte transportbeveiliging: max. Leeftijd = 63072000; includeSubDomains; voorladen
U kunt testen of uw website in aanmerking komt door naar de preloadlijst-website te gaan en uw domein in het invoervak in te voeren. De webtoepassing daar zal aangeven welke problemen (indien aanwezig) u moet oplossen.
Helaas maakt de complexiteit van moderne websites het niet mogelijk om een serverconfiguratie op maat te maken voor het vooraf laden van HSTS om in dit artikel op te nemen. Er kunnen runtime-problemen zijn met externe of andere aangepaste componenten die afzonderlijk moeten worden opgelost.
Hoewel het Chromium-project enkele implementatieaanbevelingen op de preload-website heeft opgenomen, helpen we onze klanten altijd graag hun communicatiebeveiliging te verbeteren. Stuur ons een e-mail op ondersteuning@ssl.com en een expert bespreekt graag het beste pad voor uw beveiligingsbehoeften.
Conclusie
HTTPS wordt het standaardprotocol voor webcommunicatie en als u zich er volledig aan committeert, kan dit alleen positieve gevolgen hebben voor site-eigenaren en bezoekers. We raden aan om gemengde inhoud van uw websites te verwijderen om onnodige problemen (en ontevreden gebruikers) te voorkomen.
Zoals altijd bedankt voor het kiezen SSL.com, waar wij geloven dat een veiliger internet een beter internet is.