Changes to Inthe.AM certificate acceptance policy

[bradyt]

I noticed a recent Reddit post where a user asks if taskd.credentials is private information. They determined it was fine, since a search for inthe_am on GitHub reveals many people posting their taskd.credentials on GitHub. I tried creating a Reddit account to share my opinion on the matter, but I could not because Reddit hides comments from new accounts.

The user feels that since they haven't shared their PEM files, their todo list is private. I believe this is incorrect. Anyone can use their inthe.am PEM files combined with another person's credentials to access the other person's todo list.

I would suggest that, since inthe.am is used by a number of Taskwarrior users that might not otherwise understand such details of Taskserver, that inthe.am prominently instruct users in the configuration screen, that the credentials, especially the credentials key and to some extent the credentials user, are sensitive information. And that keeping the PEM files secret would do little to prevent someone from using the credentials to access a todo list.

[coddingtonbear]

Well, good news -- I was sort of worried about this possibility & a long time ago made some modifications to taskd and our interactions with it such that it'll validate that you're handing it exactly the certificate you were given and that that certificate is associated with your account. At the moment, it's just an experimental feature; so it's not actually rejecting unexpected certificates -- we weren't historically always recording their fingerprint, but I'll turn that on this weekend if I can find a few minutes.

Thanks for the heads-up, @bradyt!

[coddingtonbear]

Actually -- it occurred to me that it's probably too risky to let that wait at all; so I just made myself a little late and instead just turned on this feature in e7c6829bf5c6b381cf3e199af5093d3bb20442fa (see https://github.com/coddingtonbear/taskserver/commit/836916c64bed496dffbd645c65212df3f5fb708b for details).

This probably won't affect anybody, but if you are a user that runs into a problem interacting with your task list, re-download your certificate from Inthe.AM and you should be back on the right track.

[bradyt]

That's great, thank you! Can you ping thread when you expect that to propagate and prevent the "unauthorized access"?

[coddingtonbear]

Well, I hope it's already doing that now, but there are some caveats -- the backfill process relied on generating & storing fingerprints for certificates users were using during synchronization. So: if somebody were to have been accessing somebody else's task list before a half hour ago, the certificate they used for that illicit access would continue to be accepted because we assumed that the user was legitimate since they gave us information that should have been treated as private along with the certificate. Unfortunately, there's no existing UI for clearing those certificates (that's really the reason this wasn't a released feature yet); so if that's a concern anybody has, they'll have to delete & re-create their account to get back to solid ground again.

[bradyt]

I believe I'm still seeing incorrect client certificate working with never before visited taskd.credentials. If that adds information to what I think you're saying.

[coddingtonbear]

I'm not sure offhand why that might be, but I'm afraid I'm out of time for now. Maybe you can find a flaw in the logic from the linked sources above?

What you might be able to do to help things is collect a list of any account names you have seen with exposed credentials so I can revoke their certificates once I have a little time. Obviously, it would be irresponsible to post that to a public thread like this, but you know my e-mail.

[bradyt]

I've sent a link to the list in an email to you.

Apologies, I'm not familiar with the Taskserver codebase, so I most likely can't help look for flaws by reading the code.

[coddingtonbear]

I spent a few minutes double-checking the property file and found the problem: I had misspelled the configuration setting (see 876d7c357aff09b9810fa518f569f2bcf92e1c03).

[coddingtonbear]

& I've brought up a new version of the taskd server & see that it's rejecting some certificates...unfortunately most commonly from the monitoring bot:

taskd_1           | 2022-02-27 01:21:51 [1] 'sync' from 'inthe_am/nagios' using 'task 2.6.0' at 172.18.0.1:44764
taskd_1           | 2022-02-27 01:21:51 [1] Certificate fingerprint: 'db19bc1bf76335c03b43d31068c323e3697fd6e896e16ed984c11dee48a8f621be3ac977f666c96ed54e904d36051ae62aa7b14cd8ff88571bd9566761100eb7'
taskd_1           | 2022-02-27 01:21:51 [1] Certificate not recognized and rejected; set 'inthe_am.reject_unrecognized_certificates' to 'off' to accept in the future.
taskd_1           | 2022-02-27 01:21:51 [1] Emitting notification to redis via taskd.certificate.nagios
taskd_1           | 2022-02-27 01:21:51 [1] The certificate you provided is not acceptable.
taskd_1           | 2022-02-27 01:21:51 [1] Serviced in 0.172787s

[bradyt]

Beautiful, in the last few minutes, the sync response has changed to this:

Sync failed.  The Taskserver returned error: 500 The certificate you provided is not acceptable.