SSL voor hele website, goed of niet?

[iApp]

Hey allemaal!

Ik heb momenteel een website met een ingebouwde webwinkel. Het hele proces komt pas in actie wanneer de klant een item aanschaft, de SSL implantatie zou ik kunnen beperken voor alleen het betaalproces. Maarrrr... is het daarnaast verstandig als ik het voor de hele website implanteer? (Oftewel: zodra bezoekers de website bezoeken, ze al op een beveiligde verbinding zitten?)

Ik heb al wat gegoogled maar heb vooralsnog geen 'praktische' antwoorden gevonden. Ik stel de vraag daarom op Tweakers om er zeker van te zijn om een goede keuze te maken.

[Megamind]

Het enige verschil met SSL en niet SSL is de handshake. Er moet een beveiligde verbinding worden opgebouwd en dat kost resources als ik processor en geheugen.

Als je een kleine website hebt ga je dit niet merken, servers en clients zijn tegenwoordig ruim snel genoeg om dit zonder enige moeite te doen, als je heel veel bezoekers hebt dan is het een ander verhaal, anders is er eigenlijk geen reden imo om het niet te doen.

[jla]

Yoast.com (Joost de Valk) heeft er pas een blogbericht over geschreven misschien nuttig voor je om eens door te lezen: https://yoast.com/move-website-https-ssl/

[iApp]

Interessante link! Ik denk dat ik toch overstap naar SSL, zo te lezen heeft het niet veel impact op de snelheid van de website (heb ong. 10.000 unieke bezoekers per maand) en geeft het de bezoeker een 'veiliger' gevoel. Nu nog even een certificaat aanschaffen, moet goed komen denk ik!

[CodeCaster]

jla schreef op zaterdag 19 april 2014 @ 20:26:
Yoast.com (Joost de Valk) heeft er pas een blogbericht over geschreven misschien nuttig voor je om eens door te lezen: https://yoast.com/move-website-https-ssl/

Er wordt in dat hele blog met geen woord gerept over waaróm je een beveiligde HTTP-verbinding zou willen gebruiken, en in een eerder blog aldaar wordt alleen het verbergen van referrers als argument genoemd.

Lees dit artikel voor wat sterkere argumenten.

[iApp]

Nog een theoretische vraag: verminderd een SSL verbinding ook de kans op hackers / spammers?

[CodeCaster]

Nee. Met SSL weet degene die naar jouw site verbindt met aan zekerheid grenzende waarschijnlijkheid dat dat ook echt jouw site is, en niet een die er erg op lijkt, én weten degenen die de verbinding kunnen afluisteren niet wat er over de draad gaat.

Alle overige zaken (SQL injection bijvoorbeeld) kunnen net zo goed op HTTP plaatsvinden als over HTTPS.

[ Voor 4% gewijzigd door CodeCaster op 21-04-2014 18:13 ]

[iApp]

CodeCaster schreef op maandag 21 april 2014 @ 18:12:
Nee. Met SSL weet degene die naar jouw site verbindt met aan zekerheid grenzende waarschijnlijkheid dat dat ook echt jouw site is, en niet een die er erg op lijkt, én weten degenen die de verbinding kunnen afluisteren niet wat er over de draad gaat.

Alle overige zaken (SQL injection bijvoorbeeld) kunnen net zo goed op HTTP plaatsvinden als over HTTPS.

Oké, dus in feite worden de gegevens die worden uitgewisseld tussen de klant en de database beveiligd d.m.v. een 256 Bit encryptie. Die gegevens kunnen worden 'afgetapt', maar dan krijgt de hacker in dat geval de 256 Bit encryptie in handen i.p.v. de daadwerkelijke gegevens. Om die 256 encryptie te kunnen decrypten heeft de hacker jaren tijd nodig.

[SKiLLa]

Je bent met HTTPS (SSL) weldegelijk beter beschermd tegen MitM aanvallen dan met kale HTTP verbinding (vertrouwelijkheid + integriteit van de data in transit). SSL is echter niet perse 256-bits; dat hangt helemaal van de server configuratie + de client software af (preferred & supported ciphersuites). Een slechte server config stelt een aanvaller alsnog in staat de encryptie 'eraf te strippen' of juist zwakkere encryptie 'af te dwingen'. Zorg ook dat je certificaat minimaal een RSA-2408 bit of langer private key heeft; geen RSA-1024 of minder. Na configuratie kun je je SSL-config controleren op (b.v.) www.ssllabs.com off sslyze/openSSL client.

Het beste is de hele website uitsluitend onder https te laten draaien en op http hoogstens een (session-less !!!) redirect te plaatsen naar de https hoofdsite. En vergeet ook niet de HSTS header te configureren om sslstrip aanvallen te mitigeren.

[Elijan9]

iApp schreef op zondag 20 april 2014 @ 21:14:
Nog een theoretische vraag: verminderd een SSL verbinding ook de kans op hackers / spammers?

Ik zou zeggen: ja voor hackers, vooral wanneer bezoekers open Wifi gebruiken: al het netwerkverkeer naar jouw website kan dan afgeluisterd worden. (Dat is in elk geval het meest praktische scenario.)
Door SSL te gebruiken, kan de doorsnee hacker dan geen gevoelige data onderscheppen zoals gebruikersnaam/wachtwoord e.d.

[Janoz]

iApp schreef op maandag 21 april 2014 @ 19:01:
[...]


Oké, dus in feite worden de gegevens die worden uitgewisseld tussen de klant en de database beveiligd d.m.v. een 256 Bit encryptie.

Nee. De verbinding tussen de browser van de gebruiker en de webserver(apache, nginx, iis, etc) waarin je webapplicatie draait is beveiligd. Het heeft helemaal niks te maken met het stuk van de webserver naar de database.

Die gegevens kunnen worden 'afgetapt', maar dan krijgt de hacker in dat geval de 256 Bit encryptie in handen i.p.v. de daadwerkelijke gegevens. Om die 256 encryptie te kunnen decrypten heeft de hacker jaren tijd nodig.

Dit klopt inderdaad. Maar daarnaast is het ook nog zo dat de gebruiker ook de garantie krijgt dat hij daadwerkelijk met jou webshop aan het kletsen is, en niet met iemand die de site nagemaakt heeft.

[Xcalibur]

Ik heb wel eens begrepen dat Google pagina's over SSL niet / minder indexeert dan gewone pagina's.
Ik weet alleen niet of dat waar is :-)

[Nakebod]

Geen idee wat de huidige indexer doet qua http vs https, maar Google zou, volgens geruchten, juist betere posities in de zoekresultaten willen geven aan beveiligde sites: nieuws: 'Google wil sites met versleuteling hoger in zoekresultaten plaatsen'

Of je hieruit kan concluderen dat beveiligde sites minder/niet worden geindexeerd? Totaal niet. Maar het lijkt mij sterk eigenlijk. Ik denk eerder dat ze gewoon dezelfde weging hebben als een normale http site. Maar goed, dat is speculeren.