Stunnel config
client = no cert = /path/to/fullchain.pem key = /path/to/privkey.pem pid = /var/run/stunnel4/stunnel.pid debug = 7 output = /var/log/stunnel4/stunnel.log
[tinyproxy] accept = 0.0.0.0:8443 connect = 127.0.0.1:7777
here's the log 2024.06.28 11:08:26 LOG7[main]: Found 1 ready file descriptor(s) 2024.06.28 11:08:26 LOG7[main]: FD=4 events=0x2001 revents=0x0 2024.06.28 11:08:26 LOG7[main]: FD=9 events=0x2001 revents=0x1 2024.06.28 11:08:26 LOG7[main]: Service [tinyproxy] accepted (FD=3) from X.X.X.X:42086 2024.06.28 11:08:26 LOG7[3]: Service [tinyproxy] started 2024.06.28 11:08:26 LOG7[3]: Setting local socket options (FD=3) 2024.06.28 11:08:26 LOG7[3]: Option TCP_NODELAY set on local socket 2024.06.28 11:08:26 LOG5[3]: Service [tinyproxy] accepted connection from X.X.X.X:42086 2024.06.28 11:08:26 LOG6[3]: Peer certificate not required 2024.06.28 11:08:26 LOG7[3]: TLS state (accept): before SSL initialization 2024.06.28 11:08:26 LOG3[3]: SSL_accept: ../ssl/record/ssl3_record.c:348: error:0A00009B:SSL routines::https proxy request 2024.06.28 11:08:26 LOG5[3]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2024.06.28 11:08:26 LOG7[3]: local_rfd/local_wfd reset (FD=3) 2024.06.28 11:08:26 LOG7[3]: Local descriptor (FD=3) closed 2024.06.28 11:08:26 LOG7[3]: Service [tinyproxy] finished (0 left)
on connect, I'm using server with OS Ubuntu16.04 with OpenSSL 1.1.1n 15 Mar 2022 (Library: OpenSSL 1.1.1 11 Sep 2018).
using my other server (OS ubuntu 2X.) and my local (Mac OS), I'm able to connect to stunnel + tinyproxy successfully. it seems the issue within the server with Ubuntu16.04 or did I miss other config ?
on the proxy server (stunnel server), I use OS Debian 12 + openssl version OpenSSL 3.0.11 19 Sep 2023 (Library: OpenSSL 3.0.11 19 Sep 2023)
On Fri, Jun 28, 2024 at 11:18:42AM -0000, jensen@fixes.hk wrote:
Stunnel config
client = no cert = /path/to/fullchain.pem key = /path/to/privkey.pem pid = /var/run/stunnel4/stunnel.pid debug = 7 output = /var/log/stunnel4/stunnel.log
[tinyproxy] accept = 0.0.0.0:8443 connect = 127.0.0.1:7777
here's the log 2024.06.28 11:08:26 LOG7[main]: Found 1 ready file descriptor(s) 2024.06.28 11:08:26 LOG7[main]: FD=4 events=0x2001 revents=0x0 2024.06.28 11:08:26 LOG7[main]: FD=9 events=0x2001 revents=0x1 2024.06.28 11:08:26 LOG7[main]: Service [tinyproxy] accepted (FD=3) from X.X.X.X:42086 2024.06.28 11:08:26 LOG7[3]: Service [tinyproxy] started 2024.06.28 11:08:26 LOG7[3]: Setting local socket options (FD=3) 2024.06.28 11:08:26 LOG7[3]: Option TCP_NODELAY set on local socket 2024.06.28 11:08:26 LOG5[3]: Service [tinyproxy] accepted connection from X.X.X.X:42086 2024.06.28 11:08:26 LOG6[3]: Peer certificate not required 2024.06.28 11:08:26 LOG7[3]: TLS state (accept): before SSL initialization 2024.06.28 11:08:26 LOG3[3]: SSL_accept: ../ssl/record/ssl3_record.c:348: error:0A00009B:SSL routines::https proxy request
What is the program that tried to connect to stunnel? Did you tell it to use an encrypted (TLS) connection? Since your stunnel is configured in its default (server) mode ("client = no", although it seems weird to see that setting in the global section), stunnel will expect whatever connects to it to speak TLS. The "https proxy request" error is returned by OpenSSL if the client sends a "CONNECT ..." request in plaintext, i.e. the client thinks that it is talking to a plaintext HTTP(S) proxy server.
2024.06.28 11:08:26 LOG5[3]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2024.06.28 11:08:26 LOG7[3]: local_rfd/local_wfd reset (FD=3) 2024.06.28 11:08:26 LOG7[3]: Local descriptor (FD=3) closed 2024.06.28 11:08:26 LOG7[3]: Service [tinyproxy] finished (0 left)
on connect, I'm using server with OS Ubuntu16.04 with OpenSSL 1.1.1n 15 Mar 2022 (Library: OpenSSL 1.1.1 11 Sep 2018).
using my other server (OS ubuntu 2X.) and my local (Mac OS), I'm able to connect to stunnel + tinyproxy successfully. it seems the issue within the server with Ubuntu16.04 or did I miss other config ?
Actually, let's take a step back: what exactly is the purpose of this stunnel/tinyproxy configuration? Knowing that might help figure out what is wrong with it.
G'luck, Peter
Hi Peter,
Thanks for your response. The purpose of the stunnel config is to have my connection encrypted using ssl while connecting to tinyproxy.
we have 1 server in HK that needs to connect to OpenAI API (HK region will not get support anymore on 9 July 2024). so I think to setup new server in supported region as proxy server, use tinyproxy for proxy server and make sure the connection is secure by using stunnel. so this way our HK server can still call OpenAI API by using the new proxy server (stunnel + tinyproxy).
on above err log, I use this curl command to connect to the proxy server curl --proxy "https://address:8443" https://www.google.com -v
the command above is working fine on my other server except Ubuntu16.04.
Hopefully this information can help. Thanks
On Fri, Jun 28, 2024 at 12:19:51PM -0000, jensen@fixes.hk wrote:
Hi Peter,
Thanks for your response. The purpose of the stunnel config is to have my connection encrypted using ssl while connecting to tinyproxy.
we have 1 server in HK that needs to connect to OpenAI API (HK region will not get support anymore on 9 July 2024). so I think to setup new server in supported region as proxy server, use tinyproxy for proxy server and make sure the connection is secure by using stunnel. so this way our HK server can still call OpenAI API by using the new proxy server (stunnel + tinyproxy).
on above err log, I use this curl command to connect to the proxy server curl --proxy "https://address:8443" https://www.google.com -v
the command above is working fine on my other server except Ubuntu16.04.
OK, now I understand what you're trying to do, and I think I know what the problem is. The support for HTTPS proxies in cURL was only added in version 7.52, while Ubuntu 16.04 only has cURL 7.47. So if you're running cURL from the same host that runs stunnel, Ubuntu 16.04's cURL will not send the correct request. Try running cURL from another host, or testing with `openssl s_client -connect address:8443` and then typing in an HTTP CONNECT request by hand.
Hope that helps!
G'luck, Peter
Hi Peter,
Thank you for bringing up the curl version concern. Last night, I attempted to connect using proxies directly with Python code on Ubuntu 16 (not using curl), but encountered the same issue.
Today, upon seeing your reply, I revisited the Python code and found the issue: there was a typo in the proxy URL 😅. Instead of https://address:8443, I mistakenly used http://address:8443.
Thank you so much for your help in getting this sorted out. I truly appreciate it!
On Sat, Jun 29, 2024 at 4:11 AM Peter Pentchev roam@ringlet.net wrote:
On Fri, Jun 28, 2024 at 12:19:51PM -0000, jensen@fixes.hk wrote:
Hi Peter,
Thanks for your response. The purpose of the stunnel config is to have my connection encrypted using ssl while connecting to tinyproxy.
we have 1 server in HK that needs to connect to OpenAI API (HK region will not get support anymore on 9 July 2024). so I think to setup new server in supported region as proxy server, use tinyproxy for proxy server and make sure the connection is secure by using stunnel. so this way our HK server can still call OpenAI API by using the new proxy server (stunnel + tinyproxy).
on above err log, I use this curl command to connect to the proxy server curl --proxy "https://address:8443" https://www.google.com -v
the command above is working fine on my other server except Ubuntu16.04.
OK, now I understand what you're trying to do, and I think I know what the problem is. The support for HTTPS proxies in cURL was only added in version 7.52, while Ubuntu 16.04 only has cURL 7.47. So if you're running cURL from the same host that runs stunnel, Ubuntu 16.04's cURL will not send the correct request. Try running cURL from another host, or testing with `openssl s_client -connect address:8443` and then typing in an HTTP CONNECT request by hand.
Hope that helps!
G'luck, Peter
-- Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
-
Jensen -
jensen＠fixes.hk
-
Peter Pentchev