Onderwerp: Google Online Security Blog: HTTPS as a ranking signal

Hier al verschillende aanvragen gehad van klanten, wat is eigenllijk het standpunt van RIPE hier tegenover..
Vanuit het opraken van IPv4 adressen vind ik dit gewoon een mega belachelijke stoot van Google...

De apache de functie aanzetten die SSL op shared IP mogelijk maakt ? Ik twijfel om het op shared servers aan te gaan zetten


Sent from my iPhone using webhostingtalk mobile app

Oorspronkelijk geplaatst door bibawa

Hier al verschillende aanvragen gehad van klanten, wat is eigenllijk het standpunt van RIPE hier tegenover..
Vanuit het opraken van IPv4 adressen vind ik dit gewoon een mega belachelijke stoot van Google...

http://en.wikipedia.org/wiki/Server_Name_Indication

Ik gebruik het al op verschillende servers en het werkt perfect!

Mocht je DirectAdmin gebruiken:
http://directadmin.com/features.php?id=1100

Ja maar dat geeft / (gaf vorig jara toch) problemen met iets oudere browsers en met name IE als ik me niet vergis..

I.E. 6 kan idd niet omgaan met, vanaf I.E. 7 gaat het prima...

Ik geef mijn klant de keuze, SNI hosted is een paar euro per maand goedkoper (prijs per IP + uplift)

Maar als je klanten op dedicated ips zet zijn we er gewoon met zijn allen - de al zo kostbare - IPv4's door aan het jagen...
Is dat allemaal wel zo'n goed plan dan? Ik denk dat we nog lang niet klaar zijn voor versie 6 van IP..

Oorspronkelijk geplaatst door bibawa

Maar als je klanten op dedicated ips zet zijn we er gewoon met zijn allen - de al zo kostbare - IPv4's door aan het jagen...
Is dat allemaal wel zo'n goed plan dan? Ik denk dat we nog lang niet klaar zijn voor versie 6 van IP..

Als je 'IE 6' support dan een reden vindt om een dedicated IP aan op te offeren ?
'dedicated IP vanwege SSL' is ook een legacy argument waar we vanaf moeten.

Oorspronkelijk geplaatst door bibawa

Ja maar dat geeft / (gaf vorig jara toch) problemen met iets oudere browsers en met name IE als ik me niet vergis..

Je weet hopelijk toch wel dat er naast SNI ook nog andere oplossingen zijn voor dit probleem zoals cloudssl certificaten (https://www.globalsign.com/cloud/mul...p-address.html). Wat mij betreft ben ik het volledig eens met @visser dat een ssl certificaat geen geldige reden meer is voor een dedicated IPv4 omdat er alternatieven genoeg zijn en het argument voor een dedicated IPv4 ten voordele van een betere SEO is ook geen geldige reden.

Alternatieven genoeg en die implementeren we hier ook , maar ik had het niet over ons maar over ons allemaal.. Er gaan gewoon veel meer IPs in gebruik genomen worden nu om die reden...

Tot nu toe slechts enkele nieuwe SSL certificaten hierdoor verkocht. SNI gebruiken we verder nog niet, voor ons is hier (voorlopig) nog geen noodzaak toe en er is nog een te groot deel dat Windows XP/IE 6 gebruikt. Daarnaast is het zo dat veel klanten met SSL toch al een eigen VPS hebben met een eigen IP adres...

Bij een SSL certificaat kunnen we een apart IPv6 adres leveren, maar we gebruiken SNI voor IPv4. Bezoekers met een browser die SNI niet ondersteunen zouden onderhand wel een keer hun browser geüpdate moeten hebben. Bij het leveren van een SSL certificaat informeer ik mijn klant hierover en deze kan ook kiezen voor een andere oplossing dan SNI, zodat ook oudere browsers de website zonder problemen kunnen bezoeken.

Oorspronkelijk geplaatst door Mark17

Tot nu toe slechts enkele nieuwe SSL certificaten hierdoor verkocht. SNI gebruiken we verder nog niet, voor ons is hier (voorlopig) nog geen noodzaak toe en er is nog een te groot deel dat Windows XP/IE 6 gebruikt. Daarnaast is het zo dat veel klanten met SSL toch al een eigen VPS hebben met een eigen IP adres...

Oorspronkelijk geplaatst door Peter Bin

Bij een SSL certificaat kunnen we een apart IPv6 adres leveren, maar we gebruiken SNI voor IPv4. Bezoekers met een browser die SNI niet ondersteunen zouden onderhand wel een keer hun browser geüpdate moeten hebben. Bij het leveren van een SSL certificaat informeer ik mijn klant hierover en deze kan ook kiezen voor een andere oplossing dan SNI, zodat ook oudere browsers de website zonder problemen kunnen bezoeken.

Daarom bestaat er dus cloudssl, dat toont gewoon een eigen certificaat indien SNI ondersteund is en indien SNI niet ondersteund is toont het een multidomain certificaat. Dus het excuus over gebruikers die te lui zijn hun OS/browser te updaten, telt ook al lang niet meer wat betreft een apart IPv4 om ssl werkend te krijgen.

Naast het feit dat gebruikers die nog op oude systemen zitten die geen SNI support hebben het verder ook weinig uitmaakt of deze gebruik maken van een https/ssl verbinding want hun systemen zijn zelf al zo lek als een zeef en dan doe je niet de moeite om daar een man in the middle attack voor te gebruiken, maar exploit je gewoon het systeem zelf . Misschien dat sommige mensen hun systemen eens wat vlugger zouden updaten als ze geen gebruik meer kunnen maken van veilige websites (omdat iedereen SNI implimenteert), want nu geeft dat eigenlijk een vals gevoel van veiligheid.

Oorspronkelijk geplaatst door The-BosS

Daarom bestaat er dus cloudssl, dat toont gewoon een eigen certificaat indien SNI ondersteund is en indien SNI niet ondersteund is toont het een multidomain certificaat. Dus het excuus over gebruikers die te lui zijn hun OS/browser te updaten, telt ook al lang niet meer wat betreft een apart IPv4 om ssl werkend te krijgen.

Ik had nog niet gehoord van CloudSSL, zal er eens naar kijken.

Oorspronkelijk geplaatst door Boskoop

I.E. 6 kan idd niet omgaan met, vanaf I.E. 7 gaat het prima...

Ik geef mijn klant de keuze, SNI hosted is een paar euro per maand goedkoper (prijs per IP + uplift)

Vanaf IE10 werkt het iid pas. Android systemen hebben ook problemen. In de laatste versie wel goede ondersteuning.

Oorspronkelijk geplaatst door Jovana

Vanaf IE10 werkt het iid pas. Android systemen hebben ook problemen. In de laatste versie wel goede ondersteuning.

Een belangrijk deel van de Android systemen draaien echter op oudere versies (mede doordat bv Samsung weinig/geen updates uit brengt en je enkel een update kan doen door te rooten).