jakob / Postico

Public issue tracking for Postico
https://eggerapps.at/postico/
475 stars 9 forks source link

Turn off warning about Connect without Encryption from Preferences #50

Open geirnoklebye opened 9 years ago

geirnoklebye commented 9 years ago

Could you please make a Preferences or per connection tickoff to NOT receive the "Connect without Encryption" warning for every connect. In the end it gets tiresome to press the Connect button every time. We already know we are connecting to a server without SSL. :-)

Thanks for the great effort you put into this app.

jakob commented 9 years ago

Making insecure connections inconvenient is the whole point of this dialog. I strongly believe that software should be secure by default, and it should be hard to do dangerous things (like connecting with an unencrypted connection).

Is there a reason why you don't want to set up SSL or SSH on the server?

geirnoklebye commented 9 years ago
  1. Because the software that use the databases don't support it.
  2. Because the connection happens behind a firewall that does not allow any PostgreSQL connections through.
  3. Because the database can only be access by a very limited number of IP addresses.
jakob commented 9 years ago

Hmm, I'm not sure I understand.

  1. You can configure your PostgreSQL server to allow both unencrypted and encrypted connections. Then the legacy software can connect without encryption, and Postico can connect with encryption.
  2. If the SSH server is on the same host as the PostgreSQL database, and you put "localhost" into the "host" field, Postico will not show the unencrypted connection warning.
geirnoklebye commented 9 years ago

Never mind, it was just a request to skip an annoying reminder. I use Navicat most of the time anyway

jakob commented 9 years ago

OK. Thanks for the feedback!

qwesda commented 7 years ago

I also have a few problems with the nag-dialog and the reasoning behind it:

1) the connection I make to our main postgres sever uses neither ssl nor ssh (as far as postico knows anyway). Rather it goes through an ipsec-tunnel or a sshuttle pseudo-vpn, i.e. the server is not publicly accessible nor is the traffic that goes over the network.

2) the nag-dialog box becomes very frustrating when I re-open a window with multiple tabs - since every tab presents the same dialog box. Having to click it once is already not great, but this makes it terrible.

3) while postico can check two indicators for the security of the connection, they are neither necessary nor sufficient indicators. They could use weak crypto algorithms, or could come from non-trustworthy sources. It is probably not possible to determine the security/safety of the setup from within the app. I would be fine with a dialog box that made a warning about what looks to be an unprotected connection - but there should be a check box that (in the unforgettable words of Sledge Hammer) says: "Trust me I know what I'm doing".

4) I really don't believe that the people, that should take this warning to heart, will be reached by it. Firstly: the capacity for mindlessly clicking away warning dialogs when opening apps is astoundingly high. Secondly: annoying people is not a good way of education.

In conclusion: have a dialog box that presents a warning once.

And if you really want to nudge people to have a better setup: have a link in the dialog box that explains why an unsecured connection is bad and lists some good resources for securing a connection. The people that will click through to this document are the only ones you can ever hope to make a better choice.

jakob commented 7 years ago

I agree that showing multiple warnings for multiple windows/tabs is stupid. This is something I can fix. Clicking ‘Allow’ once should be sufficient.

The problem with showing the warning only once is the following: 1) Assume the user is on a secure network 2) the user connects to the database, and postico shows a warning 3) since the user is on a secure network, he clicks “don’t warn again” 4) the user goes to a coffeeshop, connects to the wifi to check their email, and Postico in the background reconnects to the server for some reason, blissfully unaware that the network is anything but secure

Both TLS and SSH protect against this kind of issue.

Maybe Postico should remember whether to allow unencrypted connections per network — that would also help against “warning fatigue” (warning is much more likely to be read if it doesn’t show every time).

Not sure how to identify the “network” Postico is on (would external IP/domain be a good idea?)

geirnoklebye commented 7 years ago

The thing is you cannot babysit your users. For an application like Postico you have to make the assumption most users know what they do and where they use the application.

Also, outside your regular (office) environment, most users will be on some type of VPN or ssh tunnel when accessing a remote database directly.

qwesda commented 7 years ago

You could maybe try to get the mac address of the router. External IP is bad for all environments where the uplink gets a dynamic ip.

qwesda commented 7 years ago

I'm not sure how you could detect if the connection goes though a tunnel independently of postico. Your example seem to only apply to pg services who have their port publicly accessible - which is already not a great idea. You could try to reach it from a server you host separately, and only show the dialog, if you can reach the service from there. But I think this is a bad idea for many reasons.

Another thing is, that it might be completely out of the control of the postico user to do anything about how the service is hosted. I guess your audience is mostly compromised of programmers. Even in pretty small firms/project the roles of programmers and sysadmins tend to be separated and only the later will have in say in how the thing is hosted/configured. (And sysadmins typically shun any kind of GUI ...)

jakob commented 7 years ago

For the sake of this feature, it doesn't matter at all if the PostgreSQL server is only accessible from a private network. If Postico allows clear text connections, it is vulnerable to someone impersonating the server.

This is especially important when Postico auto-connects to the server (eg. when restoring windows). The user might just open Postico to connect to the local development database, not aware that Postico will restore windows that auto-connect to the company server.

If this happens on an insecure network, an attacker could host a fake PostgreSQL server that accepts all connection attempts and requests a clear text password, and then respond with an error message that reads "host not found". Then Postico would have leaked passwords and the user wouldn't even be aware of it.

A possible solution would be to disable window restoration or automatic connection attempts for unencrypted/unauthenticated connections.

Also @geirnoklebye, this is not about babysitting users. Unlike a babysitter, Postico will not prevent people from shooting themselves in the foot. Feel free to just click "connect" and ignore the issue. But Postico must show a warning before accidentally transmitting credentials in clear text over a public network.

I know that 99% of PostgreSQL clients are configured to allow plain text connections by default, without any indication that you are vulnerable. I think this is very dangerous.

Consider what happens when the host key of a SSH server changes. OpenSSH will refuse to connect to it. This is extremely inconvenient to people who often re-install the OS on their servers. Why can't we just disable the host key check?

Or web browsers. Why have browsers started to show warnings before transmitting passwords in the clear over unencrypted HTTP? Why can't site operators or users just disable that warning?

The more I think about it, the more I am convinced that showing the warning every time is actually necessary. Yes, it is possible to secure the connection outside of Postico. But without a TLS certificate or a SSH host key, Postico will have to trust the user. And unfortunately the user will not spend enough time thinking about the implications before checking a "do not warn again" checkbox.

geirnoklebye commented 7 years ago

Unlike a babysitter, Postico will not prevent people from shooting themselves in the foot.

Which you do by issuing the warning on first connect (or until the user turns off the warnings, whichever comes first.) By providing an option to turn the warnings off, you are off the hook and the user is in charge to make informed decisions for themselves.

vincent-dm commented 6 years ago

Hi @jakob,

I would also like the possibility to disable this warning, and I think my reasons are new to this thread, and can hopefully convince you.

You write:

Making insecure connections inconvenient is the whole point of this dialog. I strongly believe that software should be secure by default, and it should be hard to do dangerous things [...]

I agree with your intention, but enforcing the dialog on every non-SSL connect leads to a lot of false positives.

For me personally, 90% of my Postico usage is on a dev database (without any sensitive data inside of it), running within my machine on a Minikube VM (connection uses a.local hostname). I honestly can't see how adding SSL to this local connection would improve my security. Nevertheless, Postico still requires me to click away this annoying warning every time I start interacting with my local database.

But if you take a more holistic perspective about the usability aspect and general human psychology, I would argue that your current policy of always showing the warning, actually reduces overall security. After all, every time Postico forces me to click the dialog away for a local connection, Postico is actually conditioning me to ignore this dialog.

I presume you also believe in the relevance of conditioning, because for the SSL dialog you chose to make the Cancel button blue. You rightly assume that users are conditioned to click the primary button, so you applied it to the safe option.

Wouldn't it then be more consistent to provide a setting somewhere to selectively remove the warning? It would help reduce false positives, thus ultimately safeguarding the attention-grabbing effect of your dialog.

If I ever need to work with a database which is exposed directly to the internet, I'm pretty sure the nagging dialog will not be the thing that triggers me to secure it. After seeing it so many times, I am by now trained to click the white Connect button to get the reward of working with your awesome GUI.

I understand that there is a trade-off between security and convenience. Therefore I propose adding an option do disable the warning per favorite. And to further secure it, you might only allow disabling it after having shown it x times.

I'm curious about your thoughts.

Thanks!

jakob commented 6 years ago

@vincent-dm

I agree that adding SSL/TLS to local connections adds very little security (if attackers can intercept local communications, they most likely already completely compromised your system).

The difficulty that I face in Postico is that it is not trivial to determine if a connection is local or not. Currently I check for a few patterns (eg. localhost, ::1, or 127.x.x.x), and if the database host name matches, I don't show the plain text warning.

.local hostnames are usually Bonjour/Zeroconf hostnames, so they are probably on the local network, and I can't assume that the local network is safe.

So maybe I could do a DNS lookup, and if the host name resolves to a single local address, I can disable the plain text warning.

I don't want to allow disabling the warning per favorite. I've tried to explain in my previous comment, but maybe I wasn't clear enough. Here's one scenario I worry about:

1) User is on a secure network and disables the plain text warning when connecting to production.local.

2) User moves to a different network

3) Postico tries to automatically re-connect to production.local

4) An attacker on the different network intercepts the DNS query and pretends to be production.local

5) The attacker requests a clear text password

6) Postico will happily provide the clear text password because you disabled the warning about plain text connections

Allowing plain text connections is dangerous, and I really want to discourage it.

It takes about 5 minutes to configure your PostgreSQL server with a self-signed SSL cert, which you can then mark as trusted in Postico, and you'll be safe from attacks like this.

vincent-dm commented 6 years ago

@jakob Ok, I understand your reasoning, and appreciate you taking the time to explain it so thoroughly.

kevinastone commented 3 years ago

This insecure connection nag is annoying. After the first notice, I'm aware that I'm using an insecure connection ("✅ don't remind me again"). I'm currently trying out Postico, but wouldn't be comfortable paying for a license with such a constant nag in my daily routine.

geirnoklebye commented 3 years ago

Yeah. I have stopped using Postico all together because of it, and move on to other products – which happens to cost a lot more than this one. The loss is on the developer.