Door Overcome:
- Let erop dat de plaatjes, die schijnbaar op een andere site staan, geen meldingen genereren dat delen van de https website niet zijn beveiligd (te weten het deel dat van de andere site wordt gehaald). Dat roept bij mensen irritatie op.
Ik ben het alles eens met wat Overcome schrijft, behalve het laatste! Overcome bedoelt het ongetwijfeld goed, maar het lijk mij essentieel dat https site beheerders snappen waar die irritatie vandaan komt...
@TS: het probleem bij "mixed content" (d.w.z. naast
https ook
http of ander onversleuteld verkeer) is dat dit qua security de doodsteek kan zijn voor elke https verbinding. Irritatie vanwege deze fout treedt slechts op bij een zeer klein aantal gebruikers (die de fout inzien).
Zoals Ivan Ristic in deze presentatie (
http://www.youtube.com/watch?v=HnBePucKIjc) uitlegt zijn er bar weinig sites die dit goed doen (nu we het toch daarover hebben, ook https://secure.security.nl/ en https://tweakers.net/ slaan deze plank volledig mis).
Lees ook
https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.0.pdf, zeer aan te bevelen!
(Ivan Ristic is de man achter
https://www.ssllabs.com/ssltest/index.html. Interessante statistieken zijn te zien op
https://www.trustworthyinternet.org/ssl-pulse/. Ivan is trouwens ook de hoofdauteur van mod_security.
Aanvullende tips (in chronologische volgorde voor jou):
Realiseer je goed dat het certificaat (zodra je deze hebt gekocht) met daarin de public key, vrij verspreid wordt. Het enige doel van het certificaat is aan te tonen dat de
public key van jouw webshop is. Het certificaat toont uitdrukkelijk NIET aan dat de gebruiker met jouw webshop communiceert; daar zorgt de private key voor (middels de zogenaamde "SSL handshake"). Die private key mag alleen op jouw server staan en mag nooit in verkeerde handen vallen. Denk na over je backup-proces: waar gaat die private key naar toe, en gebeurt dat in versleutelde vorm?
Als je voor een
RSA type sleutelpaar kiest (het meest gebruikt), volg dan het advies van Overcome (en bovenstaande PDF): gebruik een lengte van 2048 bits. Genereer dit sleutelpaar bij voorkeur op de webserver zelf, zodat je de private key niet hoeft te transporteren. Zorg ervoor dat het sleutelpaar voldoende "random" is. Bijv. OpenSSL maakt gebruik van verschillende bronnen voor randomness. Op een computer die al een tijdje aanstaat en netwerkconnectiviteit en/of gebruikerinteractie heeft gehad, is de kans op betere randomness groter dan op een computer die zojuist is geboot.
Kies een goedkope certificaatprovider, niet omdat je Nederlander bent, maar omdat het geen klap uitmaakt voor minstens 99% van de eindgebruikers (ik ken geen "normale eindgebruikers" die root certificaten uit hun webbrowser weggooien en/of bij elk bezoek aan een https site checken welke Certificate Authority het certificaat heeft ondertekend).
De tip van Overcome om een "Subject Alternative Name" voor
www.example.com in de certificaataanvraag (CSR = Certificate Signing request) op te nemen, dus naast de Common Name
example.com (of omgekeerd), is een goede. Check, voordat je jouw CSR indient, of de CA dat toestaat (mogelijk wordt er een toeslag berekend). Even Googlen wees uit dat bijv.
http://www.networking4all.com/nl/ssl+certificaten/producten/per+type/san/ geen toeslag lijkt te berekenen, maar wellicht zijn er goedkopere en/of betere CA's te vinden.
Zorg ervoor dat je jouw webserver zo configureert dat deze geen kwetsbare cipher suites gebruikt. Laat je server (gratis) testen door
https://www.ssllabs.com/ssltest/index.html (zet een vinkje voor "Do not show the results on the boards" om te voorkomen dat eventuele problemen meteen worden gepubliceerd op die site).
Maak je niet te veel zorgen als jouw server kwetsbaar blijkt te zijn voor de "BEAST" attack. Als jouw site geen mixed content gebruikt is de kans daarop verwaarloosbaar vergeleken met alle andere fouten die je bij https kunt maken en die jouw gebruikers lopen (rekening houdend met het feit dat je geen defensiesite aan het bouwen bent).
Maak niet de fout door https te associëren met "beveiligde website" (dat tast jouw geloofwaardigheid aan).
Is er sprake van gebruikeraccounts, hou je dan aan
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet. Achtergronden vind je in
http://www.h-online.com/security/features/Storing-passwords-in-uncrackable-form-1255576.html. De aangekondigde PHP versie 5.5 moet een boel leed op dit punt gaan helpen voorkomen (zie
http://www.h-online.com/open/news/item/PHP-5-5-should-reduce-password-sloppiness-1707835.html).
Aanvullende "PKI" info kun je vinden in mijn FAQ (
http://www.security.nl/artikel/42740/1/PKI_Certs_en_Public_Key_FAQ.html) waar ik hoognodig weer eens tijd in moet stoppen om deze aan te vullen en af te maken...