Unable to connect to servers with invalid/self-signed/untrusted certificates about dino HOT 33 OPEN

Sad that this is still an issue...

from dino.

jabber.ccc.de uses CACert which is most likely not activated as a CA on your system and thus there is no way to authenticate the remote server. Your "own freedombox" likely has a similar issue.

Dino currently does not allow to ignore or handle certificate issues. If you trust CACert you can install their CA to your system or use a XMPP server that does not use broken certificates.

from dino.

Workaround (Ubuntu 18.04): Add your self-signed Cert to the System's Certstore:

1. Get the Certificate as a .crt (Or PEM and Rename it). I tried to download it myself, but that didn't work (I got the Servers cert, not one for my Domain, see below). I downloaded it via https://xmpp.net there you can analyze your Server, in the Result you can Download the Certificate as a .pem File. Download it and rename it to .crt.
   1a. If you used Gajim before, you can check the downloaded Certs-SHA-256-Key: Find the Key Gajim used in ~/.config/gajim/config , search for "ssl_fingerprint_sha256". Compare that to the output of openssl x509 -in /the/crt/file/you/downloaded.crt -noout -text -sha256 -fingerprint
2. Add the Cert as described here:
   sudo cp my.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates
3. Restart Dino, you should be able to Login now, without Errors.

Why I need to do this?
I'm using a professional Email Service, they also host XMPP. They of course have valid Certs, but I opted to use my own domain (hollerith.info). My Domain has a SRV-Record, that redirects xmpp to xmpp.mailbox.org. They issue a Self-Signed Cert for "hollerith.info", since they can't get an official cert for the Domain, because the domain is under my Control. Of course theoretically, that would be solvable, but sadly, they offer XMPP just as it is, without further support.

from dino.

It's never fun when people use the wrong github issue to discuss their own problem. And I've just become one of them ( ,_,) sorry
Your comment made me realise my real issue. My JID is [email protected] and the XMPP is server is located at domain.com. But the website domain.com is not hosted on the same machine as the XMPP server. I have an LE certificate for the website, but since the XMPP machine does not have access to that certificate, no wonder Dino complains. So I guess I will try to get a second certificate on the XMPP machine.

from dino.

Just build Dino and found this issue too. Right now the UI just loops trying to connect, without any message to the user. In future binary releases, it'd be ideal to have some meaningful alert for the user and break the log in attempt.

from dino.

Hey guys,

I have the same problem on my hosted domain @ conversations.im server. It use Let's Encrypt certificate.

Gajim, Conversations and https://check.messaging.one are fine with it but Dino give me an error: Stream Error: TlsError: Unacceptable TLS certificate

from dino.

@metbosch @licaon-kter
These changes won't be merged as they are RFC non-compliant.

The problem with metbosch's company server is that it uses a TLS certificate for jabber.company.com to claim ownership of [email protected], which is not supposed to work. The proposed change does not only change the server to connect to, it also changes the TLS verification such that it allows a certificate from that server to authenticate for any domain entered in JID field, which is wrong.

Even if a company for some strange reason is unable to use SRV records for company.com and thus requires their clients to enter jabber.company.com as a host to connect to, the TLS certificate presented must be for the company.com domain to indicate ownership of [email protected] address.

from dino.

Hi
Any fix ?

from dino.

@metbosch That's different. But why don't you PR that as an option here?

from dino.

This is an issue for anyone (like me) running an XMPP server as a Tor hidden service.

Let's Encrypt will not work with *.onion domains, so I created a self-signed certificate which creates 0 problems with profanity on desktop and conversations on Android. I have some people on my server who would rather use a GUI program, and this issue stops them from being able to use dino.

from dino.

I'm running into this issue using a wildcard certificate from Let's Encrypt. the cert is for *.domain.org and domain.org the XMPP server is at chat.domain.org. Does Dino really not like the fact that it's a wildcard cert? Why would this be considered invalid?

from dino.

@licaon-kter I don't know anything about Vala. Syntactically, it looks like C. Does it have an OR operator (||)?

81a5505#diff-a1e86d2426a1de98dbfd8c579a08552c37b459be54b9179ba4d0564bb3826afc

Edit: If Vala is like C, then I guess I wrote my first piece of Vala code in #1445 XD.

from dino.

Same issue occurs, when the jabber server uses a self-signed certificate.

from dino.

Just in case someone reaches this point in the future.

I modified the login form to contain an additional servername field. This allows defining a different domain for the server than the one in the JID. I required this modification as my company has the server running at jabber.company.com but the JID must be [email protected] to make the LDAP integration correctly work.

The code is in the master branch of my fork: https://github.com/metbosch/dino/
The error that the client was showing to me is:

Its security certificate is issued to another domain.

from dino.

@licaon-kter @mar-v-in

I can to the PR if it is interesting for the community. I didn't open it before because I do not control the corner cases (like leaving the field in blank) and I do not want to put to much effort on that. My idea was to leave the information here, just in case someone founds it interesting or it can help to develop the real solution.

Regarding @mar-v-in comment, I do not know if the mismatch between JID and servername is protocol compliant or not, but other jabber clients support the definition of both fields separately.

Here is an screenshot of my modified sing in window:

from dino.

I am not against the option to set custom server name and port (although I won't agree with the proposed UI), however setting a custom server still requires verifying the TLS certificate against the domain part of the JID.

You mentioned that you see the "Its security certificate is issued to another domain." error when connecting to your JID without entering the server name. This is a strong indication that Dino already knows the correct server to connect to and the server name and port setting should be useless in your case. Your patch helps not because it allows you to connect to your server but because it allows you to accept an illegal TLS certificate.

This can be a severe security threat to non-expert users, as they might read in the internet that entering connect.repair into that box will fix any connection issues. As they connect the server at connect.repair will receive their login credentials and is able to drive a MITM attack.

This is why a server must be able to present a TLS certificate for the domain part of the JID so that no matter what you add as a server name, it is verified that the server is actually authenticated to receive your JIDs login credentials.

from dino.

Any real solution in sight yet? I'm using a Let's Encrypt certificate like the rest of the tinkering world. I'm reading the different issues here but fail to see why this is still an issue after three years while all other XMPP clients work with my server?

from dino.

@YarmoM what's the issue if you use Let's Encrypt then?

from dino.

Even when using Let's Encrypt, I get the "Could not establish a secure connection". Dino is supposed to work with LE certs?

from dino.

@YarmoM of course, works for most of the network.

But... you have a cert for the domain or xmpp.domain or what? Detail your cert setup...and the format of your JID

from dino.

Same problem for me, using my own domain with the mailbox.org XMPP service. With Pidgin and Gajim it works fine. Dino does not seem to offer a way to deal with this self-signed certificate. I would expect a dialog to pop up that asks me whether I want to accept this self-signed certificate or not. Adding the certificate to the system store does not seem to be a clean solution because I don't want to globally trust this certificate, only with one specific application.

The used setup instructions can be found here: https://kb.mailbox.org/display/MAILBOX/Using+Jabber+service+with+your+own+domain

from dino.

@pkonow so POSH support? https://tools.ietf.org/html/draft-ietf-xmpp-posh-06

from dino.

Well, POSH might help in some specific cases, but this is more of a general issue. Any user-facing application that deals with certificates should give the user an option to manually accept self-signed certs. There can be many reasons for that, for example when connecting to your own server that nobody else uses. The application should not ultimately require a valid trust chain because there is simply no need for it in certain cases.

What's wrong with just presenting the certificate to the user, and if he trusts it then saving the fingerprint in a list of manually approved certificates? AFAIK this is how all the other XMPP clients, web browsers etc. solve it. 😉 POSH would more be an improvement on top, to avoid requiring a manual trust statement by using an alternative method to verify the authenticity of the certificate IF such a method is available.

from dino.

POSH covers your case with hosted XMPP more broadly. But I agree.

from dino.

And the accounts are [email protected] or [email protected] ?

from dino.

from dino.

Nothing useful in logs? https://github.com/dino/dino/wiki/Debugging

from dino.

@grondinm Dino doesn't do anything certificate related itself; that's done by glib and your system decides what's accepted. Thus, something is probably wrongly set up on your end. If you tell me your domain**, I can have a look at why Dino doesn't connect to it.
** Here or in a private message to fiaxh in the project channel [email protected].

from dino.

@fiaxh
Mate, can u help me as well? I am using ejabberd under ovpn, didnt have domain name, connect directly to ip. Its fine to every client except Dino. In these conditions of couse i cant use good cert.
I am willing to pay for your time and actual result. Contact me at Telegram - Cal_013, or by email - [email protected]

from dino.

Wow, this actually still is an ongoing problem. Great to hear that I'm locked out of access to xmpp.ilita.i2p due to this certificate check that cannot be disabled.

Please just offer an option to disable certificate checks.

from dino.

@PoneyClairDeLune as the message says you can have your system trust it first, right?

from dino.

@PoneyClairDeLune as the message says you can have your system trust it first, right?

It's a chore for every single XMPP server hosted on mixnets. Why not just offer an option for all hosts, or if the TLD provided is one of the mixnet TLDs (onion, i2p, loki, etc)?

from dino.

@PoneyClairDeLune there's no such issue on .onion domains, maybe see that commit and open a PR for .i2p ?

from dino.