SSL_SET_BIO(3ossl)

πŸ“¦
version 15.1 Β· 2 versions
, in freebsd 15.1

πŸ’… SSL_SET_BIO β€” the 3ossl manual, but make it make sense

okay so bestie, this is the SSL_SET_BIO(3ossl) page, and honestly it's the "link your SSL object to a BIO" page πŸŽ€. If you've ever been like "why is my SSL talking to nothing," it's probably because nobody set the bio. sit down, hydrate, let's go ✨


🌸 NAME 🌸

SSL_set_bio, SSL_set0_rbio, SSL_set0_wbio β€” the trio that connects the SSL object with a BIO 🫢


✨ SYNOPSIS ✨

#include <openssl/ssl.h>

void SSL_set_bio(SSL *ssl, BIO *rbio, BIO *wbio);
void SSL_set0_rbio(SSL *s, BIO *rbio);
void SSL_set0_wbio(SSL *s, BIO *wbio);

that's it. that's the whole vibe. three functions, all void, all vibes πŸ’œ


πŸ’– DESCRIPTION πŸ’–

πŸ¦‹ SSL_set0_rbio() β€” the read side

k so SSL_set0_rbio() connects the BIO rbio for the read operations of the ssl object. slay. the SSL engine inherits the behaviour of rbio, which is lowkey the most important part: if the BIO is nonblocking, then the ssl object will also be nonblocking. no cap, it just copies the vibe check πŸŽ€

this function transfers ownership of rbio to ssl. meaning it'll be automatically freed using BIO_free_all(3) when the ssl is freed. so like… don't free it yourself afterward, bestie, that's giving double-free energy 😭

and on calling this function, any existing rbio that was previously set will also be freed via a call to BIO_free_all(3) β€” and yes, that includes the case where the rbio is set to the same value as previously. literally frees it and re-takes it. iconic but spicy 🌢️

if you're using a custom BIO, rbio must implement either BIO_meth_set_read_ex(3) or BIO_meth_set_read(3). non-negotiable, i don't make the rules πŸ’…

🌈 SSL_set0_wbio() β€” the write side

SSL_set0_wbio() works in the same way as SSL_set0_rbio() except that it connects the BIO wbio for the write operations of the ssl object. mirror twin behaviour, we stan πŸ’–

⚠️ note that if the rbio and wbio are the same, then SSL_set0_rbio() and SSL_set0_wbio() each take ownership of one reference. so it may be necessary to increment the number of references available using BIO_up_ref(3) before calling the set0 functions. do with that what you will πŸ”₯

and if you're using a custom BIO, wbio must implement BIO_meth_set_write_ex(3) or BIO_meth_set_write(3). it additionally must implement BIO_flush(3) using BIO_CTRL_FLUSH and BIO_meth_set_ctrl(3). if flushing is unnecessary with wbio, then BIO_flush(3) should return one and do nothing. fake it till you make it 🫢

πŸ‘‘ SSL_set_bio() β€” the both-at-once one

SSL_set_bio() is similar to SSL_set0_rbio() and SSL_set0_wbio() except that it connects both the rbio and the wbio at the same time, and transfers the ownership of rbio and wbio to ssl according to the following set of rules:

  • if neither the rbio or wbio have changed from their previous values, then nothing is done. leave it alone, it's fine 🧚
  • if the rbio and wbio parameters are different and both are different to their previously set values, then one reference is consumed for the rbio and one reference is consumed for the wbio.
  • if the rbio and wbio parameters are the same and the rbio is not the same as the previously set value, then one reference is consumed.
  • if the rbio and wbio parameters are the same and the rbio is the same as the previously set value, then no additional references are consumed.
  • if the rbio and wbio parameters are different and the rbio is the same as the previously set value, then one reference is consumed for the wbio and no references are consumed for the rbio.
  • if the rbio and wbio parameters are different and the wbio is the same as the previously set value, and the old rbio and wbio values were the same as each other, then one reference is consumed for the rbio and no references are consumed for the wbio.
  • if the rbio and wbio parameters are different and the wbio is the same as the previously set value, and the old rbio and wbio values were different to each other, then one reference is consumed for the rbio and one reference is consumed for the wbio.
🫠 because of this complexity, this function should be avoided; use SSL_set0_rbio() and SSL_set0_wbio() instead. yeah. that's the actual official advice. it's giving "we made it, we regret it" πŸ’€

πŸ’€ the QUIC blocking-mode tea

where a new BIO is set on a QUIC connection SSL object, blocking mode will be disabled on that SSL object if the BIO cannot support blocking mode. and if another BIO is subsequently set on the SSL object which can support blocking mode, blocking mode will not be automatically re-enabled. so it stays off. forever. no take-backs πŸ™ˆ

for more info, see SSL_set_blocking_mode(3).


⭐ RETURN VALUES ⭐

SSL_set_bio(), SSL_set0_rbio() and SSL_set0_wbio() cannot fail. that's it. that's the section. flawless behaviour, honestly πŸ‘‘


πŸ“ SEE ALSO πŸ“

SSL_get_rbio(3), SSL_connect(3), SSL_accept(3), SSL_shutdown(3), ssl(7), bio(7)

go read them, iyk yk πŸ’–


🧚 HISTORY 🧚

SSL_set0_rbio() and SSL_set0_wbio() were added in OpenSSL 1.1.0. the set0 girls are newer, the og SSL_set_bio() has been here since forever 🌸


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>.


k bye bestie, go set some bios πŸ’…βœ¨

this has been OpenSSL 3.5.6, dated 2026-04-07, from the SSL_SET_BIO(3ossl) page β€” periodt 🫢

πŸ“¦ where this page comes from