TLS support for HTTPChaos

[Hexilee]

Signed-off-by: xixi [email protected]

Here is the rendered markdown.

[STRRL]

The simplest solutions, mainly used in the case of server-side HTTPChaos

I think there is no difference between server-side and client-side, we just hijack the TLS connection and do not even care anything about "trust things".

[Andrewmatilde]

I have the same opinion.

[Hexilee]

Of course, there is no difference in implementation, but there should be differences in normal cases. User-provided secrets can resolve most use cases of server-side HTTPChaos.

[STRRL]

Maybe another standalone extendable component ca_injector represents injecting CA to different components: OS/JVM/Others..

[Hexilee]

Yes, and we can provide options to select them by users.

[STRRL]

Well, if we assume that, the user could always provide the certs which are trusted by both "client" and "server"(with mtls), I think it could be easily applied on both server-side and client-side injection.

the user could always provide the certs which are trusted by both "client" and "server"

And actually, I think it's not a kind of difficult for any companies/orgs which hold their own PKI infrastructure, they require tons of certs with TLS for encrypting their internal/public networking communication/ service RPC between applications.

[Hexilee]

Yes

[STRRL]

Also

/cc @anuragpaliwal80

[anuragpaliwal80]

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).

[Hexilee]

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]

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 chaos-mesh/chaos-tproxy#39)

[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).

[STRRL]

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.