OpenSSL failure in Cygwin: SSL_set_tlsext_host_name returns 1 (SSL_TLSEXT_ERR_ALERT_WARNING)

OpenSSL failure in Cygwin: SSL_set_tlsext_host_name returns 1 (SSL_TLSEXT_ERR_ALERT_WARNING)

[Yuri]

I've built the proxytunnel project in Cygwin 
(https://github.com/proxytunnel/proxytunnel).

It is usually used to tunnel ssh through https using the https CONNECT 
command.


The command "proxytunnel --no-check-certificate -E -p 
{https-proxy-host}:{https-proxy-port} -d 127.0.0.1:22" works on Linux 
and BSD.


However, it fails in Cygwin with the exit code 1 
(SSL_TLSEXT_ERR_ALERT_WARNING), which causes this error message in 
proxytunnel:

 > SSL_set_tlsext_host_name returned: 1 (0x1). TLS SNI error, giving up


This prevents proxytunnel from being able to connect to the remote peer.


What might be wrong?



Thank you,

Yuri

Re: OpenSSL failure in Cygwin: SSL_set_tlsext_host_name returns 1 (SSL_TLSEXT_ERR_ALERT_WARNING)

[Andrey Repin]

Greetings, Yuri!

> I've built the proxytunnel project in Cygwin
> (https://github.com/proxytunnel/proxytunnel).

> It is usually used to tunnel ssh through https using the https CONNECT command.


> The command "proxytunnel --no-check-certificate -E -p
> {https-proxy-host}:{https-proxy-port} -d 127.0.0.1:22" works on Linux and BSD.


> However, it fails in Cygwin with the exit code 1
> (SSL_TLSEXT_ERR_ALERT_WARNING), which causes this error message in proxytunnel:

 >> SSL_set_tlsext_host_name returned: 1 (0x1). TLS SNI error, giving up

This error means that a connecting party had sent server name which server did
not acknowledge.

> This prevents proxytunnel from being able to connect to the remote peer.


> What might be wrong?

If possible, I would look at the protocol log for connection, if I were you.


-- 
With best regards,
Andrey Repin
Monday, May 8, 2023 13:09:25

Sorry for my terrible english...

Re: OpenSSL failure in Cygwin: SSL_set_tlsext_host_name returns 1 (SSL_TLSEXT_ERR_ALERT_WARNING)

[Brian Inglis]

On 2023-05-08 01:31, Yuri via Cygwin wrote:
> I've built the proxytunnel project in Cygwin 
> (https://github.com/proxytunnel/proxytunnel).
> It is usually used to tunnel ssh through https using the https CONNECT command.
> The command "proxytunnel --no-check-certificate -E -p 
> {https-proxy-host}:{https-proxy-port} -d 127.0.0.1:22" works on Linux and BSD.
> However, it fails in Cygwin with the exit code 1 (SSL_TLSEXT_ERR_ALERT_WARNING), 
> which causes this error message in proxytunnel:
>  > SSL_set_tlsext_host_name returned: 1 (0x1). TLS SNI error, giving up
> This prevents proxytunnel from being able to connect to the remote peer.
> What might be wrong?

Which Cygwin, ssl/tls-devel libraries, and ca-certificates... packages and 
versions are you using?

	$ man SSL_set_tlsext_host_name

says SSL_set_tlsext_host_name etc. returns 1 for success, 0 for failure?

Web search TLS SNI and you will find that either the host presents a list of 
certs none of which match the host name you are connecting to, a matching cert 
cannot be validated, possibly due to a missing CA chain, or one end could not 
handle the list presented or cert matched; some hits offer diagnostic suggestions.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: OpenSSL failure in Cygwin: SSL_set_tlsext_host_name returns 1 (SSL_TLSEXT_ERR_ALERT_WARNING)

[Yuri]

On 5/8/23 08:31, Brian Inglis wrote:
> Which Cygwin, ssl/tls-devel libraries, and ca-certificates... packages 
> and versions are you using?

libssl-devel-1.1.1t-1

openssl-1.1.1t-1

ca-certificates-2021.2.60-1


>
>     $ man SSL_set_tlsext_host_name
>
> says SSL_set_tlsext_host_name etc. returns 1 for success, 0 for failure?

Yes. It looks like there is a coding error that they don't just check 
for 0 or 1, and check for 0 as a sign of success.

But this code, amazingly, works flawlessly on Linux/BSD.


>
> Web search TLS SNI and you will find that either the host presents a 
> list of certs none of which match the host name you are connecting to, 
> a matching cert cannot be validated, possibly due to a missing CA 
> chain, or one end could not handle the list presented or cert matched; 
> some hits offer diagnostic suggestions.
>


This program has a special variable no_check_cert_flag that allows to 
disable certificate check: 
https://github.com/proxytunnel/proxytunnel/blob/master/ptstream.c#L356

In my case the certificate is self-signed and this variable is activated.

On Linux the same invocation doesn't cause such failure.

Is this code incorrect?


I will report the incorrect use of SSL_set_tlsext_host_name to proxytunnel.



Yuri

Re: OpenSSL failure in Cygwin: SSL_set_tlsext_host_name returns 1 (SSL_TLSEXT_ERR_ALERT_WARNING)

[Achim Gratz]

Yuri via Cygwin writes:
> The command "proxytunnel --no-check-certificate -E -p
> {https-proxy-host}:{https-proxy-port} -d 127.0.0.1:22" works on Linux
> and BSD.
>
> However, it fails in Cygwin with the exit code 1
> (SSL_TLSEXT_ERR_ALERT_WARNING), which causes this error message in
> proxytunnel:
>
>> SSL_set_tlsext_host_name returned: 1 (0x1). TLS SNI error, giving up

The port might not be open in the standard configuration of the Windows
firewall.  Maybe you can use either openssl or curl to check what
happens when you are trying to connect.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: OpenSSL failure in Cygwin: SSL_set_tlsext_host_name returns 1 (SSL_TLSEXT_ERR_ALERT_WARNING)

[Yuri]

On 5/8/23 10:40, Achim Gratz via Cygwin wrote:
> The port might not be open in the standard configuration of the Windows
> firewall.  Maybe you can use either openssl or curl to check what
> happens when you are trying to connect.


It looks like this function is used incorrectly, and it actually 
succeeds in Cygwin (returns 1) and fails on Linux/BSD (returns 0).

The upstream needs to fix this first.

I managed to make the program to work by making this just a warning.



Yuri