Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

OpenSSL (old) tutorial-style example programs ?

83 views
Skip to first unread message

R.Wieser

unread,
May 25, 2023, 3:39:51 AM5/25/23
to
Hello all,

I've been trying whip up some code using (an older version of) OpenSSL.
I've ofcourse googled for information how to use it, but all I've been able
to find is some "examples" which stop directly after reading the reply (no
code to terminate the connection), or overly complex stuff aimed at a
certain target.

Currently I have got some code which shows :

1) a BIO_xxx way to retrieve unencrypted data

2) a mix between winsock and SSL_xxx to retrieve encrypted data - not sure
how/if the SSL part is closed

3) a mix between BIO_xxx and SSL_xxx to retrieve encrypted data, but which
doesn't include code to close the connection.

4) some other bits-and-pieces

The thing is, although I can mostly find the used commands back, I can't
find anything about how they interact. As such I have a hard time to even
find how to close an SSL connecion before I close the underlying BIO/socket
one. And for closing the BIO one I'm /assuming/ that all I need is
"BIO_free_all" ...

Also, 3) does stuff with BIO_xxx which caters to the SSL connection (like
setting the name of the target domain), while with 2) I only have to provide
the connected socket to SSL_set_fd to have everything work. IOW, I would
like to see some BIO_xxx code to connect (which it only seems to do on the
first BIO_read or BIO_write), and than have the SSL_xxx part take over the
connection the same way as with a standard socket.

One other thing : To keep my first steps as easy as possible I'm using
blocking sockets. Examples that jump into the deep end using async sockets
are of little value & use to me.

tl;dr:
I'm looking for some tutorial-style example code, explaining the basic
setup, request, retrieval and tear-down steps of an encrypted connection
using OpenSSL.

I'm currently using OpenSSL 0.9.8.0 , but that might just be because I've
not come across anything related to the current v3.1.0 version ...

Regards,
Rudy Wieser


Paavo Helde

unread,
May 25, 2023, 8:28:25 AM5/25/23
to
OpenSSL 0.9 is seriously out of date. Currently supported stable
versions are 1.1.* and 3.0.*.

I do not have polished example code, my actual code is scattered around
several C++ classes and in partially platform-dependent source files.
Anyway, I can paste some snippets here, maybe these are helpful.


This code is using OpenSSL 3.0.8 for wrapping an existing connected
client-side cocked into SSL (Linux and Windows):


// Set short socket read timeout for SSL_connect, to avoid indefinite
hanging
::setsockopt(socketHandle, SOL_SOCKET, SO_RCVTIMEO, // ...
platform-dependent code ...


// Create new SSL connection state object
if ((ssl_ = SSL_new(context_->GetSSL_CTX())) == nullptr) {
// handle error
}

// Set up SNI (Server Name Indication), some websites like Google
complain if this is not done.
SSL_set_tlsext_host_name(ssl_, host.c_str());

// Attach the SSL session to the socket descriptor
SSL_set_fd(ssl_, static_cast<int>(socketHandle));

// When using the SSL_connect(3) or SSL_accept(3) routines, calling of
SSL_set_connect_state() or SSL_set_accept_state() is not needed.

int ret = SSL_connect(ssl_);
if (ret == 1) {
// OK, connected
}

// set the socket timeout larger if needed ...

********* write ******

int n = SSL_write(ssl_, buf, static_cast<int>(len));
if (n != static_cast<int>(len)) {
// handle error

******* read *****

ERR_clear_error();
int n = SSL_read(ssl_, buf, static_cast<int>(len));
if (n < 0) {
// handle errpr
int k = SSL_get_error(ssl_, n);
if (k == SSL_ERROR_WANT_READ) {
// timeout, or maybe the server side closed connection?
// the caller should reconnect and retry
} else {
// handle other error
}
}


********* cleanup ********

if (socketHandle != INVALID_SOCKET) {
closesocket(socketHandle);
}
if (ssl_) {
SSL_free(ssl_);
}

HTH




Paavo Helde

unread,
May 25, 2023, 8:52:30 AM5/25/23
to
25.05.2023 15:26 Paavo Helde kirjutas:
> 25.05.2023 10:39 R.Wieser kirjutas:
>> Hello all,
>>
>> I've been trying whip up some code using (an older version of) OpenSSL.
>> I've ofcourse googled for information how to use it, but all I've been
>> able
>> to find is some "examples" which stop directly after reading the reply
>> (no
>> code to terminate the connection), or overly complex stuff aimed at a
>> certain target.

BTW, ChatGPT4 seemed to be pretty strong with openssl, so you might just
ask it to generate some example programs. It even changed the code to
use proper std::unique_ptr lifetime management when I suggested that.


Mut...@dastardlyhq.com

unread,
May 25, 2023, 11:16:13 AM5/25/23
to
On Thu, 25 May 2023 15:26:17 +0300
Paavo Helde <ees...@osa.pri.ee> wrote:
>25.05.2023 10:39 R.Wieser kirjutas:
>This code is using OpenSSL 3.0.8 for wrapping an existing connected
>client-side cocked into SSL (Linux and Windows):

I wouldn't use Windows socket code in Linux as windows sockets are severely
hobbled by not being able to be multiplexed on select() due to Microsofts
incomprehensible decision to make sockets a special handle type instead
of just a file descriptor meaning you can't mix them with other open file types
or inputs and they have to be converted into win messages or some such
overcomplicated crap in order to be received asynchronously unless you decide
to make life your even harder and spawn a new thread for each socket connection.


R.Wieser

unread,
May 25, 2023, 11:51:47 AM5/25/23
to
Paavo,

> OpenSSL 0.9 is seriously out of date. Currently supported stable versions
> are 1.1.* and 3.0.*.

Yeah, I know. I already downloaded v3.1.0. But up until I can find example
and/or tutorial code about/for it its rather useless to me. And as I could
find info about that "seriously out of date" version that became the one I'm
working with.

> This code is using OpenSSL 3.0.8 for wrapping an existing connected
> client-side cocked into SSL (Linux and Windows):

That is quite similar to the 2) code I mentioned (using a pre-created and
connected native socket). I would like to keep everything in OpenSSL.

I would like to see a solution where I can create and connect a BIO socket
in a similar way I create a native socket (not providing hostname
information) and than use the BIO socket in the code you have posted.

The other solution I'm looking for is a full SSL_xxx one. No BIO_xxx or
native socket.

By the way: you use "context_->GetSSL_CTX()", but I do not see you cleanup
the returned handle.

It /might/ be done by something else, and that is exacly what I meant where
I say that I can find reference to commands, but not how they interact.

For "SSL_free" I found this :
https://www.openssl.org/docs/man1.0.2/man3/SSL_free.html Under "remarks" it
says

[quote]
SSL_free() also calls the free()ing procedures for indirectly affected
items, if applicable: the buffering BIO, the read and write BIOs, cipher
lists specially created for this ssl, the SSL_SESSION.
[/quote]

If it refers to the above "GetSSL_CTX" handle they have it pretty-well
hidden. :-(

Last remark : a quick search on four search-engines for that "GetSSL_CTX"
function turns up exactly nothing ...

Regards,
Rudy Wieser


R.Wieser

unread,
May 25, 2023, 11:53:46 AM5/25/23
to
Muttley,

> I wouldn't use Windows socket code in Linux

:-) I would not want to use it the other way around either.

But thats a quite big "what if" step you're making there - what makes you
think that I would want to do that ?

I think I asked how I could do the whole thing just using (BIO_xxx and)
SSL_xxx functions. Besides the "I need example code of the whole thing,
from setting up upto cleaning up" ofcourse.

On the other hand, for my blocking handles implementation I probably need a
"select" somewhere, so my code doesn't stall waiting forever for a
reply/more data while the other side is doing the same.

Regards,
Rudy Wieser


Mut...@dastardlyhq.com

unread,
May 25, 2023, 12:04:21 PM5/25/23
to
On Thu, 25 May 2023 17:51:06 +0200
"R.Wieser" <add...@is.invalid> wrote:
>Muttley,
>
>> I wouldn't use Windows socket code in Linux
>
>:-) I would not want to use it the other way around either.
>
>But thats a quite big "what if" step you're making there - what makes you
>think that I would want to do that ?

I don't care one way or the other, I was replying to Paavo, not you.


Scott Lurndal

unread,
May 25, 2023, 12:13:26 PM5/25/23
to
"R.Wieser" <add...@is.invalid> writes:
>Paavo,
>
>> OpenSSL 0.9 is seriously out of date. Currently supported stable versions
>> are 1.1.* and 3.0.*.
>
>Yeah, I know. I already downloaded v3.1.0. But up until I can find example
>and/or tutorial code about/for it its rather useless to me. And as I could
>find info about that "seriously out of date" version that became the one I'm
>working with.

Have you a copy of the O'reilly openssl book?

There's a copy on github.

Paavo Helde

unread,
May 25, 2023, 12:46:07 PM5/25/23
to
I agree life would be easier if I would only need to support UNIX
everything-is-a-file concepts. Alas, that's not the case for me.

BTW, the replacement of select() in Windows is WaitForMultipleObjects().
Windows messages are not needed (which is good because usually I have no
window which could receive them).

Anyway, sockets low-level programming is not a recommended approach.
Suggesting libcurl or Boost ASIO instead, which take care of some
aspects. OTOH, if things go south (read: corporate networks with
prescribed security regulations) it might be harder to get multiple
layers of software working, instead of a single layer.







Paavo Helde

unread,
May 25, 2023, 1:13:44 PM5/25/23
to
25.05.2023 18:38 R.Wieser kirjutas:
> Paavo,
>
>> OpenSSL 0.9 is seriously out of date. Currently supported stable versions
>> are 1.1.* and 3.0.*.
>
> Yeah, I know. I already downloaded v3.1.0. But up until I can find example
> and/or tutorial code about/for it its rather useless to me. And as I could
> find info about that "seriously out of date" version that became the one I'm
> working with.
>
>> This code is using OpenSSL 3.0.8 for wrapping an existing connected
>> client-side cocked into SSL (Linux and Windows):
>
> That is quite similar to the 2) code I mentioned (using a pre-created and
> connected native socket). I would like to keep everything in OpenSSL.
>
> I would like to see a solution where I can create and connect a BIO socket
> in a similar way I create a native socket (not providing hostname
> information) and than use the BIO socket in the code you have posted.
>
> The other solution I'm looking for is a full SSL_xxx one. No BIO_xxx or
> native socket.

For client sockets I do not use any BIO* functions.

>
> By the way: you use "context_->GetSSL_CTX()", but I do not see you cleanup
> the returned handle.
>

Right. The GetSSL_CTX() is my own function which returns a pointer to
shared SSL_CTX structure. This SSL_CTX is created once, is shared by all
SSL client connections and will be released only at the end of the program.

Setting up this context involves loading the trusted CA certificates
from various locations, and setting up a verify callback which logs
errors or warning, but also verifies the certificate against the Windows
system cert store, on Windows.

I can list the functions I use for setting up and releasing this
SSL_CTX, in call order (error checks omitted for brevity):

SSL_library_init();
OpenSSL_add_all_algorithms();
SSL_load_error_strings();

const SSL_METHOD* method = TLS_client_method();
SSL_CTX* context = SSL_CTX_new(method);
SSL_CTX_set_default_verify_paths(context);

// These can be called 0 or more times
SSL_CTX_load_verify_file(context, trustedCaBundleFile.c_str());
SSL_CTX_load_verify_dir(context, trustedCaCertDir.c_str())

SSL_CTX_set_verify(context, SSL_VERIFY_PEER, MySSLVerifyCallback);


***** cleanup *********

SSL_CTX_free(context);

******** callback *************

NOTE: contains my own functions, you need to adapt creatively

int MySSLVerifyCallback(int preverify_ok, X509_STORE_CTX *x509_ctx) {
try {
if (preverify_ok) {
// openssl has verified the cert, OK.
return 1; // success
}

X509* err_cert = (x509_ctx?
X509_STORE_CTX_get_current_cert(x509_ctx): nullptr);
const char* errMessage;
int err;
if (x509_ctx) {
err = X509_STORE_CTX_get_error(x509_ctx);
errMessage = X509_verify_cert_error_string(err);
} else {
err = -1;
errMessage = "x509_ctx==nullptr";
}

// Verify the cert against the global Windows certificates store
(ACINF-3817).
if (VerifyTLS(err_cert)) {
return 1; // success
}

char buf[256] = { 0 };
if (err_cert) {
X509_NAME_oneline(X509_get_subject_name(err_cert), buf, sizeof(buf)
- 1);
}
std::string msg = Sprintf("SSL cert verify error: num=%d: %s:
%s")(err)(errMessage)(buf);
// handle as an error or as a warning
return 1; // success
return 0; // failure
} catch (...) {
// handle error
return 0; // failure
}
}


********** VerifyTLS() for Windows **************
NOTE: contains my own functions, you need to adapt creatively

// Need a separate function because OPENSSL_free is a macro.
void FreeOpenSslBuffer(unsigned char* buffer) {
OPENSSL_free(buffer);
}

bool VerifyTLS(X509* cert) {
// openssl failed to verify the cert.

// Try to verify the cert against Windows cert store
unsigned char* buffer = nullptr;
int len = i2d_X509(cert, &buffer);
if (len < 0) {
throw Exception(ERR_IO, "i2d_X509() failed");
}
ASSERT(buffer);
DEBUG_ASSERT(len > 0);
ON_BLOCK_EXIT(FreeOpenSslBuffer, buffer);

CERT_CHAIN_PARA thing;
::memset(&thing, 0, sizeof(thing));
thing.cbSize = sizeof(thing);
PCCERT_CONTEXT winContext =
::CertCreateCertificateContext(X509_ASN_ENCODING, buffer, len);
if (!winContext) {
syserr_t errorCode = GetLastErrorCode();
throw Exception(ERR_IO, "CertCreateCertificateContext() failed: " +
GetSysErrorString(errorCode));
}
ON_BLOCK_EXIT(::CertFreeCertificateContext, winContext);

PCCERT_CHAIN_CONTEXT chain = nullptr;
if (::CertGetCertificateChain(
nullptr,
winContext,
nullptr,
nullptr,
&thing,
CERT_CHAIN_CACHE_END_CERT|CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY,
nullptr,
&chain))
{
ON_BLOCK_EXIT(::CertFreeCertificateChain, chain);
DWORD errorStatus = chain->TrustStatus.dwErrorStatus;

if (errorStatus == 0) {
return true; // Windows approved the cert
}
}
return false;
}



R.Wieser

unread,
May 25, 2023, 3:19:17 PM5/25/23
to
Paavo,

> For client sockets I do not use any BIO* functions.

That still means you could be using either native or SSL_xxx sockets.

>> By the way: you use "context_->GetSSL_CTX()", but I do not see you
>> cleanup the returned handle.
>
> Right. The GetSSL_CTX() is my own function

That explains me not finding it, but also means that your offered code is of
the same level as most of what I can find on the web : incomplete, leaving
me guess to what else to get it to work is needed. :-\

> Setting up this context involves loading the trusted CA certificates from
> various locations,

Done,

> and setting up a verify callback which logs errors or warning,

The example I found uses "SSL_get_verify_result" .

Which makes me remember that I still need to find a demo domain which
purposely has a wrong cerificate - to test if the code I have actually
works.

> but also verifies the certificate against the Windows system cert store,
> on Windows.
PEM
Currently I'm using SSL_CTX_load_verify_locations, using a local file.

I might, in the future, try to find out how I can access Windows own cert
store for it, but as said I want to keep the current code as simple/basic as
possible.

> I can list the functions I use for setting up and releasing this SSL_CTX,
> in call order (error checks omitted for brevity):

I see a *lot* more code than I'm currently using myself. I can likely
write something with /around that, but it would just be a "monkey see,
monkey do" result - no real understanding of what I'm (effectivily) copying.
:-(



By the way, the below is what I started with. First a basic non-ssl
retrieval of a webpage, afterwards the same retrieval but now over SSL.

http://jokinkuang.github.io/2015/02/27/how_to_do_http_&_https_request_with_openssl.html

As you can see it does most everything with BIO_xxx calls, with just a
sliver of SSL_xxx related calls thrown in.

This one

https://gist.githubusercontent.com/endSly/8369715/raw/ee86f381e814499bdffd34267b5e371b21839ecb/sslconnect.c

uses a native socket, connects it and than gives it to the SSL_xxx layer.
There is no "BIO_set_conn_hostname" (or an SSL_xxx version of it!) in sight
anywhere, but it seems to work nonwithstanding (probably extracting the
domain name and port from the native socket)

I've got a number of other snippets, but as I said, most are incomplete or
(far) beyond a basic setup. Like this one (which has thrown a number of
snippets on a single page):

https://cpp.hotexamples.com/examples/-/-/SSL_connect/cpp-ssl_connect-function-examples.html

Regards,
Rudy Wieser


Keith Thompson

unread,
May 25, 2023, 5:05:58 PM5/25/23
to
Do you mean "Network Security with OpenSSL" by John Viega, Matt Messier,
and Pravir Chandra? The last update was June 2002, when the latest
release was 0.9.7d.

I found a PDF copy of the book on GitHub. It appears to be pirated.

O'Reilly sometimes releases some books for free, but they haven't done
so with this one.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Paavo Helde

unread,
May 25, 2023, 5:12:40 PM5/25/23
to
25.05.2023 22:18 R.Wieser kirjutas:
> Paavo,
>
>> For client sockets I do not use any BIO* functions.
>
> That still means you could be using either native or SSL_xxx sockets.

I'm using a native socket created by the C socket() call.

>
>>> By the way: you use "context_->GetSSL_CTX()", but I do not see you
>>> cleanup the returned handle.
>>
>> Right. The GetSSL_CTX() is my own function
>
> That explains me not finding it, but also means that your offered code is of
> the same level as most of what I can find on the web : incomplete, leaving
> me guess to what else to get it to work is needed. :-\

Right. Nobody has said life should be easy ;-) Also, nobody has paid me
to prepare code examples which would exactly suit your needs.

>
>> Setting up this context involves loading the trusted CA certificates from
>> various locations,
>
> Done,
>
>> and setting up a verify callback which logs errors or warning,
>
> The example I found uses "SSL_get_verify_result" .
>
> Which makes me remember that I still need to find a demo domain which
> purposely has a wrong cerificate - to test if the code I have actually
> works.
>
>> but also verifies the certificate against the Windows system cert store,
>> on Windows.
> PEM
> Currently I'm using SSL_CTX_load_verify_locations, using a local file.
>
> I might, in the future, try to find out how I can access Windows own cert
> store for it, but as said I want to keep the current code as simple/basic as
> possible.

You just snipped the code which you maybe will try to figure out in the
future.

>
>> I can list the functions I use for setting up and releasing this SSL_CTX,
>> in call order (error checks omitted for brevity):
>
> I see a *lot* more code than I'm currently using myself. I can likely
> write something with /around that, but it would just be a "monkey see,
> monkey do" result - no real understanding of what I'm (effectivily) copying.
> :-(

Well, that's how it tends to be.

For openssl functions, you can at least just google "man FUNCTIONNAME"
to get the man page.

Of course, it does not help openssl contains hundreds of functions, half
of which are deprecated, and half of which are not needed for the task
at hand.

If one feels uncomfortable with raw sockets and raw openssl, one can use
some higher level interface like libcurl, or maybe Python. If I would
need to write this functionality again, I would probably use libcurl.



R.Wieser

unread,
May 26, 2023, 3:10:10 AM5/26/23
to
Paavo,

> I'm using a native socket created by the C socket() call.

I've got one bit of code using a native socket (ws2_32.dll). But it what I
would like to be able to do without. Just OpenSSL calls - preferrably just
SSL_xxx family calls, but opening a simple native socket using BIO_xxx would
be acceptable (iow : not using the BIO_new_ssl_connect and related ones).

> Right. Nobody has said life should be easy ;-)

Whut ?! I'm sure I've said that a few times in the past .... :-p

> Also, nobody has paid me to prepare code examples which would exactly suit
> your needs.

I can't vouch for that, but it is why I started this thread. I can google
snippets of OpenSSL code easily. The problem for me is learning how they
work - so that I have a fighting chance to combine them in new, interresting
ways.

Did I already mention that I'm a hobby programmer, who, as part of that
hobby, doesn't have a problem with spending time on trying to figure stuff
out ? Well, I am and I don't. :-)

> You just snipped the code which you maybe will try to figure out in the
> future.

I just stored the code samples which mention doing that for future use, in
current favor of some of the more basic code samples.

Though in this particular case there is a "maybe" involved. There is a good
chance that I will try to keep the whole thing self-contained. On the other
hand, there is also a good chance that I will make the use of that external
storage available depending on a (commandline) setting.

> For openssl functions, you can at least just google "man FUNCTIONNAME" to
> get the man page.

Thats what I've been pretty-much doing, and finding stuff like

https://www.openssl.org/docs/man1.1.1/man3/SSL_connect.html

That site seems to be a nice source for function reference. But just take a
look at the difference of information between the blocking and non-blocking
usage (remember that I mentioned that I'm using, for starters,using the
simpler "blocking" mode ?).

Another one :

https://www.openssl.org/docs/manmaster/man3/SSL_set_fd.html

Its good enough when you want to look up something (looking back), but isn't
as good when you need a usage explanation (looking forward).

Ahhh.... I already wondered why I have been using SSL_set_fd and BIO_get_fd
(digging down to the native socket), while not having seen anything which
loads the BIO directly into the SSL context.

It turns out that that function actually exists : SSL_set_bio. Now all I
have to do is to spend (heaps of) time googeling for that function, in the
hope I can find some code using it (showing how the BIO needs to be
created).

> Of course, it does not help openssl contains hundreds of functions, half
> of which are deprecated, and half of which are not needed for the task at
> hand.

:-) You noticed. ssleay32.dll has (just) 206. libeay32.dll has a whopping
2953 of them.

Yeah, thats part of the problem I'm having with OpenSSL. It seems to have
multiple ways of reaching the same goal (take BIO_read and SSL_read. No
real idea when either is (in)valid to use), and than finding examples which
mix the different methods does not help me in getting the big picture. :-|

> If one feels uncomfortable with raw sockets

I've got no problem with that (see below).

> and raw openssl,

And that is what I would like to do - but *not* mixing raw sockets up with
"raw" OpenSSL.

Although I have code available which does all of the "raw" / native socket
handling (parsing the host : port combination, resolving the host to an IP,
connecting to that IP and port), I cannot escape the feeling that
/somewhere/ in that humongous ammount of ssleay32 and libay32 functions
there must be functions which offer the same - but than in a simpler
package.

Actually, BIO_set_conn_hostname does the parsing just fine, but not at the
level I would like to see it happening (using the SSL_xxx environment).

By the way : I posted here because this is where I expected the most chance
of getting a "low level" answer (the "comp.lang.c" newsgroup seems to have
been poisonned by spammers). I'm actually using an Assembler (Borlands
Tasm32), which goes even lower than that. :-)

Regards,
Rudy Wieser


Paavo Helde

unread,
May 26, 2023, 4:35:36 PM5/26/23
to
26.05.2023 10:07 R.Wieser kirjutas:

> I can't vouch for that, but it is why I started this thread. I can google
> snippets of OpenSSL code easily. The problem for me is learning how they
> work - so that I have a fighting chance to combine them in new, interresting
> ways.

Suggesting you to post these questions to the openss...@openssl.org
mailing list (subscribe at
https://mta.openssl.org/mailman/listinfo/openssl-users), there are
people who know infinitely more about openssl than myself. If your use
case is not the exact same than mine then I'm afraid I can not be of
much help.

Pavel

unread,
May 26, 2023, 11:33:18 PM5/26/23
to
R.Wieser wrote:
> Hello all,
>
> I've been trying whip up some code using (an older version of) OpenSSL.
> I've ofcourse googled for information how to use it, but all I've been able
> to find is some "examples" which stop directly after reading the reply (no
> code to terminate the connection), or overly complex stuff aimed at a
> certain target.
>
> Currently I have got some code which shows :
>
> 1) a BIO_xxx way to retrieve unencrypted data
>
> 2) a mix between winsock and SSL_xxx to retrieve encrypted data - not sure
> how/if the SSL part is closed
>
> 3) a mix between BIO_xxx and SSL_xxx to retrieve encrypted data, but which
> doesn't include code to close the connection.
>
> 4) some other bits-and-pieces
>
> The thing is, although I can mostly find the used commands back, I can't
> find anything about how they interact. As such I have a hard time to even
> find how to close an SSL connecion before I close the underlying BIO/socket
> one.
SSL_shutdown (ideally, in a loop where you try it till it returns 1 (if
it returns 0, wait for the socket to be selected for read and do
SSL_read when it is)), then SSL_free, then close(socket)
And for closing the BIO one I'm /assuming/ that all I need is
> "BIO_free_all" ...
>
> Also, 3) does stuff with BIO_xxx which caters to the SSL connection (like
> setting the name of the target domain), while with 2) I only have to provide
> the connected socket to SSL_set_fd to have everything work. IOW, I would
> like to see some BIO_xxx code to connect (which it only seems to do on the
> first BIO_read or BIO_write), and than have the SSL_xxx part take over the
> connection the same way as with a standard socket.
>
> One other thing : To keep my first steps as easy as possible I'm using
> blocking sockets. Examples that jump into the deep end using async sockets
> are of little value & use to me.
>
> tl;dr:
> I'm looking for some tutorial-style example code, explaining the basic
> setup, request, retrieval and tear-down steps of an encrypted connection
> using OpenSSL.
The best tutorial-style code I could recommend is the one from the
Chapter 8 of "SSL and TLS" of Eric Rescorla. The book is great
otherwise, too, so highly recommend.

>
> I'm currently using OpenSSL 0.9.8.0 , but that might just be because I've
> not come across anything related to the current v3.1.0 version ...
>
> Regards,
> Rudy Wieser
>
>

HTH
-Pavel

R.Wieser

unread,
May 27, 2023, 3:09:37 AM5/27/23
to
Paavo,

> Suggesting you to post these questions to the openss...@openssl.org
> mailing list (subscribe at
> https://mta.openssl.org/mailman/listinfo/openssl-users),

Thanks for that.

Sigh. Yet another mailing list which I need to subscribe to just to get an
answer to a basic question - and which I will than probably leave
afterwards.

> If your use case is not the exact same than mine then I'm afraid I can not
> be of much help.

I do not have a use case yet (just a vague one, which can change on a dime).
All I'm curently doing is try to figure out the easiest way (code and usage
wise) to set up an SSL connection [read some test data] and tear it down
afterwards. Thats all.

Or, said otherwise : I'm a bottom-up programmer. The above is the basic
bottom layer. The layers placed ontop of that will give direction to what
its going to be used for.

Currently one of my vague use-cases is to retrieve HTTP (over SSL) data - as
that seems to be the easiest next step. Nicely synchronous and all that.

Regards,
Rudy Wieser


Paavo Helde

unread,
May 27, 2023, 3:51:56 AM5/27/23
to
27.05.2023 10:04 R.Wieser kirjutas:
> Paavo,
>
>> Suggesting you to post these questions to the openss...@openssl.org
>> mailing list (subscribe at
>> https://mta.openssl.org/mailman/listinfo/openssl-users),
>
> Thanks for that.
>
> Sigh. Yet another mailing list which I need to subscribe to just to get an
> answer to a basic question - and which I will than probably leave
> afterwards.

Recently they tried to shut down the mailing list, citing the same
reasons as you, but there was a serious backlash as many members
declared they love the mailing list format and would not use any online
forums.

They also have wiki with some example programs like
https://wiki.openssl.org/index.php/SSL/TLS_Client , have you studied
these already?


R.Wieser

unread,
May 27, 2023, 9:23:38 AM5/27/23
to
Paavo,

> Recently they tried to shut down the mailing list, citing the same reasons
> as you, but there was a serious backlash as many members declared they
> love the mailing list format

I can understand that love. I just don't share it.

> and would not use any online forums.

I don't either, for the same reason as as those mailing lists.

Newsgroups are my only exception to it, mainly because it combines a lot of
different knowledge groups.

> They also have wiki with some example programs like
> https://wiki.openssl.org/index.php/SSL/TLS_Client , have you studied these
> already?

Nope, not that one. And its yet another way to to do the same thing - and
again more complex than needed. On the other hand, it does have some
explanation. :-)

Than again, did you know that "BIO_do_connect" is actually a #define of the
command below it :

] #define BIO_do_connect(b) BIO_do_handshake(b)

At least, according to the documentation I've got here.

IOW, no idea why its done twice ...

Also, the latter one is again a #define of doing a BIO_ctrl with a
BIO_C_DO_STATEMACHINE argument.

... and those libeay32 and ssleay32DLLs /still/ have 3000+ functions in
them. :-)

Regards,
Rudy Wieser


Scott Lurndal

unread,
May 27, 2023, 10:46:06 AM5/27/23
to
"R.Wieser" <add...@is.invalid> writes:
>Paavo,
>
>> Suggesting you to post these questions to the openss...@openssl.org
>> mailing list (subscribe at
>> https://mta.openssl.org/mailman/listinfo/openssl-users),
>
>Thanks for that.
>
>Sigh. Yet another mailing list which I need to subscribe to just to get an
>answer to a basic question - and which I will than probably leave
>afterwards.

Have you tried your local library? Perhaps they have a copy of
the O'reilly book on OpenSSL you can check out?

Scott Lurndal

unread,
May 27, 2023, 10:51:36 AM5/27/23
to
"R.Wieser" <add...@is.invalid> writes:
>Paavo,
>
>> Recently they tried to shut down the mailing list, citing the same reasons
>> as you, but there was a serious backlash as many members declared they
>> love the mailing list format
>

>
>... and those libeay32 and ssleay32DLLs /still/ have 3000+ functions in
>them. :-)

Not surprising given that openssl is a general purpose cryptographic
toolkit, supporting dozens of crypto algorithms both symmetric
and asymmetric along with multiple transports (TLS1, TLS2), digital
signatures, secure hashs, et alia.

An opensource version of bsafe.

https://en.wikipedia.org/wiki/BSAFE

Paavo Helde

unread,
May 27, 2023, 12:10:10 PM5/27/23
to
27.05.2023 16:21 R.Wieser kirjutas:
> Paavo,

>> They also have wiki with some example programs like
>> https://wiki.openssl.org/index.php/SSL/TLS_Client , have you studied these
>> already?
>
> Nope, not that one. And its yet another way to to do the same thing - and
> again more complex than needed. On the other hand, it does have some
> explanation. :-)

At first glance, it's as simple as it can get. Openssl is a pretty
low-level library, so its usage cannot be very short. If you want
one-liner access, use Python.

> Than again, did you know that "BIO_do_connect" is actually a #define of the
> command below it :

My IDE tells me that whenever I'm inclined to be interested in such things.

Regards
Paavo

R.Wieser

unread,
May 28, 2023, 4:24:18 AM5/28/23
to
Scott,

> Have you tried your local library? Perhaps they have a copy of
> the O'reilly book on OpenSSL ...

Thanks, I did not even think of that. Than again, my local libraries are
not known to carry much of this kind of stuff. But I sure could take a
peek.

> ... you can check out?

Same problem I'm afraid. My subscription ended a few decades ago, and
starting another one just for a single bit of info simply isn't my thing.

Though the difference is that a library still allows you, even without a
membership card, to browse books and even photocopy a few pages outof them.
:-)

Regards,
Rudy Wieser


R.Wieser

unread,
May 28, 2023, 4:24:18 AM5/28/23
to
Scott,

>>... and those libeay32 and ssleay32DLLs /still/ have 3000+ functions in
>>them. :-)
>
> Not surprising given that openssl is a general purpose cryptographic
> toolkit,

Ofcourse. That is why its called "OpenCrypt", and not "OpenSSL".

Oh, wait ... :-p

Regards,
Rudy Wieser


R.Wieser

unread,
May 28, 2023, 4:24:18 AM5/28/23
to
Paavo,

> At first glance, it's as simple as it can get. Openssl is a pretty
> low-level library, so its usage cannot be very short.

Lol ? I'm an Assembly programmer. Parsing a simple domain:port string
and than connecting to it needs a /lot/ of code. Way more than the
"BIO_set_conn_hostname". :-)

> If you want one-liner access, use Python.

If I would have wanted that I would not still be an Assembly programmer. I
however /do/ try to find the simpelest way

No, the biggest problem I have is seeing, within two DLLs, multiple ways to
do the same. Which, in my book, is /not/ a good thing. Especially not
when they can (but should not?) be mixed up.

As I said before, I tend to work from the minimal code needed to do the job,
and than, if needed, add some bells and whistles. Experience has learned
me not to attempt to do it the other way around. It creates way to many
opportunities to get confused and be left with non-working, or worse, badly
working code.

>> Than again, did you know that "BIO_do_connect" is actually a #define of
>> the
>> command below it :
>
> My IDE tells me that whenever I'm inclined to be interested in such
> things.

And you're mostly not interested, as long as it works, right ? And by
that missing that two, directly following each other functions seem to be
doing the same thing ...

I did notice, and am now wondering why. And if that should not have
happened, how much I should trust the correctness of the rest of the code.
:-(

Regards,
Rudy Wieser


Paavo Helde

unread,
May 28, 2023, 1:33:51 PM5/28/23
to
28.05.2023 11:21 R.Wieser kirjutas:
>>> Than again, did you know that "BIO_do_connect" is actually a #define of
>>> the
>>> command below it :
>>
>> My IDE tells me that whenever I'm inclined to be interested in such
>> things.
>
> And you're mostly not interested, as long as it works, right ? And by
> that missing that two, directly following each other functions seem to be
> doing the same thing ...
>
> I did notice, and am now wondering why. And if that should not have
> happened, how much I should trust the correctness of the rest of the code.
> :-(

I can tell you why. Openssl has long history and has tried to clean up
its SDK, probably multiple times. Alas, it appears by some reason people
do not want to modify their old code to use new cleaned-up interfaces
and insist on that the same client code which worked with e.g. openssl
0.9.8.0 (released 18 years ago) should still work with todays' version.
Hence, there are lots of #define-s to patch over the differences and to
make the old code compile. In particular, BIO_do_connect() is documented
in the bio.h header file as: "Aliases kept for backward compatibility."

R.Wieser

unread,
May 28, 2023, 2:32:54 PM5/28/23
to
Paavo,

> I can tell you why.
...
> Hence, there are lots of #define-s to patch over the differences and to
> make the old code compile.

Thats not what I was talking about. What was is that there *two* the
identical connect calls in sequence. That isn't good (or should not be).

As for the #define's themselves ? I can understand that calling a function
named "connect" is a lot easier to remember than calling a "BIO_ctrl" one
with a BIO_C_DO_STATEMACHINE argument. Thats not the point.

.. Though it does not help my poor brain that a function with "connect" in
its name doesn't do anything like it ...

Regards,
Rudy Wieser


Öö Tiib

unread,
May 29, 2023, 2:02:18 AM5/29/23
to
It is OpenSSL made for Secure Sockets Layer. As that can't be made
without cryptography it has libcrypto in it. That libcrypto contains
wide range of cryptographic algorithms used in various Internet standards.
There is wide range of those and nothing to do, only more and more and
more will be standardised as time passes. LOT more.

Scott Lurndal

unread,
May 29, 2023, 10:11:26 AM5/29/23
to
Indeed, in the last 20 years all the uses of the openssl libraries
in my experience have been for crypto purposes, not for SSL. That
includes time at Verisign (before they divested the certificate business
to Symantec) as well as my current employer.
0 new messages