OpenSSL Secure Renegotiation

Question

OpenSSL Secure Renegotiation

#1 da (8 voti)

5

Qualcuno ha provato a fare rinegoziazione sicura su OpenSSL e verificarlo usando WireShark? Non riesco a fare una rinegoziazione sicura per quanto riguarda RFC 5746 .

Ho provato a inviare il comando di connessione " R " come suggerito qui . Tuttavia, quando guardo nel pacchetto catturato da wireshark mostra che il messaggio è crittografato. In RFC 5746, si dice che la rinegoziazione dovrebbe essere in ClientHello anziché messaggio di handshake crittografato.

Ho anche provato l'opzione " riconnetti " sul client e sia sess_out che sess_in. Dopo l'handshake, ispeziono tutto il pacchetto catturato, non sembra che abbia alcun dato verify_data nel campo RenegotiationInfo.

Comprendo che, per impostazione predefinita, OpenSSL disabilita la rinegoziazione legacy.
Questo accade quando si utilizza la suite di crittografia ECDHE-RSA-AES128-SHA ma non AES256-SHA

openssl tls

posta Ryu 30.12.2013 - 09:13

fonte

1 risposta

Leggi altre domande sui tag openssl tls

Ho trovato questo codice strano nel mio Wordpress sotto wp-includes Perché dovrei usare MAC rispetto alla firma digitale?

score 8 · Accepted Answer

Il problema della "rinegoziazione sicura" riguarda ciò che accade quando si fa un secondo handshake nel contesto del primo . Questo è ciò che fai con R nel comando openssl s_client ; ma implica che la seconda stretta di mano sia crittografata, quindi è normale e previsto che vengano visualizzati solo messaggi "handshake crittografati". Se si desidera visualizzare il contenuto del messaggio, utilizzare l'opzione della riga di comando -msg su OpenSSL; stamperà un dump esadecimale del messaggio di handshake prima della crittografia . Ad esempio:

$ openssl s_client -connect nameofsomeSSLserver:443 -msg
(...)
    Start Time: 1388406589
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
R
RENEGOTIATING
>>> TLS 1.1 Handshake [length 00eb], ClientHello
    01 00 00 e7 03 02 52 c1 67 3f 99 89 75 92 fa e6
    97 f3 c3 8a f5 2c 30 ba bd 0c 20 e9 1e 3c eb 4b
    3c 2f 85 ec cd 24 00 00 64 c0 14 c0 0a c0 22 c0
    21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00
    84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0
    03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00
    9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00
    41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00
    12 00 09 00 14 00 11 00 08 00 06 00 03 01 00 00
    5a ff 01 00 0d 0c 63 74 19 13 be ac 02 22 04 ed
    81 61 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32
    00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 0a
    00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04
    00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10
    00 11 00 23 00 00 00 0f 00 01 01

In quel ClientHello , possiamo vedere le diverse parti:

01 00 00 e7 : a ClientHello di dimensione 231 byte (0xE7).
03 02 : versione del protocollo (TLS 1.1 in questo caso).
52 c1 ... cd 24 : il "client random" (32 byte).
00 : vuoto ID di sessione (il cliente desidera negoziare una nuova sessione, non una stretta di mano abbreviata).
00 64 : lunghezza dell'elenco di suite di crittografia (100 byte, per 50 pacchetti di crittografia).
c0 14 ... 00 03 : le suite di crittografia supportate dal client (100 byte).
01 00 : un metodo di compressione supportato: la compressione nulla (cioè nessuna compressione).
00 5a : lunghezza dell'elenco di estensioni (90 byte).
ff 01 : tipo di estensione renegotiation_info , come specificato in RFC 5746 .
00 0d : i contenuti dell'estensione hanno una lunghezza di 13 byte.
0c : i dati di renegotiated_connection hanno lunghezza 12 byte.
63 74 19 13 be ac 02 22 04 ed 81 61 : è una copia dei contenuti a 12 byte del messaggio Finished del client durante l'handshake precedente.
quindi vengono alcune altre estensioni.

Quindi questo messaggio indica una "rinegoziazione sicura" come da RFC 5746.

L'opzione della riga di comando -reconnect fa qualcosa di completamente diverso: si connette, fa l'handshake, poi chiude la connessione, quindi si riconnette con una nuova connessione e prova a riprendere la sessione . Ripresa della sessione è il contrario di rinegoziazione sicura : la ripresa della sessione riguarda il riutilizzo del master secret di una precedente connessione su una nuova, mentre la rinegoziazione sicura riguarda la creazione di un nuovo master segreto mantenendo la stessa connessione.