Anytime gmail changes its ssl cert, for at least several days claws-mail will keep asking me to accept the new cert, then accept the old one, then the new one, etc. on each retrieval. This is detailed here: https://productforums.google.com/forum/#!topic/gmail/vbDcgtDcfyw This problem existed last year too. Their servers sometimes return the old cert and sometimes the new (for several days, according to the above link). If claws-mail already has a newer cert, it should use that instead of attempting to replace it with the older one.
Claws warns each time a certificate changes. It is abnormal for a server (farm or not) with a single DNS name to present different certificates at each connection. (Please do not reopen, this would not change the answer). Sorry I couldn't read your link, it requires a login.
The link doesn't require a login - not sure why you're getting that. You could search google for "Each receive of mail (claws-mail) results in rotation of 2 SSL certificates". It's fine that claws reports changes, but when a newer cert replaces an older one, then the old one appears on some connections, it doesn't look like it should be changed again. If the largest email provider is doing this regularly for years, it's not "abnormal", but normal (however incorrect or inconvenient), so I don't think just ignoring the problem is helpful - best to work from reality. Most other clients seem to handle this gracefully based on that discussion. In case you still can't find that page, here was google's response: > As you can see, the expiration date on the old certificate is fast approaching (4/22/2011), so we had to update our certificates to new ones. > > All production changes of this type are canaried, ie rolled out first to a small percentage of our servers. These canaries usually run for 3-5 days before being rolled out to the rest of the servers. > > Its unfortunate that your client doesn't like to see rotating certs, though. You're going to see this issue every year or two, since we have to renew the certificates that often. If you can, I'd talk to the developers of the client and see if they'd move to a model of permanently accepting a certificate instead of objecting every time there's a switch.
Claws has a mechanism that allows you to silently accept certs. Shut down CM, then edit clawsrc, changing unsafe_ssl_certs=0 to unsafe_ssl_certs=1 which then allows CM to save multiple certs for circumstances like this. Some consider this to be unwise, since it could allow bogus certs to be accepted silently. The choice, of course, is yours.
That's a poor workaround which doesn't apply to this situation. Frankly, you seem to just want to avoid doing any work, so you instantly close a bug report without examining the situation or giving time for further input. But I know it's fun to close bug reports without doing any work. Next time I'll know to not bother wasting my time reporting a serious usability issue with your client. Thanks.
Frankly, the bug report was not just closed "without examining the situation or giving time for further input". This is not a new issue, it is not the first time we've heard about it, you did not tell us something new. I know that it's fun to open bug reports without doing any work in the first place to find out if the issue has already been reported or is known about, or has even been dealt with previously. IMO, the certificate that the server issues is the one that should be taken notice of. It would be wrong to assume that the server has made an error (or something) because a previous certificate from it had a different, newer date. To be fair, you gave us a clue with your login name, so I can't criticise you for getting your ideas of our intent a little mixed up.
I'm not on the dev team, just a user of CM that reads bug reports via the mailing list. I offered a suggestion.
I searched and didn't find any open bug reports on this, just users complaining, so I submitted one. Now I understand why that is - you just keep closing them. If you keep hearing about an issue, it's because you're not addressing the problem in any reasonable way. If you want to ignore it, that's your choice, but my suggestion is don't mark it as 'resolved' when you haven't resolved it at all. Just leave it open until someone is actually willing to work on it, so others can see it's a known problem. Or, expect more reports just like this one. You could at least keep the new cert for the current session. Or provide some kind of an option specifically for this, since obviously your client handles the situation poorly. You can complain that the situation is not what you want it to be, but that's just ignoring reality, which never makes for good software. I see this a lot - closing a bug just to get rid of it. I think it disrespects the users who take the time to report issues. Regardless, thanks for what is usually a good app. I expected a genuinely responsive dev team because of this - instead I got the usual 'just mark it resolved so I don't have to deal with it' response. News flash: you have an UNresolved issue here - that's why you keep hearing about it.
well, thanks for the advice...
A few other thoughts on this, in case anyone is actually willing to consider them without resorting to personal attacks. Claws is unusual in that it asks the user to approve a cert ("Accept & Save"), rather than verifying the sig and using it. Fine, nice feature. But the way it's implemented is erroneous in that I already accepted and saved this newer cert. Yet it keeps prompting me to accept it over and over again, even though I have done so. That's the core of the problem, and why it makes Claws behavior look stupid. Accept means accept - don't ask me again. Apparently the only way to avoid this annoying behavior at present is to disable the 'accept' feature entirely and accept certs silently (thanks for the suggestion regardless, Brad Rogers). Because of UI deficiency, you're forcing the user to lessen their security settings just to have a functional app, which does not make for good security. Surely there is some way that Claws could handle this more gracefully for the user beyond asking the very same question over and over and over again, but instead the issue is disregarded because the dev feels google's server is "abnormal". Try taking a look at the behavior of your own app in this situation if you want to see "abnormal". That's the job of an email client - managing the underlying issues in a reasonable way for the user. Claws fails in this area due to an incomplete implementation of the 'Accept & Save' feature. I'm no fan of Google and I don't defend everything they do, but here I don't think they're doing anything so unreasonable. Google isn't going to change to accommodate Claws, but Claws can adapt in the case, for the sake of Claws users, without jeopardizing security at all (in fact improving it since the current suggestion seems to be 'silently accept everything'). This is a simple UI failure, but perhaps due to some resentment toward GMail by the Claws devs, they refuse to address the problem. I think there is an intelligent and simple way for Claws to handle this situation gracefully, but it's being ignored for the sake of egos.
Also meant to mention: Perhaps the solution could be as simple as retaining the current and previous cert for the server (I accepted both, so both should be considered valid for use until expired, and no further prompt should be necessary). Or, retain all accepted certs until expired, so I don't have to tell Claws repeatedly that it's accepted. It's really just a lack of memory here for what's 'accepted'.
I too am just a user... but Colin gave you the answer in the very first comment above. Let's parse it together... > Claws warns each time a certificate changes. Your comments indicate you are aware of this. > It is abnormal as in "not normal", "wrong", "non-compliant"... > for a server (farm or not) multiple machines (or just one) > with a single DNS name with just "gmail.com", not gmail2.com, gmail3.com, etc... > to present different certificates at each connection. are starting to see the real problem? In case... each time you check mail, you are likely hitting a different machine at gmail.com, all of which are not certificate-synched. That said; Google feels that the problem is due to the date/time in your computer... any chance it's off by a few minutes? http://support.google.com/mail/bin/answer.py?hl=en&answer=63590 HTH
> I have done so. That's the core of the problem, and why it makes Claws > behavior look stupid. Accept means accept - don't ask me again. The SSL specifications stipulate that a socket (combination of IP address and port) have exactly one valid SSL certificate associated with it. Google's procedure for distributing new SSL certificates results in sockets presenting multiple different SSL certificates. Google is wrong. Claws Mail is correct in barking about it. Even though it may look stupid to you it is the correct behavior according to the SSL specifications.
> Google is wrong. Claws Mail is correct in barking about it. Even though it may > look stupid to you it is the correct behavior according to the SSL > specifications. Thanks for your reply. The specs say something about how to inform the user, do they? Very thorough specs. If what you say about the specs is correct, that doesn't mean Claws behavior to the user is 'correct'. If it wants to bark about it, it should do so in a functional way which enhances security and is usable. What it displays (again and again and again) is not a warning, it is a dialog asking you to accept a cert, accept a cert, accept a cert, accept a cert, accept a cert, and to compare information, compare information, compare information, compare information, compare information. What do you think happens when the user is shown this a few hundred times? It's effectively a large number of false positive warnings, which reduces security (not to mention driving users to disable it entirely). This is what you call 'correct behavior'? I call it an unrefined and underdeveloped interface. Further, we all know 'specs' are not the final word and are always growing and adapting to new uses before the spec writers catch up to reality (which they never do). Other mail clients have adapted to this 'new normal'. Two keys having an overlap period of validity when being changed is not exactly unheard of. (Or if not exactly 'valid', at least recognize what is happening with some intelligence.) Google represents a new scale of mail server. If I ran something that large, I might fly a few canaries too. Adaptation to reality and common use rather than just specs is always necessary, at least if you want software that behaves anywhere near reasonably. To put it another way, if the developer's mail server showed this problem, the fix would be mighty quick, regardless of any 'specs' getting in the way of that, I assure you. No developer would tolerate this behavior - or at least no developer that knows what a quality app looks like. This is just a lack of will. If I can see what's happening in these repeated and repeated and repeated and repeated and repeated and repeated dialogs, Claws could be made smart enough to see what's happening. It would nice and much more effective to be informed of the key change - once. Like I said, this is merely a bit of lack of memory and intelligence. It's not a tough technical problem, there is simply no will to correct it. I accepted the cert - it's not expired, revoked, the sig is good - I don't need to be asked again. Defending the current behavior that the user sees is simply ridiculous, and even more so by quoting SSL specs (I suspect you haven't even seen it or you'd be embarrassed to defend it). If the devs don't want to be bothered to fix this obvious but limited problem, just have the nerve to say that, or leave it open. This discussion is obviously not worth continuing since there is simply no will to even acknowledge the problem honestly. Not everything is a technical problem.
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. Hope this helps.
Three more things before I'm done ranting: > Google isn't going to change to accommodate Claws, but Claws can > adapt in the case We heard that a few times before, and doesn't it sound a lot like what web browers implementors and web site designers have had to do in order to deal with "Microsoft isn't going to change Internet Explorer so we better adapt" ? If you know a bit about web development, you probably know where it lead : a decade of incompatibilities and multiple implementations to work around browser bugs. Hell for web developers. Standards are there for a reason and it is not to annoy users. > Also meant to mention: Perhaps the solution could be as simple as > retaining the current and previous cert for the server (I accepted > both, so both should be considered valid for use until expired, and > no further prompt should be necessary). Or, retain all accepted > certs until expired, so I don't have to tell Claws repeatedly that > it's accepted. It's really just a lack of memory here for what's > 'accepted'. Which is exactly what unsafe_ssl_certs=1 does: unsafe_ssl_certs Allows Claws to remember multiple SSL certificates for a given server/port. This is disabled by default. > But I know it's fun to close bug reports without doing any work Almost everybody involved in this bug report thread has been around since 2002 or even earlier. Some put hundreds of personal hours into code, others into helping new users on the mailing-list or bugzilla. Don't get surprised if you get harsh answers after dismissing that.
> 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 unsafe use.
Yes, Brad was spot-on on the option to use, but it's true that he mostly described the skip_ssl_check option :) Accepting and saving multiple certificates for a single host is less safe in the following way (quoting ratinox at gweep.net on the ML): > 'correct'. If it wants to bark about it, it should do so in a > functional way which enhances security and is usable. What it Automatically accepting multiple certificates for a socket is a security risk. For example, a certificate obtained from a compromised CA can be used in MITM attacks. DigiNotar revealed last year that it was tricked into issuing a valid wild card SSL cert for Google. Prior to that, Comodo revealed that it had been tricked into issuing valid certificates for Google, Yahoo and Skype. From an algorithmic perspective there is no difference between Google's "rotating" of SSL certificates and a third party MITM attack using a valid but illegal certificate on a spoofed IP. The trust chains link back to valid CAs and valid signatures. The only reliable way to determine a certificate's authenticity is using the Mark I Eyeball to compare certificates to known and verified goods every time the certificates change. Anything else leaves your accounts silently vulnerable to MITM attacks. Also, further discussion on the subject would be more in-place on the mailing-list than on Bugzilla.
>If you're suggesting I enable something labeled 'unsafe' to correct >your UI problem No, we're suggesting that you can use an unsafe method of dealing with Google's inadequate SSL certificate setup. Complain at them if you want this fixed. If you're not happy with the manual, then feel free to edit it and submit changes to the FAQ and for inclusion in the full manual. Nothing in this world is perfect, I suspect you will find that other MUAs that do not notice this issue are potentially less secure than Claws. At least it gives you the chance to see that bad things are going on, in my book that includes Google acting stupidly.