# HTTP Concealed (RFC 9729): l'autenticazione che nasconde persino l'esistenza di una risorsa
Table of Contents
La maggior parte dei sistemi di accesso a un sito ha un difetto poco discusso: si vedono. Anche quando non si conosce la password, spesso è facile capire che dietro un certo indirizzo c’è qualcosa da proteggere. A febbraio 2025 l’IETF, l’organismo che cura gli standard tecnici di Internet, ha pubblicato la RFC 9729 e ha definito un nuovo schema di autenticazione HTTP pensato proprio per evitare questo: si chiama “Concealed”, cioè nascosto.
Il problema: le porte chiuse che si notano lo stesso
Quando un browser chiede una pagina e il server richiede un accesso, di solito lo dice apertamente. Il caso classico è la risposta con codice 401 Unauthorized e l’intestazione WWW-Authenticate, con cui il server annuncia: “qui serve autenticarsi”. È un comportamento utile e corretto nella stragrande maggioranza dei siti, ma ha una conseguenza: chiunque provi quell’indirizzo capisce che lì c’è una risorsa protetta.
Gli autori della RFC usano un termine preciso per questo: gli schemi di autenticazione tradizionali sono probeable, cioè “sondabili”. Un client non autorizzato può mandare richieste a caso e osservare le risposte per dedurre dove il server tiene qualcosa sotto chiave. Per un sito pubblico non è un problema. Lo diventa quando l’obiettivo è che certi servizi restino invisibili a chi non ne conosce già l’esistenza: un pannello riservato, un endpoint di gestione, una risorsa destinata a un gruppo ristretto.
Il punto delicato è che, per un attaccante, sapere che una cosa esiste è già metà del lavoro. Uno scanner automatico che passa in rassegna migliaia di indirizzi si nutre esattamente di queste differenze nelle risposte, lo stesso tipo di traffico di fondo descritto a proposito degli attacchi brute force. Se il server tratta la porta chiusa in modo diverso da una porta che non c’è, quella differenza è un indizio.
Cos’è lo schema “Concealed”
La RFC 9729 definisce un nuovo schema crittografico di autenticazione per HTTP che ha una proprietà in più: è non-probeable, non sondabile. In pratica, un osservatore esterno non riesce a distinguere un server che richiede questo tipo di autenticazione da uno che non ne fa nulla.
Il meccanismo si basa sulla crittografia asimmetrica. Vale la pena spiegare il termine: ogni utente autorizzato possiede una coppia di chiavi, una privata (tenuta segreta) e una pubblica (condivisa in anticipo con il server). Il server conserva un elenco che associa a ogni identificativo di chiave la relativa chiave pubblica. Chi vuole autenticarsi dimostra di possedere la chiave privata firmando un dato concordato; il server verifica quella firma con la chiave pubblica che ha in archivio. Non viaggia mai nessuna password.
Un aspetto pratico da tenere presente: le chiavi vanno distribuite prima, per un’altra via. Lo schema dà per scontato che il server sappia già quali chiavi accettare. Non è pensato per iscriversi a un sito qualsiasi, ma per far entrare chi è stato messo nella lista in anticipo.
Come fa a nascondere l’esistenza della risorsa
Il trucco sta in come viene generato il dato da firmare. Negli schemi crittografici classici, per evitare che una firma vecchia venga riutilizzata, è il server a mandare al client un numero usa-e-getta (un nonce) da inserire nella firma. Ma proprio quel messaggio del server è il segnale che tradisce: annunciando il nonce, il server sta dicendo “qui c’è un’autenticazione”.
La RFC 9729 elimina quel passaggio. Il dato fresco da firmare non arriva dal server: il client lo ricava dalla connessione TLS già in corso, quella cifratura che protegge il traffico dei siti in https, la stessa base su cui poggia anche la riservatezza aggiuntiva dell’Encrypted Client Hello. TLS mette a disposizione una funzione, il keying material exporter, che permette a client e server di derivare in modo indipendente un valore segreto legato a quella specifica connessione. Con un’etichetta dedicata - EXPORTER-HTTP-Concealed-Authentication - il client ottiene questo valore, lo firma con la propria chiave privata e lo invia. Il server, dalla sua parte, può ricalcolare lo stesso valore e verificare.
Il risultato è che il client parla per primo, senza bisogno di alcun invito. E qui sta la parte importante per la riservatezza: un server che vuole restare davvero invisibile deve rispondere in modo identico sia quando la risorsa non esiste, sia quando esiste ma l’autenticazione fallisce. In pratica risponde 404 Not Found in entrambi i casi. Chi non ha la chiave giusta non riesce a distinguere “non c’è nulla” da “c’è qualcosa che non ti riguarda”.
Come funziona, in concreto
L’autenticazione viaggia nell’intestazione Authorization (o Proxy-Authorization verso un proxy), con lo schema Concealed e alcuni parametri. Senza scendere nel dettaglio crittografico, i cinque campi previsti dalla specifica sono:
k- l’identificativo della chiave che il client vuole usare;a- la chiave pubblica con cui il server verifica la firma;s- lo schema di firma impiegato, scelto dal registro standard di TLS;p- la prova (la firma vera e propria) che attesta il possesso della chiave privata;v- un valore di verifica legato all’output esportato da TLS.
Una condizione tecnica è necessaria: serve TLS nella versione 1.3, oppure la 1.2 con l’estensione extended master secret. Il motivo è che la firma deve restare ancorata a quella singola connessione. Lo schema è compatibile con HTTP/2, HTTP/3 e con il trasporto QUIC.
A cosa serve davvero
Il caso d’uso principale è tenere fuori radar i servizi che non devono essere scoperti per caso. Un endpoint di amministrazione, un’interfaccia di gestione, un’API interna: con lo schema Concealed, chi non possiede una chiave valida non ha modo di capire nemmeno che quell’indirizzo faccia qualcosa. È una forma di difesa in profondità: non sostituisce le altre protezioni, ma riduce la superficie che uno scanner automatico riesce a mappare.
C’è anche un beneficio sul fronte del tracciamento. La specifica nota che le chiavi legano l’utente a una singola origine (un singolo sito), ma sono costruite per non permettere di correlare le richieste tra siti diversi. In altre parole, la stessa persona non diventa riconoscibile spostandosi da un dominio all’altro.
Cosa tenere d’occhio
Come ogni strumento, ha i suoi limiti dichiarati apertamente nella RFC.
La firma è legata alla connessione, non alla singola richiesta. Questo apre a un rischio di riuso: se l’intestazione con la prova trapelasse - per esempio a causa di codice che gira nella stessa sessione del browser - potrebbe essere sfruttata su altre richieste della stessa connessione. Per questo la RFC è netta su un punto: le chiavi usate qui non devono essere riutilizzate in altri protocolli.
C’è poi la freschezza. Il valore firmato dipende dall’età della connessione TLS; un server che vuole imporre una prova più recente può forzare l’apertura di una nuova connessione. E c’è l’attenzione ai canali laterali temporali: se il server impiegasse tempi diversi a rispondere nei due casi - risorsa assente contro autenticazione fallita - quella differenza di millisecondi rischierebbe di svelare ciò che si voleva nascondere. Ottenere risposte davvero indistinguibili richiede cura anche su questo.
A che punto è
RFC 9729 non è una bozza: è un documento pubblicato, sulla via degli standard IETF con il livello di Proposed Standard (Standard Proposto). È il primo gradino stabile del percorso: una specifica matura e rivista pubblicamente, non ancora al livello finale di “Internet Standard”, lo stesso stadio raggiunto di recente anche dall’header HTTP che segnala le API deprecate. Prima di arrivarci si chiamava draft-ietf-httpbis-unprompted-auth ed è stata elaborata nel gruppo di lavoro httpbis dell’IETF.
Gli autori sono David Schinazi (Google), David M. Oliver (Guardian Project) e Jonathan Hoyland (Cloudflare). In concreto, il supporto lato browser e lato server è ancora agli inizi e va verificato caso per caso: la specifica è solida, la diffusione negli strumenti reali è ciò che nei prossimi tempi dirà quanto lo schema entrerà nell’uso comune. Resta comunque un’idea interessante, perché sposta l’obiettivo dell’autenticazione da “impedire l’accesso” a “non far sapere nemmeno che c’è una porta”.
