Как увидеть зашифрованный ключ в wirehark, во время обмена ключами ssl?

До недавнего времени раскрытие ClientKeyExchange было таким (версия 1.6 и ниже):

 TLSv1 Record Layer: Handshake Protocol: Client Key Exchange Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 134 Handshake Protocol: Client Key Exchange Handshake Type: Client Key Exchange (16) Length: 130 

Но если вы используете этот verison (1.7.2 вверх), раскрытие ключа будет таким:

 TLSv1 Record Layer: Handshake Protocol: Client Key Exchange Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 134 Handshake Protocol: Client Key Exchange Handshake Type: Client Key Exchange (16) Length: 130 RSA Encrypted PreMaster Secret Encrypted PreMaster length: 128 Encrypted PreMaster: 761b1beac35e59de9a3bb9f74ebf9109b738e8ad346 

Вы можете увидеть зашифрованный предварительный мастер 🙂

Вы не увидите зашифрованный общий ключ, он не будет заменен. Вы можете увидеть секретный секретный ключ перед использованием мастера RSA с аутентификацией ключей . (Обратите внимание, что использование Ephemeral Diffie-Hellman – не единственная причина не видеть сообщение об обмене ключами сервера: он также может использовать набор DH_DSS или DH_RSA , но это, насколько мне известно, необычно).

Если вы следуете инструкциям по расшифровке SSL с помощью Wireshark , используйте параметр «Отладочный файл SSL» для хранения журналов в файле. (Обратите внимание, что пользовательский интерфейс немного изменился в более новых версиях Wireshark, в том, как вы настраиваете закрытый ключ.)

Файлы журнала будут содержать секретный ключ и общие ключи.

(Кстати, для этого вам нужен секретный ключ сервера).

Используя данные примера, представленные на странице Wireshark, вы получаете:

 pre master encrypted[128]: 65 51 2d a6 d4 a7 38 df ac 79 1f 0b d9 b2 61 7d 73 88 32 d9 f2 62 3a 8b 11 04 75 ca 42 ff 4e d9 cc b9 fa 86 f3 16 2f 09 73 51 66 aa 29 cd 80 61 0f e8 13 ce 5b 8e 0a 23 f8 91 5e 5f 54 70 80 8e 7b 28 ef b6 69 b2 59 85 74 98 e2 7e d8 cc 76 80 e1 b6 45 4d c7 cd 84 ce b4 52 79 74 cd e6 d7 d1 9c ad ef 63 6c 0f f7 05 e4 4d 1a d3 cb 9c d2 51 b5 61 cb ff 7c ee c7 bc 5e 15 a3 f2 52 0f bb 32 pre master secret[48]: 03 00 ff 84 56 6d a0 fb cc fd c6 c8 20 d5 f0 65 18 87 b0 44 45 9c e3 92 f0 4d 32 cd 41 85 10 24 cb 7a b3 01 36 3d 93 27 12 a4 7e 00 29 96 59 d8 master secret[48]: 1e db 35 95 b8 18 b3 52 58 f3 07 3f e6 af 8a a6 ab c3 a4 ed 66 3a 46 86 b6 e5 49 2a 7c f7 8c c2 ac 22 bb 13 15 0f d8 62 a2 39 23 7b c2 ff 28 fb key expansion[136]: 11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7 b3 f7 33 aa b2 42 d0 1c a6 4e fb e9 9b 13 dd 29 63 aa 17 1f 47 71 95 71 08 e0 4b 8e e1 da 7b 4a 5a f3 c2 32 bd e0 a5 82 6d 14 44 3a d6 cb 2d c0 7d 57 be a8 37 de 5d d9 a1 07 fd 1b 22 71 b9 4b 7a 1e 0f 70 37 14 97 0a f0 db 98 3b 7b 74 e3 2d 51 66 2e 31 68 90 ac 6f e6 53 3c c9 5e 48 0c 05 bc 9f 92 e7 f9 91 98 f5 95 1c c4 bf d9 cb 26 ef 35 70 5e ad 21 22 3e f6 Client MAC key[20]: 11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7 b3 f7 33 aa Server MAC key[20]: b2 42 d0 1c a6 4e fb e9 9b 13 dd 29 63 aa 17 1f 47 71 95 71 Client Write key[32]: 08 e0 4b 8e e1 da 7b 4a 5a f3 c2 32 bd e0 a5 82 6d 14 44 3a d6 cb 2d c0 7d 57 be a8 37 de 5d d9 Server Write key[32]: a1 07 fd 1b 22 71 b9 4b 7a 1e 0f 70 37 14 97 0a f0 db 98 3b 7b 74 e3 2d 51 66 2e 31 68 90 ac 6f Client Write IV[16]: e6 53 3c c9 5e 48 0c 05 bc 9f 92 e7 f9 91 98 f5 Server Write IV[16]: 95 1c c4 bf d9 cb 26 ef 35 70 5e ad 21 22 3e f6 

Удивительный напишите здесь, объясняя, как работает SSL, ни в коем случае не замечайте, что это рукопожатие – это секретный ключ, когда-либо отправленный по кабелю.

http://4orensics.wordpress.com/2011/10/21/ssl-in-a-nutshell/

Короче говоря, нет способа дешифровать streamи SSL без личного ключа сервера (если вы не работаете в NSA или что-то в этом роде), однако вы можете захотеть просмотреть промежуток между сервером и клиентом во время рукопожатия, и если пользователь не выполняет проверьте действительность сертификата, который представлен вам в бизнесе.

Вот инструмент, который может сделать это для вас среди многих других

http://mitmproxy.org/

Отмечаем, что я настоятельно рекомендую статью без чтения статей о атаках SSL Mitm (Man in the Middle).