Google gaat https-sites hoger zetten in zoekresultaten

Zoekmachine Google gaat in zijn algoritme meewegen of sites standaard tls gebruiken. Sites met https-toegang krijgen een hogere plek in Google. Daarmee wil de zoekmachine sitebeheerders stimuleren om hun webpagina's veiliger te maken.

Google zal tls meewegen als 'ranking signal' in zijn zoekmachine, zegt het bedrijf op een eigen blog. Vooralsnog is de weging van https-toegang op een site niet zwaar, maar Google zegt dat het tls mogelijk meer gaat meewegen in de toekomst.

De zoekgigant heeft de weging afgelopen maanden naar eigen zeggen al getest en zag positieve resultaten. Google heeft al eerder uitgesproken dat het graag alle sites ziet overgaan op https en Google-diensten zijn dan ook al beveiligd via tls. Het zoekbedrijf raadt sites aan om 2048-bits keys te gebruiken bij de implementatie van tls. Google zegt in de komende weken tips te gaan publiceren om tls te gaan gebruiken.

De stap heeft mogelijk grote gevolgen voor veel sites. Het verkeer vanuit Google is voor veel websites de belangrijkste of een belangrijke bron voor bezoek en een lagere plaats in de zoekmachine resulteert daardoor voor veel sites in een verminderd aantal bezoekers.

Reacties (177)

[biglia]

Ik vind SSL certificaten vrij duur voor een hobby project.

[Reactie gewijzigd door biglia op 23 juli 2024 04:48]

[LinuZZ]

startssl.com

[AW_Bos]

Ja, maar die gratis certificaten gaan niet op voor elke hobbywebsite. Denk eens bijvoorbeeld aan subdomeinen.

[Reactie gewijzigd door AW_Bos op 23 juli 2024 04:48]

[LinuZZ]

Je kan per subdomein een certificaat aanvragen en met SNI scheiden.

[AW_Bos]

En hoe zou je dat bij wildcard domeinen willen doen?

[Blaise]

Je website anders opzetten of gewoon betalen.

[AW_Bos]

En het onderwerp van deze thread ging over hobbysites, en ja, die hebben niet altijd voldoende financiele middelen.

Het is toch van de gekke dat je uiteindelijk moet betalen voor een betere ranking in Google? Laat staan je site anders in te richten.

[Reactie gewijzigd door AW_Bos op 23 juli 2024 04:48]

[Blaise]

Als bezoeker van een (hobby)website is encryptie goed voor mijn mijn veiligheid en privacy, dus het heeft een toegevoegde waarde. Maar het is maar één van de vele factoren die Google meeneemt.

Voor een goede indexering en ranking moet je sowieso al rekening houden met talloze SEO gotchas. En als je als hobby met een website klungelt en alles doet voor je ranking, dan moet het ook wel lukken om een gratis certificaat te regelen of je website zo om te bouwen zodat het geen wildcard certificaat nodig heeft.

[Reactie gewijzigd door Blaise op 23 juli 2024 04:48]

[Lisadr]

Is toch alleen het eerste jaar gratis?

[Verwijderd]

Nee, ze zijn maar 1 jaar geldig, en daarna moet je ze opnieuw aanvragen/aanmaken maar die zijn dan ook gewoon gratis

[Siebsel]

~€11 voor een certificaat duur? Vind ik reuze meevallen, als je hobby project al zo serieus is dat je je druk gaat maken over je ranking bij Google, is €11 p/j peanuts natuurlijk. (bron: https://www.sslcertificaten.nl/SSLCertificaten)

ot: vind dit op zich wel een goede actie. De vertraging die de encryptie met zich meebrengt is tegenwoordig bijna verwaarloosbaar. Weer een extra "laag" waar potentiële kwaadwillenden doorheen moeten.

[Reactie gewijzigd door Siebsel op 23 juli 2024 04:48]

[sanderv]

Het is nog altijd onduidelijk (toch?) hoe ernstig je in rangschikking erop achteruit gaat. En wie weet, voorziet Google dat dit aspect op termijn ook steeds zwaarder komt mee te wegen. Als hobby-project maak je je misschien niet heel veel zorgen over de ranking, maar je wilt toch ook niet op pagina 5 terecht komen.

Ik vind elf euro ook niet zo'n probleem. Maar er zijn ook veel leken die ternauwernood een website de lucht in krijgen, waarvoor HTTPS misschien hoog gegrepen is.

Ik vind het al met al toch een wat bedenkelijke keuze van Google.

[Yggdrasil]

Google geeft in haar blogpost aan dat dit 'ranking signal' slechts licht meetelt. lichter dan bijv. het serveren van goede content.

For now it's only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content—while we give webmasters time to switch to HTTPS. But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.

Ik denk dat dit Google's manier is om de markt te stimuleren. Bij veel hosters is het al erg eenvoudig om TLS te activeren via een control-panel o.i.d. Als de vraag groter wordt zal dit straks hopelijk zo eenvoudig zijn (en hopelijk ook zo betaalbaar) dat iedere leek TLS kan inschakelen op zijn hobbysite.

[Mattie112]

(offtopic)

Je kan altijd een self-signed certificaat nemen (ok, je browser geeft wel een warning) of je neemt een gratis SSL certificaat zoals hier: https://www.startssl.com/ gebruik deze zelf ook werkt perfect en wordt door alle courante browsers als valide aangegeven.

[digdas]

Ik ben ermee bezig geweest. Heb een kleine howto gemaakt., met startssl.com

Voor geinteresserden:

http://www.digdascloud.nl/myBB/showthread.php?tid=1

[Niemand_Anders]

Bij ssls.com koop je certificaten voor een jaar prijs van 8,95 dollar (6,75 in euro). Betaling kan via creditcard of paypal en die laatste ondersteund ook Ideal.. Als je een certificaat voor 5 jaar koopt betaal je zelfs maar 4,95 dollar per jaar want dan ongeveer neerkomt op 3,70. Op een festival is dat bijna de prijs van een biertje..

Daarnaast ondersteunen alle moderne browsers ook inmiddels Server Name Indication (SNI) waarmee je op 1 IP meerdere HTTPS websites kunt draaien. SNI kun je simpel gezegd vergelijken met de 'host' header bij reguliere HTTP websites. SNI werkt echter wel alleen met TLS omdat je dan voor de handshake al kunt doorgeven welke host je wilt bezoeken. Dat kan niet bij het 'ouderwetse' SSL welke de handshake al uitvoert voordat je verbinding hebt. Bij de TLS maak je vaak eerst via een non-secure verbinding met een server en vervolgens start je eigenlijk een secure tunnel over de bestaande non-secure verbinding..

Zelfs CPU verbruikt is tegenwoordig veel minder omdat de beveiligde verbinding de resource intensieve RSA encryptie alleen gebruikt voor het encrypten van de pre-shared key voor de AES encryption welke voor de rest van de sessie wordt gebruikt. AES is zelfs geimplementeerd op je bankpas (chipknip) en heeft veel minder resources nodig dan RSA..

En inmiddels zijn ook al meerdere partijen begonnen om bij EV-SSL (groene adres balk) ook alternatieve hostnames op te geven waardoor je het certificaat alsnog op meerdere subdomeinen kunt gebruiken. Hoeveel subdomeinen je standaard kunt opnemen bij de EV-SSL certificaat ligt vooral aan je tussenpersoon. De specificatie zelf kent geen limiet. Het nadeel is wel dat bij elke wijziging van de (sub) domeinen op het EV-SSL certificaat je wel een nieuw certificaat moet installeren. Maar dat is bij veel webservers ook niet meer zo lastig..

[GoT]

Ligt aan de provider die je kiest en uiteraard welk certificaat: EV, wildcard, aantal jaar, pro, etc.
VeriSign / Symantec is het duurst, maar er zijn ook goedkopere zoals: Geotrust.
Deze kosten ± 10,- per jaar en zijn net zo goed als de duurdere providers.


Edit:
https://www.google.nl/?gws_rd=ssl#q=ssl+certificaat+kopen
Eerste hit: https://www.sslcertificaten.nl/SSLCertificaten
Comodo / Geotrust voor een tientje per jaar.

[Reactie gewijzigd door GoT op 23 juli 2024 04:48]

[Yggdrasil]

Die sslcertificaten.nl site is van Xolphin, een nederlandse leverancier waar ik al jaren met plezier gebruik van maak. Zo'n Comodo PositiveSSL certificaat kost inderdaad maar weinig en werkt net zo goed als de dure certificaten die sommige CA's aanbieden. Als je slechts domein-validatie wilt hebben is er geen reden om een duurder certificaat te gebruiken.

[The Zep Man]

Ik vind SSL certificaten vrij duur voor een hobby project.

Als het een hobby project is, is het dan echt belangrijk dat het zoekresultaat hoog in Google's index komt te staan?

Daarnaast zijn het niet de kosten van het SSL certificaat (zie de reacties hierboven), maar eerder het verkrijgen van het certificaat zelf en de correcte inrichting van de webserver om SSL te gebruiken dat vaak veel tijd (=geld) kost. Voor de goedkoopste SSL certificaten is e-mail validatie voldoende, maar dan moet je wel e-mail op het betreffende domein hebben. Heb je dat niet (nodig voor je hobby), mag je een mailserver gaan inrichten. Ook moet er wat tijd en energie in gestoken worden al wil je SSL echt veilig te maken (juiste SSL/TLS versies, cipher suites...) en te houden.

[Yggdrasil]

Gelukkig kun je tegenwoordig vaak ook je eigendom van een domein bewijzen door een bepaald TXT-record in DNS aan te maken, of door een bestandje op je website te zetten. Mocht je geen mailserver aan het domein gekoppeld hebben dan is dat vaak een snelle manier om te valideren.

[Mavericky]

Tip: StartSSL Free SSL Certificates: https://www.startssl.com/
Dit zijn echt gratis certificaten om persoonlijke websites met SSL te "beveiligen".

[Alchiadus]

Bij StartSSL kun je gratis een Class 1 SSL certificaat aanvragen.

[drdelta]

Ik vind 9€ per jaar nou niet echt heel veel..

[CAPSLOCK2000]

Niet duurder dan een eenvoudig webhostingpakketje. Het zijn inderdaad extra kosten, maar die zijn goed te overzien. Wie z'n site meer waard vindt dan het absolute minimum kan ook wel een SSL-certificaat betalen.

Overigens verwacht ik dat door deze actie van Google de certificaten standaard onderdeel worden van de hostingpakketjes. Nu betaal je nog een meerprijs voor SSL. Als het in de toekomst bij ieder pakket zit dan zullen de prijzen wel dalen door de felle concurrentie. Als je groot genoeg bent dan kan zo'n certificaat behoorlijk goedkoop zijn.

[ddbc]

Ik denk dat je al certificaten hebt voor €10 / jaar, voor zover ik weet is er geen verschil qua beveiliging tussen die en de iets duurdere (€300 /jaar) enkel de naam die er achter zit.

[gnu]

Klopt, onafhankelijk van waar je het certificaat haalt kan je zelf nog kiezen welke algoritmes je gebruikt voor de daadwerkelijke encryptie. Het certificaat kan zelfs enkel gebruikt worden voor authenticatie (bewijs dat het de goede server is), de daadwerkelijke encryptie kan hele andere parameters gebruiken.

[Verwijderd]

Ik denk dat je al certificaten hebt voor €10 / jaar, voor zover ik weet is er geen verschil qua beveiliging tussen die en de iets duurdere (€300 /jaar) enkel de naam die er achter zit.

tuurlijk is daar een verschil in: men kan opteren voor domeinvalidatie, organistatievalifatie of uitgebreide validatie

[Anoniem: 415670]

Heeft er iemand een goede tutorial voor zelf een gratis SSL te implementeren op een shared hosting packet of is dit niet mogelijk?

[Evianon]

Ligt eraan of je controlepaneel het ondersteunt en of je hoster het toestaat, meestal kan het wel. Let wel op dat je SNI moet gebruiken zolang je geen eigen IP hebt, wat niet werkt op XP, Android 2.x en nog een paar browsers.

Omdat in Nederland DirectAdmin het meest gebruikt wordt voor shared hosting, hier wat linkjes voor DA:

CSR aanmaken voor aanvraag: https://www.sslcertificat...irectAdmin_-_Aanmaken_CSR

Installeren certificaat: https://www.sslcertificat...-_Installatie_certificaat

Daarna kun je checken of het allemaal goed werkt, wil nog weleens misgaan met root / intermediate certificaten: https://www.sslcertificaten.nl/SSLCheck

[Reactie gewijzigd door Evianon op 23 juli 2024 04:48]

[Siebsel]

Je hebt hiervoor SSH toegang nodig tot de configuratie van je server (meestal); dit moet je provider voor je doen.

Wat ook een mogelijkheid is, is dat het via het control panel van je site kan, maar daar heb ik zelf niet echt ervaring mee (alleen DirectAdmin, maar dat is al lang geleden)

[arjankoole]

Heeft er iemand een goede tutorial voor zelf een gratis SSL te implementeren op een shared hosting packet of is dit niet mogelijk?

Op shared hosting? Dan zul je toch even met je provider moeten gaan praten, of ze dat uberhaupt ondersteunen.

[Zidane007nl]

Gratis gaat niet, tenzij je het certificaat zelf ondertekend. Wat tot gevolg heeft dat iedereen een waarschuwing krijgt dat het certificaat niet veilig is.

[biglia]

Ik denk niet dat dit bij elke shared hosting packet gaat. Je hebt sowieso een eigen ip nodig.

[Verwijderd]

tegenwoordig niet meer. SNI

[Reactie gewijzigd door Verwijderd op 23 juli 2024 04:48]

[drdelta]

Wel als je Windows XP/Android 2.x wilt ondersteunen.

[Verwijderd]

Klopt. Als je 10 jaar oude OS-en wilt ondersteunen dan inderdaad wel. Net zoals het een keuze is om al die CSS uitzonderingen te maken speciaal voor IE 6.

Al het niet echt absoluut noodzakelijk is dan zou ik dat gewoon lekker laten. Jammer van die enkele XP gebruiker.

(En wie echt die enkele XP gebruiker wil bedienen: dan schaf je dat IP-tje voor 1 euro per maand maar aan)

[drdelta]

Android 2.3.7 is echter op 21 september 2011 uitgegeven, dus met je "10 jaar oude OS-en" kom je niet weg. Maar ja, ik vind het geklaag "het is zo duur" ook een onzin. Voor weinig geld heb je een IP en een certificaat. En om nou te gaan zeuren om 20€ per jaar...

[Verwijderd]

Ook correct. Echter de levensduur van smartphones is veel korter dan die van PCs. Als ik de traffic van alle website waaraan ik werk (40+) bekijk is slechts 4% telefoon. En binnen die parameters is Android 40% waarbij de 2.x slechts 5%. Dat maakt nog geen half procent van mijn bezoekers die buiten de boot zouden vallen. En dat aantal neemt komende tijd alleen maar af.

Formeel heb je absoluut gelijk dat als je iedereen wilt bedienen een eigen IP nodig bent. Maar uit praktische overweging zou ik die legacy gewoon negeren.

[Terminus]

Veel sites zoals blogs hebben toch bijna geen meerwaarde er aan om standaard https te gebruiken?

[Luchtbakker]

In principe niet, maar het kan nooit kwaad, en de kans verkleind iets dat je afgesluiterd wordt.

[Eagle Creek]

Het kan wel "kwaad", het kost namelijk performance. En "afluisteren" is een breed begrip: als ik een statische site bezoek over het opwekken van kernenergie in mijn schuurtje, heeft de toevoeging van TLS weinig zin m.i. omdat ik geen informatie verzend. De informatie die ik ontvang zal in 99% van de gevallen generiek zijn (statische pagina), en dát ik de site bezoek wordt sowieso geregistreerd, wel of geen TLS.

Ik wil zeker niet zeggen dat TLS geen voordelen zou bieden. Maar "gooi er maar beveiliging het kan toch nooit kwaad" is naar mijn mening geen wenselijk argument.

Desalniettemin vind ik Google's keuze verder aardig: voor veel sites zal HTTPS het gunstigere alternatief zijn, zeker als een site in twee versies wordt aangeboden. Waar ik wel benieuwd naar ben: stel site A geeft informatie zonder TLS en site B geeft iets minder informatie met TLS. Komt site B dan toch hoger?

[Reactie gewijzigd door Eagle Creek op 23 juli 2024 04:48]

[Schway]

ik verwacht dat het af hangt van hoeveel minder informatie en wat voor informatie het is, dat ontbreekt. Maar in identieke gevallen zal de https versie hoger staan. met verschillende web sites wordt nog steeds gekeken naar meerdere punten om te bepalen hoe hoog een pagina in de resultaten komt te staan.

[gnu]

Dat je de site bezoekt wordt juist niet geregistreerd, er wordt hooguit geregistreerd dat je een bepaald ip adres bezoekt. Afhankelijk van de implementatie kan men eventueel ook nog de hostname zien, maar de specifieke url wordt ook beveiligd met tls.

[Anoniem: 421765]

Er is ook een nadeel aan https, het vraagt meer van de server. Sites kunnen trager laden.

[Xatom]

Maar je kan wel SPDY gebruiken (dit werkt alleen i.c.m. HTTPS). Kijk maar eens naar deze benchmark. Dat is zelfs ruim sneller dan gewoon HTTP, en al helemaal sneller dan gewoon SSL.

A total of 5.03 seconds (5.98 - 0.995) for SSL.
HTTP: 2.7 seconds.
SPDY/3: 1.1 seconds.
SPDY/3 push: 0.74 seconds.

Ook ondersteunen de meeste grote browsers dit protocol:

• Firefox
• Chromium/Chrome
• Internet Explorer 11
• Opera
• Safari

Volgens mij is het zelfs minder werk voor de server maar dat kan ik zo snel even niet terug vinden.

Edit: toch wel

• Compared to HTTPS, SPDY requests consume less resources (CPU and memory) on the server.
• Compared to HTTP, SPDY requests consume less memory but a bit more CPU. This may be good, bad, or irrelevant depending on which resource (if either) is currently limiting your server.
• Compared to HTTP/S, SPDY requires fewer Apache worker threads, which increases server capacity. As a result, the server may attract more SPDY traffic.

[Reactie gewijzigd door Xatom op 23 juli 2024 04:48]

[Dannydekr]

Ligt wel aan de ciphers die je gebruikt. De zwaarste encryptiesleutels kunnen de site ernstig vertragen. SPDY + OCSP Stapling, Caching, efficiënte Ciphers en een SSL CDN (liefst met SPDY) maken je site echt heel erg snel. Sneller dan zonder SSL in sommige gevallen.

De TTFB blijft altijd een uitdaging om te verlagen, met HTTPS kom je met alle optimalisaties in de buurt van HTTP, soms sneller, in sommige gevallen een aantal MS trager.

[GewoonWatSpulle]

Uitdaging, maar misschien ook verspilde moeite tot op zekere hoogte?
Cloudflare: Stop worrying about Time To First Byte (TTFB)

[Reactie gewijzigd door GewoonWatSpulle op 23 juli 2024 04:48]

[Dannydekr]

Voor SEO doeleinden is de TTFB nog steeds belangrijk, wellicht het belangrijkste snelheidsaspect binnen je score berekening, logisch ook, aangezien de bot dit direct kan meten.

http://moz.com/blog/how-w...z+%28SEOmoz+Daily+Blog%29

[Xatom]

Daar had ik even niet aan gedacht. Maar mijn vergelijking was dan ook eigenlijk voor sites die niet echt HTTPS nodig hebben en dus ook niet zo'n zware cipher.

[Blokker_1999]

Dat klopt, maar jaco86 heeft voor een deel ook gelijk. De overdracht van data op zich kan versneld worden (waardoor de site sneller lijkt te laden) maar daar staat tegenover dat op de server meer CPU kracht nodig is om de bestanden te kunnen tranfereren en op de client is meer CPU kracht nodig om de boel weer te ontsleutelen. Aan de client kant zal dat niet zo hard opvallen, maar bij een druk bezochte server kan de versleuteling wel weer een impact hebben op de bronnen lijkt mij.

[MMaster23]

En tel er ook nog bij op dat veel browsers eerst ook nog een revocation check gaan uitvoeren om het certificaat te valideren. Dit is weer een aparte connectie naar een aparte CRL host en het SSL request gaat hier wel op wachten.

Welliswaar eenmalig per sessie dus de vervolg bezoeken / links gaan een stuk sneller maar toch.

[Juup]

Daar is OCSP Stapling voor uitgevonden.
Bij Apache vanaf versie 2.3.3 beschikbaar.

[bbob]

Een certificaat kost ook geld en heb je een multistore kost het je nog meer geld.

Het idee van google is leuk maar door het meewegen krijg je een 2deling tussen grotere en kleinere sites, cq sites met meer geld en minder geld. Voor mij zou dit vallen onder machtsmisbruik van google. aangezien google een dominante marktpartij is, is dit ook weer een goed voorbeeld van misbruik van google.

[gnu]

Je kan ook gratis certificaten gebruiken. Deze werken prima op alle moderne besturingssystemen en bieden net zo veel beveiliging (tegen afluisteren) als de dure "groene url" certificaten.

En dankzij SNI is het ook prima mogelijk om op je simpele VPS met 1 IP adres al je subdomains te beveiligen met losse certificaten, het kost wat moeite maar je kan het allemaal goedkoop regelen.

De leverancier van het certificaat zegt niks over de beveiliging van het verkeer, je kan zelfs algoritmes kiezen die onafhankelijk zijn van de private key van je certificaat. Op die manier is het niet mogelijk om TLS verkeer dat ooit is afgeluisterd achteraf te ontcijferen als je private key publiek gemaakt wordt.

http://baudehlo.com/2013/...ecrecy-for-nginx-or-stud/

[bbob]

Veel webshops draaien bij een winkelaanbieder op hetzelfde ip adres, zie daar voor 1000 shop ip 1 ip adres maar eens een certificaat te krijgen.

Idem met kleinere sites op shared hosting, zie daar een certificaat te krijgen.

Je hebt toch echt een ip adres nodig. Laat het grote probleem nu zijn dat er al te weinig ip4 adressen zijn.

Hierboven werd de opmerking al gemaakt. google zou de beste inhoud op jou zoekopdracht moeten tonen. als https voorkeur krijgt wil dat dus zeggen dat je niet altijd de beste inhoud krijgt.

[digdas]

Voor apache/plesk kun je voor elk domein een eigen certificaat zetten. Ben er toevallig net mee bezig.

[gnu]

Het certificaat krijgen is geen enkel probleem, dat de winkelaanbieder niet mee werkt om er TLS op te zetten is erger.

[Foamy]

Wauw. Een certificaat kost tegenwoordig ongeveer even veel als een pak koffie. Als je dat al niet kunt ophoesten als bedrijf zijnde dan doe je imho toch wat verkeerd.

[djiwie]

Een certificaat is niet zo duur, maar zolang je SNI nog niet echt goed in kunt zetten (Windows XP en Android 2.x ondersteunen het nog niet) moet je of multi-domain certificaten kopen of meerdere ip-adressen aan je server hangen. Beide zijn niet echt handig in het beheer.

Heb je een site die op één domein draait op een server die verder toch geen andere sites bedient, dan is het inderdaad niet zo kostbaar om een certificaat toe te voegen.

[LinuZZ]

Windows XP met een alternatieve browser (Chrome of FF bijvoorbeeld) ondersteund SNI prima. daarnaast is het OS eol dus kun je foutmeldingen gaan verwachten. ik denk dat de media ondertussen aardig duidelijk heeft gemaakt dat XP gebruiken onveilig is (los van de discussie of dit terecht is). daarnaast werken sowiezo niet alle sites lekker meer op ie8. tijd om afscheid te nemen.

android 2.x wordt vrijwel niet meer gebruikt.

uiteraard afhankelijk van je gebruik maar SNI is haalbaarder dan de meeste mensen denken.

[Anoniem: 470811]

M.b.t. je Android 2.x opmerking:

https://developer.android.com/about/dashboards/index.html

Daarin staat dat Android 2.3 en 2.2 samen een marktaandeel hebben van 14% van het eco-systeem van Google. Google heeft op de laatste IO aangegeven dat het 1 miljard devices in haar eco-systeem heeft.

140 miljoen Android 2.x gebruikers. Dat is mijn inzien wel iets meer dan "vrijwel niet meer gebruikt".

Edit: correctie optelling percentage

[Reactie gewijzigd door Anoniem: 470811 op 23 juli 2024 04:48]

[LinuZZ]

ik had moeten zeggen om te browsen. ik heb de server stats op diverse omgevingen bekeken en daar was het het percentage van android 2,2 / 2,3 gezamelijk niet hoger dan 1% van de android bezoeken (minder dan 0,1% van het totaal) het percentage is met 14% (13,5+0,7) inderdaad wel hoger dan ik had verwacht.

[Anoniem: 470811]

Ah, dat kan goed kloppen. Heb mijn foutieve optelling ook gecorrigeerd .

[Murfy]

Voor zover ik weet werkt SNI niet op Windows XP omdat dit een probleem is in de OS-laag.

http://en.wikipedia.org/w...r_name_indication.5B10.5D

[LinuZZ]

van je eigen link: Google Chrome (Vista or higher. XP on Chrome 6 or newer.[13] OS X 10.5.7 or higher on Chrome 5.0.342.1 or newer) ik heb dit getest, en het werkt (ook met Firefox)

[eborn]

Daarbij meegenomen dat de huidige voorraad IP's eindig is. SNI zou daarom een echte uitkomst zijn. Alleen in onze hosting omgeving gebruiken we al 50 IP's puur en alleen voor SSL. En dan zijn wij maar een kleine vis.

[melwasul]

Waar kan je best een certificaat kopen, en wat voor type moet je nemen? Ik zie namelijk dat je verschillende varianten hebt, zoals domein validatie, organisatie validatie, uitgebreide validatie, multi domein, wildcard...

Wij hebben momenteel een website voor ons Frühstückspension in Oostenrijk. Ik heb er al een tijdje over nagedacht om over te schakelen naar https. Misschien is dit een goed moment.

[TD-er]

startssl.com is gratis. Let alleen wel op dat het niet lekker werkt op een shared-hosting server waarbij meerdere sites draaien op het hetzelfde IP-adres (het SNI-verhaal hierboven)

[melwasul]

Zal ik vanavond eens bekijken. Bedankt!

[NitSuA]

En welke dan op startssl? Is de gratis variant voldoende voor een groene balk?

[Enai]

En als je content elders gehost is?

"Welp, Blogspot heeft geen certificaat, zal ik 1/ genoegen nemen met een plaats op pagina 28 of 2/ verhuizen en mijn lezers achterlaten?"

[Verwijderd]

Het idee van google is leuk maar door het meewegen krijg je een 2deling tussen grotere en kleinere sites, cq sites met meer geld en minder geld. Voor mij zou dit vallen onder machtsmisbruik van google. aangezien google een dominante marktpartij is, is dit ook weer een goed voorbeeld van misbruik van google.

Los van het feit dat google hier bal serieus misslaat (ze moeten de beste content aanbieden, of die op http of https staat is totaal irrelevant), uw redenering klopt natuurlijk niet.
google misbruikt hier niets of niemand, ze passen hun bestaande algoritme aan. Als dit misbruik is, dan is hun oude algoritme even goed misbruik. Ze bevoordelen zichzelf hier niet mee

[bbob]

Het probleem is dat niemand behalve google het algoritme weet.
Wat wel bekend is, is dat google via dat algoritme invloed kan uitoefenen welke sites bovenaan komen.

google met haar zoekmachine is een dominante marktpartij, laten we het op 80% houden. Er lopen al onderzoeken naar misbruik van die macht. Het zou een goede zaak zijn om nog meer onderzoek te doen naar google c.q een onafhankelijke 3de partij naar het algoritme te laten kijken om te kunnen bepalen of google bepaalde bedrijven bevoordeeld.

[Verwijderd]

Het probleem is dat niemand behalve google het algoritme weet.

dat is geen probleem. coca cola's recept is al 200 jaar geheim, dat heeft ook nooit problemen opgeleverd.

Er lopen al onderzoeken naar misbruik van die macht. Het zou een goede zaak zijn om nog meer onderzoek te doen naar google

waarom dan? is er een reden waarom de huidige onderzoeken niet voldoende zijn? en waarom is dat dan?
er wordt pas onderzoek gedaan naar marktdominantie als er een partij zich benadeeld voelt en dit aankaart. Er is geen geheime marktdominantiepolitie die elke overtreding nauwlettend detecteert.

een onafhankelijke 3de partij naar het algoritme te laten kijken om te kunnen bepalen of google bepaalde bedrijven bevoordeeld.

natuurlijk bevoordeeld google bepaalde bedrijven! degene die - al dan niet per ongeluk - het best inspelen op de wensen van het algoritme staan bovenaan en krijgen meer kliks.

[bbob]

coca cola heeft geen dominante marktpartij noch een voorbeeld waar andere bedrijven afhankelijk van zijn. bij google is dit wel het geval.

Waarom de onderzoeken niet voldoende zijn. tja meningen verschillen maar klachten van bedrijven zijn er genoeg en de Eu is niet altijd even snel.

De onderzoeken gaan vooral over het bevoordelen van eigen google diensten boven concurrerende.

[Verwijderd]

coca cola heeft geen dominante marktpartij

met een marktaandeel van meer dan 50% in sommige markten mag men echt wel spreken van een dominante marktpartij!

noch een voorbeeld waar andere bedrijven afhankelijk van zijn.

voor zover ik weet baat coca cola company geen enkele albert heijn uit

Waarom de onderzoeken niet voldoende zijn. tja meningen verschillen maar klachten van bedrijven zijn er genoeg en de Eu is niet altijd even snel.

het is makkelijk wat te roepen, maar noem dan eens een klacht die niet behandeld zou zijn en waarom dat volgens jou wel had gemoeten?

De onderzoeken gaan vooral over het bevoordelen van eigen google diensten boven concurrerende.

en dat is volgens jou niet voldoende?

[Yggdrasil]

De site "Is TLS fast yet?" gaat daar in detail op in en claimt dat dat verschil met moderne technieken minimaal is.

[Anoniem: 524877]

Klopt maar een nieuws site als 'tweakers'. Waarom zou die nou standaard overal https aanzetten ? Heeft toch helemaal geen meerwaarden? Als je namelijk inlogt op een pagina die niet beveiligd is krijg je hier overigens ook netjes een melding over.

[Leanderable]

Dat lijkt mij ook. Sites die eigenlijk alleen maar content weergeven zonder bijvoorbeeld een login-systeem hebben hier volgens mij geen baat bij. En toch worden deze pagina's hier wel door 'benadeeld' - ze komen minder hoog in de resultaten. Zou Google hier rekening mee houden?

[Blubber]

Dat lijkt mij ook. Sites die eigenlijk alleen maar content weergeven zonder bijvoorbeeld een login-systeem hebben hier volgens mij geen baat bij. En toch worden deze pagina's hier wel door 'benadeeld' - ze komen minder hoog in de resultaten. Zou Google hier rekening mee houden?

Daar ben ik het totaal niet mee eens. Je kunt aan de hand van het surfgedrag van iemand allerlei dingen afleiden, SSL kan dat in het slechtste geval een stuk moeilijker maken.

Ik zie echter wel twee problemen, ten eerste is SSL nou ook weer niet zo goed. Vooral de goedkope certificaten zijn te makkelijk te verkrijgen, tevens zijn sommige CAs niet veilig (Diginotar ...). Ten tweede kosten de certificaten geld, veel geld als het om sterke certificaten gaat. Er zou een beter systeem moeten komen waarbij het vertrouwen niet van een enkele CA afhangt. Een goede stap is bijvoorbeeld het Perspective project, waarbij het bepalen van vertrouwen op een soort peer-to-peer manier gebeurt.

[arjankoole]

Daar ben ik het totaal niet mee eens. Je kunt aan de hand van het surfgedrag van iemand allerlei dingen afleiden, SSL kan dat in het slechtste geval een stuk moeilijker maken.

SSL veranderd daar niets aan. Al die trackers werken via zowel SSL als plaintext HTTP.

[Blubber]

[...]


SSL veranderd daar niets aan. Al die trackers werken via zowel SSL als plaintext HTTP.

Ik had het niet over trackers op de pagina, maar over derden die de verbinding 'afluisteren'. Je provider is bijvoorbeeld verplicht headers op te slaan van alle HTTP requests, als je SSL gebruikt wordt dat een stuk moeilijker.

[arjankoole]

Je provider is bijvoorbeeld verplicht headers op te slaan van alle HTTP requests, als je SSL gebruikt wordt dat een stuk moeilijker.

Dat is niet waar. Ze zijn verplicht de transport data op te slaan, dus:

timestamp, src ip, dst ip, src port, dst port.

That's it. Ze slaan geen headers van requests op, en SSL heeft dus ook op dat vlak geen enkel nut.

[Anoniem: 426269]

Voor elke website met een simpel contactformulier is https al gewenst. Wet bescherming persoonsgegevens.

[dajero]

Met HTTPS is het in principe niet mogelijk om tijdens het transport van een verzoek te zien wat er wordt opgevraagd en teruggestuurd. Het is een stukje extra privacy; enkel de GGZ zelf en niet je provider hoeft te weten dat je informatie over een SOA-test zoekt

[The Zep Man]

Met HTTPS is het in principe niet mogelijk om tijdens het transport van een verzoek te zien wat er wordt opgevraagd en teruggestuurd. Het is een stukje extra privacy; enkel de GGZ zelf en niet je provider hoeft te weten dat je informatie over een SOA-test zoekt

En Google, natuurlijk.

[Anoniem: 426269]

Wel als je erop inlogt op een (open) netwerk zoals een vliegveld of internetcafe.

[CAPSLOCK2000]

Kleine sites worden groot. Een site die nu nog niks heeft aan https kan over een jaar heel andere informatie bevatten waarbij https wel nodig is. Het is natuurlijk de verantwoordelijkheid van de eigenaar/beheerder om tijdig een certificaat toe te voegen, maar je weet hoe mensen zijn: lui, vergeetachtig en met weinig besef van veiligheid.
Door https tot de standaard te verheffen ondervangen we dat probleem. Men hoeft niet meer te denken of https nodig is of niet, het is er gewoon.

[Probook8979]

Ik vind dat eigenlijk alle site's per direct https moeten gebruiken, uiteindelijk komt de veiligheid van de gebruikers aan ten orde.

Ik kan nog steeds niet begrijpen dat aantal site's niet doorgevoerd zijn door https?
Kan iemand mij hierop een duidelijke verklaring geven?

Het lijkt mij toch niet moeilijk de overzet naar https?

Correct me if i'm wrong.

[Luuk1983]

- Kost geld om certificaten aan te maken
- Is langzamer (meer overhead)
- Je kan (volgens mij) maar één certificaat per IP/port combinatie hebben.

Er zijn genoeg sites waarbij het totaal niet belangrijk is dat deze https zijn. Alleen als er gegevens tussen gebruiker en site uitgewisseld worden is het belangrijk dit te beveiligen, maar gewoon wat pagina's opvragen lijkt me allemaal niet zo spannend.

[arjankoole]

- Kost geld om certificaten aan te maken

Niet altijd, StartSSL is gratis voor het zwakste certificaat. Nou kun je je afvragen hoe betrouwbaar dat certificaat is, ik geloof niet echt in gratis in combinatie met kwaliteit.

- Is langzamer (meer overhead)

Marginaal. Volgens mij hebben de meeste CPU's tegenwoordig ingebouwde crypto acceleratie.

- Je kan (volgens mij) maar één certificaat per IP/port combinatie hebben.

Dat was vroeger zo inderdaad. Met SNI is dat verleden tijd.

[gnu]

Bijna waar, het certificaat zelf heeft geen invloed op de beveiliging van de verbinding, dat is iets dat je regelt op je server.

[Blaatpraat]

Niet altijd, StartSSL is gratis voor het zwakste certificaat. Nou kun je je afvragen hoe betrouwbaar dat certificaat is, ik geloof niet echt in gratis in combinatie met kwaliteit.

Op zich betrouwbaar genoeg. 2048 bits TLS encryptie.
En mocht je het niet vertrouwen, dan maak je zelf je certificaat aan, en laat je die signen door hun (ook gratis) zodat browsers niet klagen dat het niet gesigned is door een geldige CA.

Voor 90% van de websites volstaan de gratis certificaten van StartSSL perfect.

[Dannisi]

Certificaten kosten (vaak) geld, en HTTPS kost meer CPU kracht. Als je een simpel blog hebt, heb je HTTPS dan wel echt nodig?

[Mavericky]

Tip: StartSSL Free SSL Certificates: https://www.startssl.com/
Dit zijn gratis certificaten om persoonlijke websites met SSL te "beveiligen".

[gnu]

Waarom plaats je beveiligen tussen quotes? Dit insinueert dat het niet veiliger is, maar ondanks dat je certificaat gratis is is je verbinding wel gewoon professioneel beveiligt.

[Dannisi]

Daarom stond 'vaak' ook tussen haakjes

[Mavericky]

ah, sorry ;-)

[Probook8979]

Wat ik bedoel is dat er nog steeds http wordt gebruikt bij een aantal site's waar je bijvb als member in kan loggen. Het gehele proces is dus eigenlijk niet veilig.

Daarom vind ik dat alle site's die deel uitmaken van bijvb leden systeem https moeten gebruiken.

Daarnaast moet ik je wel gelijk geven dat er op een blogsite dat niet van toepassing is. Dat betekend wel dat je nu juist onderaan in zoekmachine wordt gezet, omdat je geen https gebruikt maakt.

Dat vind ik nou jammer.

[swtimmer]

Als ik het goed begrijp moet je per domein een eigen IP adres hebben voor de goedkope ssl gevallen. Mijn hoster vraagt vrij veel geld voor extra IP adressen en daarbij zou dan nog een certificaat komen. Niet echt goedkoop voor zomaar een website met een blogje ofzo.

[Reactie gewijzigd door swtimmer op 23 juli 2024 04:48]

[Blaatpraat]

Niet nodig. Meerdere domeinen op 1 ip met allemaal een eigen certificaat gaat perfect.
Heb je meerdere domeinen die ook naar dezelfde hostingstek verwijzen (dus niet gewoon naast elkaar op 1 ip draaien), heb je een SNI certificaat nodig, en enkel deze is betalend (in het eerste geval kan je dat perfect gratis doen).

[swtimmer]

Hmm, mijn VPS host gaf aan dat ik per certificaat een IP moest kopen. Kan ik (ik heb root toegang) dan zelf ergens anders een certificaat scoren en toch een soort van https draaien?

[hackerhater]

Het kan, mits je er bewust bent dat je legancy-browsers uitsluit.
Echter als bijvoorbeeld je sites sowieso als HTML5 vereisen is dat een non-issue.

[Blaatpraat]

In het geval van IE sluit je alle windowsen vanaf XP en ouder uit.
In het geval van een alternatieve browser kun je er vanuit gaan dat als men een oudere draait, men hier een speciale reden voor moet hebben en dus ook maar al te goed weet dat je vaak certificate errors gaat krijgen (en andere problemen).

[Blaatpraat]

Een certificaat aanvragen bij startssl.
Deze kan je instellen per vhost in je apache config (en waarschijnlijk lukt dit ook wel met nginx, zou je eens moeten opzoeken mocht dat het geval zijn).
Per domein kan je een gratis certificaat aanvragen.

[Yggdrasil]

Dat klopt niet. Een "SNI certificaat" bestaat niet. Ik begrijp niet wat je precies bedoelt.

Server Name Indication is een uitbreiding van SSL en TLS die aan het begin van het handshaking proces aangeeft met welke hostname de client verbinding zoekt. Dit maakt het mogelijk voor de server om meerdere certificaten te presenteren, en daardoor aan één IP-adres en poort (poort 443) verschillende websites met SSL beveiliging te verbinden. Door gebruik van SNI vervalt de noodzaak voor het gebruik van aparte IP-adressen voor iedere website met SSL beveiliging op een webserver.

[Blaatpraat]

Was even in de war: ik bedoelde UCC met wat ik zei.
SNI is inderdaad wat jij zegt, waardoor de noodzaak voor verschillende ip's vervalt.

[wolfero]

Voor een SSL formulier heb je een eigen ip en vaak dus eigen serverruimte nodig, een gedeeld SSL certificaat staat niet echt netjes. Daarbij is het ook nog eens erg duur...

[LinuZZ]

met sni is dat ook niet meer nodig

[Yggdrasil]

Helaas kun je geen SNI gebruiken als je nog klanten hebt die IE8 gebruiken (de nieuwste IE versie op Windows XP). Die situatie zal hopelijk snel verbeteren.

[HansvDr]

En android 2.x

En als je server Windows 2008 is

Voorlopig hier dus geen optie. Max 1 SSL per IP adres dus. Nou ja, dan maar wat meer IP adressen per server gebruiken...

[Yggdrasil]

Inderdaad. Helaas maakt dat de deployment ook wat complexer. In plaats van eenvoudig via Puppet een extra vhost uitrollen moet er nu eerst een IP adres aangevraagd worden, gekoppeld worden aan de server en dan een vhost speciaal voor dat IP. Ik zal in ieder geval blij zijn als dat soort dingen niet meer nodig is.

[Probook8979]

U geeft al aan dat het (érg) prijzig kan zijn, wat moet ik daarbij denken?

In wat voor prijsklasse hebben we het erover? Is het jaarlijks? Maandelijks?

Correct me if i'm wrong

[Siebsel]

Eigen IP is niet meer nodig, dus feitelijk kun je met elk hostingpakket een SSL certificaat aanschaffen (bij shared hosting/managed hosting ben je natuurlijk afhankelijk van de meewerking van je provider). Dit kan zoals eerder gemeld gratis via startssl.com, of voor +/- €11 via sslcertificaten.nl (kosten zijn per jaar)

[Yggdrasil]

Jaarlijks €9,- voor een Comodo PositiveSSL certificaat. Werkt uitstekend. https://www.sslcertificat...vragen/Comodo/PositiveSSL

[TECHcrime]

Heel leuk dat Google de https hoger wilt zetten, maar een SSL cert moet op een uniek IP adres op de server. Ook niet erg, behalve dat de IP-adressen al op zijn en we het dus met het handje vol moeten doen die we nog hebben.

Nog lang niet iedereen zit op IPv6 only en SNI is ook niet altijd een optie. Heel leuk dat Google dit doet, maar ik denk dat de resterende IP-adressen nog sneller op zullen zijn..

[M@rijn]

Hoezo is SNI geen optie? Enkel verouderde systemen kunnen hier niet mee overweg. Zorgt er misschien voor dat de uitfasering van XP ook weer wat vlotter gaat....

[Evianon]

XP en in mindere mate Android 2.x zijn toch echt nog goed voor 10 - 20% van de bezoekers, een beetje afhankelijk van welke landen / markten je bedient.

Voor een beetje site gaan die aantallen toch aantikken, als je gewoon je geld verdient met de bezoekers / klanten op je site wil je die bezoekers echt niet missen en heb je verder weinig met uitfasering te maken. Verder krijgen bezoekers zonder SNI een dikke error over een onveilig certificaat, als onwetende gebruikers daarover gaan klagen op internet is dat ook niet best voor je reputatie, terwijl je zelf eigenlijk niets fout doet.

Het extra IP adresje voor het certificaat zou geen enkel probleem geweest zijn als de consumenten ISP's eens vooruit waren gaan denken wat betreft IPv6, maar zolang de meeste klanten niet klagen en ze er geen geld aan verdienen... Ik hoop dat ze de bal allemaal keihard terugkrijgen als ze binnenkort IPv4 adressen voor xxx per stuk moeten gaan opkopen.

[CAPSLOCK2000]

XP en in mindere mate Android 2.x zijn toch echt nog goed voor 10 - 20% van de bezoekers, een beetje afhankelijk van welke landen / markten je bedient.

Voor een beetje site gaan die aantallen toch aantikken, als je gewoon je geld verdient met de bezoekers / klanten op je site wil je die bezoekers echt niet missen en heb je verder weinig met uitfasering te maken.

Sites waar dat een probleem voor is kunnen ook wel een fatsoenlijk hostingpakketje betalen. Ze verdienen er immers geld mee. Als die paar tientjes voor een certificaat te veel zijn voor je bedrijf dan heb je grotere problemen.

Verder krijgen bezoekers zonder SNI een dikke error over een onveilig certificaat, als onwetende gebruikers daarover gaan klagen op internet is dat ook niet best voor je reputatie, terwijl je zelf eigenlijk niets fout doet.

Deze gebruikers zullen aan de lopende band problemen hebben en dit soort meldingen krijgen. Als de meerderheid van de websites SNI gebruikt (en dat verwacht ik wel) zullen ze het snel genoeg door krijgen.

Het extra IP adresje voor het certificaat zou geen enkel probleem geweest zijn als de consumenten ISP's eens vooruit waren gaan denken wat betreft IPv6, maar zolang de meeste klanten niet klagen en ze er geen geld aan verdienen... Ik hoop dat ze de bal allemaal keihard terugkrijgen als ze binnenkort IPv4 adressen voor xxx per stuk moeten gaan opkopen.

Hear! Hear!
Misschien dat deze hele actie nog wel gunstig is voor IPv6. Als je bij een IPv4-only provider veel meer foutmeldingen krijgt dan bij een provider die ook IPv6 levert zou dat een argument kunnen zijn om over te stappen. Van de andere kant, wie nu nog IE6 gebruikt zal waarschijnlijk niet beseffen wat het probleem is en nog nooit van IPv6 gehoord hebben.

[arjankoole]

Hoezo is SNI geen optie? Enkel verouderde systemen kunnen hier niet mee overweg. Zorgt er misschien voor dat de uitfasering van XP ook weer wat vlotter gaat....

Zelfs Windows XP is geen probleem, als je IE 7 of hoger geen IE gebruikt. Zo te zien gebruiken de meeste browsers hun eigen SSL/TLS implementatie.

Alleen als je dus nog stug XP en IE 6 draait heb je een issue, maar laten we wel wezen, beiden zijn end of life, end of support. Daar kan je gewoon geen rekening meer mee houden.

[Reactie gewijzigd door arjankoole op 23 juli 2024 04:48]

[gnu]

XP kan met geen enkele IE versie SNI gebruiken.

[arjankoole]

XP kan met geen enkele IE versie SNI gebruiken.

Je hebt gelijk, ik las het verkeerd.

[Mavericky]

Ik dacht dat alleen Windows XP vereistte dat een website een dedicated IP nodig heeft voor een SSL verbinding? Aangezien Windows XP niet meer ondersteund wordt en echt al verouderd is, kan je als website eigenaar besluiten om niet een dedicated IP te gebruiken.

[Yggdrasil]

Dat is eigenlijk een economische beslissing i.p.v. een technische. In ons geval hebben we nog teveel IE/XP bezoekers om SNI te gebruiken. Hopelijk niet lang meer.

[Zer0]

Een SSL-certificaat hoeft helemaal niet aan een specifiek IP, maar is in de meest simpele vorm gekoppeld aan een FQDN (dns-naam van de server) of aan een heel domein (wildcard)

[Tjahneee]

Kan iemand mij vertellen waarom het zin heeft om beveiliging te moeten gebruiken op bijvoorbeeld een kleine informatie pagina waar je niet eens een form of iets dergelijks hoeft te in te vullen? Dus al heb ik een tekst only pagina met een download link en een changelog en wat info moet ik daarbij investeren in een certificaat om beter gezocht te worden. Kan Google beter de inhoud scannen om te kijken of er forms of andere inputs mogelijkheden zijn en daarop beslissen of de pagina een certificaat nodig heeft of niet. Of heb ik het nou verkeerd?

[Verwijderd]

Kort: heeft erg weinig zin.

Maar als je alleen al een zoekfunctie op de site hebt staan wordt er data verstuurd. Echt gevoelig is die data niet maar wel te onderscheppen.

Maar nagenoeg elke website heeft wel een CMS. Die zou je toch eigenlijk wel over ssl willen hebben.

[Yggdrasil]

In dat specifieke geval zal je waarschijnlijk ook niks merken van het effect op je ranking en is dit dus geen zorg. Het merendeel van de moderne sites is echter complexer en heeft hier wel baat bij. Ik vind het daarom een goede keuze dat men het stimuleert.

[hackerhater]

Ik vraag me af hoe Google gaat reageren op sites die op beide bereikbaar zijn.
Mijn eigen sites kan je straks gewoon over http en https bezoeken tot je op de login of registratie komt.
Dan wordt je geforceerd naar https.

[Anoniem: 463321]

En vanaf dat moment dan ook alles https? Hoeveel sites zijn er niet die pagina's of delen er van nog gewoon via http laten zien nadat je via https bent ingelogd. Er zijn er velen helaas.

[hackerhater]

Jup. alles op https en de site accepteerd het dan ook niet dat je de http-versie aanroept.

[bantoo]

Iedere website(bijna) doet nog beide aangezien op het moment dat jij www.website.com intikt je browser gewoon een verzoek op poort 80 uit typt. Niemand tikt meer bijna http:// in en al helemaal niemand https://. Dat verzoek op poort 80 kan je wel naar de https versie forwarden maar je draait hoe dan ook beide.

[Bassievdb]

Als je simpelweg een website host, heb je als huurder niet altijd de nood of de kennis van https. Vaak ook wordt dat niet standaard ingesteld door de hosting companies. Zoals hierboven ook vermeld, een statische website heeft absoluut nul komma nul baat bij het feit of het verkeer nu over http of https loopt..

[Verwijderd]

En je admin/beheer/cms gedeelte dan?

En gebrek aan kennis is noooooit een argument. Als je websites gaat hosten moet je je gewoon inlezen. Je kan aan de pomp ook niet claimen dat je het verschil tussen diesel en benzine niet weet en gewoon maar "iets" tankt.

[Anoniem: 463321]

Als het enkel zou gaan tussen de keuze http of https in een instellingenvenster dan heb je gelijk maar helaas komt er meer kijken bij de keuze voor https.

[Verwijderd]

Jep, dat weet ik, kost inderdaad een uurtje om je in te lezen en een paar minuten tijd per site om zoiets te regelen. Tenminste, dat is mijn ervaring met 40+ websites bij 5 verschillende hosters, varierend van shared hosting, vps tot eigen servers.

[Dannydekr]

Ik roep dit nu al maanden! Ik heb mijn belangrijkste webshops al volledig omgezet. Snelheidsverlies is er bijna niet, soms is alles zelfs sneller. SPDY, OCSP Stapling, goede caching en een CDN met SSL (liefst ook SPDY) zijn dan wel een vereiste. Ik haal 99/100 in Pingdom en de 2.9MB frontpage laadt in 1.30 seconden.

Een goed SSL certificaat heb je voor 3 euro per jaar, de implementatie in Nginx is heel makkelijk, de optimalisatie zijn veel tutorials voor. Wordpress kan er tevens prima mee omgaan en snelheid is geen probleem meer. Kortom: ga gewoon over op SSL, je draagt bij aan een veiliger web en wordt er nu dus ook voor beloond.

[MrMarcie]

Waar kan ik die goede krijgen voor € 3,=?

[Dannydekr]

http://www.ssls.com/lp/3....MT8pNCCgcACFaYIwwodtzIAVA

[MrMarcie]

Dank je.

[lenwar]

Vreemde ontwikkeling. Ik wil graag de beste zoekresultaten voor mijn zoekopdracht. Dit staat dus los van of een site http of https is wat mij betreft.

Overigens zou het geen probleem moeten zijn met beschikbare IP-adressen enzo:

Met behulp van SNI kan je meerdere SSL certificaten op één IP adres gebruiken. Vrijwel alle (moderne) browsers ondersteunen het. Het vereist alleen dat je webserver het ook ondersteunt. (je Apache moet bijvoorbeeld zijn gecompileerd met een SNI-enabled versie van OpenSSL)

RFC: http://www.ietf.org/rfc/rfc4366.txt
Documentatie van Apache Foundation: http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

[CAPSLOCK2000]

Vreemde ontwikkeling. Ik wil graag de beste zoekresultaten voor mijn zoekopdracht. Dit staat dus los van of een site http of https is wat mij betreft.

Als de ene website veel betere informatie heeft dan de andere dan gaat het ene puntje dat je voor https krijgt het verschil niet maken. Als er twee sites met dezelfde informatie zijn, dan heb ik liever die site die https gebruikt.

[Anoniem: 463321]

Er zullen zelden sites zijn met exact dezelfde informatie. En als Google deze plannen doorzet zul je daar ook niet achterkomen want de http-site zal niet direct naast de https-variant komen te staan in de zoekresultaten.

Google is er voor zoekresultaten, de inhoudelijke kant van een site dus. Hoe zo'n site is opgebouwd interesseert mij niet.
Wat wordt de volgende stap? Sites die Java gebruiken lager zetten? Waar houdt het op?

[CAPSLOCK2000]

Als die twee sites niet dezelfde informatie hebben zal degene die het beste bij je query past bovenaan komen te staan. Als het verschil zo klein is dat het puntje voor SSL het verschil maakt dan zal die sites elkaar inhoudelijk niet veel ontlopen.

Er zal er altijd eentje boven de andere moeten staan. Google heeft al een hoop criteria die weinig met de informatie op de pagina te maken hebben. Allerlei sites met criminele bedoelingen worden nu ook onderdrukt om de gebruikers te beschermen, hoewel die misschien beter aan je query voldoen dan andere.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 04:48]