I’m currently running my own instance of opendht as proxy and coturn and try to find out how things work and to improve setup.
There I found that opendht --help shows an additional parameter called “–proxyserverssl” which however is not mentioned in the man page.
If this is designed to work similar to other TLS related services you would need a certificate and a private key. Looking at the source file “common_tools.h” I found that the “long_options” struct mentions the parameters “proxy-certificate” and “proxy-privkey” which seems to be exactly what I would have expected.
However I was not able to start opendht in proxy mode listening for tls/ssl.
DHT proxies are regular web/http services, authenticated by Jami using regular certificate chains checked against the system certificate authorities (unlike peer-to-peer TLS connections between Jami users using pinned user certificates).
You should be able to start a dhtnode in proxy mode with TLS by using these 3 arguments:
You would first need to obtain a certificate for your domain, for instance using let’s encrypt.
To use it in Jami, configure the DHT proxy as https://your-proxy-url.example:443
You should also be able to test it with dhtnode by connecting to your proxy server as a dht proxy client with dhtnode --proxyclient https://your-proxy-url.example:443 .
If you encounter any problem, please open a ticket here:
Yes that was exactly what I was trying without success. I will try again and see if I did anything wrong.
I would expect private key and certificate chain to be supplied in pem format and the certificates ordered from leaf to root. And the key to be not encrypted as there is not password needed.
Just rechecked it and it works as described and expected. No idea why it failed for the first time. Maybe I misinterpreted the log output which did not show a single line related to TLS if not in verbose mode.
Would be helpful for others if dhtnode functionality, usage message and man page would be in sync and mention these parameters.
The proxy is running but I’m unable to connect to it with latest Jami QT Client (only one I checked so far)
When adding the prefix “https://” to the connection string I get the error “No network connection” from the client. In the proxy logs I can see multiple messages like:
TLS on the proxy itself is working properly. When connecting with openssl s_client -connect
SSL handshake has read 4720 bytes and written 375 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
Any suggestions what could be wrong? Maybe the client is trying to connect with TLS v1 which is quite outdated and it is blocked by the server OS?
Just rechecked myself by forcing openssl s_client to connect to the server with -tls1 and it produces the same error logs when connecting with the Jami client, so it seems the Jami client is using TLS v1.
As it is not a good idea to enable TLS below 1.2 on a server today, the question is how to tell the JAMI client to at least use TLS 1.2.
Not sure if this is true or if these log messages are artefactual. At least from the server sources I found that beginning with opendht 3.7.1 the proxy server only accepts TLS 1.3 and not even TLS 1.2. So even no chance to overrule this by openSSL config.
To keep production server unchanged, I did further testing on a test system. Therefore I also copied the certificate where neither common name nor SAN of the certificate match the host name.
As the Jami client seems to do strict RFC 2818 compliance checking this failed on the test system.
It was the confusing log error message “tlsv1 alert internal error” leading me in the wrong direction. Additionally the fact that TLS test with “openssl s_client -connect” succeeded flawlessly.
So at the end: Sorry for wasting bandwidth and your time
