SSL_SET_FD(3ossl)

πŸ’– SSL_SET_FD β€” okay bestie, let's plug an SSL object into a file descriptor πŸ’–

So this is the SSL_set_fd(3ossl) page from the OpenSSL manual, and it's lowkey one of the most useful little functions in the whole library. It's giving "matchmaker" energy fr fr β€” you've got an SSL object and you've got a file descriptor, and this function introduces them. 🌸


✨ NAME ✨

SSL_set_fd, SSL_set_rfd, SSL_set_wfd β€” connect the SSL object with a file descriptor 🫢


✨ SYNOPSIS ✨

#include <openssl/ssl.h>

int SSL_set_fd(SSL *ssl, int fd);
int SSL_set_rfd(SSL *ssl, int fd);
int SSL_set_wfd(SSL *ssl, int fd);

✨ DESCRIPTION ✨

SSL_set_fd() sets the file descriptor fd as the input/output facility for the TLS/SSL (encrypted) side of ssl. And like, fd will typically be the socket file descriptor of a network connection β€” that's the classic use case, that's the vibe. πŸ’…

When it does its thing, a socket BIO gets automatically created to interface between the ssl and fd. The BIO and hence the SSL engine inherit the behaviour of fd, which is the important part bestie: if fd is nonblocking, the ssl will also have nonblocking behaviour. It's giving "you are who you hang out with." πŸ”₯

When used on a QUIC connection SSL object, a datagram BIO is automatically created instead of a socket BIO. And heads up β€” these functions fail if called on a QUIC stream SSL object. 😭

If there was already a BIO connected to ssl, BIO_free() will be called (for both the reading and writing side, if different). Out with the old, in with the new, no cap. πŸŽ€

SSL_set_rfd() and SSL_set_wfd() perform the respective action, but only for the read channel or the write channel, which can be set independently. So if you wanna be picky about which direction gets which fd, these are your girls. πŸ¦‹


✨ RETURN VALUES ✨

The following return values can occur:

  • 0 β€” The operation failed. Check the error stack to find out why. πŸ™ˆ
  • 1 β€” The operation succeeded. Slay! πŸ‘‘

✨ NOTES ✨

Okay so, Windows moment. πŸ’€ On Windows, a socket handle is a 64-bit data type (UINT_PTR), which leads to a compiler warning (conversion from 'SOCKET' to 'int', possible loss of data) when passing the socket handle to SSL_set_*fd(). For the time being, this warning can safely be ignored, because although the Microsoft documentation claims that the upper limit is INVALID_SOCKET-1 (2^64 - 2), in practice the current socket() implementation returns an index into the kernel handle table, the size of which is limited to 2^24. So like, breathe. It's fine. It's fine. 🧚

Real talk though: this note is telling you the warning is currently safe to ignore, not that it's always gonna be. Don't get cocky. ✨

✨ SEE ALSO ✨


Copyright 2000-2023 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


Okay that's the whole page, no skips, no summarising, we ate and left zero crumbs. πŸ“ This was version 3.5.9, dated 2026-09-29, and it's part of the OpenSSL manual β€” mwah, bye bestie, go set some file descriptors πŸ’œπŸŒˆ

πŸ“¦ where this page comes from