Simple TLS Server

From OpenSSLWiki
Jump to navigationJump to search

You may find an up to date example within repository demos/sslecho.

The code below is a complete implementation of a minimal TLS server. The first thing we do is create an SSL_CTX or SSL context. This is created using the TLS_server_method which creates a server that will negotiate the highest version of SSL/TLS supported by the client it is connecting to. The context is then configured by specifying the certificate and private key to use.

Next we perform some normal socket programming and create a new server socket, there's nothing OpenSSL specific about this code. Whenever we get a new connection we call accept as normal. To handle the TLS we create a new SSL structure, this holds the information related to this particular connection. We use SSL_set_fd to tell openssl the file descriptor to use for the communication. In this example, we call SSL_accept to handle the server side of the TLS handshake, then use SSL_write() to send our message. Finally we clean up the various structures.

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <signal.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <openssl/ssl.h>
#include <openssl/err.h>

int create_socket(int port)
    int s;
    struct sockaddr_in addr;

    addr.sin_family = AF_INET;
    addr.sin_port = htons(port);
    addr.sin_addr.s_addr = htonl(INADDR_ANY);

    s = socket(AF_INET, SOCK_STREAM, 0);
    if (s < 0) {
        perror("Unable to create socket");

    if (bind(s, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
        perror("Unable to bind");

    if (listen(s, 1) < 0) {
        perror("Unable to listen");

    return s;

SSL_CTX *create_context()
    const SSL_METHOD *method;
    SSL_CTX *ctx;

    method = TLS_server_method();

    ctx = SSL_CTX_new(method);
    if (!ctx) {
        perror("Unable to create SSL context");

    return ctx;

void configure_context(SSL_CTX *ctx)
    /* Set the key and cert */
    if (SSL_CTX_use_certificate_file(ctx, "cert.pem", SSL_FILETYPE_PEM) <= 0) {

    if (SSL_CTX_use_PrivateKey_file(ctx, "key.pem", SSL_FILETYPE_PEM) <= 0 ) {

int main(int argc, char **argv)
    int sock;
    SSL_CTX *ctx;

    /* Ignore broken pipe signals */
    signal(SIGPIPE, SIG_IGN);

    ctx = create_context();


    sock = create_socket(4433);

    /* Handle connections */
    while(1) {
        struct sockaddr_in addr;
        unsigned int len = sizeof(addr);
        SSL *ssl;
        const char reply[] = "test\n";

        int client = accept(sock, (struct sockaddr*)&addr, &len);
        if (client < 0) {
            perror("Unable to accept");

        ssl = SSL_new(ctx);
        SSL_set_fd(ssl, client);

        if (SSL_accept(ssl) <= 0) {
        } else {
            SSL_write(ssl, reply, strlen(reply));



Session Reuse[edit]

According to Viktor Dukhovni at Possible to control session reuse from the client:

> For performance testing purposes, I would like to turn off session
> reuse in the (homegrown) client I use for testing. Is there a function
> in the openssl library to do it?
> I tried googling for "openssl client don't send session id" but I didn't
> find anything useful.

Just do nothing.  Client sessions are not reused unless you explicitly
arrange for reuse of a session by calling SSL_set_session() before
SSL_connect().  If you're trying to avoid wasting memory on storing
client-side sessions that you'll never reuse then this may help:

   SSL_CTX_set_session_cache_mode(client_ctx, SSL_SESS_CACHE_OFF);

but note this is also the default state, so is also not needed unless
some other code has explicitly enabled client-side caching of sessions.

Only the server-side cache is enabled by default.


0-RTT is specified in XXX (TODO). 0-RTT allows an application to immediately resume a previous session at the expense of consuming unauthenticated data. You should avoid 0-RTT if possible. In fact, an organization's data security policy may not allow it for some higher data sensitivity levels.

Care should be taken if enabling 0-RTT at the server because a number of protections must be enabled. Additionally, some of the protections are required higher up in the stack, outside of the secure socket layer. Below is a list of potential problems from Closing on 0-RTT on the IETF TLS working group mailing list.

  • 0-RTT without stateful anti-replay allows for very high number of replays, breaking rate limiting systems, even high-performance ones, resulting in an opening for DDoS attacks.
  • 0-RTT without stateful anti-replay allows for very high number of replays, allowing exploiting timing side channels for information leakage. Very few if any applications are engineered to mitigate or eliminate such side channels.
  • 0-RTT without global anti-replay allows leaking information from the 0-RTT data via cache timing attacks. HTTP GET URLs sent to CDNs are especially vulnerable.
  • 0-RTT without global anti-replay allows non-idempotent actions contained in 0-RTT data to be repeated potentially lots of times. Abuse of HTTP GET for non-idempotent actions is fairly common.
  • 0-RTT allows easily reordering request with re-transmission from the client. This can lead to various unexpected application behavior if possibility of such reordering is not taken into account. "Eventually consistent" datastores are especially vulnerable.
  • 0-RTT exporters are not safe for authentication unless the server does global anti-replay on 0-RTT.