-1

I'm working on a server-side software that receives requests from clients via TLS (over TCP). For better performance and user experience, I'd like to avoid a full handshake for every request. Ideally, the client can just establish a TLS session with the server for hours, although most of the time the session might be idle. At the same time, high throughput is also required.

One easy way to do it is to dedicate a thread for each session and use a big thread pool to boost throughput. But the performance overhead of this method could be huge, if I want, say, 10s thousands of concurrent sessions.

The requirement of high throughput leads to me the event-driven model. The idea is when the connection is idle (namely no IO event on the underlying socket), the TLS server can switch context to serve other connections. One of the challenges is to sort of freeze the entire TLS session context while the socket is idle and retrieve it when the socket becomes readable/writable.

I'm wondering if there is support already in TLS for this kind of feature? Both cache and ticket seem relevant. Also, I'm wondering if people have implemented this idea.

qweruiop
  • 3,156
  • 6
  • 31
  • 55

1 Answers1

-1

You are talking about SSL Session resumption, and it is already implemented in both OpenSSL and JSSE, and no doubt every other SSL API you would be using. SSL sessions already survive connections. So there is nothing for you to do to get this.

The part about 'freezing the SSL session context' is completely pointless.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Well, only that OpenSSL is not event-driven. That's why I'm writing my own event-driven TLS server. If you think it's so simple, maybe you could tell me what should be done when a socket receives bytes? I think I need to look up which SSL session is associated with the socket and revive the session context (e.g. by `SSL_set_session`), then handle the data properly. Are you suggesting none of this is necessary? – qweruiop Nov 17 '17 at 03:56
  • OpenSSL can be used in association with non-blocking I/O and `select()`, which makes it event-driven. None of what you propose is necessary, as I already stated. – user207421 Nov 17 '17 at 03:59
  • Could you point me to an example program? If `select()` shows multiple client sockets are readable, I still need to read each of them with corresponding `SSL*`, so I need to somehow maintain a socket to `SSL*` map, no? Am I missing something basic? – qweruiop Nov 17 '17 at 04:40
  • Yes, of course you need SSL sockets, nobody has said anything different. I suspect you are indeed missing something pretty basic. There is plenty of sample code at http://openssl.org. – user207421 Nov 17 '17 at 04:42
  • Well, easy. I'm not saying anybody has said anything different. Could you answer my question more directly, if you think you know the answer? Of course one needs SSL sockets, but that's not my question. – qweruiop Nov 17 '17 at 04:52
  • 1
    Answer *what* question exactly? I've *given* you several answers, and I can't see any questions here that I haven't already answered. It seems to me that you need to first learn how to write a server, which is too broad, and then learn the SSL API, which is also too broad.m and study the examples at the site I gave you, which is homework. – user207421 Nov 17 '17 at 05:56
  • Trust me I know how to write a server. You don't seem to get the specifics of my questions nor did you care to. I'm asking specifically how to associate events with SSL contexts. Anyway, I found [bufferevent_openssl.c](https://github.com/libevent/libevent/blob/c6c74ce2652fd02527a1212e36cbfd788962132a/bufferevent_openssl.c) useful, esp. `bufferevent_openssl_new_impl(...)`. – qweruiop Nov 17 '17 at 17:40
  • That'e exactly why I pointed you to the example code to answer that question. Rather than try to answer it myself before you had read the sample code, which would have been a waste of everybody's time. – user207421 Nov 20 '17 at 00:50