Se vogliamo immaginare a come passiamo ad una architettura concettualmente delega ad una reale, dobbiamo immaginare che al posto di CARL ci siamo le CA. Le entità che partecipano alla comunicazione sono uno user agent. E un server che possiamo andare a identificare con un certo numero di dominio. L’identità tecnica l’FDN.
Perché uno user agent delegano le CA per autenticare le chiavi pubbliche dei servers? Perché tra i maintainers e le CA abbiamo un accordo per cui ci sono già delle pk raggruppatte delle CA di cui i dev del mio user agent (il browser) si fidano. Nel mio caso l’elenco delle CA le sceglie mozilla. Chi ha un server deve ottenere un certificato web firmato dalla CA. Lo standard che vedevamo prima lo possiamo andare a estendere anche qui
In un certo momento i maintainer del software stanno dietro alle chiavi e alle CA, non lo facciamo noi manualmente. Lo otteniamo una volta e poi lo uso tante volte con gli scambi di chiavi.
Il server web non comunica mai con la root ma con le CA intermedie ovviamente. Abbiamo sempre questa situazione a livelli ovviamente. Immagina di avere una catena di certificati dalla base fin verso la root che vengono tutti quanti autenticati.
Le root CA sono delle aziende che devono soddisfare delle policy che non sono identificabile tecnicamente spesso. Abbiamo tutta una questione di policy. Non devo avere affiliazioni con attori che portano a conflitti di interesse, che non consentono come vengono gestiti internamente i dati, abbiamo una serie di policy di governance in cui abbiamo tutto un insieme di regole apposta. Se vogliamo maggiore informazioni ogni maintainer famoso di browser ha delle sue policy. In teoria ci sono delle policy di internet ma queste possono andare a differire. Esistono anche dei log ad hoc in cui si discutono quali sono le root CA che potranno essere ammesse. Per diventare una root CA bisogna entrare nella comunità, tra le varie cose bisogna proporsi in dei blog appositi in cui ci si presenta e la comunità può investigare se ci si può fidare di noi come CA.
<aside> 💡 Ricorda che le pk + certificato sono i dati che praticamente otteniamo dalla nostra CA intermedia
</aside>
Definisco che una root ca è fidata grazie ad uno schema di firme incrociate, praticamente firmandosi da una o da due root ca differenti.
Possiamo usare openssl per andare a giocare con i certificati. Attualmente per ragioni di sicurezza i certificati non hanno una vita particolarmente lunga ma si esauriscono prima. Inoltre abbiamo anche la possibilità di andare a revocare i certificati.
Come ottenere un certificato
Questa struttura fa in modo che la CA che chi fa la richiesta sappia la chiave segreta corrispondente. Quando la CA rilascia il certificato stabilisce anche due END POINT. OCSP è un protocollo che serve per andare a consultare la lista dei certificati revocati. Questo protocollo è basato su http e non su https, perché è un protocollo che serve a https, che usiamo se un certificato di https è stato revocato, se fosse sotto https sarebbe una interdipendenza che non si risolverebbe. Gestiamo la sicurezza a livello di payload. La risposta è firmata digitalmente e ha un timestamp e ha durata limitata.
La revoca si gestisce in questo modo e cosa importante: a livello tecnico il client ottiene il certificato e può vedere se è stato certifiacto vedendo l’intero file delle revoche oppure con oscp oppure posso configurare un web server con funzionalità ocsp stapling con una risposta ocsp valida se voglio andare a diminuire la latenza.
[27-04-2023] Li appunti di oggi li devo andare ad approfondire un pochino, perché al momento sono superficiali su alcuni aspetti
Ci sono dei paradigmi per fare delle revoche immediate. Paridgma Push e Pull, due modi per andare a gestire i certificati. L’idea comunque è sempre quella di mantenere alta la sicurezza.
Una CA potrebbe andare a chiedere che noi siamo proprietari del dominio di cui stiamo chiedendo un certificati → Domain Validatedkit