Technicka poznamka: virtualni servery podle HTTP/1.1 - tj. rozpoznavani az podle pozadavku v dotazu - neni pomoci SSL/TLS mozne udelat. Jedine, co je mozne realizovat, je pouziti cisla portu v URI:
https://www.neco.cz:1234/
Zaroven IMHO neexistuje ani moznost, jak tuto vec do SSL/TLS implementovat.
A proc by to nemelo byt mozne? Pridat dalsi Header do requestu prece neni zadny problem. Akorat by byl trosku problem s certifikaty - aby se v nich uvedena adresa shodovala s pozadovanou adresou. Ale i to by jiste slo vyresit nejakym updatem standardu.
Problem je samozrejme v tech certifikatech - ovsem ze jdou udelat virtualni https servery, ale vsechny budou posilat jeden certifikat, takze nebudou sedet jmena serveru, browsery budou protestovat a na duveryhodnosti to neprida. Je to problem slepice a vejce - server muze zjistit, ktery certifikat ma pouzit z http dotazu, ovsem ten request muze zpracovavat az po SSL nalezitostech (jinak by to moc secure nebylo), ke kterym ten certifikat potrebuje...
Takze pri stavajici implementaci HTTPS je to vicenene nepouzitelne.
Ale certifikát přece nemusí být vystavený jen pro jedno doménové jméno, může být vystaven třeba i na *.seznam.cz a pak lze provozovat více serveů na jedné IP adrese a prohlížeče protestovat nebudou. Jisté omezení je ovšem to, že musí všechny weby spadat do jedné domény.
Tim, ze certifikat muze byt vystaveny na *.domena.cz si nejsem nejak jisty. Alespon mam pocit, ze jsem takovou definici v SSL standardu nevidel.
V cn ma byt fqdn pocitace a o regularnich vyrazech nevim. On sice jde vygenerovat certifikat s *.domena.cz, ale je otazka, jak se s tim implementace SSL vyrovnaji. Mate nejaky odkaz pro vase tvrzeni?
Třeba v ceníku Thawte http://www.thawte.com/pricing.html je, je tam i poznámka, že nemusí fungovat s produkty od Microsoftu. Vím, že jsme ho ve firmě před časem testovali a nějak to fungovalo. Stačí ale zadat do Google nabo Altavisty hledat wildcard ssl certificate a najde se dost relevantních odkazů.
Tusim, ze dalsim prikladem muze byt www.sourceforge.net, kde ¨drive bylo uvedeno, ze HTTPS verze spojeni nefunguje s Internet Explorery, nyni tam je, ze je vyzadovan IE 5.5 ..coz by imho mohlo byt zpusobeno timtez...
To be more flexible (when you use different hosts under your virtualhost.com domain) you can alternatively use a wildcard pattern here, for instance *.virtualhost.com. But remember that this doesn't work with all browsers.
Na co je mne certifikat, ktery funguje jen pod nekterym prohlizecem? To je snad horsi nez nektera rozsireni HTML. Brr.
Coz si tak treba vyrobit certifikat pro *.*.cz ?
Jenom by mne zajimalo, co vedlo navrhare prohlizecu, aby neco takoveho implementovali. Z bezpecnostniho hlediska je to pekne nechutne.
Jelikoz se tady smesuje nekolik mnoho veci, dovolim si take prispet - odpvoed je to vice mene na cely thread (nejenom Petrovi), ale tady bylo nejvhodnejsi misto na pripojeni
Soucasne HTTPS skutecne nelze pouzit na virtualni servery - je to proto, ze SSL/TLS hanshaking musi probehnout driv nez se prenese prvni byte uzivatelskych dat (protoze certifikat mimo jine zajistuje/ma zajistit, ze se ani request nedostane do nepovolanych rukou) pritom ale v soucasne dobe se teprve behem predani requestu zjisti jakemu serveru je request urcen a tedy jaky certifikat je "prislusny" - to je problem navrhu protokolu, ktery nelze nijak odstranit jinak, nez zmenou protokolu - v ramci SSL/TLS hanshakingu je nutne predat iformaci na zaklade ktere bude moci protistrana vybrat patricny z vice moznych certifikatu.
Napad s wildcard certifikaty je prakticky nepouzitelny a to hned ze dvou duvodu - poprve, pozaduje, aby organizace mely "spolecny" certifikat - to jednak snizuje bezpecnost, nezajistuje ochranu dat prenasenych jedne spolecnosti pred slidilem ze spolecnosti druhe, snizuje to bezpecnost i z hlediska uzivatele, protoze sice vi, ze nepredava sva citliva data kamkoliv do sveta, ale pouze jedne z mnoha spolecnosti, ktere maji spolecny server (coz je sice lepsi, ale ne dobre). Podruhe - ano wildcardovani neumoznuje rozumnym zpusobem na serveru hostovat 15 ruznych serveru domen druhe urovne - to by sice slo obejit konstrukci "nebo", ktera umoznuje vygenerovat certifikat i takto: www.(fio|spad|ebroker|akcie).cz coz sice umoznuje provozovat soucasne prave 4 servery, ale krome vsech nectnosti vyjmenovanych v "zaprve" si je potreba uvedomit, ze pokazde, kdyz mi pribude nebo ubude zakaznik na takovem serveru je potreba vygenerovat a nechat certifikovat novy klic. A nejhorsi prichazi zatreti SSL/TLS protokol VUBEC NERESI opravnenost pouziti konkretniho klice - tento cil si navrh protokolu VUBEC NEKLADL. Pouzivani FQDN jako metody zjisteni OPRAVNENOSTI UZITI klice neni vubec integralni soucasti SSL/TLS protokolu - tento protokol je vystaven na axiomu "kdo ma prislusny privatni, certifikovany a nerevokovany klic ten JE jeho opravnenym vlastnikem" - z definice a bez diskuse. Proto je take tato metoda v kazdem prohlizeci implementovana jinak, proto nelze wildcardy pouzit obecne (a stejne by to nebylo dobre) a je to take nejderavejsi cast SSL implementace v prohlizecich - jde totiz pomerne snadno obejit. Vubec - tak jak je to udelano se jedna spise o mechanismus chranici obchodni zajmy certifikacnich autorit, protoze to znemoznuje pouzit jeden vystaveny klic na vice serverech, z hlediska bezpecnosti dat uzivatele vsak jde o prakticky bezcennou feature (nebo co hur, nebezpecnou feature, protoze laikovi dava falesny pocit bezpeci).
