Opened 10 years ago

Closed 8 years ago

#2499 closed task (fixed)

SSH-style fingerprint matching

Reported by: <jid:junglecow@…> Owned by: junglecow
Priority: high Milestone: 0.12
Component: None Version: hg
Severity: major Keywords: fingerprint fingerprinting patch
Cc: Blocked By:
Blocking: OS: All

Description

Since there is no interest in implementing certificates at this time (#720), it would be nice to at least have SSH-style fingerprint matching. When a user makes a secure connection to the server for the first time, the certificate's fingerprint is stored in the local configuration, and next time it is compared against the server key. If there's a mismatch, the user gets a warning. This would help a lot against MITM attacks, which Gajim currently doesn't defend against at all.

I don't even mind if the option is turned off by default. (Keys do change from time to time, and Joe Blow doesn't know what to do with that kind of warning.) However, in that case I'd like to see a "Match SSL/TLS fingerprint" checkbox in the Connection tab in the server settings, so advanced users are aware of this option. (Or maybe Security should have its own tab?) If it's going to be turned on by default, it would be okay if it's in advanced configuration only. (The user can turn it off from the warning dialog.)

Attachments (1)

gajim-pyopenssl-with-bugs-1.patch (5.4 KB) - added by junglecow 10 years ago.
Preliminary pyopenssl patch (depends on python-pyopenssl package)

Download all attachments as: .zip

Change History (13)

comment:1 Changed 10 years ago by nk

  • Priority changed from normal to lowest

to avoid MITM use OpenPGP. isn't that enough?

comment:2 Changed 10 years ago by anonymous

OpenPGP only hides the contents of individual private

conversations.

It does not hide:

  • Who you're currently talking to, even if secured with PGP.
  • Who are on your roster, their presence status, and yours.
  • VCards of you and your contacts.
  • MUC conversation.
  • The Password1

Worse, your communication can be modified arbitrarily without having the password. Imagine the possibilities.

Furthermore, there aren't that many people who know and use PGP, and some clients prefer to implement OTR in favor of PGP, if they implement encrypted chat at all. SSL is independent of your contact's features.

I simply don't get it. Why bother implementing SSL, and then not provide even the most basic protection against attack? In the Jabber standard, SSL is the principal means of obscuring traffic from prying eyes and ensuring that we're talking to the server we think we're talking to, not PGP. Why isn't SSL used the way it's intended to? And what's the difficulty in getting a key fingerprint and comparing it against a stored value, when it provides such an improvement in security?

---- 1: If we can perform a MITM attack, it is trivial to modify the conversation to negotiate plaintext authentication. If the server refuses plain authentication, it is only slightly less trivial.

comment:3 Changed 10 years ago by nk

  • Priority changed from lowest to low

SSL/TLS came from the library. I just ask questions here. Okay I'm

convinced but that doesn't mean I will hack it. Maybe Dimitur will someday or perhaps you can try. I leave open as this is nice to have (False by default, exposed in UI as proposed, string should be "Notify on TLS fingerprint mismatch") and a good tooltip is needed.

comment:4 Changed 10 years ago by <xmpp:junglecow@…>

Hmmm, I just looked at how Gajim uses SSL, and I'm beginning to appreciate the resistance against SSL features.

Gajim uses the SSL API from Python's standard library. The problem with that is that it doesn't offer any features at all. Really all you can do is open an SSL connection. You can't get any information from the SSL layer except some descriptive strings. That is... well, let's be polite here... "very bad". It's useless except for casual encryption. It doesn't look like there are plans to extend the API either.

That means we're looking at potentially using an external SSL library. As far as I can see, this issue has never been discussed before. Maybe it needs its own ticket.

In the mean time, I'm looking at suitable candidates. TLS Lite looks nice, clean API, pure Python but can optionally use other crypto libraries for speed, and it's in the public domain. Comments, please.

comment:5 Changed 10 years ago by junglecow

  • Owner changed from asterix to junglecow

comment:6 Changed 10 years ago by junglecow

  • Status changed from new to assigned

comment:7 Changed 10 years ago by junglecow

Here's a preliminary patch. It seems to be working fine until you try to join a room. Joining works just fine, but it blows up (as shown below) once Gajim starts getting VCards. I'm lost, please help.

DEBUG: socket       got   <message from='gajim@conference.gajim.org' to='junglecow@gajim.org/Gajim' type='groupchat'>
  <subject>Welcome to the official room of Gajim. New Bugs at http://trac.gajim.org/newticket, http://www.frappr.com/gajim add yourselves! Paste in http://gajim.pastebin.com, shots in http://imageshack.us, room logs in http://www.gajim.org/room_logs/</subject>
  <body>jim has set the subject to: Welcome to the official room of Gajim. New Bugs at http://trac.gajim.org/newticket, http://www.frappr.com/gajim add yourselves! Paste in http://gajim.pastebin.com, shots in http://imageshack.us, room logs in http://www.gajim.org/room_logs/</body>
  </message>
DEBUG: dispatcher   ok    Got jabber:client/message stanza
DEBUG: dispatcher   ok    Dispatching message stanza with type->groupchat props->[u'jabber:client'] id->None
DEBUG: socket       sent  <iq to="gajim@conference.gajim.org/DaTa" type="get" id="28">
  <vCard xmlns="vcard-temp" />
  </iq>
DEBUG: socket       sent  <iq to="gajim@conference.gajim.org/rituko_a_" type="get" id="29">
  <vCard xmlns="vcard-temp" />
  </iq>
DEBUG: socket       sent  <iq to="gajim@conference.gajim.org/azerttyu" type="get" id="30">
  <vCard xmlns="vcard-temp" />
  </iq>
DEBUG: socket       sent  <iq to="gajim@conference.gajim.org/bronger" type="get" id="31">
  <vCard xmlns="vcard-temp" />
  </iq>
Traceback (most recent call last):
  File "/home/zovier/tmp/gajim-svn/src/common/xmpp/transports_nb.py", line 244, in _do_receive
    received = self._recv(RECV_BUFSIZE)
  File "/home/zovier/tmp/gajim-svn/src/common/xmpp/transports_nb.py", line 57, in recv
    if flags is None: return self.sock.recv(bufsize)
OpenSSL.SSL.Error: [('asn1 encoding routines', 'a2d_ASN1_OBJECT', 'first num too large'), ('asn1 encoding routines', 'a2d_ASN1_OBJECT', 'first num too large')]
DEBUG: socket       error Socket error while receiving data
DEBUG: client       stop  Disconnect detected

Changed 10 years ago by junglecow

Preliminary pyopenssl patch (depends on python-pyopenssl package)

comment:8 Changed 10 years ago by junglecow

First testing code is in SVN in its own branch. Please help with testing and see PersonalJunglecow#PyOpenSSLBranch for more information.

comment:9 Changed 9 years ago by anonymous

  • Keywords patch added

comment:10 Changed 9 years ago by steve-e

  • Milestone set to 0.12
  • OS set to All
  • Priority changed from low to high
  • Severity changed from normal to major
  • Type changed from enhancement to task
  • Version set to svn

comment:11 Changed 9 years ago by Mirrakor

I think this is an important thing, what junglecow raises. I'm defenitely for it, also I'm for turned off by default + UI Option. (Like he said, a "normal" user may be confused by the message, but for people like us it's a nice feature, and feels safer).

But I'd change "Notify on TLS fingerprint mismatch" to "Check TLS fingerprint for mismatch", I think we could disable the complete check when it's turned off - saves us some ms and and is one source of problems less.

Or, we turn it on by default(what's bad with "Secure by default"?), and give the user some hint's what he can/could do(Psi warn's user for selfsigned SSL certs, I think this wasn't a problem for the many windows users), something like: "A TLS fingerprint missmatch occured! The fingerprint just retrived is different from the stored one, this can, but however doesn't have to, mean that your connection has been corrupted and is affected by a men-in-the-middle(MITM)-attack. You should correspond the website, supportchannel or administrator and ask for changes of the TSL Certificat and the reason why(remember, even the attacker could be in the Support channel!). In the time where the immunity of the connection can't be secured/confirmed, it's recommend to avoid a connection to the server, if you've no other chance try to keep your conversations as less private as possible!"

"What do you want to do? Abort Connection, Continue Connection, Safe new Fingerprint[should have a warning, aka: "Do you really want to change the saved Fingerprint for Server XY"?]"

Thx for your time :)

comment:12 Changed 8 years ago by asterix

  • Resolution set to fixed
  • Status changed from assigned to closed

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

Note: See TracTickets for help on using tickets.