OCSP responder szoltáltatás

Security-all

Ismer valaki OCSP responder szolgáltatót? PaaS-ként érdekelne, nem IaaS-ként. Vagy rosszul keresek, vagy tényleg nem létezik ilyen.
Olyan helyre kellene, ahova nem jó a saját és jó lenne egy nagy cégtől amit nem tudnak dos-olni, nem áll le a gép (ill. szolgáltatás) stb.

A CA PK-ját nyilván nem kapja meg, de nincs is szükség rá, elég, ha a CA által van aláirva a saját cert-je és azzal irja alá a válaszokat.

Egyébként őrület, hogy mekkora káosz van böngészőkben a cert. revocation kapcsán:

- IE mindkettőt támogatja (CRL/OCSP) ellenben nem fogadja el a certet, ha egyik sincs a CA-ban megadva.
- Firefox csak OCSP-t támogat és nem érdekli az sem, ha még az sincs a cert-ben, de nem használja a windows certificate store-ját, a saját store-jába is be kell tenni a CA-t.
- Chrome egyiket se támogatja, ez a legviccesebb, de legalább használja a központi store-t.

Ezért kellene egy megbizható cloud-os megoldás ahova a CRL-t is feltehetem és az OCSP-t is megoldja az odarakott CRL-ekből.

  • 6831 megtekintés

( bAndie9100 | 2014. 06. 22., v – 01:37 )

Chrome egyiket se támogatja

chromiumban van a settings-ben egy checkbox "Check for server certificate revocation" - de nem úgy tűnik mintha valamit is befolyásolna, és ráadásul default off.

(rejtett sub)

~~~~~~~~
deb http://deb.metaltux.tk/ wheezy yazzy repack

Ezt nehezen hittem el, ezért utánanéztem: http://www.zdnet.com/chrome-does-certificate-revocation-better-70000285…

Amikor egy szolgáltató úgy dönt, hogy egy CA tanúsítvány helyett 50 ezer végtanúsítványt von vissza, és több megabájtos lesz a CRL, az tényleg gáz...

Valamennyire érthető a lépés, és helyette van más, de nem mezei adminisztrátornak való, hanem ők eldöntik, hogy melyik CA-kat vizsgálják. Egy root CA kompromittálódása esetén úgyis browser update kell, akkor miért is ne használnák ezt mindenre.

--

Ha lehet ne vigyük el a témát ebbe az irányba, de jó nagy hülyeségek vannak a cikkben.
Ha én a saját PKI-mben visszavonok egy cert-et, akkor az bizony abban a pillanatban invalidálódik OCSP-n és CRL-en is, utóbbi maximum a kliensek cache-elésével tolódik el, ami szabályozható de az alapból is sokkal rövidebb mint a chrome naponként frissitése.
És hogy is jut el a chrome-ba az én cert visszavonásom? Sehogy. Gondolom pár naggyal megegyeztek, akik beküldik a google-nek, a többiek meg le vannak tojva. De még a nagyok visszavont cert-jét is simán egy napig értesülés nélkül használni chrome-al, elvégre fő a biztonság.

Az meg, hogy 4 megásra nőtt egy crl, attól még nem dől össze a világ, természetesen azt 1x töltik le a kliensek, utána cache-elik, a cache idő lejártakor ellenörzik, hogy változott-e, visszakapják pár byte-ban, hogy nem változott és minden megy tovább. (amint az látszik az összes többi böngészővel is, semmi nem lassult le az 50 ezer tanusitvány visszavonása után sem)

A hülyeség csak folytatódik a cikkben a forgalomba beékelődött emberrel, aki szerinte majd meggátolja az OCSP forgalmat és akkor baj van. Csak azt nem tudom ugyanez az ember miért nem gátolja meg a chrome update-jét is, amivel ugyanott lesz: nem értesül a böngésző a visszavonásról. Nem beszélve arról, hogy hány milliomod részét érintheti egy ilyen szintű támadás az internetezőknek. Mert bár nem oldja meg nekik sem a problémáját a chrome, de legalább a többi 99,999999999%-nak is elszarja.

Szóval bármennyire is szarul esik, hidd el, hogy a chrome ezügyben a lehető legkevésbé biztonságos, az IE a legbiztonságosabb, firefox meg a kettő között.

Szerintem meg nem. Valótlanságok vannak benne (4 megás crl-től jaj mi lesz, semmi) és téves előnyök a chrome felé (MiM a chrome módszerét is ugyanúgy hazavágja).
Szóval semmi előnyt nem kapsz, csak hátrányt.

A mostani rendszer bár messze nem tökéletes, de igenis működik (normális böngészőn).
Ráadásul a késleltetés problémája is megoldható CRL és OCSP mellett is, egyszerűen aszinkron kell kezelni a revocation check-et, addig nyugodtan töltődjön be az oldal és ha majd a user POST-ol(!) valamit és még mindig nincs meg a revocation eredménye (99,9%-ban eddigre meglesz) mert pl beirja a nevét-jelszavát akkor kell felugorjon egy ablak, hogy nem sikerült még a revocation check, döntse el a user, hogy mit akar.

CRL-t ma is sokan kiszervezik, simán kirakják szolgáltatóhoz, hiszen semmi nem kell hozzá csak egy statikus webkiszolgáló, abból meg triviális magas rendelkezésre állású szolgáltatást találni, főleg a nagy cloud szolgáltatóknál.
Szerintem inkább az a baj, hogy az OCSP még nincs elterjedve, kevesen használják.

"Szerintem meg nem. Valótlanságok vannak benne (4 megás crl-től jaj mi lesz, semmi) és téves előnyök a chrome felé (MiM a chrome módszerét is ugyanúgy hazavágja).
Szóval semmi előnyt nem kapsz, csak hátrányt.

A mostani rendszer bár messze nem tökéletes, de igenis működik (normális böngészőn)."

Pont most néztem meg legújabb firefox alól egy SSL-es oldalt, és - ha jól láttam plain http-n intézte az ocsp-t. MiM esetén ez triviálisan alkalmatlan. Ha a gugli a saját listáját https-en keresztül kéri le (és ellenőrzi a saját szervere cert-jét is), akkor szerintem már jobb a helyzet. Ha nem, akkor az is szar.

"Ráadásul a késleltetés problémája is megoldható CRL és OCSP mellett is, egyszerűen aszinkron kell kezelni a revocation check-et, addig nyugodtan töltődjön be az oldal és ha majd a user POST-ol(!) valamit és még mindig nincs meg a revocation eredménye (99,9%-ban eddigre meglesz) mert pl beirja a nevét-jelszavát akkor kell felugorjon egy ablak, hogy nem sikerült még a revocation check, döntse el a user, hogy mit akar."

Csak addig a js-t is tiltani kell. Mert még a post előtt is simán ellophatja JS-el a nevet és a jelszavat. Továbbá flash, java, silverlight, tetszőleges browser plugin futását is tiltani kell.

plain http-n intézte az ocsp-t

én nem rég foglalkozok az ocsp-vel de észszerűnek tűnik, hogy http-n történik az ocsp kérdés-válasz, mivel ha ssl alatt töténne és az ocsp server tanusítványában is van ocsp kiterjesztés és ebben a másik ocsp szervertanusítványban is... :D
tehát ugyan az ocsp request http-n utazik, de a válasz alá van írva és timestamp-elve is van.
tehát gyakorlatilag az ssl tartalom a http body-ban van.

~~~~~~~~
deb http://deb.metaltux.tk/ wheezy yazzy repack

Ha a MiM megvalósul, akkor édesmindegy, hogy HTTP vagy HTTPS, egyszerűen blokkolja a chrome update forgalmát és máris ott van, hogy vigan el fogja fogadni a chrome a már visszavont tanusitványt. Nem visszavont eredményt a HTTP-be sem tud belecsempészni, mert alá van irva a válasz az OCSP/CA kulcsával.

A MiM egy célzott, relative ritka támadási mód, ami ellen egyik revocation rendszer sem véd, de nem is érinti az internetezők 1 milliomod részét sem. A többiekkel kellene foglalkozni, hogy nekik viszont a lehető legjobb legyen. A chrome megoldásával nekik a lehető legrosszabb, az 1 milliomodnak meg ugyanolyan.

"Csak addig a js-t is tiltani kell. Mert még a post előtt is simán ellophatja JS-el a nevet és a jelszavat. "

Ez igaz, de POST-olni ő sem fog tudni, a js-es GET-elést, ajaxolást pedig nyugodtan le lehet tiltani addig. Többi plugin tiltás is rendben van, itt pár tizedmásodpercről max 1 mp-ről beszélünk az esetek 99%-ban.