[Users] [Bug 2738] Erroneous rotation of SSL certificates
noreply at thewildbeast.co.uk
noreply at thewildbeast.co.uk
Fri Sep 28 15:22:02 CEST 2012
--- Comment #16 from IgnorantGuru 2012-09-28 15:22:02 ---
> Actually, the solution Brad pointed out is spot-on as it was implemented
> precisely to deal with GMail's issue. See manual for its description. It was
> initially named "multiple_ssl_certs" and got renamed because storing multiple
> certificates for one host is actually unsafe, as has been pointed out.
> Read the manual for a precise description of that option, and to know whether
> or not is applies to the current situation.
> So we did consider that issue, we did work on it to provide a solution, it is
> documented, all of these happened a few years ago and that is why I just closed
> your bug report.
Thanks for the genuine reply. If this is such a well-known issue, your initial
reply could have been more helpful - perhaps a link to (or even mention of) a
known solution or help page instead of a warning not to reopen the issue
because it would be ignored anyway.
You say Brad is spot-on, but he says:
> Claws has a mechanism that allows you to silently accept certs...
> Some consider this to be unwise, since it could allow bogus certs to be
> accepted silently.
Doesn't sound very encouraging - it makes it sound like Claws will no longer
prompt when a new certificate is encountered, which is not what I want. Nor is
the one line in the manual on this helpful - it doesn't define the behavioral
change that this option entails, it doesn't mention any potential use for the
option, and it doesn't mention GMail or the cert rotation issue. It's instead
about as brief and mysterious as it could be.
So does this option silently accept all certs, silently accept only signed
certs, silently accept only certs that have already been previously approved by
the user (what I want), etc? What exactly does it do? And why exactly is it
considered unsafe? What are the ramifications of enabling it and what
potential exploits does it open? If you're suggesting I enable something
labeled 'unsafe' to correct your UI problem, you could at least document it. I
still don't see why using a cert that's I've explicitly accepted is a problem.
The only difference is that for a brief period there are two valid and
*user-accepted* keys for the same server. So what?
Further, it's buried in hidden preferences. I think a simple option on the
Accept dialog that says 'Accept both of these certificates and don't ask me
again' would be a much more user-friendly solution. Or a custom dialog could
be displayed which explains that it appears a key is merely being changed and
giving the user a few options to prevent the wildly repetitive behavior Claws
currently exhibits. It is a GUI app, after all.
So if you addressed this issue already, it doesn't appear you have addressed it
very effectively, in the GUI or in the docs.
It's obvious a lot of work went into Claws, and I often describe it to others
as an example of how stable and functional Linux apps can be. I was surprised
to find the dev team so dysfunctional for a simple issue. I don't think this
issue is the end of the world. I merely wanted to bring it to your attention
(including the fact that however you think you have handled it, it's not very
effective for the user encountering the problem). The replies I received to a
simple bug report were rude, defensive, etc. I still think you have an
unresolved usability issue (which is why you're still hearing about it). You
can deny that with whatever arguments you want, but results speak.
As for standards and their inevitable extensions, it's always a tricky issue,
but comparing what Microsoft did with IE to this issue is a bit of a stretch.
If you feel it's a genuine security problem (despite the user examining and
approving both keys explicitly), then I think a more user-friendly solution is
all the more indicated, since the default behavior creates confusing and thus
Configure bugmail: http://www.thewildbeast.co.uk/claws-mail/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the Users