Hello all,

I'm running into a few problems regarding OpenSSL.

1) I can't seem to find which OpenSSL version is the last one which will run under XP.

I have tried OpenSSL v3.3.1, but when I extract the "openssl-3\x86\bin\"
folder and try try to start 'openssl.exe' I get the error that it isn't a
valid windows executable.

2) I've got OpenSSL v1.0.2 (just the DLLs), but can't seem to find example
code (a basic client) for it.

I've found a number of code samples, but no indication which version of
OpenSSL they are for. The same is goes when I look for information one any
of the DLLs functions.


This one

https://wiki.openssl.org/index.php/SSL/TLS_Client

looked to be a fit for OpenSSL v1.0.2 - it mentions that version a few times
in the page - but I than run into a brick wall because BIO_get_ssl isn't available in v1.0.2 . :-(


Questions:

1) Where can I find a webpage where the "minimum OS" requirement is named
for the different versions of OpenSSL ?

... or at least what the last version for XP is.

2) Where can I find code samples which specify which versions(s) of OpenSSL they are valid for.

Help?

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-21, R.Wieser <address@is.invalid> wrote:

<snip>

Questions:

1) Where can I find a webpage where the "minimum OS" requirement is named
for the different versions of OpenSSL ?

... or at least what the last version for XP is.

2) Where can I find code samples which specify which versions(s) of OpenSSL they are valid for.

Help?

I got OpenSSL 1.0.1g working under XP several years ago, using Borland
C++ Builder 5.5. It only handles up to TLS 1.1, though. I tried
building the latest version of OpenSSL, but its code requires features
that the Borland compiler doesn't provide. I got a copy of MinGW,
which compiles the latest OpenSSL, created another makefile to build
my programs under MinGW, and made the few necessary tweaks to my code.
My programs compile with both compilers under XP, and the resulting
executables (both versions) run under any Windows version from XP
through 11. The MinGW versions support up to TLS 1.3.

I tend to not try to use every bleeding-edge option of a system,
so my C code compiles and runs under a wide range of versions.
I now have two makefiles for Win32 (plus one for Linux); makefile.w32
uses Borland and makefile.mgw uses MinGW. (Getting a Linux version
running was dead easy, since OpenSSL comes standard with Linux.)
All makefiles compile the same source module, which incorporates
maybe half a dozen #ifdefs to accomodate slight differences between
Borland and MinGW, e.g.

#ifndef MINGW

/* The following function is a wrapper for compatibility with
Borland Win32, which doesn's support SSL_get1_peer_certificate(). */

X509 *SSL_get1_peer_certificate(const SSL *ssl)
{
return(SSL_get_peer_certificate(ssl));
}
#endif /* !MINGW */

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Charlie,

I got OpenSSL 1.0.1g working under XP several years ago, using
Borland C++ Builder 5.5. It only handles up to TLS 1.1, though.

That last part is the point of my current searching.

I would like to be able to use TLS 1.2 (and higher?) connections too, but
have zero idea if OpenSSL v1.0.2 supports it (and having a bad time trying
to find excample code to help me figure it out), or which version does, and
if its (still) compatible with XP.

I tried building the latest version of OpenSSL, but its code requires features that the Borland compiler doesn't provide.

As I don't have a(ny) compiler(s)* I just downloaded the Windows binaries
and worked with them.

* I'm writing Assembly, using Borlands Tasm v5. Yes, very old school. :-)


I'm getting the idea that you are statically compile OpenSSL into your programs.

If not and you dynamically load ssleay32.dll and libeay32.dll, is there a chance you would be willing to share those DLLs (and possibly the code using them as well, as my sought for "example programs") ?

Yes, I would rather download those pre-compiled DLLs from a known source,
but as long as those are not available (or error-out when I try to use them)
I would not mind at all (understatement) to use yours instead.


By the way, I downloaded the "not a valid Windows executable" v3.3.1 from
here :

https://kb.firedaemon.com/support/solutions/articles/4000121705-firedaemon-openssl-1-1-1l-dev-binary-distribution-for-microsoft-windows#Download-OpenSSL

(the "OpenSSL 3.3.1 ZIP File (x64/x86)" top-right)

Any chance that you [c|w]ould take a peek and possibly be able to tell me
why the "openssl.exe" file I mentioned errors-out on XP ? I'm rather
curious ...

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Charlie,

is there a chance you would be willing to share those DLLs (and possibly
the code using them as well, as my sought for "example programs") ?

Ignore that request please.

Reason :

but I than run into a brick wall because BIO_get_ssl isn't available in
v1.0.2 . :-(

Its true, neither of the DLLs contains a "BIO_get_ssl" function. Though
while (again) seeking information about the different OpenSSL versions and looking for example code I ran across a website which shows the MAN pages
for OpenSSL v1.0.2 .

And in there I noticed it does have an entry for that "BIO_get_ssl"
function. Following the link and viewing the man page for it it turns out
that that function is simply a #define using a a BIO_ctrl function :

#define BIO_get_ssl(b,sslp) BIO_ctrl(b,BIO_C_GET_SSL,0,(char *)sslp)

And that ofcourse means my "brick wall" has disolved, and I can now continue converting the example client code.


Though if you have any information on how to check and/or enable the TLS 1.x ciphers I'd still like to hear.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-22, R.Wieser <address@is.invalid> wrote:

Though if you have any information on how to check and/or enable the TLS 1.x ciphers I'd still like to hear.

Dunno about the ciphers, but I do check which version of TLS I've
connected with.

i = SSL_SESSION_get_protocol_version(sslsession);

I use this to reject anything less than TLS 1.2.
(TLS 1.1 is deprecated and its use is now discouraged.)

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Charlie,

After a bit of searching, I get the impression that TLS 1.2 was
supported starting in OpenSSL 1.0.1.

https://stackoverflow.com/questions/48178052/when-was-tls-1-2-support-added-to-openssl

Grumble. I didn't think of approaching the problem from that direction (to focussed on getting info of all the OpenSSL versions).

TLS 1.3 support first appeared in in OpenSSL 1.1.1.

https://wiki.openssl.org/index.php/TLS1.3

If you're using TLS at all, you might as well go for 1.3 - it's more
secure than its predecessors and the code contains lots of fixes

As chances have it I already downloaded a few OpenSSL 1.1.1{letter}
versions, but ran into that "<progname> is not a valid Win32 application"
there too. :-(

I did find a 1.1.1h version that does seem to want to work though.

... now I only have to go thru the whole song-and-dance again of trying to
find example code and info matching that version. :-|

It looks as if you'll have to build OpenSSL using your own tools.
Start here to get MinGW:

I do not have any compilers (to speak of) here, and have very little wish to install them just to be able to create a pair of DLLs. Its like what they
say about RegEx-es : you try to solve a (small) problem with them, and now you've got two (and in this case, more than a handfull). :-\

Besides, the DLLs are only a part of the problem. Absense of (version annotated) example code and header file(s) is a major other part.

And by the way: I got the sample code that I linked to to work - even though
I had to figure out that more than that BIO_get_ssl function where actually defines, and that the MAN page website for 1.0.2 only showed the define for BIO_get_ssl, but somehow didn't for a few others. I took a chance and used
the ones I found on a MAN 1.1.x website - which seemed to work. Phew).

Another problem was that the sample code showed BIO_do_connect and BIO_do_handshake, which do not exist in the DLL and the MAN page does not
show defines for. Worse, from my tinkering with OpenSSL v0.9.8 I seem to remember that they both translate to the same BIO_ctrl(b,BIO_C_DO_STATE_MACHINE,0,0) sequence. So, I chose to use only
one. Which, as far as can tell, works.

-- from your next post

Though if you have any information on how to check and/or enable the
TLS 1.x ciphers I'd still like to hear.

Dunno about the ciphers, but I do check which version of TLS I've
connected with.

i = SSL_SESSION_get_protocol_version(sslsession);

Thanks. But my (first) step was aimed at checking which TLS versions are supported by my current OpenSSL version. Being able to check which ciphers
the server offers would be a second, and being able to check the actually negociated one a distant third.

I use this to reject anything less than TLS 1.2.
(TLS 1.1 is deprecated and its use is now discouraged.)

I thought that you could tell OpenSSL to only use a certain TLS version ?

At least, I though that that was what the SSL_set_cipher_list(ssl, PREFERRED_CIPHERS); line (in the example code) was for.


By the way, Thanks for the responses/help. :-)

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Charlie,

Speaking of oddball directions, I just did a scan of my entire
code base, and there is not a single occurrence of the string
"BIO_". I call functions with the prefix "SSL_", e.g.

When I was busy with v0.9.8 I tested versions using both. And yes, I
rather use only SSL_* calls than the BIO_* calls and than /still/ have to
use some SSL_* ones.

I will "most likely" also try to find example code using just those SSL_* calls. But currently first had/have to find out which TLS versions v1.0.2
all supports (read: if I can access all websites I can reach with my FF v52 browser).

But ... do you perhaps have a link to example code using only SSL_* calls ?
I could use it.

There is indeed such an option. I found some code (currently #ifdefed
out), which controls this:

I saw them mentioned too, thanks for reminding me. I imagine that using
that to disable everything but TLS 1.2 and than asking for the supported ciphers should give an indication if its actualy supported.

By the way, Thanks for the responses/help. :-)

You're welcome. It's not a easy path, but hopefully you can
get something going.

I think I have. It looks like I have converted the example code correctly, seeing that I can do an HTTPS request and get data back.

Now its just a question of adding certificate checking and possible
connection restarts - neither of which looks, in the example code,
complicated.

I also downloaded some (the?) sourcecode to 1.0.2 , so that I have access to its header files and definitions of certain funcions in it.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-23, R.Wieser <address@is.invalid> wrote:

Charlie,

After a bit of searching, I get the impression that TLS 1.2 was
supported starting in OpenSSL 1.0.1.

https://stackoverflow.com/questions/48178052/when-was-tls-1-2-support-added-to-openssl

Grumble. I didn't think of approaching the problem from that direction (to focussed on getting info of all the OpenSSL versions).

I tend to approach problems from oddball directions. :-)

<snip>

And by the way: I got the sample code that I linked to to work - even though I had to figure out that more than that BIO_get_ssl function where actually defines, and that the MAN page website for 1.0.2 only showed the define for BIO_get_ssl, but somehow didn't for a few others. I took a chance and used the ones I found on a MAN 1.1.x website - which seemed to work. Phew).

Another problem was that the sample code showed BIO_do_connect and BIO_do_handshake, which do not exist in the DLL and the MAN page does not show defines for. Worse, from my tinkering with OpenSSL v0.9.8 I seem to remember that they both translate to the same BIO_ctrl(b,BIO_C_DO_STATE_MACHINE,0,0) sequence. So, I chose to use only one. Which, as far as can tell, works.

Speaking of oddball directions, I just did a scan of my entire
code base, and there is not a single occurrence of the string "BIO_".
I call functions with the prefix "SSL_", e.g.
SSL_CTX_new()
SSL_new()
SSL_set_fd()
SSL_accept()
SSL_connect()
SSL_read()
SSL_write()
SSL_error()
SSL_shutdown()
SSL_CTX_free()

<snip>

I thought that you could tell OpenSSL to only use a certain TLS version ?

At least, I though that that was what the SSL_set_cipher_list(ssl, PREFERRED_CIPHERS); line (in the example code) was for.

There is indeed such an option. I found some code (currently #ifdefed
out), which controls this:

/* Disable older methods if desired. Setting all of the options below
(they can be ORed together) will disable anything less than TLS v1.2. */

SSL_CTX_set_options(sc->socksslcontext, SSL_OP_NO_SSLv2);
SSL_CTX_set_options(sc->socksslcontext, SSL_OP_NO_SSLv3);
SSL_CTX_set_options(sc->socksslcontext, SSL_OP_NO_COMPRESSION);
SSL_CTX_set_options(sc->socksslcontext, SSL_OP_NO_TLSv1);
SSL_CTX_set_options(sc->socksslcontext, SSL_OP_NO_TLSv1_1);

By the way, Thanks for the responses/help. :-)

You're welcome. It's not a easy path, but hopefully you can get
something going.

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-23, R.Wieser <address@is.invalid> wrote:

I will "most likely" also try to find example code using just those SSL_* calls. But currently first had/have to find out which TLS versions v1.0.2 all supports (read: if I can access all websites I can reach with my FF v52 browser).

From what I've dug up, 0.9.8 does not support TLS 1.2, while 1.0.1 probably does.

But ... do you perhaps have a link to example code using only SSL_* calls ?
I could use it.

Here's the code I use to start and stop SSL on an existing connection.
From here you can use SSL_read() and SSL_write(), which are pretty straightforward.

/*----------------------------------------------------------------------

Negotiate an SSL connection.

If "server" is TRUE, call SSL_accept() to
wait for an SSL handshake from the client.
If "server" is FALSE, call SSL_connect() to
initiate an SSL handshake with the server.

"certfile" is the name of a file containing certificates
(or NULL if no certificates are provided).

If errors occur, build an error string and
return a pointer to it; otherwise return NULL.

----------------------------------------------------------------------*/

#ifdef PROTOTYPE
char *socksslstart(struct socktag *sc, BOOL server, char *certfile)
#else
char *socksslstart(sc, server, certfile)
struct socktag *sc;
BOOL server;
char *certfile;
#endif
{
static char errmsg[MAXLEN];
X509 *cert;
X509_NAME *certname;
FILE *fp;
extern char *logfilename;
long templong;
char *s;
int i;

if(sc == NULL) {
strcpy(errmsg, "socksslstart: NULL argument");
return(errmsg);
}

sc->socksslcontext = NULL;
sc->socksslhandle = NULL;

#ifndef _INC__MINGW_H
/* Register the available ciphers and digests. */

SSL_library_init();

/* Register the error strings for libcrypto & libssl. */

SSL_load_error_strings();
#endif

#ifdef DELETE_THIS
OPENSSL_config(NULL);
#endif

/* Create a new context. */

if(server)
sc->socksslcontext = SSL_CTX_new(SSLv23_server_method());
else
sc->socksslcontext = SSL_CTX_new(SSLv23_client_method());
if(sc->socksslcontext == NULL) {
strcpy(errmsg, "SSL_CTX_new() failed: ");
s = ERR_error_string(ERR_get_error(), NULL);
i = sizeof(errmsg) - strlen(errmsg) - 1;
strncpy(errmsg + strlen(errmsg), s, i);
errmsg[sizeof(errmsg)-1] = '\0';
return(errmsg);
}

#ifdef NEW_STUFF
/* Disable older methods if desired. Setting all of the options below
(they can be ORed together) will disable anything less than TLS v1.2. */

SSL_CTX_set_options(sc->socksslcontext, SSL_OP_NO_SSLv2);
SSL_CTX_set_options(sc->socksslcontext, SSL_OP_NO_SSLv3);
SSL_CTX_set_options(sc->socksslcontext, SSL_OP_NO_COMPRESSION);
SSL_CTX_set_options(sc->socksslcontext, SSL_OP_NO_TLSv1);
SSL_CTX_set_options(sc->socksslcontext, SSL_OP_NO_TLSv1_1);
#endif

/* Process certificates. */

if(certfile != NULL) {

/* Set default locations for trusted CA certificates.
"certfile" is the name of a file containing one or more CA certificates
in PEM format. The optional third argument names a path containing
PEM-format files, each of which contains one CA certificate. */

if(!SSL_CTX_load_verify_locations(sc->socksslcontext,certfile,NULL)) {
strcpy(errmsg, "SSL_CTX_load_verify_locations() failed: ");
s = ERR_error_string(ERR_get_error(), NULL);
i = sizeof(errmsg) - strlen(errmsg) - 1;
strncpy(errmsg + strlen(errmsg), s, i);
errmsg[sizeof(errmsg)-1] = '\0';
socksslstop(sc);
return(errmsg);
}

/* If we're a server, send the list of CAs to the client. */

if(server) {
SSL_CTX_set_client_CA_list(
sc->socksslcontext, SSL_load_client_CA_file(certfile));
}

/* Load the certificates in the file SSL_SERVER_CRT (if server)
or the file SSL_CLIENT_CRT (if client) into the SSL context. */

if(!SSL_CTX_use_certificate_file(sc->socksslcontext,
certfile, SSL_FILETYPE_PEM)) {
strcpy(errmsg, "SSL_CTX_use_certificate_file() failed: ");
s = ERR_error_string(ERR_get_error(), NULL);
i = sizeof(errmsg) - strlen(errmsg) - 1;
strncpy(errmsg + strlen(errmsg), s, i);
errmsg[sizeof(errmsg)-1] = '\0';
socksslstop(sc);
return(errmsg);
}

/* Load the private keys into the SSL context. */

if(!SSL_CTX_use_PrivateKey_file(sc->socksslcontext,
certfile, SSL_FILETYPE_PEM)) {
strcpy(errmsg, "SSL_CTX_use_PrivateKey_file() failed: ");
s = ERR_error_string(ERR_get_error(), NULL);
i = sizeof(errmsg) - strlen(errmsg) - 1;
strncpy(errmsg + strlen(errmsg), s, i);
errmsg[sizeof(errmsg)-1] = '\0';
socksslstop(sc);
return(errmsg);
}

/* Check the consistency of a private key with the
corresponding certificate loaded into the SSL context. */

if(!SSL_CTX_check_private_key(sc->socksslcontext)) {
strcpy(errmsg, "SSL_CTX_check_private_key() failed: ");
s = ERR_error_string(ERR_get_error(), NULL);
i = sizeof(errmsg) - strlen(errmsg) - 1;
strncpy(errmsg + strlen(errmsg), s, i);
errmsg[sizeof(errmsg)-1] = '\0';
socksslstop(sc);
return(errmsg);
}

SSL_CTX_set_mode(sc->socksslcontext, SSL_MODE_AUTO_RETRY);
SSL_CTX_set_verify(sc->socksslcontext,
SSL_VERIFY_PEER | (server & SSL_VERIFY_FAIL_IF_NO_PEER_CERT), NULL);
SSL_CTX_set_verify_depth(sc->socksslcontext, 1);
}

/* Create an SSL structure for the connection. */

sc->socksslhandle = SSL_new(sc->socksslcontext);
if(sc->socksslhandle == NULL) {
strcpy(errmsg, "SSL_new() failed: ");
s = ERR_error_string(ERR_get_error(), NULL);
i = sizeof(errmsg) - strlen(errmsg) - 1;
strncpy(errmsg + strlen(errmsg), s, i);
errmsg[sizeof(errmsg)-1] = '\0';
socksslstop(sc);
return(errmsg);
}

/* Connect the SSL structure to our connection. */

if(!SSL_set_fd(sc->socksslhandle, sc->sockfd)) {
strcpy(errmsg, "SSL_set_fd() failed: ");
s = ERR_error_string(ERR_get_error(), NULL);
i = sizeof(errmsg) - strlen(errmsg) - 1;
strncpy(errmsg + strlen(errmsg), s, i);
errmsg[sizeof(errmsg)-1] = '\0';
socksslstop(sc);
return(errmsg);
}

/* If we're the server, wait for an SSL handshake from the client. */

if(server) {
if(SSL_accept(sc->socksslhandle) != 1) {
strcpy(errmsg, "SSL_accept() failed: ");
s = ERR_error_string(ERR_get_error(), NULL);
i = sizeof(errmsg) - strlen(errmsg) - 1;
strncpy(errmsg + strlen(errmsg), s, i);
errmsg[sizeof(errmsg)-1] = '\0';
socksslstop(sc);
return(errmsg);
}

/* If we're the client, initiate an SSL handshake with the server. */

} else {
if(SSL_connect(sc->socksslhandle) != 1) {
strcpy(errmsg, "SSL_connect() failed: ");
s = ERR_error_string(ERR_get_error(), NULL);
i = sizeof(errmsg) - strlen(errmsg) - 1;
strncpy(errmsg + strlen(errmsg), s, i);
errmsg[sizeof(errmsg)-1] = '\0';
socksslstop(sc);
return(errmsg);
}
}

/* Get the remote certificate into an X509 structure. */

if(!server && (certfile != NULL)) {
cert = SSL_get1_peer_certificate(sc->socksslhandle);
if(cert == NULL) {
sprintf(errmsg,
"socksslstart(%s): SSL_get1_peer_certificate() returned NULL: ",
sc->sockname);
s = ERR_error_string(ERR_get_error(), NULL);
i = sizeof(errmsg) - strlen(errmsg) - 1;
strncpy(errmsg + strlen(errmsg), s, i);
errmsg[sizeof(errmsg)-1] = '\0';
writetolog(errmsg, FALSE, -9);
}
if(cert != NULL) {
templong = SSL_get_verify_result(sc->socksslhandle);
if(templong != X509_V_OK) {
sprintf(errmsg,
"socksslstart(%s): SSL_get_verify_result() failed: %ld",
sc->sockname, templong);
s = ERR_error_string(ERR_get_error(), NULL);
i = sizeof(errmsg) - strlen(errmsg) - 1;
strncpy(errmsg + strlen(errmsg), s, i);
errmsg[sizeof(errmsg)-1] = '\0';
writetolog(errmsg, FALSE, -9);
} else {
fp = fopen(logfilename, "a");
if(fp != NULL) {
#ifdef DELETE_THIS
certname = X509_NAME_new();
#endif
certname = X509_get_subject_name(cert);
X509_NAME_print_ex_fp(fp, certname, 4,
XN_FLAG_MULTILINE & ~ASN1_STRFLGS_ESC_MSB);
certname = X509_get_issuer_name(cert);
X509_NAME_print_ex_fp(fp, certname, 4,
XN_FLAG_MULTILINE & ~ASN1_STRFLGS_ESC_MSB);
fclose(fp);
}
}
X509_free(cert);
}
}

/* If all went well, we've successfully set up an SSL connection. */

return(NULL);
}



/*----------------------------------------------------------------------

Stop an SSL connection.

----------------------------------------------------------------------*/

#ifdef PROTOTYPE
void socksslstop(struct socktag *sc)
#else
void socksslstop(sc) struct socktag *sc;
#endif
{
if(sc == NULL)
return; /* Connection is missing! */

if(sc->socksslhandle != NULL) {
SSL_shutdown(sc->socksslhandle);
SSL_free(sc->socksslhandle);
sc->socksslhandle = NULL;
}
if(sc->socksslcontext != NULL) {
SSL_CTX_free(sc->socksslcontext);
sc->socksslcontext = NULL;
}
}

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Charlie,

From what I've dug up, 0.9.8 does not support TLS 1.2, while 1.0.1
probably does.

It looks that way, yes. And why I was looking for a version newer than
0.9.8 . Getting a hard "no" from some webservers isn't what I want to hear when retrieving data from them.

Here's the code I use to start and stop SSL on an existing connection.
From here you can use SSL_read() and SSL_write(), which are pretty straightforward.

[snip code]

Thats .. C++ ? Objective C ? Never can tell (shows you how much I use
those languages).

But thank you. I'll likely be able to rewrite it in Assembly (read: use it
to see what should happen when).

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-24, R.Wieser <address@is.invalid> wrote:

Charlie,

From what I've dug up, 0.9.8 does not support TLS 1.2, while 1.0.1
probably does.

It looks that way, yes. And why I was looking for a version newer than 0.9.8 . Getting a hard "no" from some webservers isn't what I want to hear when retrieving data from them.

Yes, it's sadly out of date. You might as well go for the whole enchilda
and try 3.x.x. It'll be more work up front, but it'll have all the latest security fixes and will handle TLS 1.3.

Here's the code I use to start and stop SSL on an existing connection.
From here you can use SSL_read() and SSL_write(), which are pretty
straightforward.

[snip code]

Thats .. C++ ? Objective C ? Never can tell (shows you how much I use those languages).

Straight C. I never got into those newfangled variants.

But thank you. I'll likely be able to rewrite it in Assembly (read: use it to see what should happen when).

Hopefully it'll give you enough hints. In case you're wondering,
these functions use a socket descriptor which contains the socket
handle plus a bunch of supporting stuff, e.g. SSL session handle.

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Charlie,

You might as well go for the whole enchilda and try 3.x.x.

I did.

But alas, I could only find ones which throw that "<progname> is not a valid Win32 application" error when I try to start their "OpenSSL.exe" programs.
IOW, I still have to find a prebuild binaries download which (still)
supports XP - and I could imagine that they simply do not exist. XP is /ancient/, and nobody uses it anymore. :-)

Thats .. C++ ? Objective C ? Never can tell (shows you how much I
use those languages).

Straight C. I never got into those newfangled variants.

Hmmmm... As I use straight C on a RPi (GCC) I should to take a look about
how to use objects (with members and properties) there. Over time I've
started to see the reason of having functions and data combined into a
single package (not in Assembly though. To much work to create an object
and call its members)

And it just occured to me : wouldn't "straight C" just be an "I" ? :-)

Years ago I attempted to decompile some C#. I should have suspected it, but what I found was that a C# program was just a header which would call the C# interpreter (stored in a DLL) providing it the rest of its "program" (the C# bytecode) as data. ... just as if you would call "QBASIC /RUN {somename}.BAS". :-)

But thank you. I'll likely be able to rewrite it in Assembly (read: use
it to see what should happen when).

Hopefully it'll give you enough hints.

It (most likely) will. It shows the methods to call, what data they expect
and the order in which its supposed to happen.

In case you're wondering, these functions use a socket descriptor
which contains the socket handle plus a bunch of supporting stuff,
e.g. SSL session handle.

:-) "Some" of the names strongly hinted in that direction, yes.

Ofcourse, it does help that I already "done stuff" with v0.9.8, where I
figured out that the BIO_* and SSL_* methods where doing the same (carrying round CTX handles). IOW, there was a bit of recognition.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <v7jk64$72ng$1@dont-email.me>, address@is.invalid says...

Hello all,

I'm running into a few problems regarding OpenSSL.

1) I can't seem to find which OpenSSL version is the last one which will run under XP.

I have tried OpenSSL v3.3.1, but when I extract the "openssl-3\x86\bin\" folder and try try to start 'openssl.exe' I get the error that it isn't a valid windows executable.

2) I've got OpenSSL v1.0.2 (just the DLLs), but can't seem to find example code (a basic client) for it.

I've found a number of code samples, but no indication which version of OpenSSL they are for. The same is goes when I look for information one any of the DLLs functions.

This one

https://wiki.openssl.org/index.php/SSL/TLS_Client

looked to be a fit for OpenSSL v1.0.2 - it mentions that version a few times in the page - but I than run into a brick wall because BIO_get_ssl isn't available in v1.0.2 . :-(

Questions:

1) Where can I find a webpage where the "minimum OS" requirement is named
for the different versions of OpenSSL ?

... or at least what the last version for XP is.

2) Where can I find code samples which specify which versions(s) of OpenSSL they are valid for.

Help?

Last I checked the current version of OpenSSL still works fine on
Windows XP. Certainly 3.0.14 still does, and I'm sure I checked the 3.1
series sometime in the past year too.

When building it though, you've got to pass -D"_WIN32_WINNT=0x502" to
the configure script or the resulting binaries will give you the error
you encountered.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <v7vmkp$2olun$1@dont-email.me>, address@is.invalid says...

David,

Last I checked the current version of OpenSSL still works fine on
Windows XP. Certainly 3.0.14 still does, and I'm sure I checked the
3.1 series sometime in the past year too.

Thanks for that. I was already wondering if (when) the later versions had dumped support for XP.

When building it though,

Thats the problem though, I do not have a build environment for them (I'm using a fully different programming language), and am therefore dependant on the so-called "prebuild binaries" (ssleay32.dll and libeay32.dll).

I've downloaded a number of them, but have had a significant number of them error-out on my machine with the error message "OpenSSL.exe is not a valid Win32 application".

Which is part of my subject line : most of those prebuild binaries do not come with a list of requirements. You know, "minimum supported OS version" or "Win32" / "Win64". Heck, I've even had dowloads which, if you actually wanted to use them, needed other (C runtime) DLLs to be able to function.

In short: all I can currently do is to pick a, pretty-much random, one, download it and *only than* see if it is compatible with my (XP sp3) OS.

... And dont even ask me about how I am able to find any kind of information (including example programs), needed to be able to know how to use those DLLs.

Its also remarkable that the targetted OpenSSL version is seldom, if ever, mentioned in the (found) sourcecode, header files or the webpages
themselves. :-(

And that is what my question is all about : Trying to find something better than throwing the dice and hoping to get lucky.

Currently I have a working set of DLLs (and some example code) for OpenSSL v1.0.2h . Later (prebuild binaries) versions all errored out on me.

Well, I *may* be able to help out with XP-compatible OpenSSL binaries. I maintain the program formerly and soon again to be known as Kermit 95
which still supports TLS on Windows XP. So you could probably grab the XP-compatible openssl 3.0.14 bits (libcrypto3.dll, libssl-3.dll,
zlib1.dll, openssl.exe) from a recent successful build of that from
Github such as:
https://github.com/davidrg/ckwin/actions/runs/10100891255
If you do this you'll want the ckwin-vc14.2-x86 or ckwin-vc14-x86
artifact - those are the only ones that have current OpenSSL and work on
XP.

Though if you want to keep up-to-date with OpenSSL *and* have Windows XP support, getting a suitable build environment is probably better than
relying on finding compatible binaries online. You should be able to do
it with entirely free tools such as the community edition of Visual C++
2019 or older, or the old Windows 7 Platform SDK v7.1 (~Visual C++ 2010)
which you can grab here: https://ftp.zx.net.nz/pub/dev/WinSDK/win7-7.1-
dn4/

With Visual C++, perl, and nasm installed and in your path and the zlib
and openssl sources extracted somewhere you should be able to open a
Visual C++ command prompt and run something like this to build it (this
is effectively what my CI does):
cd zlib\1.2.13
cmake .
nmake -f win32\Makefile.msc
cd ..\..\
cd openssl\3.0.14
perl Configure VC-WIN32 zlib-dynamic --with-zlib-include=..\..\zlib
\1.2.13 -D"_WIN32_WINNT=0x502"
nmake

(though it would probably best to use zlib 1.3.1 now that thats out
assuming its XP compatible - something I guess I will have to test soon
now that I know about it)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David,

Last I checked the current version of OpenSSL still works fine on
Windows XP. Certainly 3.0.14 still does, and I'm sure I checked the
3.1 series sometime in the past year too.

Thanks for that. I was already wondering if (when) the later versions had dumped support for XP.

When building it though,

Thats the problem though, I do not have a build environment for them (I'm
using a fully different programming language), and am therefore dependant on the so-called "prebuild binaries" (ssleay32.dll and libeay32.dll).

I've downloaded a number of them, but have had a significant number of them error-out on my machine with the error message "OpenSSL.exe is not a valid Win32 application".


Which is part of my subject line : most of those prebuild binaries do not
come with a list of requirements. You know, "minimum supported OS version"
or "Win32" / "Win64". Heck, I've even had dowloads which, if you actually wanted to use them, needed other (C runtime) DLLs to be able to function.

In short: all I can currently do is to pick a, pretty-much random, one, download it and *only than* see if it is compatible with my (XP sp3) OS.

... And dont even ask me about how I am able to find any kind of information (including example programs), needed to be able to know how to use those
DLLs.

Its also remarkable that the targetted OpenSSL version is seldom, if ever, mentioned in the (found) sourcecode, header files or the webpages
themselves. :-(


And that is what my question is all about : Trying to find something better than throwing the dice and hoping to get lucky.

Currently I have a working set of DLLs (and some example code) for OpenSSL v1.0.2h . Later (prebuild binaries) versions all errored out on me.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David,

So you could probably grab the XP-compatible openssl 3.0.14 bits (libcrypto3.dll, libssl-3.dll, zlib1.dll, openssl.exe) from a recent successful build of that from Github such as:
https://github.com/davidrg/ckwin/actions/runs/10100891255

I would love to. Really.

One problem though : that github page doesn't show any indication of which
of the (jobs?) download links there contains them.

If you do this you'll want the ckwin-vc14.2-x86 or ckwin-vc14-x86
artifact -

How ? The only occurrences of "ckwin" on that page are just bits of text in the "deprication notice" and the "Artifacts" list - neither of which
contains anything downloadable.

Though if you want to keep up-to-date with OpenSSL *and* have Windows
XP support, getting a suitable build environment is probably better
than relying on finding compatible binaries online.

Thanks for the suggestion, but no thanks.

Besides that I've got zero wish to install a C{something} build environment just to generate a few DLLs (and only for them!), one of the other
responders here told me that he needed to "tweak" the sourcecode to get it
to compile and work on XP. Did I already mention that C{something} is
*not* my programming language ?

IOW, I would be increasing (by quite a bit) the number of problems I would
need to solve, not lessening them. :-(

With Visual C++, perl, and nasm installed

:-) Lets guess : I just have to install a random version of each and it will all work nicely together ? No ? Some combinations will work but others
won't ? And I just have to pick some and hope I get lucky ? :-)

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <v82676$39lo3$1@dont-email.me>, address@is.invalid says...

David,

So you could probably grab the XP-compatible openssl 3.0.14 bits (libcrypto3.dll, libssl-3.dll, zlib1.dll, openssl.exe) from a recent successful build of that from Github such as:
https://github.com/davidrg/ckwin/actions/runs/10100891255

I would love to. Really.

One problem though : that github page doesn't show any indication of which
of the (jobs?) download links there contains them.

If you do this you'll want the ckwin-vc14.2-x86 or ckwin-vc14-x86
artifact -

How ? The only occurrences of "ckwin" on that page are just bits of text in the "deprication notice" and the "Artifacts" list - neither of which
contains anything downloadable.

Unfortunately you need to be logged in to github to download artifacts
from CI runs. If you don't have a github account, you could try the
openssl bits from this older build: https://ftp2.zx.net.nz/pub/Kermit95/test_builds/regent25-test/ckw-pre- b6-regent-test.zip

Though if you want to keep up-to-date with OpenSSL *and* have

Windows

XP support, getting a suitable build environment is probably better
than relying on finding compatible binaries online.

Thanks for the suggestion, but no thanks.

Besides that I've got zero wish to install a C{something} build environment just to generate a few DLLs (and only for them!), one of the other
responders here told me that he needed to "tweak" the sourcecode to get it
to compile and work on XP. Did I already mention that C{something} is
*not* my programming language ?

There is no need to tweak the C code at this time. OpenSSL 3.0.14 builds unmodified for XP provided that you tell the configure step to build it
for XP rather than Vista or newer.

OpenSSL has required that special configure step to target Windows XP
for a few years now which will be why you've struggled to find any off- the-shelf binaries that work. Anyone wanting OpenSSL for XP for the last
few years will have been building it themselves.

IOW, I would be increasing (by quite a bit) the number of problems I would need to solve, not lessening them. :-(

yeah, targeting a 23 year old operating system thats been out of support
for a decade is not the easy path.

I'm thankful that OpenSSL hasn't dropped support yet, but its really a
matter of time. I've already had to patch one library I use (libssh) to
restore XP support, I don't think I will be willing to do the same for
OpenSSL when the time comes.

With Visual C++, perl, and nasm installed

:-) Lets guess : I just have to install a random version of each and it will all work nicely together ? No ? Some combinations will work but others won't ? And I just have to pick some and hope I get lucky ? :-)

Visual C++ 2019 is the newest that can target XP, Visual C++ 2010 is the
oldest I've attempted to build current OpenSSL on - I don't know how
much older you can go, but I do know that Visual C++ 6.0 is too old.

Any version of perl will do - its only used to run the configure script
that generates the makefile. I just grab the current version of
Strawberry perl from https://strawberryperl.com/

Any version of nasm will do. I just grab the current version from https://www.nasm.us/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <v84o67$3qod9$1@dont-email.me>, address@is.invalid says...

David,

Unfortunately you need to be logged in to github to download
artifacts from CI runs.

Nope. For the same reason I'm not going to not install a VC compiler environment (for a one-off something).

Well, its not really a one-off - there have already been 14 releases of
OpenSSL 3.0 and I'm sure there will be plenty more before it goes out of support in September 2026.

If security is important (and I assume it is, otherwise why bother with OpenSSL), you'll likely be building it a few times a year to fix
security vulnerabilities whenever they come up.

you could try the openssl bits from this older build:

[snip link]

Thanks. Alas, the "openssl.exe" executable in it also thows that "is not a valid Win32 application" error (although I can make a guess, I still don't know what causes it).

one of the other responders here told me that he needed to "tweak" the sourcecode to get it to compile and work on XP.

...

There is no need to tweak the C code at this time.

That means that I've now got two sources of information that are conflicting with each other. :-(

yeah, targeting a 23 year old operating system thats been out of
support for a decade is not the easy path.

Preceede that with sorely lacking information about (the available for download) OpenSSL versions in general (which makes it next-to-impossible to figure out which download is compatible with my 32-bit XP OS), and you understand the predicament I'm in. :-(

I would have thought that the users of XP would be making extensive use of OpenSSL, because the commercial products have dropped XP from their vocabulary.

Any chance you know of someone who's willing to compile a 32-bit XP compatible version of OpenSSL 3.x for me ? It should be easy right ? It just needs a small(?)configuration change. :-)

Thanks for the responses/help.

Just had a look and indeed that openssl.exe doesn't work on Windows XP.
I checked a build of my application that I know for certain can do TLS
on Windows XP and openssl.exe is broken there too despite the DLLs
working fine! Turns out the linker was marking the executable with a
subsystem version too high for XP. Ended up just patching the makefile
as the openssl configure script doesn't let you specify particular
linker flags (ran into this when cross-compiling OpenSSL for Itanium).

In here you'll find OpenSSL 3.0.14 built for Windows XP fresh from CI
along with a screenshot showing it running: https://ftp.zx.net.nz/public/tmp/openssl-3-xp/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-28, R.Wieser <address@is.invalid> wrote:

one of the other responders here told me that he needed to "tweak" the
sourcecode to get it to compile and work on XP.

...

There is no need to tweak the C code at this time.

That means that I've now got two sources of information that are conflicting with each other. :-(

As one of those sources, I probably misspoke. I'm trying to remember
something I did a while ago and probably got some of it wrong. It's
probably more accurate to say that I was tweaking not the C source
code itself, but the build procedures. It took a bit of work, and
I don't remember the intricacies in full detail. So no, there's
probably no conflict between us.

(Note that the word "probably" occurs four times in the preceding
paragraph. I qualify virtually everything I say.)

Any chance you know of someone who's willing to compile a 32-bit XP compatible version of OpenSSL 3.x for me ? It should be easy right ?
It just needs a small(?)configuration change. :-)

If you don't mind figuring out how to statically link to MinGW libraries (libcrypto.a and libssl.a), I could probably put the ones I finally built
up on Dropbox.

--
/~\ Charlie Gibbs | We'll go down in history as the
\ / <cgibbs@kltpzyxm.invalid> | first society that wouldn't save
X I'm really at ac.dekanfrus | itself because it wasn't cost-
/ \ if you read it the right way. | effective. -- Kurt Vonnegut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David,

Nope. For the same reason I'm not going to not install a VC compiler
environment (for a one-off something).

Well, its not really a one-off

:-) Thats a maintainer kind of POV, not a/my User one. If v0.9.8 would
have had TLS1.2+ support I would not even have considered looking for a
newer version (don't try to fix what aint broken).

If security is important (and I assume it is, otherwise why bother
with OpenSSL),

You have no idea what another reason could be ?

In my case security could not be less important.

What is is that when I go to the baker to buy me a loaf bread - something everyone can afford - I'm not allowed into the store without having a money-movers type of truck to transport that loaf.

Sound silly ? But that is how it nowerdays works. Even when a website
doesn't have got anything of worth (like just a few pictures of pets doing silly things or some webstrips) I may only get what they have when I have
high levels of SSL security.

As how low my interest in security is ? The version I now have (using the
DLLs FireFox comes with) I have not even bothered to check the servers certificates.

IOW, the only reason I'm rewriting that version using OpenSSL is because the locks on the servers front doors get ever more complex, and I want to make
sure that I can keep entering them.

Now you know /two/ reasons why someone would want to use OpenSSL. :-)

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <v85k5l$3vd4f$1@dont-email.me>, address@is.invalid says...

David,

Nope. For the same reason I'm not going to not install a VC compiler
environment (for a one-off something).

Well, its not really a one-off

:-) Thats a maintainer kind of POV, not a/my User one. If v0.9.8 would
have had TLS1.2+ support I would not even have considered looking for a
newer version (don't try to fix what aint broken).

If security is important (and I assume it is, otherwise why bother
with OpenSSL),

You have no idea what another reason could be ?

In my case security could not be less important.

What is is that when I go to the baker to buy me a loaf bread - something everyone can afford - I'm not allowed into the store without having a money-movers type of truck to transport that loaf.

Sound silly ? But that is how it nowerdays works. Even when a website doesn't have got anything of worth (like just a few pictures of pets doing silly things or some webstrips) I may only get what they have when I have high levels of SSL security.

As how low my interest in security is ? The version I now have (using the DLLs FireFox comes with) I have not even bothered to check the servers certificates.

IOW, the only reason I'm rewriting that version using OpenSSL is because the locks on the servers front doors get ever more complex, and I want to make sure that I can keep entering them.

Now you know /two/ reasons why someone would want to use OpenSSL. :-)

Out of curiousity, what is it you're trying to do? I assume not build a
web browser.

If you *are* doing https stuff though, there are perhaps easier ways
than dealing with OpenSSL directly. There are proxy servers you can run
on some other computer like a Raspberry Pi that will downgrade the
SSL/TLS version to something vintage computers will understand. There is
one that will re-render the page in a way vintage browsers will handle
too. Probably much easier than trying to wrangle the poorly documented
OpenSSL API.

Also, I forgot to mention those XP-compatible binaries I linked to will
need the Visual C++ redistributable installed, though I expect by now
mostly everyone will already have the last XP version of that: https://ftp.zx.net.nz/pub/dev/redist/vcpp/2019_16.7/VC_redist.x86.exe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David,

Out of curiousity, what is it you're trying to do? I assume not
build a web browser.

I'm trying to re-build my webpage download tool.

If you *are* doing https stuff though,

:-) Yep. Otherwise I would just have used Windows own WS2_32.DLL and be
done with it.

there are perhaps easier ways than dealing with OpenSSL directly.

I'm sure of it. But as a hobby programmer I'm inclined to see if I can do
it myself too (doesn't mean that I will never switch to use pre-made
solutions, just that they are not the first thing I think of)

There are proxy servers you can run on some other computer like a
Raspberry Pi that will downgrade the SSL/TLS version to something
vintage computers will understand.

There is not even a need to use a seperate 'puter for it, a proxy service
will run as well on the client 'puter itself.

There is one that will re-render the page in a way vintage browsers
will handle too.

That sounds /very/ interresting. Especially when you can script the "re-endering" part (read: being able to scrub webpages before viewing).

IOW, do you perhaps have a name and/or link for me ?

Probably much easier than trying to wrangle the poorly documented
OpenSSL API.

"Probably" ? Thats an easy bet. :-) But as I'm not willing to just "give
up" because "it looks too hard" I will try my damnest to see if I can figure
it out before conceeding defeat (yeah, you can just call it "stubborn" if
you want. :-) ).

Also, I forgot to mention those XP-compatible binaries I linked to
will need the Visual C++ redistributable installed,

I didn't even get far enough to get an error about it. :-|

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Charlie,

As one of those sources, I probably misspoke.

...

It's probably more accurate to say that I was tweaking not the C
source code itself, but the build procedures.

...

So no, there's probably no conflict between us.

Thank you for posting that. :-) It does take my confusion away.

Alas, it doesn't it doesn't really change anything for me. I still have no intention to install a VC compiler (and its dependancies) just for the sake
of creating the two DLLs. Besides the problem of having to find the info to how to tweak the build process - when finding even just basic info about OpenSSL is problematic.

If you don't mind figuring out how to statically link to MinGW
libraries (libcrypto.a and libssl.a), I could probably put the ones
I finally built up on Dropbox.

Thanks for the offer, but I'm afraid that my language-of-choice uses .OBJ
files for that. IOW, those files are likely incompatible with my Borlands
Tasm v5 assembler.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David,

Unfortunately you need to be logged in to github to download
artifacts from CI runs.

Nope. For the same reason I'm not going to not install a VC compiler environment (for a one-off something).

you could try the openssl bits from this older build:

[snip link]

Thanks. Alas, the "openssl.exe" executable in it also thows that "is not a valid Win32 application" error (although I can make a guess, I still don't
know what causes it).

one of the other responders here told me that he needed to "tweak" the sourcecode to get it to compile and work on XP.

...

There is no need to tweak the C code at this time.

That means that I've now got two sources of information that are conflicting with each other. :-(

yeah, targeting a 23 year old operating system thats been out of
support for a decade is not the easy path.

Preceede that with sorely lacking information about (the available for download) OpenSSL versions in general (which makes it next-to-impossible to figure out which download is compatible with my 32-bit XP OS), and you understand the predicament I'm in. :-(

I would have thought that the users of XP would be making extensive use of OpenSSL, because the commercial products have dropped XP from their
vocabulary.

Any chance you know of someone who's willing to compile a 32-bit XP
compatible version of OpenSSL 3.x for me ? It should be easy right ? It
just needs a small(?)configuration change. :-)

Thanks for the responses/help.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <v87dqo$cir7$1@dont-email.me>, address@is.invalid says...

David,

Out of curiousity, what is it you're trying to do? I assume not
build a web browser.

I'm trying to re-build my webpage download tool.

If you *are* doing https stuff though,

:-) Yep. Otherwise I would just have used Windows own WS2_32.DLL and be done with it.

there are perhaps easier ways than dealing with OpenSSL directly.

I'm sure of it. But as a hobby programmer I'm inclined to see if I can do
it myself too (doesn't mean that I will never switch to use pre-made solutions, just that they are not the first thing I think of)

There are proxy servers you can run on some other computer like a
Raspberry Pi that will downgrade the SSL/TLS version to something
vintage computers will understand.

There is not even a need to use a seperate 'puter for it, a proxy service will run as well on the client 'puter itself.

There is one that will re-render the page in a way vintage browsers
will handle too.

That sounds /very/ interresting. Especially when you can script the "re-endering" part (read: being able to scrub webpages before viewing).

IOW, do you perhaps have a name and/or link for me ?

This is the tool: https://github.com/tenox7/wrp

Its not quite what I would consider ideal though - it can either send
back a very simplified version of the webpage, or it can render the
webpage server-side and then send an imagemap to the browser. So in that
mode you're really just operating chrome remotely via a vintage web
browser.

Probably much easier than trying to wrangle the poorly documented
OpenSSL API.

"Probably" ? Thats an easy bet. :-) But as I'm not willing to just "give up" because "it looks too hard" I will try my damnest to see if I can figure it out before conceeding defeat (yeah, you can just call it "stubborn" if
you want. :-) ).

Also, I forgot to mention those XP-compatible binaries I linked to
will need the Visual C++ redistributable installed,

I didn't even get far enough to get an error about it. :-|

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David,

There is one that will re-render the page in a way vintage browsers
will handle too.

That sounds /very/ interresting. Especially when you can script the
"re-endering" part (read: being able to scrub webpages before viewing).

IOW, do you perhaps have a name and/or link for me ?

This is the tool: https://github.com/tenox7/wrp

Its not quite what I would consider ideal though - it can either send
back a very simplified version of the webpage, or it can render the
webpage server-side and then send an imagemap to the browser. So in
that mode you're really just operating chrome remotely via a vintage
web browser.

Thanks for that.

As for the drawback of the "simplified version of the webpage", between my GreaseMonkey and RequestPolicy firefox add-ons (page scrubbing and
third-party resource blocking) I might well already be looking at such "simplified versions" of webpages. :-)

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)