Ticket #720 (closed task: fixed)

Opened 3 years ago

Last modified 11 months ago

SSL certificate verification feature

Reported by: Pihhan Owned by: asterix
Priority: high Milestone: 0.12
Component: dialogs Version: svn
Severity: major Keywords: security
Cc: bronger@… OS: All

Description

I would like see some SSL certificate handling in some of next version of gajim. Somewhere i found about jabber system: They tells you about secure communication, but (almost) every client doesnt handle any kind of certificate, so its not secure at all. I have to say that this man was true - Jabber IM system has SSL feature very long time. Its good that not everyone can read your communication. But SSL itself is only secure transport channel from one host to another. Without any certificate checking, you never know what is your true remote host. You can have secure channel to hacker, which is intersted in your love postings with your girlfriend, or worse your passwords to some thing. Anyone who has access to router between you and your server can listen to your secure traffic if he know how simple it is. If you really want present SSL layer to user with lock icon, remember they think they are protected. But they are protected as if you lock front door of your house, but leave unlocked doors to garden. Anyone can redirect your traffic to himself, read it and send encrypted to server. Anything he needs - iptables and stunnel. Really almost every can spoof your ssl. If you bother with SSL layer, you should make it valuable - really protecting its users.

Best way to do - use strong ciphers (use by default often), and check that you talk to right server. Each certificate has some issuer. You can do a little for any certificate.

If server has self-signed certificate, there is not much to do. You cannot verify validity of certificate. But you can check, if certificate had not changed. This does not prevent attacker from reading your traffic, if he is there all the time. But if you are lucky, you connected when there was no attacker in way. So you saw certificate of real server, and you saw its fingerprint. You save it for later use. Then, if attacker comes, he send you another certificate for same server. Here, you can notify user that something changed. That something is not as should be. You can do this without any preinstalled certificates or access to system certificates. You can simply check fingerprints for change. As SSH do. Its not perfect, but it is some protection.

The best way is to use root certificates and try checking their source. Check if this certificate is valid. It it is, you are sure this is your server. Unless jabber server was compromited and keys lost. Nobody's perfect. :)

Most of jabber servers dont have signed certificate from public certificate authority, because it costs money. But you should not use Psi's aproach - ignore any SSL errors. Instead, save receiver certificate and in next connection you are able to validate certificate about change. Have you seen install button in web browser? Yes, they check it too. You may install even self-signed.

So, please, let us have best IM solution really secure. :) So, please, it would be good if: for self-signed, verify thats has not changed. Check certificate hostname if it matches with server name and save with fingerprint for next connection. for cert with CA - allow saving CA certificate or/and try to use some from browser or system to validate. check if SSL hierarchy is valid, and top most can be validated from your certificates. If not, allow saving of server's certificate fingerprint or allowing topmost CA to be trustworthy. When saving new certificate, it is good habit to show user fingerprint. Most of them will simply press OK. But they will see it only first time, and get bonus protection from that. I think it is worth to consider.

Sorry for spamming, its long. I repeat myself, but i think checking certificate is good thing.

Attachments

ssl_cert_verif.diff (5.7 kB) - added by asterix 12 months ago.
ssl_cert_verif.2.diff (11.5 kB) - added by asterix 12 months ago.

Change History

Changed 3 years ago by nk

  • priority changed from low to lowest
  • milestone 0.9 deleted

I cannot understand what that is a good idea.. It's not that you get to buy or give your VISA so you have to be bugged about SSL being singed by "trusted companies" (I do not trust them) or untrusted like other sources.

Moreover even if we have this feature we should not default to Yes as Psi does because most servers will give warnings and it's the worse user experience that a client can give.

a client is to just talk with others for most people, and that is it. We'd better focus on providing security via E-Sessions and that is all.

I propose WONTFIX

Changed 3 years ago by nk

  • status changed from new to closed
  • resolution set to wontfix
  • milestone set to 0.9

Moreover user choooses which server he wants to use. So he somehow trusts him, but if he doesn't, then he should not use that server at all.

IM security is welcome and is done via E-Sessions and PGP encryption and those make trusting SSL (the poor admin has to pay $$$$$$$$$$$$$$$$$$$$$$$ and €€€€€€€€€€€€€ to company that "assures" it's "safe"). Even GMAIL's guides for Psi say: "turn off ssl warnings" in almost hidden tab in almost hidden setting

Changed 3 years ago by TobiX <gajimbts@…>

  • priority changed from lowest to normal
  • status changed from closed to reopened
  • resolution wontfix deleted
  • milestone 0.9 deleted

I think your understanding of security is flawed. If you don't want to support SSL certificate verification then be so honest to your users and disable SSL/TLS support completely. The current usage of SSL/TLS is totally useless since it cannot protect against a MITM-attack at all. Since it is very easy to get a "good" certificate for free via CAcert (Debian already includes their certificate, browser inclusion is near) I see your money-argument as as void.

And if you personally don't trust those CAs you can safely remove all Root-CAs from your browsers/mail programs/etc. and verify each certificate fingerprint manually.

Changed 3 years ago by nk

  • priority changed from normal to lowest
  • severity changed from normal to trivial

I'm not hear to argue with anyone. Over my dead body this will pass as default to ON though. if you like that, use Psi.

Jabber should be for common users, who if he gets TLS/SSL jargon he will reply: "Yes. ET PHONE HOME"

This is not to say that foo user doesn't deserve security & privacy, but those concepts should be delivered to him transprently if possible, else we should not bug him.

Since you seem to know everything, I guess I must remind you that using whatever measure to secret something, won't make it secret, just harder to break. And that harder in most cases it's a day or two for those that would really care. f.e. yesterday in Greece (where I live) the gov announced that 100 mobile phones (including those of top ministers and Prime Minister) were being co-heard by unknown (think USA embacy) persons.

to sum up, there is no security, wake up

have fun and I almost forgot, go ahead and patch us!

ps. browsers are used to buy (eg. give visa, mastercard etc..). Jabber and Gajim is atm mostly blablalblablalba so Encryption such as OpenPGP is enough. as to Man in the middle, this in theory can never be avoided. anyways..

Changed 3 years ago by nicfit

We should most definitely support this, and IMO by default. It is how the security model works, and doing it halfway defeats most of its purpose.

It should work just like Mozilla, the key is checked against a list of CAs (ideally the user would be able to tweak this list) and if the key is not signed by a valid CA prompt deny/accept this session/accept forever. The last option is what you want to check to never be prompted again.

It does not take the extorting Verisign to make this model work. It could be Yann that is your trusted CA, or me (but you prolly would not trust an American ;)), or better yet CA Cert (http://www.cacert.org/)

To take it one step further, Gajim should also provide the ability to present its own cert to servers to allow for x509 auth, for example. But this is just dreaming of the future...

Obviously I've not been concerned about where I connect, or I might have hacked on it. But whether it should be considered is a no-brainer.

So about them patches? :)

Changed 3 years ago by nk

guys I know cacert and I know Gajim is not a browser. Can you find me IM clients that do this thing? I know that GTALK official page, says how to disable ssl warnings in Psi to connect to them... that says it all why it cannot be on by default imo (I cannot just go in super hidden tab and disable super hidden setting) just to talk to my friend or girlfriend.. (because I won't *BUY* sth using Gajim)

Changed 3 years ago by dkirov

In addition, it will be one more pain in the a** since python builtin socket.ssl doesn't support certificate verification and we'll need to depend on PyOpenSSL.

Having gajim with support for extra security checks/verifications and not having the needed dependencies installed is the same as having gajim without the ssl verifications, even worst - one may think that he is secure, while his client is doing nothing, because of the missing dependency. If we are about to *hard* depend on pyopenssl this means that we are stuck with it. For a certain reason I cannot install pyopenssl on my machine, so I cannot use gajim!

Changed 3 years ago by nk

I don't know many that demand or would like to have security in their IM. and those that want are geeks and can use GPG or ESessions (OTR) message encryption.

I still propose WORKSFORME. Yann?

Changed 3 years ago by nicfit

Exodus does this. I was not aware of the SSL issues. I propse it stay active as a nice to have, but hey, I've not turned back from using gajim because this is not implemented, so it is not something that I MUST have. Bon't a well implemented patch would be nice and I'd be +1 on adding.

Changed 3 years ago by nk

so Exodus bugs the user or it's off by default?

btw, I don't think Exodus is the most User Friendly Jabber client in the world (although feature rich)

Changed 3 years ago by nk

  • status changed from reopened to closed
  • resolution set to wontfix
  • milestone set to 0.10

security and whatever has to be transparent. since Gajim is IM and u don't use it to buy a house or sth via that asks your visa or mastercard I think the way to go for security of messages (for those that use IM and worry for privacy, is #544) as since that is not done yet, use OpenPGP. both do not bug the casual user who chats with GF that will break up 6 months later.

or as a Google official said, most chinese do not search for 'democracy' in google.cn, they just google around their pop stars

Changed 18 months ago by steve-e

  • severity changed from trivial to major
  • os set to All
  • priority changed from normal to high
  • version changed from 0.8.1 to svn
  • milestone changed from 0.5 to 0.12
  • type changed from defect to task

The world hast changed. See [8211]

Changed 18 months ago by steve-e

  • keywords security added; SSL certificate removed

Let me begin with some comments:

a client is to just talk with others for most people, and that is it. We'd better focus on providing security via E-Sessions and that is all.

This does not protect your loginpassword. The problem is that many people only have one password for everything.

Moreover user choooses which server he wants to use. So he somehow trusts him, but if he doesn't, then he should not use that server at all.

I trust my server, but not the other guys on public wlans.

the poor admin has to pay $$$$$$$$$$$$$$$$$$$$$$$ and €€€€€€€€€€€€€ to company that "assures" it's "safe" one who uses

XMPP.org offers certs.

Even GMAIL's guides for Psi say: "turn off ssl warnings" in almost hidden tab in almost hidden setting

Doors should not be lockable, because people lose their key all the time?

The current usage of SSL/TLS is totally useless since it cannot protect against a MITM-attack at all.

Absolutly right

Changed 18 months ago by steve-e

Section of RFC 3920:

14.2 Certificate Validation

   When an XMPP peer communicates with another peer securely, it MUST
   validate the peer's certificate.  There are three possible cases:

   Case #1: The peer contains an End Entity certificate which appears to
      be certified by a chain of certificates terminating in a trust
      anchor (as described in Section 6.1 of [X509]).
   Case #2: The peer certificate is certified by a Certificate Authority
      not known to the validating peer.
   Case #3: The peer certificate is self-signed.

   In Case #1, the validating peer MUST do one of two things:

   1.  Verify the peer certificate according to the rules of [X509].
       The certificate SHOULD then be checked against the expected
       identity of the peer following the rules described in [HTTP-TLS],
       except that a subjectAltName extension of type "xmpp" MUST be
       used as the identity if present.  If one of these checks fails,
       user-oriented clients MUST either notify the user (clients MAY
       give the user the opportunity to continue with the connection in
       any case) or terminate the connection with a bad certificate
       error.  Automated clients SHOULD terminate the connection (with a
       bad certificate error) and log the error to an appropriate audit
       log.  Automated clients MAY provide a configuration setting that
       disables this check, but MUST provide a setting that enables it.

   2.  The peer SHOULD show the certificate to a user for approval,
       including the entire certificate chain.  The peer MUST cache the
       certificate (or some non-forgeable representation such as a
       hash).  In future connections, the peer MUST verify that the same
       certificate was presented and MUST notify the user if it has
       changed.

   In Case #2 and Case #3, implementations SHOULD act as in (2) above.

Changed 18 months ago by asterix

  • status changed from closed to reopened
  • resolution wontfix deleted

that sound perfect to me to do that. Does that really solve the MITM attack ? Can't this man in the middle sends us a valid cert that gajim will accept ?

Changed 18 months ago by steve-e

No, it does not kill MITM. Trusted certs don't work if you do not trust the one who signs them (versign, thawte etc). So if the attacker has a cert we accept, we have a problem unless we check fingerprints.

Asterix, do you have got any connection to the xmpp.org guys? We might talk to them and their free certs for jabber admins . It would be cool if they can offer us a list with fingerprints of all their certs.


see #2499 and #1923

Changed 18 months ago by anonymous

In #3232 I suggested importing the distribution's CA-certs automatically. I did some research about that and found that at least Debian, Gentoo, Suse, Fedora and their derivatives (Ubuntu..) store symlinks to their CA-certs in /etc/ssl/certs. Thats five major distributions. Mandrake seems to use /etc/ssl/*/.

Also at least Gentoo and Debian have a file called /etc/ca-certificates.conf, containing a list of all CA certificates on the system. (The files are listed relative to /usr/share/ca-certificates/)

You could load all files from those directories (load_verify_locations can be called multiple times) instead of using a certificate file included in the gajim distribution. With this step you'd put the would trust problem aside (CAs included in a user's distribution are likely to be checked against a gpg key on installation or so)

If not, please add cacert.org to your certificate list.

For that OpenSSL-dependency problem: This might sound somewhat sick, but you could open a second socket for the (python) SSL part and tunnel traffic between the connection and the SSL socket. Read the certificate and validate it manually (or using the command line tool). dup2 the sockets together afterwards. Or ship gajim with an advanced _ssl.so, which does the validation part. However, I'd prefer a pyopenssl dependency over an IM which does not support key security features.

Changed 17 months ago by junglecow

Hi,

steve-e asked me to comment on this ticket. Unfortunately personal circumstances have left me with too little time to keep up with Gajim. I hope this can gradually improve in the coming months.

  1. To Asterix, Yes, properly validating certificates will prevent most common MITM attacks, and should be enough for the average user. Please note emphasis on properly, which includes verifying the server's hostname against the one listed in the certificate. (See quoted RFC for exact details.)
  2. Using certificates already supplied by the distribution is a good idea. Some mechanism is needed for advanced users to choose which certs they trust, however this is not critical and can be added later.
  3. The fingerprint mechanism is still needed, among others for this use case:

The server you are trying to connect to has presented a signed certificate. However, Gajim does not recognize the signing authority. [insert certificate info here] Would you like to trust this certificate anyway? (Yes/No)

And of course also because of point 2 from the RFC quote above.

Changed 16 months ago by Mirrakor

I guess the fingerprint check can be done rather easy: We save the fingerprint we get when we first connect, and check if it's the same on every reconnect, sure adds a few ms to the connection process, but it's worth it I think.

Changed 16 months ago by steve-e

Mirrakor, you have to be secured beginning with the first connection. We have to retrieve hash/cert over a secured transport channel, because we cannot be sure that our connection is not spoofed.

Changed 12 months ago by asterix

Here is a patch that shows a dialog to accept or not the certificate. comments are welcome

Changed 12 months ago by asterix

Changed 12 months ago by asterix

about the load_verify_locations function, it's only partialy implemented in python bindings: second parameter (folder where to find certs) is not usable ... so we have to parse file and add cert ourself. it's what I did in my patch to add certs we already trusted.

Changed 12 months ago by asterix

Changed 12 months ago by asterix

here is an improved version with sha1 fingerprint verification.

Changed 12 months ago by asterix

  • status changed from reopened to closed
  • resolution set to fixed

(In [9095]) SSL certificate verification, certificate fingerprint verification. fixes #720, #2499

Changed 11 months ago by steve-e

  • status changed from closed to reopened
  • resolution fixed deleted

See: http://trac.gajim.org/ticket/1923#comment:34

Gajim cannot deal with unknown root certs.

Changed 11 months ago by asterix

the "add root cert" checkbutton should not be shown for all SSL errors. It should be for errors like error 18 ("Self signed certificate in certificate chain").

And we should first check if it is present in file before showing the checkbutton too.

Changed 11 months ago by anonymous

  • cc bronger@… added

Changed 11 months ago by asterix

  • status changed from reopened to closed
  • resolution set to fixed

(In [9194]) don't propose to add certificate to cacerts.pem file if it's useless, and don't add it if it is already in. fixes #720

Changed 11 months ago by steve-e

  • status changed from closed to reopened
  • resolution fixed deleted

The last commit breaks cert handling. Just remove your cacerts.pem and try to connect to gajim.org.

Changed 11 months ago by asterix

Could you explain the problem ?

There is a problem with cert of gajim.org, it's expired. So it's normal that you get an error dialog each time you try to connect there. Is that the problem you mention?

I'll update it when I'll have time ...

Changed 11 months ago by nicfit

I no longer get the checkbox for always accepting expired tickets. Before I got the checkbox, checked it, and kept getting prompted during connections (although it did show up in cacerts.pem). No there is no checkbox at all.

Changed 11 months ago by asterix

it's normal to not get the checkbutton and to get a warning each time we connect in this case. I thing eveythong is ok here. I'll make SSL error bold to see it more clearly

Changed 11 months ago by asterix

  • status changed from reopened to closed
  • resolution set to fixed

(In [9206]) how SSL error message in bold. fixes #720

Add/Change #720 (SSL certificate verification feature)

Author



Change Properties
<Author field>
Action
as closed
Next status will be 'reopened'
 
Note: See TracTickets for help on using tickets.