Showing results for 
Show  only  | Search instead for 
Did you mean: 

Help reading o/p of show ssldecr server

Hi , can someone help me know the meaning of highlighted part in screenshot . I am not able to decrypt this data using a valid key


Dynatrace Pro
Dynatrace Pro


Decryption is possible only when AMD saw whole session, including the handshake which occurs at the beginning of the session. Highlighted part says that AMD saw sessions that have been established prior to beginning of the AMD observation. It can't decrypt such sessions because it didn't see the handshake.

In more technical details: Valid key that you have (assuming it's an RSA private key) is used by client and server to negotiate the session key, which is different for every session. AMD needs the server private key to snoop on the session key negotiation, so then it can use the session key to decrypt session traffic. Session key negotiation is computationally expensive, so server and client don't do it every session. They agree to use previously negotiated key if one is present. When they agree so, they don't exchange the key (this is the part of the full session handshake), just reuse what they bth negotiated before. Highlighted text reports sessions that reused session keys that have been negotiated during previous handshakes, which haven't been seen by the AMD. These sessions used so-called short handshakes instead of regular (full) handshakes. This is normal procedure, commonly used to speed up session setup. However, in typical situations the web browsers enforce full handshake every N sessions or N minutes, for the sake of consistent security. So after long enough observation period, the number of short-handshake sessions that can't be decrypted because its corresponding long-handshake session hasn't been seen - should decline towards zero. Therefore a question: how long is the observation period that the screenshot represents? If it's quite long (say an hour), then next question would be whether subject traffic is perhaps sever to server, not browser to server? In such situation session reuse may occur forever (putting security aspects aside), so AMD may not be able to get in sync with the keys that servers exchanged when they communicated with each other for the first time. Read: you may need to wait until servers re-negotiate the connection. Or force them to do so, to let the AMD see the full handshake.

Hope this helps

hi , thanks for the detailed explanation . It does make sense , however I just captured a number of tcpdump for this IP . I can see a several client hello and server hello . Doesnt that mean my AMD is getting data from the start of the session . While even decryption is failing,

New session which reuses the keys starts with the Hello as well. Then the negotiation results in previous key reuse.

Do you have SSL connections setup monitoring enabled in NAM configuration? You would see on CAS repots how many long versus short handshakes occurred.

I can see short handshakes in the o/p , is that what you re suggesting to check?

Dynatrace Pro
Dynatrace Pro

AMD console statistics in deed show that woful handshakes have been seen. But I don't know for what time period is this statistics. i.e. when has AMD last restarted? I suggested to look at reports in the CAS to compare other days, other servers, perhaps over AMDs if you have them.

@Kris Z. thankyou . after AMD restart , issue got resolved.