Security Professionals - ipfw add deny all from eindgebruikers to any

simpele webshop - welk ssl certificaat kopen ?

13-09-2012, 13:32 door Anoniem, 11 reacties
Beste Allemaal,

Ik vroeg me af welke ssl certificaat ik het beste kan kopen voor een webshop.
De betalingen gaan via ideal, dus dat deel vangt de bank op.

Er zijn tegenwoordig zoveel aanbieders, dat ik door de bomen het bos niet meer zie.
Het betreft 1 domeinnaam www. een zonder www. alleen de plaatjes heb ik op een andere subdomein gezet media.

Of maakt het niet zoveel uit, en kan ik gewoon de goedkoopste kiezen ???

Mvg,
Martijn
Reacties (11)
13-09-2012, 15:45 door Anoniem
Ik ben een Nederlander en raad je daarom aan voor de goedkoopste te gaan.
13-09-2012, 18:20 door Overcome
Ik zou zeggen: kies de goedkoopste, zeker voor een simpele webshop. Enkele tips (doe ermee wat je wilt natuurlijk):

- Zorg ervoor dat de certificaat uitgever bekend genoeg is dat het root CA certificaat is opgenomen in de certificate store van de grote browsers (Chrome, Firefox, etc). Zelfs de goedkoopste aanbieders staan er meestal wel in.
- Vergeet het extended validation verhaal (de groene adresbalk wanneer een https site wordt bezocht). Dat kost alleen maar meer geld zonder dat het jou of je klanten wat oplevert.
- Zorg ervoor dat het SSL certificaat zowel de DNS naam met als zonder "www" afvangt via het specificeren van een Subject Alternative Name (SAN). Dat scheelt geld en is voor de beveiliging van de site, zeker bij een 2048 bits sleutel, niet erg.
- 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.

Succes.
13-09-2012, 19:55 door [Account Verwijderd]
[Verwijderd]
13-09-2012, 22:14 door Erik van Straten
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...
14-09-2012, 09:52 door Anoniem
Zoveel nuttige informatie had ik niet verwacht ! Bedankt.

Ik ga het eens rustig doornemen en kijken of die media.domein.ext een probleem op gaat leveren i.v.m. irritante meldingen voor eindgebruikers.

Misschien moet ik het maar anders doen anders moet ik waarschijnlijk 3 ssl certificaten kopen (wildcard is te duur +/- 300 euro per jaar)

De subdomein www.domein.ext > forwarden naar domein.ext
en 1 ssl certificaat voor media.domein.ext

Dus iemand komt dan altijd uit op domein.ext en toont plaatjes van https://media.domein.ext
Ik vraag me af of er in dit geval ook meldingen komen naar klanten ?
14-09-2012, 10:48 door 0101
Door Anoniem: Zoveel nuttige informatie had ik niet verwacht ! Bedankt.

Ik ga het eens rustig doornemen en kijken of die media.domein.ext een probleem op gaat leveren i.v.m. irritante meldingen voor eindgebruikers.

Misschien moet ik het maar anders doen anders moet ik waarschijnlijk 3 ssl certificaten kopen (wildcard is te duur +/- 300 euro per jaar)

De subdomein www.domein.ext > forwarden naar domein.ext
en 1 ssl certificaat voor media.domein.ext

Dus iemand komt dan altijd uit op domein.ext en toont plaatjes van https://media.domein.ext
Ik vraag me af of er in dit geval ook meldingen komen naar klanten ?

In principe kun je drie verschillende certificaten gebruiken voor www.domein.tld, domein.tld en static.domein.tld. Let er dan wel op dat elk certificaat apart gedownload moet worden, wat voor een tragere verbinding kan zorgen. (StartSSL biedt overigens gratis 'basis' certificaten aan.)

Let er bij de configuratie trouwens ook op dat je sessies nog steeds gekaapt kunnen worden als je je sessie-cookie zowel via HTTP als HTTPS verstuurt. Google heeft in dit geval een apart cookie voor HTTP + HTTPS en alleen HTTPS, maar aangezien dit waarschijnlijk niet eenvoudig te implementeren is kun je ook mensen direct naar HTTPS doorsturen (Strict Transport Security + een secure flag voor je sessie cookie + een HTTP 301 redirect naar HTTPS).
14-09-2012, 13:22 door Anoniem
Houd er wel rekening mee dat het niet straightforward is om meerdere SSL sites met meerdere certificaten te runnen op 1 IP adres.
M.a.w. als je media.domein.ext daadwerkelijk een andere server is dan heb je geen probleem, maar als je dit alleen maar gedaan hebt met name based virtual hosting op een en dezelfde machine als www.domein.ext dan moet je gaan nadenken of je de complicaties en beperkingen van SNI wel wilt hebben.
Misschien ben je beter af als je je site ombouwt om bijvoorbeeld www.domein.ext/media/... te gebruiken.

Of je een apart certificaat nodig hebt voor domein.ext en www.domein.ext dat hangt van de uitgever af.
Wij kopen ons certificaat via WideXS bij Comodo, en als je daar domein.ext aanvraagt dan zetten ze er ongevraagd www.domein.ext bij als 2e naam.
(na een hoop vragen en frustratie waarschijnlijk)
Als je media.domein.ext aanvraagt dan krijg je ook www.media.domein.ext erbij.
14-09-2012, 13:25 door Anoniem
Die StartSSL heeft wel heel goedkoop als je vergelijkt met de rest van de wildcards
http://www.startssl.com/?app=40

Voor $59,-

Web server certificates (SSL/TLS)
Wild cards (*.domain.com)
Multiple domains (DNS Alt Names)
128/256-bit encryption
Object Code Signing
Client and mail certificates (S/MIME)
US $ 10,000 insurance guaranteed
Certificates 2 Years valid (730 days)

dan heb ik ook geen problemen met redirects en meerdere subdomeinen.

Bedankt voor de tip !
14-09-2012, 13:28 door Anoniem__
De meeste SSL certificaten, bijvoorbeeld die geleverd door Xolphin, hebben standaard SAN properties voor domein.ext en www.domein.ext, je zou dan alleen nog een certificaat erbij hoeven te nemen voor static.domein.ext.
14-09-2012, 15:45 door Anoniem
Het meeste is al gezegd, echter nog wel enige aanvulling op het mijns inziens kort door de bocht advies van neem de goedkoopste. Je hebt keuze uit drie soorten SSL certificaten, een DV (Domain validated), een OV (Organisation validated) en een EV (Extended validated).

Verder heb je hierbinnen keuze uit een variant op basis van 1 common name (domeinnaam) en op basis van meerdere domeinnamen. Een wildcard is ideaal als nog steeds wilt uitgaan van een vaste domeinnaam, maar daarvoor elke sub wilt kunnen hangen. Dus bij bv *.domein.ext kun je het certificaat ook laten werken voor alles wat je op het * kan plaatsen. Een SAN wordt vaak gebruikt als je meerdere domeinnamen wilt opnemen in het certificaat, dit kunnen ook interne servernamen zijn. Een ideale oplossing ook voor als je bijvoorbeeld meerdere webshops hebt.

Wat nog niet genoemd is dat toevoegen van organisatiegegevens ook als marketing middel ingezet wordt om bij je klanten vertrouwen te scheppen en dit vertrouwen kan helpen meer sales te genereren. Je laat zien wie je bent en dat je dit hebt laten controleren. Bij een EV wordt dit zelfs extra benadrukt met de bekende groene balk. Een Ov is een tussenoplossing, wel organisatiegegevns in je certificaat en wel gecheckt, geen groene balk.

Heeft dus niets met het technische verhaal erachter te maken, buiten de reeds genoemde extra voordelen. Technisch gezien zijn een DV, OV en EV allemaal gelijk. Maar je geeft wel aan (meest zichtbaar met een EV) dat je de beveiliging serieus neemt. Studies hebben aangetoond dat de aanschaf van een SSL-certificaat met EV kan leiden tot een omzetstijging van 5% en meer. Dat geld ook voor de bekendheid van de Certificate Authority (uitgever van het certificaat). Een site seal plaatsen op je website kan ook meehelpen. Overigens hoeft een EV niet duur te zijn.

Banken en grote webshops kiezen dus bijna altijd voor een EV. Zeker bij banken speelt dan ook het merk nog mee. Verder zijn er inderdaad veel aanbieders, maar dat zijn vooral de partijen die de wederverkoop van de SSL certificaten doen. Certificate Authorities zijn er veel minder, waarvan de bekenste wel Symantec, GeoTrust, Thawte, Commodo en GlobalSign zijn. Banken kiezen vaak voor Symantec (voorheen VeriSign geheten). Zie het zo. Jouw klant kent vaak niet de SSL aanbieders merken. Maar bijvoorbeeld Symantec kennen ze vaak wel van hun Norton antivirus. En zie, dat is marketing, het schept vertrouwen. Het kan, met de nadruk op kan, net bepalend zijn voor een klant om een product niet bij webshop X, maar bij webshop Y te bestellen. Als bijvoorbeeld webshop Y een groene balk heeft en ook een bekend SSL merk site seal bijvoorbeeld. Kan net dat stapje zijn.
Is net als met echte winkels, de ene loop je voorbij, de andere nodigt uit om in te lopen. Hoe groter je bedrijf/webshop/bank/etc, hoe groter de belangen en dan kan elk procentje omzet meer uitmaken. Je kunt hier natuurlijk ook naar toe groeien. Beginnen met een DV, later een OV/EV.

Wat je ook kiest, wettelijk gezien heb je wel een SSL certificaat nodig. Welke maakt niet uit.

Kortom. Insteek van keuze van een SSL certificaat is. Wat wil ik er mee? Wat wil ik er mee bereiken. Wil ik vertrouwen uitstralen en het als marketingtool inzetten? Is merk hierin belangrijk? En uiteraard als Nederlander, wat mag het kosten? Als je dat weet kun je naar een aanbieder gaan zoeken. Er is hier door Erik van Straten al een aanbieder genoemd, deze heeft ook een SSL certificaat wizard op hun website staan: https://www.networking4all.com/nl/ssl+certificaten/wizard/ .

Ik heb geprobeerd het zo eenvoudig mogelijk te omschrijven. De meeste specifieke details en technische weetjes zijn al beschreven. Bovenstaande reply helpt vooral dus voor mensen die weinig kennis van SSL hebben en gewoon eenvoudig een keuze willen kunnen maken.

Succes met je keuze.
14-09-2012, 16:55 door Anoniem
"dit kunnen ook interne servernamen"
Vroeger wel maar, inmiddels is niet dit niet meer mogelijk omdat dit te fraude gevoel is.
https://www.networking4all.com/nl/ssl+certificaten/veelgestelde+vragen/wijziging+san+uitgifte/

https://www.sslcertificaten.nl/ is voor sommige certificaten overigens goedkoper
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.