Exam 301b All QuestionsBrowse all questions from this exam
Go to Exam
Question 40

Given this as the first packet displayed of an ssldump:

2 2 1296947622.6313 (0.0001) S>CV3.1(74) Handshake

ServerHello -

Version 3.1 -

random[32]=

19 21 d7 55 c1 14 65 63 54 23 62 b7 c4 30 a2 f0

b8 c4 20 06 86 ed 9c 1f 9e 46 0f 42 79 45 8a 29

session_id[32]=

c4 44 ea 86 e2 ba f5 40 4b 44 b4 c2 3a d8 b4 ad

4c dc 13 0d 6c 48 f2 70 19 c3 05 f4 06 e5 ab a9

cipherSuite TLS_RSA_WITH_RC4_128_SHA

compressionMethod NULL

In reviewing the rest of the ssldump, the application data is NOT being decrypted.

Why is ssldump failing to decrypt the application data?

    Correct Answer: C

    ssldump is failing to decrypt the application data because the data is contained within a resumed TLS session. In resumed TLS sessions, the necessary key exchange does not occur again, and hence the session-specific keys required for decryption are not available to ssldump.

Discussion
GVKDOption: C

C - Correct Here's what you can look for to identify a resumed TLS connection in ssldump: 1. Missing ClientHello and ServerHello messages: In a resumed session, these messages are omitted as the client can reuse the existing session information. 2. Session ID presence: Look for the "Session ID" field in the handshake messages. If present, it indicates that the client is attempting to resume a previous session. 3. Cipher Suite agreement: In resumed sessions, the client and server directly agree on the cipher suite without negotiation, unlike the multiple options offered in a full handshake. 4. Short and fast handshake: Resumed sessions have significantly shorter handshakes as they do not require the full key exchange process. 5. Missing server certificate: Since the server already presented its certificate during the initial handshake, it won't be resent in a resumed session.