how to protect against TLS GOLDENDOODLE with c++ and openssl? - c++

Question

have a simple web server made with C++ and openssl, and when running SSL Lab's SSL Server Test on it, it informs me that the server is vulnerable to GOLDENDOODLE and Sleeping POODLE (among other things, screenshot here),
i'm running libopenssl 1.1.1c, which is the latest openssl release as of writing, so i don't think it's a case of using an old outdated vulnerable TLS library, instead i'm probably just using it wrong,
hence the question: how do you protect against GOLDENDOODLE with openssl? here is the entire (vulnerable?) server source code:
#include <iostream>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <thread>
#include <chrono>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <openssl/ssl.h>
#include <openssl/err.h>
const uint16_t port=443;
int create_socket(const uint16_t 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");
exit(EXIT_FAILURE);
}
if (bind(s, (struct sockaddr*)&addr, sizeof(addr)) < 0)
{
perror("Unable to bind");
exit(EXIT_FAILURE);
}
if (listen(s, 1) < 0)
{
perror("Unable to listen");
exit(EXIT_FAILURE);
}
return s;
}
void init_openssl()
{
SSL_load_error_strings();
OpenSSL_add_ssl_algorithms();
}
void cleanup_openssl()
{
EVP_cleanup();
}
SSL_CTX *create_context()
{
const SSL_METHOD *method;
SSL_CTX *ctx;
method = SSLv23_server_method();
ctx = SSL_CTX_new(method);
if (!ctx)
{
perror("Unable to create SSL context");
ERR_print_errors_fp(stderr);
exit(EXIT_FAILURE);
}
return ctx;
}
void configure_context(SSL_CTX *ctx)
{
// - Congratulations! Your certificate and chain have been saved at:
// /etc/letsencrypt/live/fuviewer.ml/fullchain.pem
// Your key file has been saved at:
// /etc/letsencrypt/live/fuviewer.ml/privkey.pem
(void)ctx;
SSL_CTX_set_ecdh_auto(ctx, 1);
/* Set the key and cert */
// SSL_FILETYPE_PEM
if (SSL_CTX_use_certificate_chain_file(ctx, "fullchain.pem") <= 0)
{
ERR_print_errors_fp(stderr);
exit(EXIT_FAILURE);
}
if (SSL_CTX_use_PrivateKey_file(ctx, "privkey.pem", SSL_FILETYPE_PEM) <= 0 )
{
ERR_print_errors_fp(stderr);
exit(EXIT_FAILURE);
}
}
int main(int argc, char **argv)
{
(void)argc;
(void)argv;
int sock;
SSL_CTX *ctx;
init_openssl();
ctx = create_context();
configure_context(ctx);
sock = create_socket(port);
std::cout << "server running!" << std::flush;
/* Handle connections */
while(1)
{
struct sockaddr_in addr;
socklen_t len = sizeof(addr);
SSL *ssl;
const char reply[] =
"HTTP/1.0 200 OK\r\n"
"Test-header: Yep\r\n"
"Content-Length: 3\r\n"
"\r\n"
"abc";
const auto reply_size=sizeof(reply)-1;
int client = accept(sock, (struct sockaddr*)&addr, &len);
if (client < 0)
{
perror("Unable to accept");
exit(EXIT_FAILURE);
}
ssl = SSL_new(ctx);
SSL_set_fd(ssl, client);
if (SSL_accept(ssl) <= 0)
{
ERR_print_errors_fp(stderr);
}
else
{
if(SSL_write(ssl, reply, reply_size)!=reply_size)
{
throw std::runtime_error("FAILED TO SEND ALL BYTES");
};
{
// openssl gets cranky if we don't try to read at least 1 byte, even tho we don't really want to..
uint8_t unused;
SSL_read(ssl,&unused,sizeof(unused));
}
SSL_shutdown(ssl);
//std::this_thread::sleep_for(std::chrono::seconds(1));
}
SSL_free(ssl);
close(client);
}
close(sock);
SSL_CTX_free(ctx);
cleanup_openssl();
}

Answer 1

While there are only few information about affected TLS stacks it looks like that OpenSSL should not be vulnerable, even when using CBC ciphers.
I think what you see instead is a false positive, which is triggered by your server not matching the expectations of the test. While I don't know how the GOLDENDOODLE detection by SSLLabs works I've looked at the original detection program from Tripwire.
And it looks like that this script expects a proper HTTP server at the other end, i.e. one which first reads the request and then sends the response. Only, your server does it the other way: first sending the response and reading (and ignoring) a bit of the request only after the response was sent. Such non-HTTP behavior is not taken into account (why should it) and confuses the detection which results in falsely reporting a non-existing problem.