[WIP, feedback wanted] macaroons: add new request hash caveat to improve replay protection

[guggero]

This PR addresses #285.

To make sure that a macaroon that is somehow intercepted during transmission cannot be used by an attacker, the lncli already sets a caveat for a 60 second timeout. Additionally, the macaroon can be locked down to a specific IP address.
With this PR the gRPC client (for now, just lncli, the feature can be disabled with --no-macaroon-request-hash) creates a SHA256 hash of the method name concatenated with the JSON serialized request gRPC object.
That hash is added to the macaroon as a first-party caveat named request-hash.
On the server side, this caveat is validated by hashing the method and request object again.

I'm not sure if I'm on the right track with my implementation. That's why I created the PR with the status 'work in progress'. I would really appreciate feedback on what I did, especially from @aakselrod since he created the original issue/feature request.

As I see it, the following questions arise from the way I implemented it:

• The solution works well for unary/synchronous requests, since the request data is available and can be hashed. For streaming/asynchronous requests, this cannot be done, because the macaroon is only sent at the beginning, when opening the connection. But through that connection, many requests can then be made and no further macaroon is required. For example, the SendPayment is a streaming command where several payments can be sent through the same stream but with only one macaroon that is sent at the beginning. So the only thing we can hash is the method name itself (like lnrpc.SendPayment). But if an attacker can sniff that macaroon, he can send payments himself (until the 60 second timeout runs out). So my question is: Does anyone have an idea on how to further improve the replay protection for streaming requests?
• The JSON serialization of a request object should produce the same output for the same object on all platforms/languages/libraries, because this is done by the gRPC library that should behave the same in Java, JavaScript, Python, Ruby, and so on. So it would be possible for this feature to work for other clients than just lncli and should in principle also be doable over the REST gateway. My question is: Should we provide code samples on how to do that for all languages? Should we maybe write some kind of simple integration tests for the languages we support?

This is the current state of the implementation:

• Get the request-hash feature to work for unary/synchronous requests in lncli.
• Get the request-hash feature to work for streaming/asynchronous requests in lncli.
• Add a feature toggle parameter called --no-macaroon-request-hash.
• Add a test for the UnaryServerInterceptor.
• Add documentation on how this is implemented in lncli.
• Add documentation on how the request hash feature can be used by app developers using the gRPC interface.
• Finish tests for all client and server interceptors.
• Manually test all unary and stream commands in lncli.
• Split commits into smaller changes

As always, thank you for your input!

[guggero]

Not really relevant and not a big security benefit.