On Thu, Feb 15, 2018 at 3:02 PM Aleksandar Lazic <[email protected]> wrote:
> Hi. > > Am 15.02.2018 um 22:42 schrieb Christopher Lane: > > Internally, my company uses pregenerated SSL sessions. > > Just for my curiosity what is a "pregenerated SSL session" ? > What's the use case for this? > > SSL sessions, as negotiated between the client and server, can be serialized and saved to disk or database or whatever. Then when a new connection comes in, they can be de-serialized and the old session can be resumed, skipping the multiple round trip SSL handshake and the expensive RSA key operations. We generate the SSL sessions (which include the session AES key so are as sensitive as the RSA private key) and distribute them throughout the data center so we can get 5 ms SSL connect times instead of 20-30 ms connect times. An alternative way to use this functionality is to put all newly created SSL session objects into memcached or the like and then keep loading the memcached sessions into the listening SSL contexts. > > I am thinking > > about maybe changing haproxy to load and use our sessions. Would there > > be interest in some sort of opensource change to allow session loading > > as some easy extension/config for haproxy. Like some config > > > > ssl_get_sessions_from_exe=custom_session_emitter > > where custom_session_emitter writes the appropriate ASN1/PEM session > > data or some such? > > > > Or > > > > ssl_get_sessions_from_file=sessions.pem > > > > (less good because we encrypt the session data on disk). > > > > If not, I'll just strive to make my patches clean against the tree, but > > if so, I'm happy to contribute the interface. (As far as I can tell, > > not many places are using pregenerated sessions, but to do save a lot of > > latency). > > Do you need to handle the session dynamically or only at startup time? > Start up time will be simple enough for us, we aren't using the DB caching model. Something runtime would have to involve some C api or exposing it to LUA or something more complicated. > > > --Chris > > Nevertheless sounds interesting. > > Best regards > aleks >
