tcp fallback on linux doesn't work

[grzech0]

If no SNI field found in https reqest, host address on upstream squid is empty.

command:
curl -Iv https://193.109.212.15 -X GET -k

• Trying 193.109.212.15:443...
• Connected to 193.109.212.15 (193.109.212.15) port 443 (#0)
• ALPN, offering h2
• ALPN, offering http/1.1
• successfully set certificate verify locations:
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: /etc/ssl/certs
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 193.109.212.15:443
• Closing connection 0
  curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 193.109.212.15:443

aproxy log:
2024/03/26 09:27:08 ERROR failed to connect to http proxy src=172.18.0.6:37458 original_dst=193.109.212.15:443 host=:443 error="proxy return 400 response for connect request"

upstream squid log:
1711445229.279 0 192.168.118.11 NONE/400 3738 CONNECT :443 - HIER_NONE/- text/html

[weiiwang01]

Thank you for reporting this issue. It is indeed a problem, but finding a straightforward solution appears to be challenging. The simplest approach is, as aproxy is designed for SNI, it may suffice to close the connection and print an error message saying that SNI was not found. But ideally aproxy should also support TLS sites without SNI, such as https://1.1.1.1.

To achieve this, the proxy needs to populate the host field with information from the TCP connection (either the destination address or the original destination address). However, this method has a problem: it can easily create an infinite loop in certain cases. For example, if aproxy instance is listening on 10.0.0.1:443 and an HTTP proxy is on 10.0.0.2:8080, a direct connection to the proxy (e.g., curl https://10.0.0.1:443) would result in the aproxy sending connection request to 10.0.0.1:443 to the HTTP proxy. The HTTP proxy, as requests, would then connect to 10.0.0.1:443, leading the proxy to send another connection request to the HTTP proxy, and so on.

I think as a starting point, It will be good to simply close the connection and print an error message in the case of no SNI.

[cbartz]

@weiiwang01 is it planned to follow-up here? Otherwise please close the issue.

[weiiwang01]

@weiiwang01 is it planned to follow-up here? Otherwise please close the issue.

This pull request has the potential to fix the problem, but I'm not sure if it will be included in the end. I think we can keep this issue open for now, and I'll follow up later.

#31

[cbartz]

@weiiwang01 the pr #31 landed, so I guess this can be closed?