Qualcuno può spiegare perché c'è una differenza tra il padding richiesto in PKCS7 link Pagina 22 - che è
01
02 02
03 03 03 ...
e padding utilizzati in TLS 1.2 link pagina 24 o link Pagina 1 - che è
00
01 01
02 02 02
03 03 03 03 ...
Perché i ragazzi di TLS non hanno usato la versione PKCS7 del padding?
Il padding non è diverso - in realtà è PKCS7 padding. La differenza è che i dati terminano con un campo di 1 byte che esprime la lunghezza del padding. In quanto tale, quello che stai vedendo è:
MAC Padding PadLen
xx xx xx .. xx | 05 05 05 05 05 | 05
Questo non è univoco per TLS 1.2: se scorri tra le RFC scoprirai che TLS 1.1, TLS 1.0, SSL 3.0 condividono anche questa stranezza. La ragione sembra essere la compatibilità legacy.
La specifica SSL 2.0 non è molto chiara su come (o cosa) dovrebbe essere applicato il padding, ma la lunghezza del padding è data in chiaro come un campo nel pacchetto. Poiché ciò comporterebbe la distinzione della lunghezza del padding rispetto al padding stesso, si ottiene una situazione in cui un padding di 03 03 03 ha un record di lunghezza di 03 , dando un valore completo di 03 03 03 03 . Detto questo, SSL 2.0 non usa il padding in stile PKCS7, ma usa invece padding random, ad es. %codice%. Portando lo stesso metodo di riempimento a SSL 3.0 (e successivamente a TLS) probabilmente è stato più facile adattare il codice esistente.
Quindi, la risposta è: non c'è alcun vantaggio per la sicurezza o il danno per avere il byte extra in TLS 1.2, purché tutti i byte del padding siano correttamente controllati. Il motivo per cui esiste è il supporto legacy e la facilità di implementazione dei nuovi protocolli su stack più vecchi.
Leggi altre domande sui tag tls