SSL_SET_BIO(3ossl)
π 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,rbiomust implement eitherBIO_meth_set_read_ex(3)orBIO_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
rbioorwbiohave changed from their previous values, then nothing is done. leave it alone, it's fine π§ - if the
rbioandwbioparameters are different and both are different to their previously set values, then one reference is consumed for therbioand one reference is consumed for thewbio. - if the
rbioandwbioparameters are the same and therbiois not the same as the previously set value, then one reference is consumed. - if the
rbioandwbioparameters are the same and therbiois the same as the previously set value, then no additional references are consumed. - if the
rbioandwbioparameters are different and therbiois the same as the previously set value, then one reference is consumed for thewbioand no references are consumed for therbio. - if the
rbioandwbioparameters are different and thewbiois the same as the previously set value, and the oldrbioandwbiovalues were the same as each other, then one reference is consumed for therbioand no references are consumed for thewbio. - if the
rbioandwbioparameters are different and thewbiois the same as the previously set value, and the oldrbioandwbiovalues were different to each other, then one reference is consumed for therbioand one reference is consumed for thewbio.
π« because of this complexity, this function should be avoided; useSSL_set0_rbio()andSSL_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 π
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
- freebsd 15.1: base 15.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms