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

In public tang server - block response until approval #20

Open
ieugen opened this issue Feb 3, 2018 · 15 comments
Open

In public tang server - block response until approval #20

ieugen opened this issue Feb 3, 2018 · 15 comments

Comments

@ieugen
Copy link

ieugen commented Feb 3, 2018

Hi,

I'm ttying to figure out how I can use tang + clevis in a public setup.

My idea was to develop an approvsl step around tang where a request for decription woll wait for human approval until it is served.

This might meje the system work over the internet. Of course this can be abused.

Is this a good solution?
Any ideas on how to solve the issue of using tang over public internet?

Thanks,

@npmccallum
Copy link
Contributor

The current solution would be to use a VPN. Alternatively, we would accept patches to support client authentication over HTTPS. In this case, you can just put an authenticating proxy in front of Tang.

@npmccallum
Copy link
Contributor

But yes, an interactive system would be interesting as well. Suggestions?

@ieugen
Copy link
Author

ieugen commented Feb 4, 2018

I'll see if I can find some time to make one. I'll probably do it in Java since I'm much more familiar with the language and tooling. Is it easy to implement the tang protocol in Java? I saw the code is not that much as jose library handles most of the crypto. Any idea on how I can test my code ?

I'm curious how clevis behaves: does it block, does it have a timeout? Does it retry after timeout? Is this behavior specified someplace?

@zdenekpizl
Copy link

+1 for this idea

Should it be just enough to extend Tang's REST API to

  • enable/disable approval of clients' requests explicitly,
  • get list of waiting requests
  • approve/deny single requests or set of requests from list of waiting ones

I understand there is a question of asynchronous communication when requests are waiting for an approval, so it could be tricky, but it is feasible basically, I hope.

Regards .zp.

@npmccallum
Copy link
Contributor

Push code can actually proxy. It can connect to the Tang server and connect to awaiting Clevis and proxy the data between the two. This is possible because we don't require encryption. So we don't need support in Tang directly. But we do need support in Clevis. Perhaps we should move the request there?

@zdenekpizl
Copy link

@npmccallum - not sure whether your response is bound to my comment or to the former one. I think both sides should be extended to work smoothly with this (still a wish) new feature. But I may be wrong as many times before 😄

@npmccallum
Copy link
Contributor

@zdenekpizl My comment is just in general. What is the specific use case for this request?

@zdenekpizl
Copy link

Imagine following situation:

  • you have server/servers in a datacenter which has no SOC2, ISO* or HIPAA certification. Just a plain common datacenter without much trust to it
  • server has been restarted suddenly, but you do not know the reason. Is it just a crash or is it intended attack with tweaked system booting from LiveCD and asking for LUKS decryption?

In such case, you want to have an option to postpone the decryption key delivery and investigate little bit before an approval AFAIK. Or - is there any other option in such game?

@npmccallum
Copy link
Contributor

I agree that this would be tremendously useful. However, what is the system that is going to manage this? You'll need a notification that a request is pending. This needs to go in a queue somewhere. You'll also need some system for managing who's doing what on each system. What are you using for this?

@zdenekpizl
Copy link

zdenekpizl commented Feb 19, 2018

Usually, if you are using LUKS you are understanding the system is important. Therefore you are monitoring it somehow, by Icinga, Zenoss, SiteScope (sigh, I hope nobody is forced to use it any more) or similar tool. So you know that system went down and has been restarted. That's about notifications, let's third-party tools do this job.

The queue of waiting approvals is another question, from top of my head I can imagine persistent list somewhere at Tang's directory structure (a file with lines of clients or better one file for one client with content identifying the client uniquely) or employ some messaging (rather not, that's too complicated)

I am not sure about the sentence '''You'll also need some system for managing who's doing what on each system'''.
I think for beginning we can just use binary approach: Tang is serving secrets without waiting for an approval versus Tang is waiting for an approval for any request.

@ieugen
Copy link
Author

ieugen commented Feb 20, 2018

Hi,

I think the approval can be a simple web page / web api that is secured and you can access via web browser or mobile phone to approve the request.

It doesn't have to be very complicated at first. It just needs to work and prove the concept. If people find it useful it will be enhanced.

@jonstelly
Copy link

I've just started setting up tang but I'd like to see something like this too. A mobile app where I get a notification and have to approve/reject the request.

In my mind something like the battle.net authenticator would be the ideal. You get a push notification to your phone, you tap the notification to open the authenticator app that shows information about the request and you click 'approve' or 'deny'. 2-3 taps and you're done. Including some more/different metadata of the client on the approval page would be helpful (IP address, hostname?, not sure what metadata exists or comes across in the unlock request yet).

I could also see a slack/teams/discord bot integration where the request gets pushed to a channel on one of those platforms and anyone (from some specific list) can approve the unlock request. That may be the more interesting way to go. Having the mobile app would be great but from an ops perspective I know a lot of ops groups already hang out in slack channels with those kinds of integrations, and you could use their mobile client. It would be slightly less friendly on a phone compared to the dedicated app but it wouldn't require the overhead of creating and maintaining a custom mobile app.

image

@adhaussy
Copy link

* enable/disable approval of clients' requests explicitly,
* get list of waiting requests
* approve/deny single requests or set of requests from list of waiting ones

I understand there is a question of asynchronous communication when requests are waiting for an approval, so it could be tricky, but it is feasible basically, I hope.

There is something like that on mandos server.
Unfortunately it doesn't manage very well with several hundreds servers.

  • Ability to enable/disable clients with mandos cli.
  • Regular handshake between client/server at defined interval.
  • If the client has not been seen since interval, it is disabled.
# mandos-ctl
server01.domain No      00:05:00 <- disabled
server02.domain Yes     00:05:00 2022-01-26T09:39:19.832069 <- last handshake ok
server03.domain Yes     00:05:00 2022-01-26T09:39:19.832585 <- last handshake ok

@krzee
Copy link

krzee commented May 31, 2022

I came to request this but I was thinking it could be a script hook placed and enabled in the tang server which would exit 0 for success and non-0 for no connection to be allowed? Then we could implement our own desires in that script

@krzee
Copy link

krzee commented Nov 21, 2022

#92 seems to do what I want, and can be extended to do what everybody wants through outside applications. the outside application would place a file when it is told to allow decryption and remove the file when decryption should no longer be allowed.

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

No branches or pull requests

6 participants