I'm having difficulty getting any documentation at all about how HTTP.SYS caches TLS/SSL sessions. I notice that IIS6 and earlier used SChannel to handle TLS caching. Is this still the case for IIS7-8? I get the impression that HTTP.SYS might now handle TLS/SSL internally instead. Note that I'm not talking about client side caching of the HTTPS responses in Internet Explorer. I'm talking specifically about the caching of TLS/SSL sessions on the server to enable reconnection without a RSA negotiation.
We have a very unusual requirement to support the caching of an extremely large number of TLS sessions. This is not a general purpose website. The clients are extremely low powered and data bandwidth costs are
extremely critical. The client software is not a web browser, but custom
code completely under our control. Power usage, data costs and server
resources simply do not permit these devices to negotiate via RSA for every connection. In an Ideal world we could cache 1 million (yes really!) TLS sessions on a single server and these sessions could remain open for at least a day, preferably months, with time between requests variable, but averaging around 30 minutes. For scalability, power and network topography reasons, we must aim to hold the TCP session itself open for less than 100 milliseconds in the typical case. We are comfortable providing the additional 4GB or so of RAM required to hold these TLS sessions in RAM, although a system that could persist the sessions to disk would enable faster recovery from server downtime.
It is very difficult to find out if HTTP.SYS is capable of supporting this number of suspended TLS sessions or even which component is responsible for it, HTTP.SYS or SChannel.
We'd really like to use the existing functionality, but need to know if we actually need to write a new listener from scratch, which is a major undertaking. Another alternative would be a on-server proxy that would handle the TLS side and just connect to IIS on port 80 with the decoded traffic. Again, this is more work than just configuring IIS if it is capable of handling so many cached sessions already.