Charlie,

Here's the code I use to start and stop SSL on an existing connection.

Writing a basic client :

I just noticed how you did that, by providing the handle thru "sc->sockfd".

Does that mean you just do a connect to a server using a the OS standard
means and than call this method ?

Also, before calling "SSL_connect" I do not see you provide the hostname anywhere. Neither the SSL_* equivalent to "BIO_set_conn_hostname", nor its
TLS cousin, "SSL_set_tlsext_host_name".

Could you please explain ?

Regards,
Rudy Wieser

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

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

Charlie,

Here's the code I use to start and stop SSL on an existing connection.

Writing a basic client :

I just noticed how you did that, by providing the handle thru "sc->sockfd".

Does that mean you just do a connect to a server using a the OS standard means and than call this method ?

Exactly. For example, when talking to a mail server, I'll make a standard connection, issue a STARTTLS command, then call socksslstart().

Also, before calling "SSL_connect" I do not see you provide the hostname anywhere. Neither the SSL_* equivalent to "BIO_set_conn_hostname", nor its TLS cousin, "SSL_set_tlsext_host_name".

Could you please explain ?

I never really thought about it. I already have an open socket,
so host name isn't really relevant here. The name is in sc->sockname,
but I think I only use it when building error and debug messages.

--
/~\ 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,

Also, before calling "SSL_connect" I do not see you provide the hostname
anywhere. Neither the SSL_* equivalent to "BIO_set_conn_hostname", nor
its
TLS cousin, "SSL_set_tlsext_host_name".

Could you please explain ?

I never really thought about it. I already have an open socket,
so host name isn't really relevant here. The name is in sc->sockname,
but I think I only use it when building error and debug messages.

The thing is that the first SSL packet send normally contains the hostname -
to help the server send the request packet to the right handler (there might
be multiple virtual servers on a physical one).

I'll just have to try and see what actually gets send. Who knows, maybe OpenSSL extracts the target hostname from the socket.

Regards,
Rudy Wieser

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

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

Charlie,

Also, before calling "SSL_connect" I do not see you provide the hostname >>> anywhere. Neither the SSL_* equivalent to "BIO_set_conn_hostname", nor
its
TLS cousin, "SSL_set_tlsext_host_name".

Could you please explain ?

I never really thought about it. I already have an open socket,
so host name isn't really relevant here. The name is in sc->sockname,
but I think I only use it when building error and debug messages.

The thing is that the first SSL packet send normally contains the hostname - to help the server send the request packet to the right handler (there might be multiple virtual servers on a physical one).

I'll just have to try and see what actually gets send. Who knows, maybe OpenSSL extracts the target hostname from the socket.

Could be. All I know is that at this point I don't worry about the
host name, just the socket handle - and it Just Works.

--
/~\ 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,

All I know is that at this point I don't worry about the
host name, just the socket handle - and it Just Works.

I can't be satisfied with "it just works". I have the need to know *why* it (not) works. One of the drawbacks of being a hobbyist programmer I guess.
:-)

Regards
Rudy Wieser

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

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

Charlie,

All I know is that at this point I don't worry about the
host name, just the socket handle - and it Just Works.

I can't be satisfied with "it just works". I have the need to know *why* it (not) works. One of the drawbacks of being a hobbyist programmer I guess. :-)

s/hobbyist/inquisitive/

I'm a professional programmer and I really want to know how and why
things work (or don't work) too. It can save a lot of pain down the
road.

However, in this case all the TLS magic is being performed on an
already-opened socket. The host name (and port number) are no longer
relevant at this point; only the socket and SSL session handles matter.

By the same token, once I get a disk file open, I just call fgets(),
fputs(), getline(), etc. without worrying about what the file is called.

--
/~\ 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,

s/hobbyist/inquisitive/

True. Though as an inquisitive /commercial/ programmer there isn't always
time for that. But as a hobby programmer is already "wasting" his time ...
:-)

I'm a professional programmer and I really want to know how and
why things work (or don't work) too. It can save a lot of pain
down the road.

Thats the positive side of being inquisitive. And ofcourse that that
knowledge helps making better choices in later projects.

However, in this case all the TLS magic is being performed on
an already-opened socket. The host name (and port number) are
no longer relevant at this point; only the socket and SSL session
handles matter.

The problem is that the (only initial?) SSL communication with the server needs(?) that hostname too. And as I said, where does that "TLS magic" get
it from ? Or is it that in your case its send as an empty string and you've been lucky the other side doesn't need it ?

Regards,
Rudy Wieser

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

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

However, in this case all the TLS magic is being performed on
an already-opened socket. The host name (and port number) are
no longer relevant at this point; only the socket and SSL session
handles matter.

The problem is that the (only initial?) SSL communication with the server needs(?) that hostname too. And as I said, where does that "TLS magic" get it from ? Or is it that in your case its send as an empty string and you've been lucky the other side doesn't need it ?

Perhaps, but I've done SSL communication with lots of machines,
so either the host name isn't needed or I'm very lucky.

But you may be right. I haven't dug into the intricacies of the
SSL handshake, and maybe there's a host name is tucked in there
somewhere. The SSL code could be digging out the host name itself,
e.g. with gethostbyaddr().

--
/~\ 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,

Perhaps, but I've done SSL communication with lots of machines,
so either the host name isn't needed or I'm very lucky.

In that case I'm going to rule out luck.

I haven't dug into the intricacies of the SSL handshake, and maybe
there's a host name is tucked in there somewhere.

It is. I'm capturing that name in a small program which I re-route all unwanted SSL connections to, so I'm made aware of any attempted connections.

The SSL code could be digging out the host name itself, e.g.
with gethostbyaddr().

I was thinking the same (though not with that function. It could return a different name than you expect when targetting a server with multiple
hosts). But why than are there still two functions there which will also
set such a name ?

And what happens when you provide those two different hostnames ? Inquiring minds want^Wneed to know ! :-)

Did I already mention that I find the absense of OpenSSL documentation a problem ? :-|

Regards,
Rudy Wieser

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