Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for manual certificate verification #452

Open
muchweb opened this issue Nov 12, 2018 · 13 comments
Open

Add support for manual certificate verification #452

muchweb opened this issue Nov 12, 2018 · 13 comments

Comments

@muchweb
Copy link

@muchweb muchweb commented Nov 12, 2018

Users should have freedom to skip security measures that are enabled by default in Dino.

Proposed user flow:

  1. User tries to log in;
  2. SSL error happens, which disables user account;
  3. User may navigate to 'Accounts' dialogue;
  4. User may view error details, with possibility ignore it once (until next launch of Dino).

Proposed UI
screenshot


This is how other clients handle this:

Pidgin

pidgin

Conversations
conversations

Gajim
gajim

Jitsi
jitsi


badge

@licaon-kter

This comment has been minimized.

Copy link
Contributor

@licaon-kter licaon-kter commented Nov 12, 2018

Did you build Dino today?

@muchweb

This comment has been minimized.

Copy link
Author

@muchweb muchweb commented Nov 12, 2018

No, should I?

@licaon-kter

This comment has been minimized.

Copy link
Contributor

@licaon-kter licaon-kter commented Nov 12, 2018

@muchweb yup

@muchweb

This comment has been minimized.

Copy link
Author

@muchweb muchweb commented Nov 12, 2018

@licaon-kter I am still getting Invalid TLS certificate message in Accounts (Error: TlsError: Unacceptable TLS certificate in terminal) with no option for adding an exception.

@licaon-kter

This comment has been minimized.

Copy link
Contributor

@licaon-kter licaon-kter commented Nov 12, 2018

Oh, I'm...sorry...I thought you need OMEMO fingerprint....

No, this is not implemented and I'm not sure it will ever be.

See #209

/close as duplicate #57

@muchweb

This comment has been minimized.

Copy link
Author

@muchweb muchweb commented Nov 12, 2018

Solution that is proposed in #209 is only a temporary fix that requires change of local alias and does not provide a UI to check certificate. #57 does not discuss a solution

@the-metalgamer

This comment has been minimized.

Copy link
Contributor

@the-metalgamer the-metalgamer commented Nov 16, 2018

I would much rather see this solution implemented than #57 . Maybe even add a switch in configuration window to enable this feature

@nifker

This comment has been minimized.

Copy link

@nifker nifker commented Mar 1, 2019

@licaon-kter why would you not implement this feature?

@licaon-kter

This comment has been minimized.

Copy link
Contributor

@licaon-kter licaon-kter commented Mar 1, 2019

@nifker read those issues linked above...

@tsyrya

This comment has been minimized.

Copy link

@tsyrya tsyrya commented Oct 11, 2019

Please, add this feature. Can't use the app because of that

@mightyBroccoli

This comment has been minimized.

Copy link

@mightyBroccoli mightyBroccoli commented Oct 11, 2019

Valid certificates aren't that hard to get and for small local instances you could verify the certificate locally.
There is no real benefit with this.

@tsyrya

This comment has been minimized.

Copy link

@tsyrya tsyrya commented Oct 11, 2019

It is not hard, it is just that in my organization there are not valid certificates and no one will make or get one. That's why we have to use our old one.
I can't see any reason why you can't add an option to trust the certificate.

@danwizard208

This comment has been minimized.

Copy link

@danwizard208 danwizard208 commented Dec 16, 2019

I don't accept the argument "LetsEncrypt makes getting valid certificates easy, so we shouldn't let users override invalid certificates". Unix philosophy has always been to let users who know what they're doing (and ones that don't!) force through anyway - that's what typical -f is for.
If the argument is "it would take significant dev time to implement the override and only a handful of users will benefit" I'm more receptive.

In my particular use case, I have a friend who self-signs the cert for their server, which I've been manually accepting in pidgin for years. I can't use dino to talk to them, at my own risk, because dino is making a security choice for me. As a result I can't use dino. Which is a shame, it looked like it might be my im client of choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.