Bekijk Volledige Versie : SSL noodzakelijk bij een reselleraccount
Dag
Ik vraag me af in hoeverre SSL wenselijk is voor het controlpanel van een
reselleraccount. Het lijkt me vrij essentieel dat dit veilig zou moeten zijn omdat alle websites van klanten hierin worden beheerd; als mijn wachtwoord wordt gesnift kan diegene overal bij.
Ik ben op zoek naar een reselleraccount die dit kan, of is het overdreven dit te willen?
Een VPS zou dit sowieso moeten kunnen bij de meeste providers, maar heb weinig technische kennis om een server bij te houden.
Hebben jullie advies/meningen?
Ik hoop het
thnx!
Pjotter
Iedere hoster zal toch zeker wel het control panel op HTTPS draaien, al dan niet met een "echt" certificaat? Het is van groot belang om je logins te beschermen.
T.Bloo, dank voor je antwoord.
Bij mijn huidige provider (Flexwebhosting) is dat niet het geval, en ook bij Versio waar ik in eerste instantie heen wilde bieden ze geen https op directadmin.
Laatst heb ik bij Leaseweb een pakket afgenomen om te vergelijken, waar ze wel https hebben op Plesk (zonder certificaat overigens). Ik ben daardoor gaan twijfelen.
Leaseweb heeft echter geen gunstige reseller pakketten.
Heeft iemand tips?
dreamhost_nl
02/11/10, 17:40
Wij bieden ook gewoon SSL aan op onze (cPanel) servers; reguliere requests (http) worden zelfs automatisch doorgeleid naar de beveiligde omgeving (https). M.i. is dat toch wel het minste wat een provider moet kunnen aanbieden, maar mogelijk heeft dit mede te maken met het door de hoster gebruikte controle paneel.
Wat voor tip zoek je precies?
Ik zoek eigenlijk tips voor providers, van gebruikers die gebruik maken van een resellerpakket met SSL.
Zoals dreamhost_nl heb ik een gelijkaardige setup waarbij klanten doorverwezen worden van de http naar de https. Zo draaid mijn shared webmail voor klanten ook onder ssl alsook het klanten beheer paneel. Kortom mijn mening is dat alles waarvoor een login nodig is het onder https moet draaien (al dan niet onder een self-signed certificaat).
Ik zoek eigenlijk tips voor providers, van gebruikers die gebruik maken van een resellerpakket met SSL.
Aangezien hier vooral hosters zitten zul je dus niet zoveel gebruikers tegen komen. Misschien kan je een aanbieding gevraagd topic openen en dan zie je vanzelf wel welke providers aan je wensen voldoen.
Houd er even rekening mee dat het, los van wat je aangeboden mocht worden, kinderlijk eenvoudig is om met een packetsniffer wachtwoorden te achterhalen die in plain text van de gebruiker naar de server worden verzonden. Het gebruik van SSL met de populaire controlpanels is dus absoluut noodzakelijk.
De reseller logt namelijk ook met plain text in op de server. Als iemand eenmaal dat wachtwoord in handen heeft, kan hij naar hartelust met alle onderliggende accounts aan de slag.
Direct Admin heeft standaard geen SSL, maar door slechts 1 regeltje aan de configuratie file van direct admin toe te voegen kan wel alles via een beveiligde verbinding.
Alle panelen die door klanten worden bezocht werken ook bij ons via SSL (http requests worden ook doorgestuurd naar https), zeker nu het goedkoopste SSL certificaat nog maar ongeveer 10 euro kost is er eigenlijk niet meer een kosten argument waarom inloggen niet altijd beveiligd kan.
Bij DirectAdmin zet je zo SSL aan:
SSL certificaat generen: http://help.directadmin.com/item.php?id=15
SSL=0 naar SSL=1 veranderen in: /usr/local/directadmin/conf/directadmin.conf
DirectAdmin herstarten: service directadmin restart
That's it!
Ik vraag me af in hoeverre SSL wenselijk is voor het controlpanel van een
reselleraccount. Het lijkt me vrij essentieel dat dit veilig zou moeten zijn omdat alle websites van klanten hierin worden beheerd; als mijn wachtwoord wordt gesnift kan diegene overal bij.
Ik heb geen idee hoe wenselijk het is, maar (aangezien dit waarschijnlijk alleen over DA gaat) ik zou niet weten waarom je het niet standaard zou aanzetten.
Kan me wel voorstellen dat van selfsigned wisselen naar een signed cert weinig toegevoegde waarde heeft, zeker in een markt met weinig marges.
@vDong
Heb jij al gezien hoe hedendaagse browsers reageren op self-signed certificaten?
Bedankt voor jullie reacties (en bevestigingen) allemaal!
Heb al met een aantal providers contact gehad en die zeggen de SSL niet aan te kunnen zetten; alleen per website/domeinwaarbij dan een eigen ip nodig, of hoeft een eigen ip niet als je het zelf signeert?
Ik ben de enige die het certificaat te zien krijgt dus dat is verder geen probleem.
Aangezien hier vooral hosters zitten zul je dus niet zoveel gebruikers tegen komen. Misschien kan je een aanbieding gevraagd topic openen en dan zie je vanzelf wel welke providers aan je wensen voldoen.
dank dat zal ik doen
dreamhost_nl
03/11/10, 11:28
Klopt, wij hebben al onze servers recentelijk ook voorzien van een commerciëel SSL certificaat en alle door de servers zelfgegenereerde certifcaten daarmee vervangen. De hoeveelheid problemen (lees: meldingen) die met name FireFox gaf met zelfgegenereerde certificaten bij minder ervaren gebruikers kostte onze support soms flink wat tijd.
marsipulami
03/11/10, 11:31
Het is natuurlijk ook krom in het algemeen om als support of techneut tegen de gebruikers te zeggen dat die melding bij een unsignedcertificate normaal is en dat ze mogen doorklikken. Want als ze dan gaan internetbankieren en die melding zou eens een keer voorbij komen dan klikken ze ook massaal op doorgaan terwijl het dan absoluut niet de bedoeling is.
@ dreamhost,
Wij gebruiken ook ssl, dit kost tegenwoordig niks meer en dat beetje gemak wat er bij komt is alleen maar fijner
Voor de kosten hoef je het niet te laten natuurlijk, Comodo Essential 1yr $USD $9.95/yr. Domain verification is voldoende voor eerder genoemde zaken.
Hier de output van wat browsers met een self signed certificate op een testserver. Dit wil je je klanten toch niet voorschotelen lijkt me. :thumbdown:
Als we het dan toch over ssl certificaten hebben en de prijs daarvan, hier heb ik een tip voor de mensen die dit nog niet zouden weten. Startcom (startSSL) (http://cert.startcom.org/) heeft een free certificaat dat bedoeld is voor zaken als logins voor control panels, webmail, ....
Ah kijk dit ziet er toch wat veiliger uit voor de klant. :thumbup:
Op dit moment zie ik 2 nadelen:
- Klanten moeten een nieuwe URL gaan onthouden voor het controlpanel (irritant, verder geen bezwaar)
- Reseller klanten krijgen te maken met 1 centrale URL per server waar niet hun domein in zit maar een domein van ons (kan bezwaarlijk zijn voor bepaalde partijen)
Zodra dit opgelost is gaan we het richting alle servers maar eens forceren tot op dat moment maar eens beginnen met het rustig uitrollen binnenkort op alle servers waar het geen bezwaar is.
als je http://joucontrolpanel.nl in tikt wordt je automatisch doorgelinkt naar httpS://joucontrolpanel.nl
Als je cPanel gebruikt is dit al opgelost.
Als een gebruiker http://www.mijndomein.nl/cpanel typt word hij automatisch redirect naar https://www.servervanzijndomein.nl:2083
Tenminste als je dit zo instelt dan.
Het punt van de TS is, dat hij als reseller een SSL certificaat op *zijn reseller domein* wil hebben in combinatie met het control panel. Dat betekent dat het control panel programma meerdere SSL certificaten moet ondersteunen. De meeste panels op een andere poort dan 80 zullen dit niet doen. Je kunt wel met een interne proxy werken en dan het SSL certificaat aan Apache etcetera overlaten. Dus niet dat de klant van de reseller de domeinnaam van de server van de leverancier te zien krijgt.
Standaard gebruiken we DirectAdmin en alle klanten maken gebruik van http://sub.hundomein.tld:2222/. Daarnaast blijft het punt mbt resellers staan. Dat ze een nieuwe URL moeten onthouden is ook nog wat anders voor te verzinnen (DA op andere poort, op poort 2222 een redirect pagina).
De oplossing van t.bloo klinkt wel goed. Dat wordt denk ik de oplossing die wij maar gaan gebruiken (mede gezien het feit dat meerdere klanten reeds SSL voor de site gebruiken).
Als je cPanel gebruikt is dit al opgelost.
Als een gebruiker http://www.mijndomein.nl/cpanel typt word hij automatisch redirect naar https://www.servervanzijndomein.nl:2083
Tenminste als je dit zo instelt dan.
En dan kom je tot het probleem dat het certificaat niet geldig is omdat het een ander domein heeft dan hetgeen in het certificaat staat. Tenzei je voor iedere reseller een appart ip gebruikt en hier zijn eigen certificaat voor aanmaakt.
@vDong
Heb jij al gezien hoe hedendaagse browsers reageren op self-signed certificaten?
Ja, echter dat weegt niet op tegen het gewoon over http te doen.
dreamhost_nl
04/11/10, 08:23
En dan kom je tot het probleem dat het certificaat niet geldig is omdat het een ander domein heeft dan hetgeen in het certificaat staat. Tenzei je voor iedere reseller een appart ip gebruikt en hier zijn eigen certificaat voor aanmaakt.
Als je een SSL certificaat voor de server zelf hebt ingesteld heb je hier echt geen last van, zoals Domenico al aangaf wordt er door cPanel automatisch doorgesprongen als je het volgende intypt :
http://www.domeinnaamopserver.xx/cpanel/ -> https://servernaam.serverdomeinnaam.xx:2083/ of
http://cpanel.domeinnaamopserver.xx/ -> https://servernaam.serverdomeinnaam.xx:2083/
Bij voorgenoemd voorbeeld heb je alleen een SSL certificaat nodig voor servernaam.serverdomeinnaam.xx en krijg je geen vreemde (browser)meldingen.
Als je een SSL certificaat voor de server zelf hebt ingesteld heb je hier echt geen last van, zoals Domenico al aangaf wordt er door cPanel automatisch doorgesprongen als je het volgende intypt : ...
Dat is bij directadmin ook zo, gebruik het zelf op die manier. Maar waar het over ging was dat er providers zijn waar hun resellers willen dat https://server.resellerdomein.tld:xxxx ook werkt ipv doorverwijzing naar server.hoster.tld:xxxx. En dan moet je al iedere reseller een eigen ip geven en eigen ssl cert (in hoevere dit in control panel mogelijk is). Of zou je rare reverse proxy opstellingen kunnen maken.
dreamhost_nl
04/11/10, 16:23
Onze servers zijn al anoniem opgezet (dus niet servernaam.dreamhost.nl of zo iets), dus ontvangen we dat soort verzoeken eigenlijk nooit. Wellicht is het dan beter voor die reseller om voor een VPS te kiezen?
Onze servers zijn al anoniem opgezet (dus niet servernaam.dreamhost.nl of zo iets), dus ontvangen we dat soort verzoeken eigenlijk nooit. Wellicht is het dan beter voor die reseller om voor een VPS te kiezen?
Anoniem is het eigenlijk nooit, uit de whois van je domein kan je ook veel info halen. Zelf al is je domein 123abc456.tld. Dan moet de ptr op het ip ook hupeldepup noemen etc in een netblok van janpietAnoniem.
Heb directadmin op 2 poorten draaien; 2222 voor http verkeer en 2223 voor https. Force SSL staat dan ook niet aan. 2223 op whitelabel domein, mocht de klant dat niet willen kan 2222 nog.
Whitelabel bestaat inderdaad eigenlijk niet, maar de meesten zijn er tevreden mee.
ik las zelfs dat er tegenwordig mogelijkheden zijn om SSL mogelijk te maken voor klanten, via TLS.
maar ook via een andere techniek waarbij het cert dus op hostnaam basis werkt (en dus vhost compatible is)
t nadeel lijkt te zijn; dat het niet werkt op oudere browsers (moz firefox eerder dan 3.0 MS IE onder winxp. etc,
ik ben eigenlijk benieuwd naar wie er al ervaring heeft met goedkope beveiliging voor budget klanten. je zou zolangzaam aan toch zeggen met 2011 al voor de deur dat een hostname bassed ssl key - standaard bij je account hoort.
persoonlijk vind ik het zo onderhand wel eens tijd worden dat 'internet beveiliging' standaard zou moeten worden ingevoerd door sidn : om maar wat te noemen, de inlog gegevens van een simpel forum en het bekende feit dat meer dan de helft van alle internetters niet in staat is om meer dan 1 wachtwoord te onthouden kortom, snif ik je ww op blaatforum.tld is de kans groog dat die passwordt ook gaat werken op je provider.nl/email met alle gevolgen en mogelijk data-diefstal gevolgen vandien...
maar het is iets waar ik al langere tijd aan het over denken ben...
ik ben alleen van mening dat het lang niet alleen voor de inlog pagina van pleks zou moeteng gelden...
bron: http://en.wikipedia.org/wiki/Server_Name_Indication#Support
ik las zelfs dat er tegenwordig mogelijkheden zijn om SSL mogelijk te maken voor klanten, via TLS.
maar ook via een andere techniek waarbij het cert dus op hostnaam basis werkt (en dus vhost compatible is)
t nadeel lijkt te zijn; dat het niet werkt op oudere browsers (moz firefox eerder dan 3.0 MS IE onder winxp. etc,
bron: http://en.wikipedia.org/wiki/Server_Name_Indication#Support
Wij hebben hier al flink naar zitten kijken. Bijkomend probleem is dat (omdat de data encrypted is) het eerste deel van de handshake plaats vind met de default vhost aangezien het gewenste domein op dat moment nog niet bekend is. Hierdoor krijgt de bezoeker alsnog een melding "fout certificaat" TENZIJ je op de default vhost een multi-domein SSL certificaat plaatst met daarin alle domeinen die gebruik maken van SNI. En een multi-domein certificaat is weer niet goedkoop.
Zodra de SSL handshake is voltooid is het gewenste domein leesbaar voor apache en kan het juiste certificaat getoond worden.
een multi-domein SSL certificaat plaatst met daarin alle domeinen die gebruik maken van SNI
en die moet je dan iedere keer aan laten passen als er een nieuwe vhost bij komt? of kun je ook wildcard domeinen *.* krijgen?
aangezien het gewenste domein op dat moment nog niet bekend is
voor zover ik begreep, zou dat met SNI nu juist, niet het geval morgen zijn zodra het geconfigureerd staat op je server, en je browser het ondersteund,
de browser stuurt (als ik 't goed begrijp) namelijk het gewenste domain direct al mee tijdens de eerste aanvraag dus nog VOOR de handshake.. dat zou nu juist het hele punt moeten zijn van SNI ...
deze pagina (http://wiki.cacert.org/VhostTaskForce)geeft daar mogelijk wat meer duidelijkheid over...
voor zover ik begreep, zou dat met SNI nu juist, niet het geval morgen zijn zodra het geconfigureerd staat op je server, en je browser het ondersteund,
de browser stuurt (als ik 't goed begrijp) namelijk het gewenste domain direct al mee tijdens de eerste aanvraag dus nog VOOR de handshake.. dat zou nu juist het hele punt moeten zijn van SNI ...
deze pagina (http://wiki.cacert.org/VhostTaskForce)geeft daar mogelijk wat meer duidelijkheid over...
Edit: sorry, je hebt gelijk :) wat ik vertelde IS het probleem, SNI is daar juist de oplossing voor :p
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
@ t.bloo:
With a *.*.* wildcard certificate, you could impersonate www.amazon.com, www.paypal.com and everyone else you want with one certificate.
En daarom is het dus onveilig.
heet grootste nadeel van sni is dat het (geloof ik) nog niet standaard enabled is in openSSL, - en dat er nog behoorlijk wat brouwsers zijn die het NIET onderstuenen. Konqueror (kde) Internet Explorere (windows xp >>> wel onder vista en win7 ) .
en Safari OSX ondersteunen het dus niet.
Moz Firefox, 3.x Google Chrome in recente versies (ook onder xp). ondersteunen het dan in ieder geval wel. dat is ook de reden waarom ik het toch overweeg. ondanks dat deze functie zich niet echt leent voor gracefull degradation.
dit soort dingen laat toch zijn dat het ook voor webbouwser steeds interessanter wordt om hun bezoekers te attenderen op de noodzaak van een moderne browser.
SebastiaanStok
14/12/10, 11:51
persoonlijk vind ik het zo onderhand wel eens tijd worden dat 'internet beveiliging' standaard zou moeten worden ingevoerd door sidn : om maar wat te noemen SIDN is een TLD beheerder geen hoster of iets :)
Ze kunnen jouw dus niet verplichten om SSL/TLS te gebruiken, zij kunnen alleen de DNS schakel beveiligen (zoals dat nu ook in zekere maten gebeurd met DNSSEC).
Helaas zijn er nog veel systemen die gebruik maken van win xp (laatst nog opgeleverd bij een klant). Vaak is dan ook nog een IE de standaardbrowser, voorlopig genoeg reden om nog niet afhankelijk te willen zijn van SNI.
Ze kunnen jouw dus niet verplichten om SSL/TLS te gebruiken, zij kunnen alleen de DNS schakel beveiligen (zoals dat nu ook in zekere maten gebeurd met DNSSEC). sidn zou ervoor kunnen kiezen om samen met z'n leden te bekijken of een rol als bijv CA voor haar is weggelegd (dat was mijn punt) waarbij je dus een standaard name-based cert krijgt voor *.domain.nl - dat is allicht beter dan een self signed ding, en legt misschien net genoeg in de schaal om een laagste level trusted ca te worden in je browser.
Helaas zijn er nog veel systemen die gebruik maken van win xp (laatst nog opgeleverd bij een klant). Vaak is dan ook nog een IE de standaardbrowser, voorlopig genoeg reden om nog niet afhankelijk te willen zijn van SNI. je kunt als webontwikkelaar niet blijven achterhouden omdat bepaalde bedrijven etc het vertikken om te upgraden naar een moderne infra. ik hoor zovaak < xp doet het nog dus waarom> mijn pakket heeft IE6 nodig dus waarom een nieuwe browser.
mijn stelling omdat het dan veiliger wordt op het net omdat je met sni elke forum login netjes kunt afschrermen voor MiM's en packet sniffers.
dan moeten ze maar over op firefox (werkt ook onder xp) ... en FF kan het gewoon WEL... als we nooit wat wilde veranderen op het web hadden we beter bij ie4 kunnen blijven...
dit alles wil niet zeggen dat je dus al je klanten etc enkel nog maar naar tls met sni moet aanbieden in tegen deel, betalende klanten willen meer veiligheid en dus betere bescherming dan is een eigen cert en een eigen ip alleen maar goed. maar voor het gross dat nu helemaal geen ssl-achtige beveiling gebruikt zou sni al een hele verbetering zijn....
die browsers die het niet ondersteunen kunnen dus of http blijven gebruiken (als de site dat toestaat). of de beveiligings-waarschuwing (op eigen risico) negeren. met datadiefstal dus als mogelijk gevolg...
Laat de SIDN eerst zijn domeinentaak maar op orde krijgen voor ze ook nog CA moeten gaan spelen... :O
SebastiaanStok
14/12/10, 14:39
Ja idd :) maar het idee zelf is zo lang zo gek nog niet.
De TLD beheerder is de hoogste schakel van het domein ( de '.' root uitgesloten natuurlijk ) dus zij kunnen met zekerheid zeggen of iemand de eigenaar een domeinnaam is.
Wat is er mis met "eigen verantwoordelijkheid"? Je kunt wel voor alles een organisatie laten meekijken.