301B: BIG-IP LTM Specialist: Maintain and TroubleshootDemo

By F5 · Question Mode

QuestionQ106

Identify and Resolve LTM Device Issues

Given the following first packet shown in 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

After reviewing the remaining ssldump output, the application data is not decrypted.

Why does ssldump fail to decrypt the application data?

  • A The application data is encrypted with SSLv3.
  • B The application data is encrypted with TLSv1.
  • C The data is contained within a resumed TLS session.
  • D The BigDB Key Log.Tcpdump.Level needs to be adjusted.
Explanation

TLS session resumption uses an abbreviated handshake and reuses the prior session’s security state rather than performing a new full key exchange. ssldump does not implement session caching, so it cannot obtain the reused session secrets needed to decrypt application data from a resumed session. TLS version 3.1 denotes TLS 1.0, not SSLv3. RFC 2246 specifies that a matching nonempty session ID causes the peers to proceed directly to the finished messages in a resumed session.

Learn more

Community Discussion

No comments yet. Be the first to start the discussion!