In windows 7, session tickets were disabled by disabling schannel cache, example:


Other Microsoft sources say the following in regard to Windows 10: Schannel EnableSessionTicket, value 2, disables Session Ticket TLS "Optimization" in the system.


Is there a difference between "Session Ticket TLS Optimization" and "Session Tickets in general?" Or is it TLS Session Tickets with OPTIMIZATION, like rtt0 or some other form of optimization?

Logically, I would assume disabling TLS session tickets would require the following entry


However, this source claims setting dword:00000002, the system will revert to handling TLS sessions exactly like the sessions were negotiated in earlier Windows Server operating systems.

To disable Session Tickets, does this mean users must enable the following 3?


And finally, what does "EnableSessionTicket"=dword:00000000, and dword:000000001 do?

Thank you.

  • Why not use powershell ?: Disable-TlsSessionTicketKey – Overmind Feb 4 '19 at 7:02
  • I am mostly interested as a poweruser/workstation that is not part of a domain. Does this affect local services or remote services or both? This apparently allows one to disable session tickets for individual service accounts but not globally like Schannel; and what service account deals with cryptoapi, windows update, iis, remote desktop, and all the rest if one was to do this effectively? – Tyler Feb 5 '19 at 19:08
  • I've detailed the situation in an answer. – Overmind Feb 6 '19 at 7:33

I'd recommend if possible that you use Disable-TlsSessionTicketKey from powershell instead of the global disable.

This affects the service account specified, preventing it from decrypting existing TLS session tickets and does not affect anything else. This method makes it easier to protect a specific service that we know it could represent a vulnerability, while not preventing other services from using the feature.

Otherwise, you can set

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\MaximumCacheSize to 0 


HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ServerCacheTime to 0 

and by preventing any caching the ticketing feature will not work. This is sufficient to prevent it from working. The disadvantage of this may be latency in the case of heavy TLS usage.

Note that the setting "EnableSessionTicket"=dword:00000002 does NOT disable ticketing, it disables the session ticket TLS optimization. Logically, if you'd want it disabled you could set it to "0", but as I mentioned it is not necessary if there is no caching.

  • Could you explain what you believe is the benefit of disabling TLS tickets for a local service account over doing it globally? If you could update your post with the relevant info, that would be nice. I'm assuming this is to only affect sensitive security critical accounts on domains / servers that use Schannel. I am starting to see TLS resumption as less of an issue than previously thought, at least for non critical applications. – Tyler Feb 8 '19 at 7:32
  • Thank you for the comment. As I said in the answer, the proposed method only affects the target service account. This makes it easier to protect a specific service that we know it could represent a vulnerability, while not preventing other services from using the feature. I have added the above part in my answer. – Overmind Feb 8 '19 at 7:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.