Il riempimento in TLS è quasi uguale al padding PKCS # 7, ma con alcune sottili differenze.
Quando si utilizza la crittografia CBC, in TLS, le cose vanno come segue:
-
Il MAC viene calcolato sul testo in chiaro e aggiunto al testo in chiaro. Nel caso di TLS_RSA_WITH_AES_128_CBC_SHA, questo è HMAC / SHA-1, quindi 20 byte extra.
-
Ciò che verrà crittografato è la concatenazione del testo in chiaro, del MAC e del padding. La lunghezza totale deve essere un multiplo della dimensione del codice a blocchi, ovvero 16 nel caso di AES. Il padding consiste nell'aggiungere n +1 byte, in modo che 0 ≤ n ≤ 255. Quindi c'è almeno 1 byte in più, al massimo 256, tutti hanno lo stesso valore e quel valore è uno in meno della lunghezza del padding.
(Nel vero padding PKCS # 7, ci sarebbero n +1 byte che hanno tutti valore n +1, non n . )
-
Al momento della decrittografia, DEVE essere verificato il contenuto dei byte di riempimento, così come il MAC. Farlo in modo sicuro è difficile da fare ma se stai scrivendo uno strumento di ispezione, allora tu sei l'attaccante e quindi puoi permetterti di fare le cose più insicure.
Nella precedente versione di SSL 3.0, solo l'ultimo byte di padding doveva avere valore n , gli altri byte erano casuali (e questo è un punto debole del protocollo). Al contrario, in SSL 3.0, la lunghezza totale del padding non era consentita per superare la lunghezza del codice di blocco, mentre in TLS può essere più lunga (fino a 256 byte), a condizione che la lunghezza totale del messaggio sia un multiplo della lunghezza del blocco.
Per uno strumento di ispezione, il metodo di implementazione più semplice sarebbe quello di decodificare con padding "none", quindi ispezionare e rimuovere il padding e il MAC con il codice esplicito che si scrive da soli. Non esiste un metodo di riempimento "standard" implementato in Java che corrisponda alla variante utilizzata in TLS.
Se sei interessato a decifrare l'handshake SSL / TLS, potrebbe essere una buona idea scrivere prima la tua libreria SSL / TLS - non per uso di produzione (queste cose sono molto difficili da ottenere riguardo a attacchi di canale laterale ), ma molto altro per acquisire esperienza nei minimi dettagli del protocollo. Quando la tua biblioteca riesce a completare una stretta di mano, sai di averli tutti correttamente. Inoltre, gli elementi del codice saranno riutilizzabili per il tuo strumento di ispezione. Quindi, scrivere la tua biblioteca è un buon investimento pedagogico (purché tu ricordi la condizione: non per uso di produzione!).
Potresti leggere questa risposta come introduzione al protocollo.