[BUG] Proxy connection not working #2719

michael-o · 2025-03-24T17:04:12Z

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]

The text was updated successfully, but these errors were encountered:

michael-o · 2025-03-24T17:28:59Z

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 · 2025-03-24T17:49:02Z

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 · 2025-03-24T19:02:30Z

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 · 2025-03-24T19:17:52Z

Let me double check tomorrow for 3.2

michael-o · 2025-03-24T20:10:51Z

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 · 2025-03-24T20:55:35Z

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 · 2025-03-24T21:35:58Z

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 · 2025-03-25T11:25:53Z

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 · 2025-03-25T15:48:17Z

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 · 2025-03-27T15:40:07Z

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

w4ntun · 2025-04-02T19:02:02Z

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

w4ntun · 2025-04-02T19:54:30Z

@drwetter just thinking again about the change, I think it was related to this comment: #2328 (comment)

Since there are some DNS records that might not work through proxies, we decided to keep DNS_VIA_PROXY as false by default, and let the user choose if the resolution takes place exclusively at the proxy by adding --ip=proxy. If not, the script will use the local resolver if available.

My new PR sets DNS_VIA_PROXY to true again and follows this approach:

If the --proxy option is set, the DNS request must be sent through the proxy as it is de default behavior when using a proxy server. So in the new version, only the --proxy option needs to be set.
If the --ip option is set, the DNS resolving is not made by the proxy and we have multiple options: the value of an specific IP (no need to DNS resolving), the value of one (when obtaining multiple IPs from the local resolver, just keep the first one) or the value of all (get the IP addresses from a local resolver and scan all of them).

However, if there are some checks that make use of other DNS records apart from A, AAAA and CNAME, this approach may not work.

drwetter · 2025-04-04T09:58:45Z

Thanks. --> next week I can look at it. Still don't know yet whether I'd like to merge it now as said, it's a breaking change.

Apart from that: Looks like your PR needs to be rebased.

w4ntun · 2025-04-12T18:23:47Z

Hi @drwetter , thank you for your comment. I have rebased my PR and it should look fine right now. Let me know if you take a look at it.

drwetter · 2025-05-20T15:03:10Z

@michael-o : could you try with 3.2.0:

DNS_VIA_PROXY=true testssl.sh --proxy de.coia.siemens.net:9400 --nodns none sykatec.de:443
DNS_VIA_PROXY=true testssl.sh --proxy de.coia.siemens.net:9400 sykatec.de:443

Apply patch from #2728 or just use @w4ntun's branch, see PR

drwetter · 2025-05-20T15:06:21Z

Yet another tricky you. For several hosts we have split DNS

That should be handled either

by the client as the client knows which DNS to query. This is valid for every application on the client.
or by the proxy. If a proxy is used the idea of the proxy is that it does DNS resolution (which at the moment requires in testssl.sh still DNS_VIA_PROXY=true)

michael-o · 2025-05-21T07:06:19Z

@michael-o : could you try with 3.2.0:
* ` DNS_VIA_PROXY=true testssl.sh --proxy de.coia.siemens.net:9400 --nodns none   sykatec.de:443`

* ` DNS_VIA_PROXY=true testssl.sh --proxy de.coia.siemens.net:9400  sykatec.de:443`
Apply patch from #2728 or just use @w4ntun's branch, see PR

osipovmi@deblndw011x:~/testssl.sh (3.2 *=)
$ DNS_VIA_PROXY=true ./testssl.sh --proxy de.coia.siemens.net:9400 --nodns none   sykatec.de:443

#####################################################################
  testssl.sh version 3.2.0 from https://testssl.sh/
  (388f3a33 2025-05-20 17:59:19)

  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 (Mar 31 2025)  [~183 ciphers]
  on deblndw011x:./bin/openssl.FreeBSD.amd64

Fatal error: Proxy IP cannot be determined from "de.coia.siemens.net"

and

osipovmi@deblndw011x:~/testssl.sh (3.2 *=)
$ DNS_VIA_PROXY=true ./testssl.sh --proxy de.coia.siemens.net:9400    sykatec.de:443

#####################################################################
  testssl.sh version 3.2.0 from https://testssl.sh/
  (388f3a33 2025-05-20 17:59:19)

  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 (Mar 31 2025)  [~183 ciphers]
  on deblndw011x:./bin/openssl.FreeBSD.amd64

 Start 2025-05-21 09:04:18        -->> sykatec.de:443 <<--

 Via Proxy:              185.46.212.91:9400
 rDNS (sykatec.de):      --
 Service detected:       HTTP

 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
...

drwetter · 2025-05-22T20:27:28Z

Thanks, the latter looks as expected. The first may be just consistent but it's confusing for the user.

I guess the best would be (in 3.2) to change DNS_VIA_PROXY=true and improve the UX by just checking --nodns and if $PROXY is just a hostname or FQDN.

michael-o added bug:needs triage/confirmation bug:to be reproduced ... from maintainers labels Mar 24, 2025

michael-o changed the title ~~[BUG] No proxy connection working~~ [BUG] Proxy connection not working Mar 24, 2025

w4ntun mentioned this issue Apr 2, 2025

Cleaner and more straightforward version when using proxy server #2728

Open

13 tasks

[BUG] Proxy connection not working #2719

[BUG] Proxy connection not working #2719

Comments

michael-o commented Mar 24, 2025

michael-o commented Mar 24, 2025

Uh oh!

michael-o commented Mar 24, 2025

Uh oh!

drwetter commented Mar 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

michael-o commented Mar 24, 2025

Uh oh!

michael-o commented Mar 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

drwetter commented Mar 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

michael-o commented Mar 24, 2025

Uh oh!

drwetter commented Mar 25, 2025

Uh oh!

michael-o commented Mar 25, 2025

Uh oh!

drwetter commented Mar 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

w4ntun commented Apr 2, 2025

Uh oh!

w4ntun commented Apr 2, 2025

Uh oh!

drwetter commented Apr 4, 2025

Uh oh!

w4ntun commented Apr 12, 2025

Uh oh!

drwetter commented May 20, 2025

Uh oh!

drwetter commented May 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

michael-o commented May 21, 2025

Uh oh!

drwetter commented May 22, 2025

Uh oh!

drwetter commented Mar 24, 2025 •

edited

Loading

michael-o commented Mar 24, 2025 •

edited

Loading

drwetter commented Mar 24, 2025 •

edited

Loading

drwetter commented Mar 27, 2025 •

edited

Loading

drwetter commented May 20, 2025 •

edited

Loading