[BUG] Proxy connection not working

[michael-o]

I am running version

testssl.sh version 3.0.9 from https://testssl.sh/

Before you open an issue please whether this is a known problem by searching the issues

I couldn't find anything

Command line / docker command to reproduce

Consider the following:

$ testssl.sh --proxy de.coia.siemens.net:9400 -n none   https://sykatec.de
...
Fatal error: Proxy IP cannot be determined from "de.coia.siemens.net"
$ host "de.coia.siemens.net"
de.coia.siemens.net has address 185.46.212.91
de.coia.siemens.net has address 185.46.212.98
$ drill a "de.coia.siemens.net" | awk '/ANSWER SECTION/,/AUTHORITY SECTION/ { print $NF }' | awk '/^[0-9]/'
185.46.212.91
185.46.212.98

It is not really clear why you have to resolve the IP address of the proxy yourself since both curl and openssl-s_client will happily accept hostnames and will invoke getaddrinfo() for you.

Expected behavior

Use the proxy as-is, ideally.

Your system (please complete the following information):

• OS: FreeBSD 13.5-STABLE
• Platform: FreeBSD 13.5-STABLE amd64
• OpenSSL + bash: Using bash 5.2.37. OpenSSL 1.0.2-chacha (1.0.2k-dev) [~183 ciphers]

[michael-o]

I have applied the following patch, but get:

# diff  testssl.sh /usr/local/bin/testssl.sh
--- testssl.sh  2025-03-24 18:13:59.855072000 +0100
+++ /usr/local/bin/testssl.sh   2025-03-24 18:14:12.140478000 +0100
@@ -18421,12 +18421,7 @@
           #if is_ipv4addr "$PROXYNODE" || is_ipv6addr "$PROXYNODE" ; then
           # IPv6 via openssl -proxy: that doesn't work. Sockets does
 #FIXME: finish this with LibreSSL which supports an IPv6 proxy
-          if is_ipv4addr "$PROXYNODE"; then
-               PROXYIP="$PROXYNODE"
-          else
-               PROXYIP="$(get_a_record "$PROXYNODE" 2>/dev/null | grep -v alias | sed 's/^.*address //')"
-               [[ -z "$PROXYIP" ]] && fatal "Proxy IP cannot be determined from \"$PROXYNODE\"" $ERR_CMDLINE
-          fi
+          PROXYIP="$PROXYNODE"
           PROXY="-proxy $PROXYIP:$PROXYPORT"
      fi
 }

Command:

$ testssl.sh --proxy de.coia.siemens.net:9400 --nodns none   sykatec.de:443
...
Fatal error: No IPv4/IPv6 address(es) for "sykatec.de" available

[michael-o]

An ugly workaround is to query a public DNS server:

$ drill sykatec.de @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 63370
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; sykatec.de.  IN      A

;; ANSWER SECTION:
sykatec.de.     300     IN      A       89.22.120.168

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 12 msec
;; SERVER: 8.8.8.8
;; WHEN: Mon Mar 24 18:42:45 2025
;; MSG SIZE  rcvd: 44
osipovmi@deblndw011x:/tmp/testssl.QUNZn3
$ testssl.sh --proxy de.coia.siemens.net:9400 --nodns=none --ip 89.22.120.168   sykatec.de:443
...

I need to figure out with the DNS master why there are no A records internally, but my understanding is that with a proxy there is no need to resolve the hostname at all, that is what the proxy is for.

[drwetter]

Thanks for filing the issue.

What do you expect when providing z-n none`? There's no DNS resolution of the proxy IP at least.

But when providing the proxy IP and the FQDN of the target IIRC that should work automatically. That does not using 3.2 though. It works though (for 3.2) when one uses DNS_VIA_PROXY=true ./testssl.sh --proxy <PROXY:PORT> --nodns=none <TARGET> .

There was a change wrt to DNS_VIA_PROXY=true and I need to remember the logic of the change.

Likely this won't be addressed in 3.0 anymore. Please use 3.2

[michael-o]

Let me double check tomorrow for 3.2

[michael-o]

Latest RC looks a bit better, but still not good:

$  ./testssl.sh --proxy de.coia.siemens.net:9400 --ip=proxy   sykatec.de

#####################################################################
  testssl.sh version 3.2rc4 from https://testssl.sh/dev/
  (5359befc 2025-03-20 15:44:28)

  This program is free software. Distribution and modification under
  GPLv2 permitted. USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

  Please file bugs @ https://testssl.sh/bugs/
#####################################################################

  Using OpenSSL 1.0.2-bad (Sep 1 2022)  [~183 ciphers]
  on deblndw011x:./bin/openssl.FreeBSD.amd64

 Start 2025-03-24 21:07:48        -->> sykatec.de:443 <<--

 Via Proxy:              185.46.212.98
185.46.212.91:9400
 rDNS (sykatec.de):      --
 Your OpenSSL cannot connect to sykatec.de:443
 The results might look ok but they could be nonsense. Really proceed ? ("yes" to continue) --> yes
 Service detected:       Couldn't determine what's running on port 443, assuming no HTTP service => skipping all HTTP checks

 Testing protocols via sockets except NPN+ALPN

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    not offered
 TLS 1.2    offered (OK)
 TLS 1.3    not offered and downgraded to a weaker protocol
 NPN/SPDY   not tested as proxies do not support proxying it
 ALPN/HTTP2 not tested as proxies do not support proxying it

 Testing cipher categories

 NULL ciphers (no encryption)                      not offered (OK)
 Anonymous NULL Ciphers (no authentication)        not offered (OK)
 Export ciphers (w/o ADH+NULL)                     not offered (OK)
 LOW: 64 Bit + DES, RC[2,4], MD5 (w/o export)      not offered (OK)
 Triple DES Ciphers / IDEA                         not offered
 Obsoleted CBC ciphers (AES, ARIA etc.)            offered
 Strong encryption (AEAD ciphers) with no FS       offered (OK)
 Forward Secrecy strong encryption (AEAD ciphers)  offered (OK)


 Testing server's cipher preferences

 Oops: openssl s_client connect problem

Fatal error: repeated openssl s_client connect problem, doesn't make sense to continue
Consider increasing MAX_OSSL_FAIL (currently: 2)

I still don't understand why testssl.sh needs to resolve the proxy IP eventhough openssl-s_client opens the socket and why testssl.sh needs to resove the hostname eventhough a proxy has been passed and one can expect that the proxy should resolve via DNS not you, that's the purpose of it.

In contrast:

$ /usr/local/openssl-unsafe/bin/openssl s_client -connect sykatec.de:443 -proxy de.coia.siemens.net:9400
CONNECTED(00000003)
depth=0 C = DE, ST = Bavaria, L = Nuremberg, O = Innomotics GmbH, CN = www.sykatec.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = DE, ST = Bavaria, L = Nuremberg, O = Innomotics GmbH, CN = www.sykatec.de
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=DE/ST=Bavaria/L=Nuremberg/O=Innomotics GmbH/CN=www.sykatec.de
   i:/C=US/O=DigiCert Inc/CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
 1 s:/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2 G3
   i:/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2 G3
 2 s:/C=BM/O=QuoVadis Limited/CN=QuoVadis Global SSL ICA G3
   i:/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2 G3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIH1TCCBr2gAwIBAgIQCA4nGXsrBDHVJ1DvZuC17zANBgkqhkiG9w0BAQsFADBZ
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMTMwMQYDVQQDEypE
aWdpQ2VydCBHbG9iYWwgRzIgVExTIFJTQSBTSEEyNTYgMjAyMCBDQTEwHhcNMjQw
OTA5MDAwMDAwWhcNMjUwOTA4MjM1OTU5WjBmMQswCQYDVQQGEwJERTEQMA4GA1UE
CBMHQmF2YXJpYTESMBAGA1UEBxMJTnVyZW1iZXJnMRgwFgYDVQQKEw9Jbm5vbW90
aWNzIEdtYkgxFzAVBgNVBAMTDnd3dy5zeWthdGVjLmRlMIICIjANBgkqhkiG9w0B
AQEFAAOCAg8AMIICCgKCAgEA253NIb9HbRs1PwR9Exwf+G0YlRv3czqQNmIdLDec
/QeFZ3U7eFPyVh3cDNgwX0rE73RijVef/WPjdzx3ijgYydwUmg0KarbK3JSzU9vg
DSTUuCu1mcb1GuJ9QGee99dNI5Cmuh2NZS13fgmAJ42QuxLBCF9UREz7mWBrvdc9
zbYopwBx2o9YAhTc6PzaRINC/AVq67/91ccjnlDJLPqNjbd52Ww6HHGcCF7us0Md
I+bub64eEBpWq8DZl+mDOOgYUft/DokptVY/Lnn8BY+xH31ktjZ7kSKihFVdSdt9
sGUgD9btX+UylpYEtRPENITK1kUM6VHCRm8oFQPs2zduBauuJNk2Ie5DOf2nIxW3
f0zAloma7h2CmrAlZK9acS37/UpA2kdhs373s8F8hZFAGyH4ciVuG0xmO7bjCFPh
vAX9cENyJHOD3WEGflTVg+KphdLTT5wNw9RE951orYxZgDwiIotRGMxFdewvBNeG
2EaAHW5DIQQsdhkpLuR/GGxFN+lpm0X7CTtFydax2PrLwnACZ1Fqg//YhEHLWU0o
Lv0bR3ms1gxVIt6/kNbg+EIRzunfoy9q9MJCVJGa4d+9HGh3L/P3CeIHjFZFqYQA
xedSQCTKNJ77NBqpEYBZMcyaUPZ9iIk960kEn6oxK9e3W6irzPwQqqFp0mwAf2J/
vwcCAwEAAaOCA4owggOGMB8GA1UdIwQYMBaAFHSFgMBmx9833s+9KTeqAx2+7c0X
MB0GA1UdDgQWBBRFg6jDv3m13zNlp9LcE6ick54XADAZBgNVHREEEjAQgg53d3cu
c3lrYXRlYy5kZTA+BgNVHSAENzA1MDMGBmeBDAECAjApMCcGCCsGAQUFBwIBFhto
dHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwDgYDVR0PAQH/BAQDAgWgMB0GA1Ud
...

Yet another tricky you. For several hosts we have split DNS, thus internally they have one address and maybe different TLS and form the internet another IP address. If you use a proxy for scanning your report the internal IP address, but are actually scanning the public one. Here is an example:

$ host devops.alm.innomotics.net
devops.alm.innomotics.net is an alias for k8s-devopspr-devopspr-73ed1e5379-1a17941313d9cf83.elb.eu-central-1.amazonaws.com.
k8s-devopspr-devopspr-73ed1e5379-1a17941313d9cf83.elb.eu-central-1.amazonaws.com has address 10.64.230.245
k8s-devopspr-devopspr-73ed1e5379-1a17941313d9cf83.elb.eu-central-1.amazonaws.com has address 10.64.230.197
$ host devops.alm.innomotics.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

devops.alm.innomotics.net has address 135.236.87.0

[drwetter]

I still don't understand why testssl.sh needs to resolve the proxy IP eventhough openssl-s_client opens the socket

One answer is on the code above. IPv6 proxy doesn't work with the openssl version you were using. Even the IPv4 proxy code was backported in your openssl. Moreover we don't use openssl everywhere but bash sockets . Or how did you think your ./bin/openssl.FreeBSD.amd64 does a check for TLS 1.3?

[michael-o]

I still don't understand why testssl.sh needs to resolve the proxy IP eventhough openssl-s_client opens the socket

One answer is on the code above. IPv6 proxy doesn't work with the openssl version you were using. Even the IPv4 proxy code was backported in your openssl. Moreover we don't use openssl everywhere but bash sockets . Or how did you think your ./bin/openssl.FreeBSD.amd64 does a check for TLS 1.3?

That makes sense, but to add an important detail is that there is no IPv6 here at all. I don't know whether this makes a difference.
One problem is that these implementation details aren't really obvious to the user and lead to inconsistent behavior.

[drwetter]

I don't know whether this makes a difference.

No / not yet. See code.

Other than that I do not understand what's inconsistent here? The behavior is also documented, see ~/doc/ dir.

What we could think of is changing the default so that DNS_VIA_PROXY's default is true.

[michael-o]

What we could think of is changing the default so that DNS_VIA_PROXY's default is true.

This is reasonable especially when we assume that hosts behind a proxy oare on a purpose not available directly.

[drwetter]

@w4ntun: do you remember the reason why we changed DNS_VIA_PROXY from true to false in #2295 / #2328 ?

[w4ntun]

Hi @drwetter . I really don't remember why we switched it to false. There had to be some use case that needed it, but I should retest it since that was a long time ago. However, reading the comments in #2328, I saw that I wrote another version of the code, but never created the PR. I have reviewed the code, and DNS_VIA_PROXY has been set back to true in a cleaner, more straightforward approach:

#2328 (comment)

I have created the PR in case you want to have a look: #2728