Stringa esadecimale nel campo SNI TLS

3

Sto osservando le acquisizioni di pacchetti del traffico TLS e vedo connessioni crittografate TLS in cui il campo SNI contiene una lunga stringa esadecimale (una sequenza di 64 nibbles hex) - non un nome di dominio.

Cosa potrebbe scatenare questo? Sono abituato ai client HTTPS che inseriscono un nome di dominio nel campo SNI (il nome di dominio del server Web che stanno tentando di contattare). Esiste un'estensione TLS che suggerisce di inserire una stringa esadecimale o un'impronta digitale hash nel campo SNI? Oppure esiste un protocollo non HTTPS che utilizza TLS e inserisce una stringa esadecimale o un'impronta digitale nel campo SNI?

Le specifiche SNI ( RFC 6066 ) non dicono nulla al riguardo. Fornisce a SNI un nome host, non un altro tipo di valore. Non sono stato in grado di trovare alcuna estensione TLS che spiegherebbe questo.

    
posta D.W. 20.09.2016 - 02:34
fonte

1 risposta

2

Sembra piegare le regole

L'estensione IANA TLS registro dice RFC6066 è la definizione corrente documento per l'estensione "nome_server".

E la sezione RFC6066 su SNI dice:

Currently, the only server names supported are DNS hostnames; however, this does not imply any dependency of TLS on DNS, and other name types may be added in the future (by an RFC that updates this document).

Non c'è questo aggiornamento RFC. Nessuno è elencato nel registro. (Inoltre nessun "aggiornato da" è elencato nell'angolo in alto a sinistra della prima pagina della RFC.)

E un po 'più in basso, c'è questo:

TLS MAY treat provided server names as opaque data and pass the names and types to the application.

Ho letto questo per indicare "ogni volta che inventiamo un nuovo tipo, potremmo farlo ma ora con gli attuali nomi host DNS, non" .

Quindi, se qualcuno mette ancora qualcosa lì dentro, allora direi che sono in un'area grigia / che piegano le regole.

    
risposta data 18.01.2017 - 12:54
fonte

Leggi altre domande sui tag