Mersi de raspunsuri ... si daca pentru cultura mea generala am mai citit acum niste info de ssl, sa fac un rezumat la ce am inteles vis-a-vis de subiectul "session resumption"
In TLS 1.2+ ai doua variante de session resumption: 1. session ids, trimise de catre server catre client la inceput de handshake (daca binenteles clientul se jura ca stie ce-i aia si cu ce se mananca); la restabilirea conexiunii clientul va trimite session id-ul, si daca din verificarile serverului totul e ok vor putea folosi cheia de sesiune din handshake-ul primordial cum informatiile de sesiune sunt tinute pe server, in caz ca ai mai multe servere trebuie un spatiu comun de stocare; insa daca cloudflare la nivelul la care este o face la nivel de POP inseamna ca nu e chiar asa de nefezabil pe cat credeam (btw: foloseste memcache); in cazul asta nu ai nevoie de vreo alta cheie de criptare decat daca vrei un layer in plus de securitate (cloudflare are, ceea ce inseamna alte chei cu rotatiile de rigoare, insa tine strict de cum stochezi sesiunile, nu de protocolul tls in sine) 2. session tickets, care stau doar pe client, daca nu ma insel e cheia de sesiune criptata cu o cheie pe care doar serverul o stie (alta decat cheia privata "principala" de ssl); partea distractiva e ca pana la tls 1.2 se transmite in clar (totusi, macar informatia este criptata, insa nu face parte din canalul tls); aici nu mai ai nevoie de spatiu comun de stocare, ci doar o cheie care trebuie sa existe pe toate serverele, pentru a putea decripta tichetul de sesiune (si cum aceasta cheie trebuie sa fie rotita cat mai des, iti trebuie un mecanism care sa genereze respectivele chei si sa le faca push catre masini, plus sa pastrezi ultimile x chei pentru clientii mai vechi); desi e mai noua varianta cu tichete, are macar teoretic flaw-urile ei pe partea de forward secrecy, deci de abia pe la tls1.3 isi atinge scopul in concluzie in niciunul din cazuri nu depinde de cheia "primara", pe baza caruia a fost generat certificatul, asa cum ma si asteptam de altfel Alex ps: bine punctat cu intentia protocolului (asta de fapt ar fi argumentul ca probabil imi fac griji degeaba) ... insa una e teoria initiala si alta e practica curenta :-P On 24-Mar-21 16:42, Petru Rațiu wrote: > 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. > _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
