Debian Lenny alatt https kliensek azonositasa

 ( jusztin | 2010. október 1., péntek - 18:59 )

Kishazamban a szemelyi igazolvanyok kiadasanal igenyelni lehet a digitalis alairashoz szukseges kulcsot (azonositot) is de kulon is be lehet szerezni mas forrasokbol. Egy olyan regisztracios reszt es/vagy bejelentkezo oldalt szeretnek kialakitani ami azeket a kulcsokat hasznalja ...

Az oldalak mukodnek is szepen https abban az esetben ha a kienstol nem kovetelem meg a kulcs (vagy hogy nevezik) megletet, es akkor is ha egy konkret CA kulcsait igenylem meg akkor nincs gondom a php fugvenyekkel ki tudom olvasni a cert adatait szoval minden mukodik ...

Visoznt az a gondom hogy nekem ugy kellene mukodni az egesznek hogy (vegyuk pl. a regisztracios oldalt) az kliens kinyitja az oldlt a https en keresztul. Es ha nincs meglevo kulcsa akkor ures formulart (mezoket) kap, de ha a kulcs megvan akkor a mezokben mar egyes mezok ki lennenek toltve ... Viszont nekem csak vagy igy vagy ugy mukodik ...

Az kellene hogy a https akkor is "beengedjen" ha van a kulcs es ha nincsen akkor is ...Persze ha megvan a kulcs akkor a megfelelo mezok pl a $_SERVER['SSL_CLIENT_V_REMAIN'] az ervenyes adatokkal lenne feltoltve... Ha nem kovetelem meg a kulcsot akkor a kliensek el sem kuldik es a mezok uresek, ha meg megkoveltelem es felveszem a CA -t akitol elfogadom a ulcsokat akor meg azok nem tudnak belepni akiknek ez nincsen ...

Hogyan lehet megoldani hogy a kulcs csak opcionalissan kelljen de azokat is beengedi akinek nincs de akinek van ott kitolti a php valtozokat? Egyaltalan megoldhato ez ugyanazon az oldalon? vagy muszaly 2 kulonallo aldomain (https://kulcsal.foo.bar/reg.php es https://kulcsnelkul.foo.bar/reg.php) ?

Az egesz az lenne hogy azok a regisztralt felhasznalok akik kulcsal endelkeznek azoknal lenne az egesz alkalmazasban egy jelzes hogy o valoban az kinek kiadja magat...Vagyis o igazolta magat....

Ugyszinten a belepesnel ha a kartyaolvasoban ott lenne a kartya a megfelelo kulcsal akkor nem kerne user es jelszot ...vagy ez nem jo otlet?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Azt hiszem van itt egy kis keveredés, és ezért nem tudod leprogramozni.
A kulcs az általában kettő kulcs, (kettő fájl belül zagyvalékkal): magán és publikus. Ezek összetartoznak, egyikből a másik nem állítható elő.
A https az ssl tanúsítványt használ a kapcsolat titkosítására. Valójában egy ssl-be burkolt http protokoll.
A kliensek is azonosíthatók kliens tanúsítvánnyal, de az érvényes kliens tanúsítványokat a http szerverben kell rögzíteni. Nem azonos a https SSL tanúsítványával.
A kulcspár és a tanúsítvány között lényeges különbség, hogy a tanúsítvány ellenőrzött, bizonyítottan azonosított publikus kulcsa valakinek, legalábbis elméletileg. Technikailag van benne a kérelmező publikus kulcsa, a tanúsító szervezet adatai, kérelmező adatai, ellenőrzés elvégzésére alkalmas ellenőrző összegek, stb.

A https tehát nem keverendő a kulccsal. Kulcsgeneráláshoz ne akarj kliens tanúsítvánnyal klienset azonosítani, mert feltehetően még nem lesz neki olyan.

Nem látom át, hogy pontosan mit szeretnél, csak sejtem. Hátha segít nézd meg ezt.

Linuxscripting

A kliensek azonositasarol beszelek...A szerveren beallitom hogy melyik CA altal alairt azonositoval rendelkezo kliensek lephetnek be....Es ez igy mukodik is, de akkor csak az a CA altal alairt kliensek lephetnek be ...Es ez igy rendben is van ha masokat nem akarnak beengedni ....

Masik esetben ha nem kovetlem meg a klienstol az azonositot akkor is mukodik ... Persze akkor azok a mezok ugyebar ertelemszeruen uressek....Barkit beenged...

Nekem viszont a fenti kettol kellene egyben ...szoval hogy beengedjen minden klienset ha van a CA altal alairt azonositaja akkor is es ha nincs akkor is ....A kulonbseg csak a $_SERVER[] mezokben lenne a szerveren ....

Amit te írtál az a zagyvaság, részint. Most akkor arra szeretnél rávilágítani, hogy a valid kliens tanúsítvány nem kulcs, vagy arra, hogy nem érti mit akar használni? A dolog nem egyszerű a link jó, tanulásnak, de imho ő nem ezt akarja, ő kliens tanúsítványokkal akar azonosítani, és erőforrást engedélyezni

Igen ha jol ertem akkor azt akarnam :)

Fogalmazzak ugy hogy van egy oldal, legyen a https://foo.bar/test.php oldal amit barki (akarki) megtud nyitni es egy ures oldalt kap ahol peldaul ahol azt irja hogy nincs elfogadhato tanusitvanya de ha egy olyan valaki nyitja meg akinek van megfelelo tanusitvanya akkor a tanusitvanyban levo adatait kapja visza ....

Es ez nekem mukodis is ha a latogatonak megvan a megfeleo tanusitvanya, de nekem az is kell hogy ha a tanusitvany nincs meg akkoris megtudja nyitni az oldalt ...

Néhány alap felvetés:
Az ssl kézfogás http előtt van, ezért a webszervernek mindenképp el kell mondani, hogy követeljen meg tanúsítványt a klienstől.
Ha kér, akkor vannak neked SSL_CLIENT_* nevű változóid.
Mivel feltételezem apache, a location configurációval lehet limitálni a SSLVerifyClient -et (nem néztem meg, most nem tuti a változónév, csak nagyjából). Azaz nem kell "külön host" ahogy kérdezted.
Viszont ha nincs tanúsítványa, vagy amit kiválaszt lejárt, nem érvényes, akkor nem tudod meg nem történtté tenni, mivel nem sikerül a kapcsolatfelvétel (lásd első pont).
A sslverifyclient required helyett van optional (ekkor van lehetőséged arra, hogy elküld rewrite-al valahova), de annak nem egészen teljes a böngésző támogatása (renegotiation engedélyezése esetleg segíthet) szóval, vagy jó a cert, vagy nem. Lehetőséged kapcsolat hiányában bármi további műveletre nem nagyon van. Minden mást remélhetőleg értesz.

Igen, en is valahogyan igy gondoltam. A szervernek mindenkeppen kerni kell klienstol a tanusitvanyt, a kliens viszont attol fuggoen hogy van-e neki elkuldi azt ha van ... Igy elmeletileg meglesznek nekem a SSL_CLIENT valtozoim (nevezzuk igy oket ahogy irtad) es ez mukodik is szepen. Viszont valahogy aztkellene megoldani hogy ilyenkor amikor a kliens megsem kuldi a szerver fele a tanusitvanyt akkor a szerver felulbiralja az elobbi allitasat hogy megkoveteli a tanusitvanyt es siman beengedje akkoris a felhasznalot, csak a SSL_CLient valtozokat uresen hagya... Probaltam mar azal az SSLVerifyCLient allitgatni de valahogy nem mukodik, most require -re van allitva es igy ugy mukodik ahogy irtam is. A doksikat bongeszve az optional -ra kellene tennem de akkor sem ugy mukodik ahogy en elkepzelem ....De valahol ott van a gond ....

http://hup.pastebin.com/uHtp8vd5

Akkor mégsem tiszta ez számodra.
A kulcsmotívum a SSLVerifyClient.
Ha te required-re állítod, akkor feltételezed, hogy a kliens rendelkezik JÓ client certtel. Ameddig nem adja meg, nem tud kapcsolódni sem a szerverhez (nincs http kapcsolat, nincs lehetőséged semmire).
Ha optional -ra van állítva, akkor nem kell rendelkeznie, de a belépéshez meg kell adnia egy JÓ certet. Ez azt jelenti, ha lejárt a cert, vagy nem tudja a szerver ellenőrizni (pl. nem ismeri a CA-t) akkor sem tudod továbbküldeni, mivel ő megad egy rossz certet. Így nincs lehetőséged tovább menni.
Az optional csak akkor jó, hogy ha nincs certificate amit megadjon, vagy ő nemleges választ ad a böngésző kérdésére, ilyenkor tudsz vele valamit kezdeni (ekkor nem érkezik client cert a szerverhez, és így nem lesz megtagadva a kapcsolat).
Az "optional" _lehet_ jó neked, de ezzel módszerrel nem minden böngésző tud együtt élni.
Ha a böngésző rendben van (FF, Chr) a SSL_CLIENT_VERIFY (nézz utána emlékezetből van) tartalma ha nem SUCCESS, akkor tudsz rá egy rewriterule-t helyezni, és átirányítani 1 másik helyre ahol pedig akár más módon azonosítod.
Nem erőltetném én ezt a helyedben. Zárt környezetbe jó. Sőt ha te adod ki a client cert-et is lehet jó. Ha ismeretlen a célközönség az nem jó.

Igen mar lejjebb irtam az elobb hogy en is a SSLVerifyClient korul keresgeltem...

Az optional csak akkor jó, hogy ha nincs certificate amit megadjon, vagy ő nemleges választ ad a böngésző kérdésére, ilyenkor tudsz vele valamit kezdeni (ekkor nem érkezik client cert a szerverhez, és így nem lesz megtagadva a kapcsolat). -- Na pont ez az eset kell nekem !!!

Ha a böngésző rendben van (FF, Chr) a SSL_CLIENT_VERIFY (nézz utána emlékezetből van) tartalma ha nem SUCCESS, akkor tudsz rá egy rewriterule-t helyezni, és átirányítani 1 másik helyre ahol pedig akár más módon azonosítod.

Vagyis ez nem fog minden bongeszovel mukodni? Arrol a rewriterule rol tudsz valami linket vagy hasonlot?

Most igy nez ki az apache config resze: http://hup.pastebin.com/uHtp8vd5

A pont, ez az eset nem biztos, hogy neked jó, majd elválik :)
A igen, az renegotiation problémás néhány böngészőnél (msie), vannak workaroundok, de csökkentik a biztonságot stb.
Rewriterule? Hát azt neked kell kitalálni, valami hasonlót javaslok:
(apache2)
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !^SUCCESS$
RewriteRule . /nonssl.html [last]

Ha jol ertettelek, te egy olyan megoldast javasolsz hogy a melevo (jol mukodo) megolsdast annyiban modositsam hogy RewriteRule -val a klienset atiranyitom egy masik php oldalra ha nincs azonositoja, ahol a server nem koveteli meg tole az azonositot .... ?

a jelenlegi megoldásod (pastebin) required-re van állítva, a minimum elvárás hogy azt átállítsd. Hogy én mit tennék az más kérdés. A másik, hogy legalább 1 location-re ne igényeld a verify-t (ahova irányítod).
Alapvető javaslat, hogy vagy fogjál hozzá https szerver írásába amely csak a https client authot megcsinálja az igényed szerint. Vagy korlátozd az igényeidet.
Gondjaid lesznek azzal, hogy az emberek nem fogják érteni, mi az, hogy lejár a certjük (nem tudják kezelni), és te sem mert renegotiation-nál újra ugyanazt teszi és így optional-al is failba fut. Aztán gond lesz a hibás kiválasztással, stb stb...
Kellene egy olyan metódus, amely elfogad bármilyen client-cert -et, de validity ellenőrzést te végzed. Ilyen nincs jelenleg (Nem ismerek pontosabban, hogy legyünk őszinték. Én próbálkoztam 1 kezdetleges projekttel, meg láttam valami mod-ssl patch-et is, de nem erősen terjed, nem erre vannak kitalálva).
Ja és még valami: attól még nem tudod ki az ha van valid cert-je, gondolom továbbgondoltad, de ha nem a serial-t és a dn-t javaslom figyelmedbe.

Igen most a reduired-re van allitva es igy ha a kliensnek megvan az azonositoja jol is mukodik, mert most jelenleg csak egy konkret CA altal megadott azonositot fogad el, ez bovitve lessz a jovoben, de most csak ettol az egy CA -to lehet. Na most ez az CA csak a szemelyi igazolvannyal egyutt adja ki az azonositoto sot az azonosito a szemelyi csipjeben van benne. Igy ha az azonosito a megfelelo CA altal ala van irva akkor az a szemely tuti az akinek kiadja magat ...

Egyelore a mod_rewritet nezegetem es ugy nez ki hogy azzal sikerul osszehoznom az atiranyitast ha az azonosito nem megfeleleo ...

Ha jól értem, valami ilyesmire lenne szükség: http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500

Ez is hasznos lehet: http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html > Client Authentication and Access Control

Elso nekifutasra ahogy beleneztem a 2 linken talahato anyagba nem ez kell nekem, vagyis ez a resze mukodik is rendesen, csak azzal kell kiegeszitenem hogy ha a kliensnek megse nincs CA altal alairt azonositoja akkor is beengedje ...

Hogyan probalyam elmagyarazni mit is akarok? :) Van egy regisztracios oldal es ott az emberek ugyebar kitoltenek egy formulart az adataikkal, (na most vegulis oda barki barmit irhat) Nekem az a lenyeges az egeszbe hogy barki regisztralni tudja magat (az is akinek nincs CA altal alairt azonositoja) meg az is akinek van. A vegeredmenyben csak az lessz a kulonbseg hogy aki a megengedett CA -k altal alairt azonositoval rendelkezve regisztalja be magat ott a MySql tablaban bene leszz hogy o valoban o ...

Igy hogy megkovetelem mindenkitol az azonositot az oldal mukodik rendesen csak az azonosito nelkulieket is bekellene engedni ...

http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslverifyclient itt talatam is ra utalast csak az optional -ra eleg "furcsan" fogalmaz ...

idezem:
In practice only levels none and require are really interesting, because level optional doesn't work with all browsers and level optional_no_ca is actually against the idea of authentication (but can be used to establish SSL test pages, etc.)

Ok, sorry, még 1x átolvastam az eddigieket :)

Ha jól gondolom, az SSL-el kapcsolatos Apache változók meg kell, hogy jelenjenek a $_SERVER tömbben, vagy getenv()-el elérhetőek lesznek. (SSLOptions +StdEnvVars +CompatEnvVars beállítás esetén)
Próbáltad phpinfo()-val vagy var_dump($_SERVER) -el megnézni, hogy mik jönnek át?
Remélhetőleg ezáltal a PHP rész megoldódik.

Hogy ne legyen két aldomain:
- az SSLVerifyClient használható Location-re is,
- vagy Directory-ra SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS".
- Ha ezekkel valami gond lenne, még meg lehet próbálni a mod_rewrite modul csodáit is, hogy elrejtsd a felhasználó elől az két aldomaint.

Egyébként tényleg érdekesen fogalmaznak a doksiban :)

Ha jól gondolom, az SSL-el kapcsolatos Apache változók meg kell, hogy jelenjenek...
Igen megis jelennek es az a resz is mukodik jol, presze amikor a kliens azonostija magat, de akkor minden tokeletesen mukodik! :) Vagyis a php resz mar meg is van oldva...

Az elkepzeles az hogy a kliensnek ugyanazt az oldalt kellene tudni megnyitni azonositoval is es anelkul is ...