On Wed, Mar 24, 2021 at 3:33 PM Alex 'CAVE' Cernat <c...@cernat.ro> wrote:
> On 24-Mar-21 14:29, Petru Rațiu wrote: > > In afara de aspectul financiar (care zici ca nu te apasa pentru ca LE), > > problemele sunt exact aceleasi pe care le-ai avea cand reinnoiesti > > certificatul/cheia (plus niste chestii dragute daca vrei sa faci session > > resumption de TLS 1.2+, dar sigur nu faci de-alea ca ai fi stiut de > > problema). > > ar fi interesant de stiut in cazul mai multor servere cum procedeaza > clientul pentru session resumption (mai ales pe la tls 1.3 unde s-ar > vrea 0-rtt), daca o face dupa dns sau dupa ip-ul la care se conecteaza > ... n-am sapat chiar atat de jos dar ceva imi zice ca depinde de > implementare > Se face un shared cache de care trebuie sa ai grija sa se sincronizeze out of band (sau te multumesti sa faca fallback la handshake mai explicit), de-aia ziceam ca daca nu stii explicit de problema asta, probabil nu te intereseaza :) Probabil ca nici acolo nu depinde de cheia de certificat in sine dar s-ar putea sa dea cu virgula cand treci de pe un certificat pe altul si sa pierzi 1-2 RTT-uri (nu m-am mai dat de mult prin TLS internals si nu tin foarte tare sa reincep acum). > iar in cazul in care nimeresti pe alt server clientul oricum nu va fi > recunoscut (ca nu e in session cache), indiferent daca cheile si > certificatele sunt aceleasi sau diferite (decat eventual daca ai o > tabela globala de cache de sesiuni ssl, ceea ce mi se pare total sf, > nici nu stiu daca e posibil de implementat, nu mai vorbim de fezabil) > > Daca conteaza asta pentru tine, exact asa se face, cu shared session cache. Tine ofc de balancer si daca suporta asta. > ideea era urmatoarea: cu sa zicem mai multe servere distincte pe acelasi > domeniu, eventual si in locatii diferite (deci fara posibilitatea de a > avea un unic LB in fata); ai 2 variante: > 1. fiecare server cu cheile / certificate lui, solutie de tipul fire & > forget (binenteles cu monitorizarea de rigoare, ca sa nu ai surprize, > desi s-a vazut la case infinit mai mari :-P); bonus, dupa cum ziceai, > cheia privata nu paraseste serverul, everybody happy > 2. o masina suplimentara care sa se ocupe de reinnorea certificatelor, > pe care apoi sa le distribuie tuturor serverelor; efort in plus, inca o > rotita care poate sa se blocheze samd, complicatie inutila(?) > > intrebarea era de fapt ce impediment ar exista in cazul 1, evident mai > simplu; pana acum nu am gasit niciunul (in afara de a "polua" dublu, > triplu, etc. lista globala de certificate - dar vorbim de cateva > servere, nu de zeci, sute, mii etc) > nu am vazut pe nicaieri in recomandarile LE sa ai un singur certificat > per domeniu, nu am gasit nimic legat de faptul ca vreun client ar putea > stramba din nas ca pentru acelasi domeniu exista mai multe certificate > (corect cazul expus de tine cu reinnoirea certificatelor unde nu ai cum > sa le faci chiar simultan pe toate masinile); insa intreb, sa fiu sigur > ca nu mi-a scapat ceva > > De notat ca de pe vremurile imemoriale de dinainte sa se inventeze LE si lumea dadea bani pe certificate (brr, ce concept, right?) CA-urile te puneau sa juri ca nu folosesti certificatul ala decat pe un device si daca vrei mai multe sa iei cate unul separat. Nu zic ca nu erau motivati de bani, dar nu e complet fantezista aceasta cerinta. In sfera noastra de linuxisti hipioti, certificatul si cheia sunt un fisier pem cu prostii in base64 pe care-l dai din mana in mana pe slack si mail pana ajunge acolo unde trebuie (si te mai si injura apache-ul ca nu e root only). In alte medii mai cu cravata (sau chipiu), cheile pot sta pe device-uri neexportabile, adica generezi CSR-ul acolo, vii cu el semnat si cheia moare cu device-ul si nici picior de fiinta vie nu pune ochiul pe cheie in clar, doar da challenge-uri sa verifice daca face match. Cu alte cuvinte, protocoalele criptografice ar trebui sa suporte ideea de o cheie diferita per device (ca de fapt certificatul certifica device-ul pe care e cheia, daca stai sa te gandesti). In plus, cum ziceam, cheia poate fi reinnoita din mers si asa cum nu e acceptabil ca un client sa dea pe spate ca s-a schimbat de ultima oara cand a vazut-o (5 ms sau 5 ani), ar trebui la fel de bine sa ajunga pe alt device si sa nu crape, provided ca certificatul chiar se valideaza. Problemele care pot aparea sunt fie de performanta (vrei 0-rtt si chestia aia cu session cache s-ar putea sa devina mai tricky, dar daca ma gandesc s-ar putea sa nu depinda de cheie si certificat tocmai din motivele de mai sus - again, mi-e lene sa ma uit la specifics), fie mai degraba operationale: una din chei e expirata sau emisa de alt CA decat stia clientul sau e pe alt subiect si nu se mai valideaza sau te-ai jurat pe undeva prin HPKP sau CAA ca nu schimbi stuff si s-a schimbat, etc, etc. Dar de mers n-are de ce sa nu mearga, pentru ca asta cu copiatul manual al cheii de pe un server pe altul e deviatie de la intentia protocolului si nu invers. -- P. _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
