the different possibilities of securing a connection with the server are currently obscure

[bb]

basically, there are three types of connection: tls, ssl and plain , in that order of security. currently, one can choose between either "tls_and_plain" or "ssl" by enabling or disabling ssl connections, with the note that ssl is "legacy". if this is disabled it is unclear and not brought to the notice of the user whether the current connection is actually secured with tls and thus more secure than it would have been with ssl or if it is a plain text connection and thus very insecure. the little lock icon in the account name doesn´t mean much to most people (does it mean my connection is secured or does it indicate I have an openPGP key attached to this account? just for example.)

imo, it should be like this in the configuration panel:

Security :

• choose automatically
• specify manually

two radiobuttons, the first meaning that the connection is first checked for tls availablity, then for ssl and as a last option plain text is used. the specify manually would simply be a dropdown menu where you could choose either of three connection methods.

last but not least there could also be three ACE values, for the advanced users; "allow_tls" , "allow_ssl" and "allow_plain" .

[jim++]

What I think is a problem :

I'm a normal user, I see : [X]Use ssl

So I understand, check it to have a "secure" connection (I don't care about details how it is secured). And so, I suppose not-secure if I don't check the checkbox. Of course I don't read the tooltip because it seems obvious.

But that's not what this option mean in reality.

[hawke]

I think it would be good to take a page from Gaim here, and make those

options "Use TLS if available", "force old ssl" ("use tls if available" would still try to fall back to SSL if TLS didn't work), and "allow plaintext auth over unencrypted streams" .. defaulting to on,off,off respectively.

[bb]

a new idea was born after some discussion in the gajim conference room:

how about, when the password is about to be sent over a non secured connection, a warning shows up saying:

warning! your password is about to be sent in plain text over a non secured connection to server blabla.bla. do you wish to proceed?

[ ] ignore this warning for this server in the future.

[yes] [no]

[dkirov]

Generally "use ssl" checkbox is not needed, because Gajim will guess it

automatically (try to set port to 5223, without checking "use ssl"). We can show the warning dialog and keep other prefs in ACE, but I cannot image who will need to set 'allow_tls' to False.

[bb]

indeed, which user would willingly want ssl and not tls? basically, the

only reason would be the server not supporting it, in which case gajim automatically degrades to ssl (right?). so in the end the warning is sufficient, and a couple of ACE values...

[dkirov]

Yes, what gajim cannot automatically select is the port. I don't know of

server, which listens to 5223 only.

Also 'send keepalives' is option, that noone will like to disable and there was a talk about that in one of the other tickets. This can't be a reason to save trafic: sending ~30 bytes each minute makes ~42Kb trafic for 24 hours! Some avatars are much bigger than that. We can still keep 'send keepalives' in ACE.

[asterix]

I don't like the warning window: Most users don't care about security. And

they will think "yes ok ... and .. What can I do against that ?"

I like Hawke solution, but without the "Use TLS" option (at least in UI), as dkirov said, who wants to disable that ?

so 2 options:
"force old SSL (legacy)" (the old word means there is a new way, so I'll probably read tooltip) which is our current option with additional "old" word
"allow plaintext auth" off by default

and try SSL after TLS and before plain

For keepalive: I disable them (server is local :D ) but you're right, move them in ACE only sounds good

[bb]

well, I don´t know, but who would actually turn "allow plaintext auth"

on? only a very small number of users I presume. I would say; avoid putting it in the config, it would only be a useless option for most users. ACE sounds ok.

You have a point with the thing about users asking themselves what to do about it, for which I believe you should point them to a (wiki?) page that explains what is going on. If a user actually clicks that link you can be pretty sure he knows close to nothing at all about security and in that case some information would be very important for him. or a "help" button. I still favour the warning, since plaintext logins are very uncommon these days and you can have gajim remember never to display them again. Let´s face it; security is a very important matter and MOST users, (especially the ones that would auth over an insecure connection!) use one and the same pass for a lot of things.. I know of enough users that use their jabber password for their ISP, e-mail and computer login account. It sucks, but it´s a fact. I therefore think that if somebody has actually gotten as far as to being about to sending his password plaintext, he should be warned. well. plus; we shouldn´t disregard the increasing amount of wifi usage which makes this option all the more important.

I therefore say: no ui option, a couple of ace options as mentioned above and a warning with a checkbutton to disable future warnings and a link to a page that explains what is going on.

[jim++]

Is there a known reason for which someone wants to force old SSL (legacy)

?

[jim++]

oops

[anonymous]

Yes, there is a reason for which someone wants to force old SSL. Because

some clients only use TLS to encrypt the logon process, but not the ongoing communication (*cough* Gaim *cough*).

BTW when i first used Gajim i also checked the SSL option, because i didn't know it also can use TLS. So if there's an option that will say "allow plaintext auth" i would have known that there was another encryption methode. I don't want to say this is a perfect solution, but you have to make sure that a first time user can be sure his client is using a secure connection and will not fall back to plain text.

[anonymous]

Replying to anonymous:

> Yes, there is a reason for which someone wants to force old SSL. Because some clients only use TLS to encrypt the logon process, but not the ongoing communication (*cough* Gaim *cough*).

then again; we are talking about Gajim, and not other clients.

[jim++]

Replying to anonymous:

> Yes, there is a reason for which someone wants to force old SSL. Because some clients only use TLS to encrypt the logon process, but not the ongoing communication (*cough* Gaim *cough*).

Is this a reason ?

[patrys@…]

+1 for dropping the whole thing and adding a warning:

No secure authentication method could be found for server XYZ

Gajim is about to fall back into plain text login. This is not safe and is prone to credential theft therefore not recommended. Do you still want to continue?

[Log in anyway] [Abort]

[patrys@…]

Ah the checkbox should be there and Abort has to be the default option

(and aligned to the right side of the window).

[asterix]

and a Help button too which open browser to a wiki page.

another question: when we try SSL, we always try on port 5223? what to do to connect to port 443 with SSL ?

first try: TLS on configured port
second try: SSL on port ???
warning
third try: plain on configured port

[<jid:junglecow@…>]

Actually, I suggest adding a separate configuration setting for legacy SSL

port.

Also, there seems to be a strong focus on passwords here, so I'm not sure if you're suggesting to warn only if plaintext authentication over a plain link is negotiated. (I hope not.) It would be good to be able to enforce a fully secured connection (Also at initial account creation).

Currently, we can only force a secure link by selecting legacy SSL, but that's only possible after the account has already been created, and we don't even have a way of knowing whether the account was created securely, other than running a sniffer in parallel.

[asterix]

we want to release 0.12 soon, this is not really release critical

[junglecow]

This whole thing needs to be reworked anyway. I think we should ask the user about their security preference, one of (off, low, normal, high, paranoid), and use good default settings for each of those preferences. The higher the level, the more warning dialogs and configuration options there would be.

[asterix]

those options won't be enought for someone who knows what he does: what does paranoid mode do ?

imho we should default to a quite high security, and then let advanced users do what they want in account modification window, security tab (we'll add it if there are enough option)

[junglecow]

I think we should default to 'normal' mode, where we will use and trust certificates distributed with Gajim, those in the OpenSSL directory, and maybe those from browser too. That should be plenty secure for normal users, and avoid security popups except for some obscure or new servers.

Since all servers I know support SSL, we can probably forbid plain connections at 'normal' level. (Use 'low' for that.) Of course there should be a per-account override in ACE. In fact all such settings should be in ACE, with global 'security level' providing the defaults.

At higher levels, we can ask user to confirm each certificate before it's first used, and check fingerprints too. Maybe not all levels will be needed, but I'll see about that when I get to implementing. It's all in the future now.

First I'll start on fingerprints, since it's easiest to do and needs the least GUI changes.

[junglecow]

My current line of thinking to implement security at this stage is:

• Forbid plain connections to hosts that we have a fingerprint for (either in servers.xml or ACE)
• Grab fingerprint from server at first connect, store in ACE. (Should it be done quietly, or do we want a dialog?)

On mismatch:

• Grab bad fingerprint and store somewhere. (ACE? DB?)
• Disconnect with scary message. (Already done.)
• Inform user about what can be done somehow (how?)
• Expose both good and bad fingerprint in server config. Add button to overwrite old fingerprint with new one. I don't see a reason to add manual entry here; users who need that can use ACE. On the other hand, it may make it much too easy for the average user to ignore security here.
• Maybe we can have a button there which checks/downloads latest servers.xml from gajim's web?

When we made a successful connection:

• In server config, hide fingerprints and button.

Comments?

[asterix]

as user has no way to know if his first connection is really secured, I think store the fingerprint in ACE quietly is better. noobs may not understand what happen

on mismatch:

why should we store the bad fingerprint ? keep it in a var seems enough.
what's the diff between "Inform user about what can be done somehow" and "Add button to overwrite old fingerprint with new one". On mismatch we of course disconnect before auth, and show a dialog: "SSL certificate of your server has changed. Your jabber server admin has maybe updated it, or your connection is listened by someone else. do you want to update the certificate with the new one?"

if yes -> reconnect if not -> do nothing

[junglecow]

Problem is that I'm not sure if it's OK to show a dialog. We don't do that for any kind of connect failure at the moment. You just get a popup for a few seconds, and if you miss it, too bad. That said, I still like this solution.

As for what to do on first connect, ideally the user should get the fingerprint from the server admin, either from a secured web page, secure e-mail or by phone. Also don't forget that fingerprints for public servers will be included with Gajim, so remaining servers are likely to be local or company servers. In these rarer cases it's not so bad to forbid plain connections by default, and ask the user to confirm fingerprint on first connect, which ssh does too.

[asterix]

In this case the problem is not that Gajim can't connect, but that Gajim should ask to user "not secured authentification, are you sure you want to connect" so showing a dialog is not really a pb.

For the first connect pb, I agree with you. if no fingerprint in servers.xml and in ACE, it's the same as mismatch and we should ask the user if he want to use this fingerprint.

[asterix]

see also #3232

[steve-e]

All fingerprint and cert stuff should be discussed in #720. (all comments in this ticket after 11/16/06)

Gajim supports TLS, SSL and plaintext connections and all agree that security starts with the first connection:

• tweak acc create wizard
  • remove password entry from server connection slide
  • add a new slide (we check the server connectivity):
    • "Your server only supports plaintext connections. This is insecure, because someone on the Internet may steal your password. You are advised to go back and select another server." (depends on if we create a new account or just add an existing)
    • "Your server supports secure connections."
      • here we can do stuff for certs/fingerprints. What this actually is can be discussed in #720
      • plaintext auth can be disabled for this account as he supports ssl/tls
• remove "legacy ssl" option from preferences.
  • with the step in the account create wizard we default to the most secure connection
  • those who want to tweak it can use ACE (connection_types = (tls ssl plain))

We have to find a way to run this dialog for people who already use a previous gajim version.

[pourriel@…]

What about using a checkbox to set "I want to encrypt" Y/N, whatever it deals with and another checkbox to tell what options for encryption I need? So the port (ex 443) would not decide alone when to encrypt or not.

[asterix]

I prefer a "allow plain text connection", cause with yours we can check it and be connected unencrypted.

443 is not dedicated to SSL, if a server listens on 443 without SSL, Gajim will discover that with SRV, or you can enter this port number manualy.

[bronger]

I find the current error message confusing if a root certificate is missing. Gajim asks whether to add the server cert to the list of known certs, and I think most users would expect that this removes the problem. However, the root cert is still missing after all, so the popup comes again, and if the user puts again a tic in the checkbox, the certs is appended a second time to the .pem file. In the worst case, you have dozens of duplicated in the .pem file and a slighly irritated user.

[asterix]

hmmm what is the exact message you get? the second one should not be that cert is missing ...

[steve-e]

There was an error verifying the SSL certificate of your jabber server: The authenticity of the myJabberServer.foo certificate could be invalid.
SSL Error: Unable to verify the first certificate
Do you still want to connect to this server?

[bronger]

Yes, steve-e, this is the message. Then, you can add the server cert to the cacerts.pem file by activating the checkbox. However, this is not sensible in my opinion for two reasons:

a) the root certificate (may be even more than one) is still missing, so it will fail again when connecting the next time.

b) the server cert shouldn't be in cacerts.pem because it may change (happened to jabber.org two days ago) which causes confusion. Besides, it is not necessary to put the server cert in cacerts.pem; the root certificate is totally sufficient because you trust in it.

[asterix]

see answer  there

[asterix]

We have to come to a solution so we can implement it. What about that:

Nothing in GUI.

1. Try TLS on port discovered by SRV (or use custom host/port)
2. Try SLL on port discovered by SRV (or use custom host/port)
3. Warn user that connection is not secured with a checkbutton to not be warned
4. Connect insecurely

2 ACE options for each account:

• "force_connection_type" that can be None (default), TLS, SSL, PLAIN: will do only one step of the above list.
• "allow_plain_connection": If False (default) do step 3 of the above list, if True, skip it.

[steve-e]

I think your solution is a good step in the right direction.

Nothing in GUI

When we add nothing to GUI, we have the problem that a new user will not no about whether gajim will use TLS/SSL or just PLAIN. Therefor I suggest to add the Allow_Plain_connection option to GUI. Nobody will want to disable but he will be sure that he is connected over a secured connection. (Accounts window and Account Wizard)

Warn user that connection is not secured with a checkbox to not be warned

I like the following dialog.

'''No secure authentication method could be found for server XYZ'''

''Gajim is about to fall back into plain text login. This is not safe and
is prone to credential theft therefore not recommended. Do you still want
to continue?''

 [Checkbox] Do not ask me Again
 [Log in anyway] [Abort]

For Account Create Wizzard I like the following solution:

Tweak Acc Create Wizard
  o remove password entry from server connection slide
  o add a new slide (we check the server connectivity):
    - "Your server only supports plaintext connections. This is insecure, because
 someone on the Internet may steal your password. You are advised to go back and select another server." 
u(depends on if we create a new account or just add an existing)

For ACE, what about the following scheme which offers some flexibility: We try all connection types in the tupel. Default would be (tls sll).

connection_types = (tls ssl plain)) 

[asterix]

there are strange things:

I uncheck allow plain text connection, but I can be asked if I want to connect plain text ... I already unchecked the option!

What about naming this option "warn when connection is not secured"

That would also fix another strange thing: I unchecked allow_plaintext_conn and there in plain in connection types.

For the wizard, I'm ok to add the slide if connection is not secured, but I don't understand the first point (remove password): we'll show the server form only if connection is secured (or user accepted to connection insecurely)

and I like your syntax connection_types = tls ssl plain (without parenthesis)

[steve-e]

Yep, I agree.

+1

[asterix]

(In [6814fc52ad00612197c3defb01f7f7069c2e0154]) add checkbutton to YesNoDialog?. Ability to fall back from tls to ssl and then plain. Warn user when using insecure connection. fixes #1923