Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 67 reacties

Google gaat sites waar een https-versie van is, als standaard indexeren. Dit houdt in dat Googles zoekalgoritmes zo aangepast worden dat er meer gezocht wordt naar https-pagina's. Ruim een jaar geleden startte Google al met het hoger in de zoekresultaten plaatsen van https-sites.

https sslDe zoekmachine zal eerst proberen of er ook een variant van een webpagina is die gebruikmaakt van http over tls ofwel https. Dit gaat de machine ook doen als er geen directe link tussen beiden is, staat op het webmaster-blog. Als twee url's van hetzelfde domein dezelfde inhoud hebben, maar via verschillende protocollen verzonden worden, zal gekozen worden de pagina te indexeren als https.

Toch zal niet elke beveiligde pagina standaard geïndexeerd worden. Pagina's moeten daarvoor aan een aantal voorwaarden voldoen. Zo mogen er geen onveilige afhankelijkheden in de pagina zitten, mag de pagina niet geblokkeerd worden in de robots.txt, mag de pagina gebruikers niet via een onveilige verbinding doorsturen, mag de rel="canonical"-tag niet linken naar een http-pagina, mag er geen noindex-tag instaan, mogen er geen links op dezelfde host naar een http-pagina zijn en moet de server uiteraard voorzien zijn van een geldig tls-certificaat.

Op deze manier hoopt Google internetgebruikers veiliger te laten surfen en minder bloot te stellen aan mogelijke aanvallen via een content injection of man-in-the-middle-aanvallen. Verder raadt het bedrijf aan om de hsts-header te gebruiken op servers, zodat gebruikers standaard naar een https-verbinding worden doorgestuurd.

Moderatie-faq Wijzig weergave

Reacties (67)

Die push naar HTTPS is best netjes, maar ik vraag me af of het niet een beetje doorgetrokken wordt. Wat is het nut van https op een publieke website bijvoorbeeld?
Een eigen blogje beginnen bijvoorbeeld brengt dan zo toch weer additionele kosten met zich mee terwijl je je sterk kan afvragen waarom dat over HTTPS moet.

Edit: Ik ben bekend met gratis SSL certificaat opties maar dat is momenteel alleen leuk voor mensen die een eigen server draaien. Als je gewoon een hostingpakketje neemt en daar SSL op wil kost dat voorlopig gewoon geld.

[Reactie gewijzigd door Alpha Bootis op 17 december 2015 18:23]

Wat is het nut van https op een publieke website bijvoorbeeld?
Het probleem dat we hebben is dat iemand moet beoordelen of er https nodig is of niet. Zoals altijd in de IT gaat dat nogal vaak fout. Zelfs als er in eerste instantie een goede inschatting wordt gemaakt dan kan een website later nog veranderen waardoor https wel nodig wordt. Het is maar de vraag of de beheerder dat op tijd door heeft.
Door altijd https te gebruiken hoef je er niet meer over na te denken en kan het ook niet fout gaan.

Daarnaast zijn er ook een hoop publieke websites die toch privacygevoelig zijn in een bepaalde context. Het gaat niemand iets aan of ik de website van een moskee of synagoge bezoek, of ik op wikipedia over geslachtsziektes lees, of ik lingerie maatje XXXL bestel of dat dat ik de vactures van de concurrent bekijk.

De kosten voor https worden steeds lager, er zijn verschillende plekken waar je gratis SSL-certificaten kan krijgen. Computers zijn zo snel geworden in encryptie dat het voor de meeste websites niks uit maakt.

Van de andere kant worden de risco's van datalekken steeds groter. Een kleine investering in https verlaagt de kans op een kostbaar incident een aanzienlijk.
Daarbij; wil je HTTP/2 gebruiken dan zul je https MOETEN gebruiken, aangezien dat de enige manier is waarop HTTP/2 door moderne browsers wordt ondersteund. Met daarbij alle performance en latency voordelen die dit met zich meebrengt welke oorspronkelijk door Google zijn ontwikkeld in de vorm van SPDY. Denk hierbij aan multiplexing en pipelining, waardoor de pagina laadtijd verkort wordt.
Voor bedrijven en grote sites vind ik een SSL certificaat ook een nobrainer voor exact de redenen die je benoemd maar als Harry Doorsnee een website wil beginnen over modeltreinen lijkt het me een beetje overkill momenteel.
Google benadeeld zo'n site als ik het goed lees dan echter wel op basis van het ontbreken van https.
We zijn goed onderweg om HTTPS een no-cost optie te maken maar dat is nog verre van overal en altijd het geval en ik vraag me dus op die basis af of ze niet een beetje aan het rennen zijn voordat het startschot gegeven is.
als Harry Doorsnee een website wil beginnen over modeltreinen lijkt het me een beetje overkill momenteel.
We moeten toe naar een situatie dat Harry daar niet over hoeft na te denken om dat z'n hoster het al heeft geregeld.
Google benadeeld zo'n site als ik het goed lees dan echter wel op basis van het ontbreken van https.
We zijn goed onderweg om HTTPS een no-cost optie te maken maar dat is nog verre van overal en altijd het geval en ik vraag me dus op die basis af of ze niet een beetje aan het rennen zijn voordat het startschot gegeven is.
Een klein beetje maar. Als er twee gelijkwaardige sites zijn en eentje heeft wel https en de andere niet dan komt die met https boven die zonder te staan. De site zonder https blijft echter gewoon vindbaar, maar 1 positie lager.

Nu hebben ze toegevoegd dat als een website zowel via http als via https bereikbaar is dat je dan automatisch naar https gaat. Het verandert niks aan de zoekresultaten. Als jouw pagina op de eerste plek stond dan blijft dat zo, maar als je die pagina zowel http als https aanbiedt dan zal Google voortaan de versie met https gebruiken.
Google toont bij het zoeken nog steeds de sites die hun algoritme relevant vindt bij de zoekende persoon en zijn zoekopdracht.

Als iemand op modeltreintjes zoekt en niets wil kopen is de kans wellicht groot dat alle relevante sites zulke blogs zijn, waardoor Harry niet benadeeld wordt.

Maar bekijk het eens met de bril van Google: ze weten nu met hoe weinig data je een redelijke indruk kunt hebben van de voorkeuren en het gedrag van een persoon. Daardoor zijn ze extra alert geraakt dat anderen dat ook kunnen. Ze zien overheden en commerciële partijen ongevraagd profielen van burgers verzamelen. Dat is concurentie niet goed voor hun privacy, dus helpen ze de burgers die in zulke situaties zitten door mima te minimaliseren.

Bedenk eens wat hotjar, clicktale etc allemaal van mensen weten, naast double click (google), linkedin (pixels, bel gedrag, ...), facebook, ...
Als ik het verhaal goed begrijp, kom je nu eerst allerlei webshops tegen die https ondersteunen.
Welke sites je bezoekt kun je wel zien, ondanks dat je HTTPS gebruikt. Alleen wat je vervolgens op die site bekijkt is niet te zien. Vooral nu met LetsEncrypt hoeft geld niet meer de bottleneck te zijn. Het probleem ligt meer bij het beheren/deployen van de certificaten. Ook voor sommige low-end apparatuur (embedded devices) is SSL vaak nog wat teveel gevraagd.
Het voordeel van Let's Encrypt is ook vooral dat je geen persoonlijke informatie in het certificaat moet zetten. Vooral voor sommige bloggers (die liever anoniem blijven) is dat een groot voordeel. Ken eigenlijk geen CA die mij niet gelijk om mijn naam en adresgegevens vraagt.
Waarom? Je kunt met enige moeite gratis certificaten ontvangen. Op moment zijn er startssl.com en letsencrypt.com. Let's Encrypt en haar community ontwikkelen tools, zodat je zonder veel moeite een certificaat ontvangt.
Kon al een tijdje bij https://www.startssl.com

Echter is het niet altijd evenmakkelijk te doen (afhankelijk van je hosting provider)
Startssl is een puinzooi, maak je een account aan en probeer je in te loggen wordt je constant naar een random pagina verwezen. Kom je uiteindelijk op de inlog pagina, die met HTTPS is beveiligd, krijg je een SSL error. https://twitter.com/TerryNacht/status/653963302679281664.

Daarna via CACERT geprobeert, maar die lopen helaas ook achter de feiten aan, laatste bericht dat ik hoorde was dat het in februari gefixed moest zijn. https://twitter.com/TerryNacht/status/653967116912173057

Ik hoop van harte dat Let's Encrypt z'n zaakjes wel goed in orde heeft, want in de gratis CA's die er nu zijn heb ik eerlijk gezegd nul vertrouwen.
Je hebt wel zelf je eigen SSL cert in je eigen browser geïnstalleerd (die je gekregen hebt bij het aanmaken van je StartSSL account)? Aan de foutmelding die je krijgt lijkt het er namelijk niet op.
@gerwim heeft gelijk, je hebt het certificaat dat word gebruikt om je aan te melden bij het control panel niet geinstalleerd...
Ze hebben mij nergens een certificaat aangeboden en meer dan 'registreer en krijg een authenticatie certificaat' staat er ook niet op hun helppagina. Dat ze je doorsturen naar een random pagina als je op het dashboard knopje drukt helpt ook niet. Mogelijk werkt het certificaat dan, maar door alle wazigheid heb ik nog steeds 0 vertrouwen ;)
Het wordt toch echt duidelijk uitgelegd... Kwestie van gewoon snel snel snel en niet goed kijken denk ik dan?, immers @gerwin en mijzelf wisten dat ook.

Random pagina is natuurlijk onzin ze sturen je altijd naar dezelfde oftewel https://auth.startssl.com/

Ik gebruik startsll al een paar jaar en er is nooit iets mis geweest, uitstekende gratis service.

Om nu meteen te gaan roepen het is een puinzooi wazig en wat niet, omdat jij het niet begrijpt, is dan erg flauw
De link naar het dashboard eindigt met ?app=11. Als ik daar op drukte werd ik, 'i kid you not', doorgelinkt naar een ?app=randomnummer. Ik ben er dik een uur mee bezig geweest en heb nooit dat certificaat gezien.
Maar zo te zien is er na dit weekend een nieuwe website, dus dan zal ik het nog eens proberen.
Die kosten zijn tegenwoordig geen issue meer:
https://letsencrypt.org/
Dat is een mooi initiatief maar ook nog redelijk betá weet ik uit praktische ervaring. (lees: werkt nog niet op mijn server/apache installatie)
Ook moet je een eigen server hebben om die certificaten op te installeren.
Nochtans is SSL een dienst die geld kost bij de meeste websiteboeren. Wellicht dat dit afsterft maar daar zijn we nog nét niet...

[Reactie gewijzigd door Alpha Bootis op 17 december 2015 18:26]

Dat wil je, en ik noem alleen even de gevallen waar men niet zo vaak aan denkt, omdat:
- China een keer evil javascript heeft geinjecteerd in verkeer van de baidu zoekmachine om zo github te ddossen:
https://thehackernews.com...-ddos-attack-from_27.html
- Free Wifi en ISP's injecteren ads in HTTP pagina's:
http://bits.blogs.nytimes...tyard-marriott-wifi/?_r=0
- Hoe denk je dat overheden binnen dringen op PC's van "verdachten"? 1 HTTP request en boem overheid voegt script toe dat 0-day uitvoert klaar.
- Veel website toch iets hebben waarvan ze niet dachten dat het belangrijk was. Contact fomulier, login over HTTPS maar daarna sessie cookie over HTTP, Laatst nog een website aangeschreven die een volledige medische anamnese afnam en dacht dat dit alleen clientside werd verwerkt met cookies. Dit bleek niet zo te zijn en alle data ging onversleuteld hen en weer naar de server :X

HTTP is evil. HTTPS wtf!
HTTPS wtf?
HTTPS ftw! (klein verschil ;) )

[Reactie gewijzigd door Tjark op 18 december 2015 11:15]

Bijvoorbeeld CloudFlare Free biedt gratis HTTPS aan, zo hoef je zelf geen certificaat aan te schaffen.
Uiteindelijk zal toch gewoon elke hosting bedrijf gewoon https aangeven? Lijkt mij dat dat dan de norm moet worden.
De meerwaarde bestaat er in dat niemand kan nagaan welke informatie je opvraagt. Stel ik surf morgen naar een gay porno site en er zit iemand tussen op die connectie dan kan die persoon nagaan dat ik die site bezocht heb (kans dat het gebeurd is klein, maar niet onbestaande). Met https kan men hoogstens het IP adres van die site te weten komen (al blijft de DNS vraag natuurlijk wel nog altijd onversleuteld over het net gaan).

Of neem nu het feit dat steeds meer overheden beginnen vragen aan ISPs om metadata op te slaan. Herinner je je die wetgeving van in Groot Brittanië nog? Met https kan een ISP zelfs die metadata niet meer opslaan omdat ook je headers encrypted zijn.

Wat is vandaag de reden om het niet te doen? De http/2 standaard bijvoorbeeld word op de meeste browsers enkel ondersteund als je gebruik maakt van https.
De dns qeury is nog wel open en bloot te zien ( no pun intended) echter zijn de invoervelden etc beveiligd/ niet plain text
Met de komst van http/2 is de move naar https nog veel belangrijker geworden.

Zelf heb ik enkele 'simpele' sites die inmiddels allemaal over zijn op TLS. Vooral om het 'why not', ook om wat performance van http/2 mee te pakken.
Met de ixquick browser kun je alle sites via ''Proxy'' met https openen
https://www.ixquick.com/

[Reactie gewijzigd door 8mile13 op 17 december 2015 19:01]

Je zet een beveiligde verbinding met ixquick op, daarna houdt het op. Je kan geen https verbinding maken met een server die geen SSL ondersteund.
Op deze manier hoopt Google internetgebruikers veiliger te laten surfen en minder bloot te stellen aan mogelijke aanvallen via een sql-injectie of man-in-the-middle-aanvallen. Verder raadt het bedrijf aan om de hsts-header te gebruiken op servers, zodat gebruikers standaard naar een https-verbinding worden doorgestuurd.
Wat heeft sql injecties te maken met het https protocol :s

Vind het alleen jammer dat SSL certs nog relatief duur zijn tenopzichte van domeinnamen.

De single site ssl certs zijn dan misschien wel gratis op moment maar de wildcard en extended validation zijn gewoon enorm duur...

Gratis SSL certs:Uitleg verschillende types SSL certs:

[Reactie gewijzigd door xleeuwx op 17 december 2015 18:35]

Ik heb de auteur er even op gewezen. Hij had 'content injection' geinterpreteerd als sql-injectie. Met content injection bedoelt Google, neem ik aan, zaken als van die providers die proxies plaatsten die advertenties toevoegden aan sites.
Dat zou inderdaad kunnen en klinkt logischer, daarintegen is het symptoombestrijding want je lost het er niet mee op je maakt het wat moeilijker. Zeker nu vandaag de dag de certificaten (single site) gratis zijn
Nu moet je een SSL-proxy toevoegen ipv een reguliere proxy. Dat is inderdaad niet onmogelijk en valt nauwelijks op, tenzij iemand echt goed naar het certificaat kijkt (bijv via die groene balkjes).

[Reactie gewijzigd door ACM op 17 december 2015 18:25]

Een SSL-proxy valt nauwelijks op als je controlle hebt over de PC die tegen de proxy praat. Je moet namelijk je eigen CA certificaat op die PC krijgen anders krijg je certificaat foutmeldingen. Als een aanvaller controlle heeft over je PC is MITM het laast om je zorgen over te maken :) .
Er is geen in browsers aanwezige CA meer die certificaten uitdeelt die dit in een proxy voor je kunnen doen, dus geen controlle over de PC is geen mogelijkheid tot HTTPS MITM (als goed ingericht met HSTS en HPKP).
Een CA hoort ideaal gezien alleen certificaten uit te geven aan de eigenaar van het domain maar helaas blijkt het in de praktijk toch nog wel eens te gebeuren dat er certificaten onterecht aan derden worden verstrekt. Die certificaten kunnen vervolgens gebruikt worden om een proxy te draaien/MITM aanval uit te voeren.

Als een aanvaller controle over je PC heeft kan je er sowieso wel van uit gaan dat alles verloren is, dan heb je ook geen proxy meer nodig. Ieder encryptie scenario valt of staat met het bestaan van een Alice/Bob en een Eve die geen toegang heeft tot hun data/systemen. Op het moment dat er geen Alice en Bob te onderscheiden zijn of op het moment dat één van beide gecorrumpeerd is door Eve heeft encryptie geen enkel nut meer.
Dat is inderdaad iets meer werk maar voor de doelgroep die dit soort dingen (mis)gebruiken is het gewoon een stap extra in het proces
Houd er wel rekening mee dat er wel degelijk enorme verschillen zitten in certificaten en je je moet afvragen of je een SSL aanschaft omdat Google het zo graag wil en je klanten het graag willen zien of dat je echt voor de veiligheid van persoonsgegevens een SSL aanschaft.

De gratis certificaten zijn er voornamelijk voor om te laten zien dat je een SSL hebt. Het aantal bit van de encrypty is bij startSSL namelijk enorm laag. Bij letsencrypt is dat wel goed (2048/4096)

Verder zit je met de verzekerde waarde, ook niet geheel onbelangrijk.

De garantie is het bedrag wat maximaal aan een eindgebruiker wordt uitgekeerd wanneer het SSL certificaat wordt uitgegeven aan een onbevoegde partij, waarbij de eindgebruiker geld is kwijt geraakt. De exacte voorwaarden voor het uitkeren van dit bedrag verschillen per leverancier.

De garantie wordt ook wel verzekerde waarde genoemd en verschilt per merk, type en validatieniveau van het certificaat.

Zelf heb ik mijn SSL bij Versio aangeschaft. Deze bieden zeer goede concurrerende prijzen voor SSL certificaten van bekende uitgevers welke tevens garantie bieden.

Uiteraard kun je voor een persoonlijke site waar geen gegevens van klanten/gebruikers worden verstuurd ook een gratis certificaat gebruiken.
Verzekerde waarde? Je post klinkt meer als reclame. Indien een CA certificaten aan anderen uitgeeft dan hoort die CA niet meer vertrouwd te worden, klaar. Een certificaat kan prima automatisch en d'r is geen reden waarom het niet goedkoop kan.
Verder zit je met de verzekerde waarde, ook niet geheel onbelangrijk.

De garantie is het bedrag wat maximaal aan een eindgebruiker wordt uitgekeerd wanneer het SSL certificaat wordt uitgegeven aan een onbevoegde partij, waarbij de eindgebruiker geld is kwijt geraakt. De exacte voorwaarden voor het uitkeren van dit bedrag verschillen per leverancier.
Vergeet het maar, daar heb je niks aan. Jouw CA heeft geen enkele controle over wat andere CA's doen. Zo'n verzekering helpt alleen als ze zelf een fout maken, tegen een kwaadaardige tegenstander of een zwakke CA helpt het niks. Als ze zelf een fout maken dan heb je geen verzekering nodig om ze aansprakelijk te stellen. Dan moet je wel eerst aantonen dat je schade hebt geleden en voor de gemiddelde website zal behoorlijk moeilijk zijn om aan te tonen dat een verkeerde SSL-certificaat iets te maken heeft met dalende inkomsten.
Naar mijn mening is zo'n verzekering dus oplichterij. Als je je tegen dit soort risico's wil indekken ben je beter af met een echte verzekering.
De single site ssl certs zijn dan misschien wel gratis op moment maar de wildcard en extended validation zijn gewoon enorm duur...
Maar Google maakt geen onderscheid tussen de verschillende vormen, als het maar over TLS gaat. Dat er dus ook duurdere varianten bestaan maakt niet uit, als jij je site hoger bij Google wil krijgen voldoet het simpelste certificaat al.
Nu nog wel maar verwacht dat dit binnen een jaar wel anders is.
Met gratis certs is het toch niet zo'n bezwaar om voor elk subdomein een nieuw certificaat te maken waardoor je geen noodzaak tot een wildcard-certificaat meer hebt? Zo heb ik het opgelost in ieder geval.
Voor de meeste sites gaat dit inderdaad wel op echter werken wij met releases en is dus een subdomein: "https://release-x123.website.nl".

Hierdoor kunnen wij wel van te voren allerlei certs gaan aanvragen maar dat is heel tijdrovend. Daarnaast gebruiken wij dit ook voor projecten die op vrijwillige basis zijn maar dus al van te voren veel kosten met zich mee brengen. Dit staat natuurlijk los van dat die subdomeinen nooit geïndexeerd gaan worden.

Echter is het voor sommige sites wel belangrijk dat automatisch aangemaakte subdomeinen een SSL certificaat heeft en hier niet elke keer een een appart certificaat voor aangevraagd hoeft te worden.
Nu Let's Encrypt publiekelijk is gegaan, is de door jou genoemde situatie juist erg makkelijk op te vangen. Die dienst is zelfs perfect geschikt voor een dergelijke testomgeving.

Heb de afgelopen dagen veel lopen spelen met Let's Encrypt en met één simpele command verkrijg en installeer je letterlijk < 1 minuut een certificaat.
Jammer genoeg wordt het gratis CAcert door bijna geen enkele browser direct geaccepteerd. Ik gebruik het zelf wel voor een eigen site, die ik vooral ook zelf bezoek met clients waar ik de CA cert certificaten zelf op heb gezet.

Maar voor een publieke website is het eigenlijk niet bruikbaar.
Dat vroeg ik me inderdaad ook af!
"onveilige afhankelijkheden", bedoelen ze dan dat als je een wordpress plugin/thema hebt dat een afbeelding/script via http laadt, je dan niet aan de voorwaarden voldoet? (In chrome krijg je dan zo een schildje te zien in de adresbalk).

[Reactie gewijzigd door lampstoelkast op 17 december 2015 18:09]

Dat zal vast gaan over hetgene dat normaliter als 'mixed content' wordt omschreven.
Dat vermoed ik ook, maar zo is het nog een stapje breder volgens mij.
Dat denk ik wel, dat is namelijk 'onveilig'.
Het beste kan je het stukje ''http://' in je code even vervangen door "//".
Die gratis certificaten schijnen niet erg bruikbaar te zijn voor commerciële sites wegens de onmogelijkheid om dat te laten verzekeren heb ik me onlangs laten vertellen.
Ik ben zelf druk doende om een website te bouwen voor mijn op te starten eigen bedrijfje en het werd mij door wat meer ervaren sitebouwers in mijn omgeving afgeraden om gratis ssl certificaten te gebruiken.
Ik vind dat het nogal lastig is om over deze materie duidelijkheid te krijgen.
Onzin. Gratis certificaten werken tot nu toe allemaal met domain validation en zijn even veilig als betalende certificaten (met domain validation). Je kan voor een EV-certificaat gaan (dan staat je bedrijfsnaam in de URL-balk (zoals bijvoorbeeld https://www.rabobank.nl/), maar dat heeft verder weinig meerwaarde.

Wij beheren voor onze klanten een hondertal websites die we gemaakt hebben over de laatste paar jaren, en zijn actief al onze bestaande certificaten aan het omzetten naar de gratis Let's Encrypt-certificaten, en op sites die tot voor kort enkel over HTTP beschikbaar waren schakelen we HTTPS ook al (optioneel) in waar mogelijk, opnieuw met Let's Encrypt.

Dus: gewoon voor Let's Encrypt gaan, of een andere gratis/goedkope CA.
Dank je voor de reactie.
Ik ga gelijk even ev-certificaat googlen _/-\o_
Voor een EV-certificaat kan ik je deze aanbevelen: https://certsimple.com/
Snel, betaalbaar en betrouwbaar.
Let's Encrypt certificaten werken (nog) niet op mijn smartphone (BlackBerry Q10) en dat is vast niet het enige device waarbij dat zo is. Ik blijf er dus vanaf. Zeker in combinatie met de korte levensduur van Let's Encrypt certificaten blijf ik er vanaf. Heel leuk dat ze willen dat ik automatisch certificaten vervang maar dan moet wel elke keer de configuratie van allerhande services (IMAP, SMTP, FTP, HTTP, IRC) aangepast worden. Word ik ook niet heel blij van. StartSSL is veel beter wat dat betreft, en net zo gratis.
Let's Encrypt is sowieso HTTP-only, hun certificaat is niet geschikt voor andere diensten. Het voordeel van Let's Encrypt is gewoon de automatisering. Wij doorlopen nu geen enkele certificate flow nog manueel. Voor ons is SSL aanzetten op een website een flag 'letsencrypt: yes' geworden, en we zijn er. Dat is het coole aan Let's Encrypt. Voor mensen met een BlackBerry is dat jammer, maar dat is zo'n klein aandeel dat dat niet de moeite is voor ons.
Waarom zou dat verzekerd moeten worden, wat verzeker je dan en waarom kan dat niet apart? Begrijp er weinig van.
Goed idee. Zeker met SPDY en HTTP2 zijn sites via SSL ook veel sneller in t laden.
Dat Google de inhoud controleert is wel essentieel. Er zijn best wat sites waar je een s achter http kan zetten, een geldig certificaat hebben, maar waar vervolgens niets of weinig of iets van apache staat..Tja dan ben je als Website eigenaar de klos. Vaak bestaan die https delen dan enkel voor het afrekenen/inloggen/etc.
Het word alleen gedaan als de https versie dezelfde content bevat, echter is het raar dat er geen canonical tag naar http mag wijzen
Zo gek vind ik dat niet. De canonical-tag is voor Google een indicatie waar de 'echte versie' van een pagina staat. Als je vanuit https zegt -> zie http, dan is het ook weer niet erg netjes als Google dat dan negeert.
ah duidelijk, ik dacht dat het meer als "kopie" ipv de "echte" variant bedoeld was :), maar 301 in htacces, of ngix z'n alternatief werkt naar mijn mening veel beter bij een migratie van http naar https, dan is het voor alle browsers bij de eerste keer bezoeken van een link gelijk duidelijk dat de site naar https verhuist is.
Inderdaad en een HTST-header om aan te geven dat je altijd op HTTPS wilt, ook als de bezoeker later geen https voor een url zet tijdens het typen.
Ssl is een ranking factor en zal uiteindelijk net zoveel invloed hebben als alle andere factoren om betere posities te krijgen
Ik snap dit niet, een simpele 301 in apache heeft mij geen verandering in verkeer opgeleverd, en na 5 dagen was alles via google en bing https verkeer, alle oude links worden vanuit forums etc ook goed doorgestuurd dan.
Je kan je browser ook standaard de HTTPS variant laten pakken.

https://www.eff.org/https-everywhere

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True