Hypothetically speaking, could an attacker run a targeted attack on a network that would inject information into a victim's cache of recent TLS connections? Specifically, the master-key and sessionID of your existing session you'd maintain with a specific website the victim would likely visit later.

When the victim goes to connect to the website over https, the full handshake will be forgone and the client will attempt to renegotiate a session using the injected (and known by the attacker) master key and sessionID. In turn, allowing the attacker to eavesdrop on all following encrypted communications.

Is this correct, or is my understanding of TLS implementation incorrect? Of course, injecting the information is a mountain to climb all it's own; but I'm still learning a lot about TLS and asked myself this question.

  • 1
    I don't think you could do such a without having access to the machine with full access to the process. Then it might be simpler to just steal the private key. Commented Sep 1, 2014 at 18:00
  • 1
    It would be even easier to add a fake Certification Authority certificate to the system, change the DNS server configuration, and be able to decrypt every SSL connection.
    – ThoriumBR
    Commented Sep 1, 2014 at 18:13

1 Answer 1


A cached and reused session with attacker-chosen key will only work to/via the attacker, since the legit peer who has been impersonated won't know this id and key. So this doesn't allow passive eavesdropping, it allows active impersonation (including MitM) to continue more efficiently once it has been started, just as it allows continued legitimate connections to be more efficient.

Obviously intercepting and faking the initial connection (with full handshake) will cause the peer's normal cache logic (if any, see below) to store the evil session. Beyond that malicious alteration to the cache depends on the implementation; there isn't any TLS operation which pulls sessions into cache the way DNS or ARP will pull "poisoned" entries off the wire.

You tagged openssl and described the action of https client only, although your question doesn't state such a limit. If you do mean openssl client, that does not cache at all by default. If the client app or perhaps user specifies the context needed for caching, by default openssl will keep the cache only in memory, although the app can provide callbacks to do something else. In contrast openssl server does cache in memory by default, and at least some real servers do use an external session store shared by mutiple processes to handle a large client volume.

If other implementations are of interest, ask a more specific question. (Or if you can formulate it as an improvement to this question please be clear about the change; it is considered impolite in this forum to "orphan" already given answers.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .