Afdrukvoorbeeld
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_...cation#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.Citaat:
Oorspronkelijk geplaatst door ichat
Zodra de SSL handshake is voltooid is het gewenste domein leesbaar voor apache en kan het juiste certificaat getoond worden.
en die moet je dan iedere keer aan laten passen als er een nieuwe vhost bij komt? of kun je ook wildcard domeinen *.* krijgen?Citaat:
Oorspronkelijk geplaatst door DutchTSE
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,Citaat:
aangezien het gewenste domein op dat moment nog niet bekend is
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 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 :pCitaat:
Oorspronkelijk geplaatst door ichat
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.
SIDN is een TLD beheerder geen hoster of iets :)Citaat:
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
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.
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.Citaat:
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).
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.Citaat:
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.
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
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.