Cookie-ból kiolvasható-e a jelszó?

Hát, vannak nyilván, de eléggé függ attól, hogy milyen az infra.  (És amit én most lendületből tudnék mutatni, az zorp, azzal nem vagy előre szerintem :) ) Ugye a TLSt nem a webapp kezeli, hanem a a HTTPS infra, szóval az easy case sem teljesen ízi.

• A minimalista megoldás az kb annyi, hogy be van konfolva az nginx/apache, hogy ellenőrizzen kliens certet. Nyilván bonyolultabb esetekben elindul a ki(k) a load balancer(ek), hol termináljuk a TLSt és hasonló móka. Ez arra már jó, hogy random csóka egy session cookieval sehova nem jut, mert eleve előbb lepattan.
• Arra viszont nem, hogy a userek ne tudjanak laterális támadást csinálni, ahhoz valahogy össze kell nézni a session cookiehoz tartozó usert, a kliens cert userével. Ehhez jellemzően elérhetővé kell tenni a backend számára a kliens infót, tipikusan headerekbe injektálja be webszerver, de lehetne akár olyat is csinálni, hogy mondjuk a JWTt összenézi a proxy azzal, amit a tlsből kiszedett.

Aztán ez az egész megfejelődik azzal, hogy a hibakezelést így a browser intézi, annak meg az UXe a béka segge alatt van 13 km-el, illetve bejön a cert disztibutálás problémája (hogy konkrét példát mondjak, a takarnet pár éve pl még postán küldött CD-t), és ha a kezedben van a cert, még akkor se trivi, hogy hogyan kerül be a browserba.

Hát, random publikus lófaszokon ezért nem szokott lenni...

Mivel szeretnéd használni? Mert Apache tud, Tomcat tud, Haproxy tud (stb. ennyit láttam/konfiguráltam már ilyenre) kliens certet bekérni és az alapján dönteni, hogy mehet vagy sem (nekem volt olyanhoz is szerencsém, hogy a kliens certből a CN-t használta loginhoz, azaz kellett a cert, _és_ az adott névhez tartozó jelszó is).
Ezeken felül minden TLS-t bontó "rendes" tűzfal képes kéne,hogy legyen kliens cert alapon eldönteni, hogy a benyújtott cert jó-e az adott szolgáltatás eléréséhez vagy sem. (Ilyet Zorppal, illetve most már PNS-sel csináltam).