rfcs icon indicating copy to clipboard operation
rfcs copied to clipboard

TLS support for HTTPChaos

Open Hexilee opened this issue 2 years ago • 6 comments

Signed-off-by: xixi [email protected]

Here is the rendered markdown.

Hexilee avatar Apr 29 '22 15:04 Hexilee

Also

/cc @anuragpaliwal80

STRRL avatar May 07 '22 06:05 STRRL

Thanks, @Hexilee, for creating this draft. To me, it looks we need different ways to handle server-side and client-side.

  1. server-side: As per current draft, user has to provide privateKey and certificate, which might be difficult as user don't have access to these details as they have limited rights as per their roles, etc. Needs to explore more.
  2. client-side: Self-Signed Certificates approach looks good. Looks like we don't need any certificate related details from user. I will keep digging more for better understanding.

In general, as we divided this work between two main areas (server-side and client-side), can we pick the client-side first (if possible).

anuragpaliwal80 avatar May 08 '22 08:05 anuragpaliwal80

I divide implementation by client-side and server-side to indicate the self-signed cert and ca-injector are mostly required by the client-side one. User-provided secrets can resolve the most of use cases for server-side HTTPChaos and parts of use cases for client-side HTTPChaos. @STRRL @Andrewmatilde @anuragpaliwal80

Hexilee avatar May 09 '22 03:05 Hexilee

Thanks, @Hexilee, for creating this draft. To me, it looks we need different ways to handle server-side and client-side.

  1. server-side: As per current draft, user has to provide privateKey and certificate, which might be difficult as user don't have access to these details as they have limited rights as per their roles, etc. Needs to explore more.
  2. client-side: Self-Signed Certificates approach looks good. Looks like we don't need any certificate related details from user. I will keep digging more for better understanding.

In general, as we divided this work between two main areas (server-side and client-side), can we pick the client-side first (if possible).

We divided the use cases instead of work. The user-provided secrets and self-signed cert are the same implementation in chaos-tproxy. (Actually, we are doing it now https://github.com/chaos-mesh/chaos-tproxy/pull/39)

Hexilee avatar May 09 '22 03:05 Hexilee

We divided the use cases instead of work

I agree, it's a better way to say it as use case.

The user-provided secrets and self-signed cert are the same implementation in chaos-tproxy.

Thanks, I will have a look.

Other than this, I was exploring on server side and here are few points that I would like to share:

  • Earlier I was thinking it might not be possible to get cert and key, but after exploring more I found it's should be possible, and it even makes sense to get these details from client as mentioned by @STRRL as well.
  • The only challenge is to version control this file with these certs and private key and client needs to be careful with the same (which we can assume).

anuragpaliwal80 avatar May 11 '22 12:05 anuragpaliwal80

We divided the use cases instead of work

I agree, it's a better way to say it as use case.

The user-provided secrets and self-signed cert are the same implementation in chaos-tproxy.

Thanks, I will have a look.

Other than this, I was exploring on server side and here are few points that I would like to share:

  • Earlier I was thinking it might not be possible to get cert and key, but after exploring more I found it's should be possible, and it even makes sense to get these details from client as mentioned by @STRRL as well.
  • The only challenge is to version control this file with these certs and private key and client needs to be careful with the same (which we can assume).

When using a certain cert/key pair for the chaos experiment, I think signing new certs from PKI with extremely short validity (like 1 day) could be helpful and make sense.

STRRL avatar May 12 '22 06:05 STRRL