In public tang server - block response until approval

[ieugen]

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]

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]

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

[ieugen]

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]

+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]

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]

@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 :smile:

[npmccallum]

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

[zdenekpizl]

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]

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]

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]

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]

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.

[adhaussy]

* 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]

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]

https://github.com/latchset/tang/pull/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.