Skip to content
This repository has been archived by the owner on Dec 12, 2021. It is now read-only.

Santa Client Certificate Authentication #31

Open
thehesiod opened this issue Oct 26, 2018 · 8 comments
Open

Santa Client Certificate Authentication #31

thehesiod opened this issue Oct 26, 2018 · 8 comments

Comments

@thehesiod
Copy link

so per the santa docs, the way one is supposed to lock down santad<->upvote communication is via server based client certificate auth. Unfortunately, after looking at ValidateClient, it seems some sort of header token auth is instead expected by upvote.

I looked a little bit into implementing client certificate auth however it seems webapp2 does not support this, nor does the GAE environment in general. What method of santa<->upvote auth do the authors of upvote expect end-users to implement to be secure?

@thehesiod
Copy link
Author

btw I'm going forward with a variation of http signatures: https://tools.ietf.org/html/draft-cavage-http-signatures-10, much like AWS API Auth

@thehesiod
Copy link
Author

thehesiod commented Dec 5, 2018

btw, from what I read client auth may be possible if this project moves to be a "flexible" GAE project

@msuozzo
Copy link
Member

msuozzo commented Dec 6, 2018

Sounds good! How are you planning on attaching the header to the client requests? Client-side proxy?

And yes mTLS is a possibility with flex but the migration is non-trivial (I believe datastore and memcache interfaces change substantially).

@thehesiod
Copy link
Author

we're planning on modifying the santa binary since we want to change the branding anyways so users aren't presented with "santa" popups, and rather some form of corporate security :) That's an interesting idea though of the proxy, thanks!

I'll post a link here later with our changes to santa. I already have most of the changes done, unfortunately I've been battling the calendar API for a LONG time due to a variety of issues. If you happen to have any contacts with the calendar API team it would be appreciated!

@russellhancox
Copy link

nitpick: that would be Santa binaries, the pop-ups come from Santa.app, syncing is done by santactl.

Also, Santa has configuration options so you can customize some of the messaging. We had plans to make the entire UI customizable but the engineering effort involved coupled with the way the resulting UI worked (decidedly non-native and with subpar accessibility) resulted in us abandoning those plans.

@thehesiod
Copy link
Author

yes ty! So changing santa app for UI and santactl for auth. We wanted to mostly change the titles of the dialogs. I'd imagine most of it could be done with some form of custom resource (its been awhile since I've done native OS-X, will report back).

@thehesiod
Copy link
Author

ok I have initial code done:
santactl: farmersbusinessnetwork/santa@c13198e
upvote: farmersbusinessnetwork@1f90eeb

right now it's geared towards our company, however it can be generalized.

We'll test in our org it as soon as we get our kext cert approved by Apple. For now via debugger seems to work ok with our prod upvote server.

@bricksii
Copy link

Hello all, I realize I'm necroing an old thread—would it be more appropriate to start another issue regarding expanding Upvote's ValidateClient() stub to more readily implement mTLS or would continuing this thread be preferred?

We want to generally recommend to our admins that they use client authentication with mTLS when using Santa/Upvote, but the need to implement a validation function makes that out of reach for many. It's unclear to me if the GAE project type remains a hurdle still, but properly directing any interest that might exist to do this work seems wise.

Thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants