13

I have to secure an existing socket client connection using OpenSSL to replace connect, send, receive, close functions.
But I'm not really comfortable with the use of the SSL and BIO functions.
I know there have been some questioning about it here and here, but it is still not clear to me the exact difference between them. Can anyone help me understand the exact relation between them (1)?

OpenSSL documentation always refer to BIO as an underlying structure, but there is no further explanation on the subject. As I understand it, any call to SSL_write will also write to a BIO, that can be handled or not.
Is there any difference in doing a BIO_write or a SSL_write to send data to the socket (2)?
If no, what is the advantage of using the BIO functions in my case (3)? Is there any (4)?

I have found some useful examples on SSL clients here and here. The first one mix up the use of BIO and SSL functions like using SSL_do_handshake instead of BIO_do_handshake. Is that ok (5)?

Since BIO is underlying to SSL functions, should I avoid using it (6)?

Community
  • 1
  • 1
learning_frog
  • 305
  • 1
  • 3
  • 14
  • 7
    The SSL API sits on top of the BIO API. By default, the SSL API uses a socket BIO to handle all socket I/O for you, requiring you to re-write your existing code logic, ie to use `SSL_recv()`/`SSL_write()` instead of `recv()`/`send()`. If you want to do your own I/O, you can create a couple of memory BIO pairs and link them to an SSL session with `SSL_set_bio()`. This way, any raw data you receive can be pushed into one BIO pair and `SSL_recv()` will decrypt what it reads from it, and `SSL_write()` will push encrypted data into the other BIO pair and you can then send whatever you read from it. – Remy Lebeau Sep 06 '16 at 20:28
  • 1
    So, if I only want to send/receive through the socket, I don't need to use the BIO functions? SSL functions will suffice? – learning_frog Sep 06 '16 at 20:36
  • 3
    In other words, if you use the BIO API in conjunction with the SSL API, you can preserve your existing socket I/O logic with the I/O API of your choice, while still adding SSL encryption/decryption on top of it. Otherwise, you have to re-write your socket logic to split encrypted and non-encrypted socket handing using separate I/O APIs, and that is not always desirable (especially when it comes to reading and error handling (especially because OpenSSL tends to work opposite to how socket developers are traditionally taught to manage socket I/O). – Remy Lebeau Sep 06 '16 at 20:37
  • 1
    You don't NEED to use the BIO API directly at all, but it is *preferred* when applicable. It really depends on your existing socket codebase and how much effort you want to put into rewriting it to make it SSL-enabled. – Remy Lebeau Sep 06 '16 at 20:38
  • As I understand it, you think it is easier to keep my socket code unchanged and add another layer on top of it using BIOs to encrypt/decrypt data. Is that what you mean? – learning_frog Sep 06 '16 at 20:40
  • 5
    I said that is up to you to decide based on your codebase and level of effort desired. You can go either way. The SSL API by itself is a bit simpler to use, but does have some different semantics than traditional socket APIs (for example, in non-blocking mode, don't call `select()`/`poll()` until OpenSSL asks you to first, whereas in traditional APIs you would call `recv()`/`send()` when `select()`/`poll()` tells you its OK). On the other hand, the BIO API is a bit more work to use, but it offers more flexibility in how you handle I/O operations. – Remy Lebeau Sep 06 '16 at 21:08

0 Answers0