Puncte:0

mTLS: restricționați certificatul client la un anumit subdomeniu?

drapel pk
Joe

tldr

Prin mTLS, încerc să găsesc o modalitate de a emite un certificat de client care să permită clientului să acceseze un anumit subdomeniu. Am o bănuială că acest lucru nu este posibil, dar nu sunt sigur.

Ceea ce încerc să realizez

Să presupunem că am un server care ascultă orice direcționat *.foo.flar.com

Fiecărui client i se atribuie propriul subdomeniu care îndeplinește wildcard-ul din adresa serverului.

De exemplu, client1 ar trebui să acceseze serverul prin customer1.foo.flar.com, și client2 ar trebui să acceseze serverul prin customer2.foo.flar.com.

În plus, un client trebuie să fie împiedicat să acceseze serverul folosind un subdomeniu diferit al clientului. Deci, este ilegal pentru client1 la cerere customer2.foo.flar.com, iar o astfel de cerere ar trebui respinsă.

Speram că voi putea realiza acest lucru la nivelul de sesiune prin mTLS și o utilizare inteligentă a certificatului SAN, dar întâmpin probleme să funcționeze corect.

Cum am configurat lucrurile

Sunt destul de nou în a juca cu TLS, așa că multe din asta au venit acest răspuns SO despre configurația SAN și acest articol despre configurația mTLS de bază.

Am omis câteva lucruri aici, cum ar fi generarea certificatelor CA și generarea CSR pentru client și server pentru a încerca să mențin lucrurile concentrate, dar le pot adăuga dacă doriți.

Am creat un certificat de server folosind ceva de genul:

openssl x509 \
  -req \
  -extfile <(printf "subjectAltName=DNS:*.foo.flar.com") \
  -zile 365 \
  -in server.csr \ 
  -CA ca.crt \
  -CAkey ca.key \
  -CAcreateserial \
  -out server.crt

Apoi am creat un certificat client folosind ceva de genul:

openssl x509 \
  -req \
  -extfile <(printf "subjectAltName=DNS:customer1.foo.flar.com") \
  -zile 365 \
  -in client.csr \ 
  -CA ca.crt \
  -CAkey ca.key \
  -CAcreateserial \
  -out client.crt

Serverul (scris în Go) este configurat să solicite și să verifice certificatele client.

Problema

Problema este că atunci când testez această configurare, conexiunea reușește atunci când m-aș aștepta să eșueze.

Dacă am un client care a emis client1 cert sunați la server la customer1.foo.flar.com, conexiunea reușește.

Cu toate acestea, dacă am un client care a emis client1 cert sunați la server la customer2.foo.flar.com, acea conexiune reușește și atunci când m-aș aștepta să eșueze.

Speram că, după inspecția certificatului clientului, serverul va vedea asta client1 nu are acces la client2..., și ar respinge cererea. Dar acest lucru nu pare să se întâmple.

Idei?

Puncte:3
drapel se

Certificatele client conțin doar informații pentru autentificarea utilizatorului. Orice restricții privind ceea ce poate face utilizatorul autentificat (autorizare), inclusiv pe ce site va fi acceptat certificatul, revin serverului care verifică certificatul.

drapel pk
Joe
Deci, setarea valorilor SAN pe un certificat client este pur informațional și nu are efecte altfel?
drapel pk
Joe
De fapt, acum că mă gândesc mai mult la asta, cred că are sens. Deoarece strângerea de mână TLS are loc înainte ca serverul să știe ce resursă este solicitată, nu ar exista nicio modalitate ca TLS să ia măsuri semnificative.
Nikita Kipriyanov avatar
drapel za
Ce face un certificat unic, ce este suficient pentru a distinge un certificat de alții, adică pentru a se autentifica? Valoarea reală „semnată” din acest certificat este cheia publică, iar ceea ce îl face un certificat este o semnătură CA care acoperă această cheie.Cheia este importantă deoarece este folosită în cripto-ul asimetric propriu-zis. Orice altceva este „pur informațional”, totuși unele elemente precum DN sunt mai ușor de lucrat și este posibil să fie unice, de ex. eligibil la autentificare.
Steffen Ullrich avatar
drapel se
@NikitaKipriyanov: *Totul în rest este „pur informațional”* - nu sunt de acord. În afară de cheia publică, există restricții de utilizare a cheilor, scopul certificatului... - care au o semnificație clar definită și standarde cum ar trebui să fie tratate. Există, de asemenea, SAN (și mai vechi: CN) care are un sens clar definit și standardizat în contextul certificatelor și protocoalelor de server precum HTTPS, SMTP, IMAP, ... . Nu există totuși un astfel de standard pentru restricționarea certificatelor de client la domenii.
Nikita Kipriyanov avatar
drapel za
*Autentificarea* reală, definită ca procesul de evaluare a identității actorului, este legată matematic de cheie și *doar* de cheie. Cheia privată este ținută secretă de o entitate și, deoarece un actor este capabil să decripteze provocarea pe care am criptat-o ​​cu cheia publică, înseamnă că este această entitate. Tipul de entitate este înregistrat în certificat, iar valabilitatea acestor informații este semnată de CA. În cazul site-ului, identitatea este numele acestuia, așa că semnăm împreună cheia și SAN. În cazul unui certificat de client putem folosi cheia însăși ca identificator al entității, la fel ca SSH.
Nikita Kipriyanov avatar
drapel za
Scopul certificatului, restricțiile de utilizare a cheilor și așa mai departe, nu joacă niciun rol în procesul de autentificare. Dacă provocarea a fost decriptată corect, știm sigur că cealaltă parte are cheia privată. Dacă se poate stabili identitatea unei chei publice (de exemplu, utilizând un câmp al unui certificat, de exemplu SAN), ea a autentificat de fapt cealaltă parte. Toate celelalte câmpuri sunt mai informaționale și legate de autorizare. Și aveți dreptate (în răspuns), depinde de cealaltă parte dacă ar putea folosi aceste informații.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.