Ez tényleg fáj:
Kurt Seifried rájött, hogy a RapidSSL (és minden bizonnyal még néhány "jónevű" CA) pusztán egy (tipikusan ssladmin@ kezdetű) e-mail cím meglétéhez köti az SSL tanúsítványok kibocsátását, ami ingyenes webmail szolgáltatók esetében nem túl szigorú feltétel...
A probléma első sorban nyilván man-in-the-middle támadásra ad lehetőséget: Pl. egy megfelelően beállított vezetéknélküli AP segítségével a rapid tanúsítványt használva gyakorlatilag bárkit meggyőzhetünk, hogy a valódi levelezőrendszerrel beszélget, miközben a kommunikációt a saját magunk által üzemeltetett, preparált szájton vezetjük át.
Mindez persze valójában nem a webmailek hibája, hanem CA-ké (akiknek néha elég egy céges fejléccel ellátott, aláírt papírt átfaxolni a hitelesítéshez), de azért nem árt, ha a hasonló szolgáltatásban utazók letiltják az ilyen, félreértésekre okot adó címek regisztrációját.
Itt olvashatók C Keigher tapasztalatai, aki a húsvétra való tekintettel Jézus Krisztus néven regisztrált néhány nagyobb szolgáltatóhoz - sikerrel.
Gondoltam teszek én is egy próbát, és beregisztráltam a nagyobb hazai szolgáltatóknál (freemail, indamail, citromail, mailbox) az ssladmin fiókot. Különösebb problémába nem ütköztem, innentől kezdve én is is szaladhatnék a RapidSSL-hez tanúsítvány igényelni... de minek?
A mélyen tisztelt hazai szolgáltatók ugyanis az esélyét sem adják meg annak, hogy biztonságosan férjünk hozzá a leveleinkhez, az említett oldalak HTTPS-en nem elérhetők...
Aron bacsi 2010.04.18. 22:58:51
Buhera! Az ssladmin@-os fiókok jó ötletek! :D Hasonló érdekességet csinált az egyik ismerősöm is: ahol tudta, regisztrálta a MAILER-DAEMON@-os címeket is... Ott is voltak már ebből vicces helyzetek...
EQ · http://rycon.hu 2010.04.19. 19:13:23
Aron bacsi 2010.04.19. 20:33:37
Tehát nem a fizikai környezettel (pl. törhető HSM?), nem a kulcsokat használó kripto alkalmazásokkal (pl. rossz PRNG OpenSSL-nél?), nem a kripto algoritmussal (pl. AES 128 vagy 256 erősebb?), még csak nem is az egyszerű júzerrel (pl. PIN kód a kártyán?) van a baj, hanem a CA folyamataival. Értem én, hogy nehéz "fejből sorolni azt a 2x db stringábrázolást", de úgy gondolom, hogy ha egy CA ennyire felügyelet nélkül bocsát ki tanúsítványokat, akkor azért komolyabb szűréseket, néhány jól megírt regexp-et elviselne a rendszer input-validálásnál. Ha jól tudom, az itthoni CA-knál is van valamennyi automatizmus, de azért van a folyamatban olyan pont, ami ember által felügyelt. Az is igaz, hogy itthon valszeg nincs annyi SSL tanúsítványigénylés, ami miatt teljesen automatizálni kelljen a folyamatokat...
synapse · http://www.synsecblog.com 2010.04.20. 10:12:24
Nem, arra utaltal hogy az openssl fejlesztok inkompetensidiotak: "nem (annyira) hozzáértő emberek szagolnak hozzá egy éles PKI szolgáltatáshoz"
"pl. rossz PRNG OpenSSL-nél?" PRNG jovolt, nem volt megfeleloen beseedelve.
Az hogy faxra kapsz certet meg megarofl.
Aron bacsi 2010.04.20. 21:00:52
hiba, amit a Perl script-ekben kellett javítanom anno, de az OpenSSL forrásához, a kripto-maghoz nem nyúltam hozzá.
Az OpenSSL-t már csak azért sem szólnám le, mert én is ezt használom referenciaként, amikor a saját Windows-os appjainkat tesztelem a cégnél. :D A pid-es seed mondjuk valóban hiba volt, de ezzel együtt is az OpenSSL-t nagyon jó kis cuccnak tartom...