Agreed your idea.

Chao Zhang
[email protected]



> On Oct 24, 2020, at 7:38 PM, Zexuan Luo <[email protected]> wrote:
> 
>> taken here about the TLS SNI extension, the Session reuse and the SSL
> verification.
> 
> I think we don't need to support SSL session reuse. Using TLS ticket is
> enough, which is supported by the client automatically.
> 
>> an explicit item like “verify”
> 
> I think we should also support customized trust CA like what
> `lua_ssl_trusted_certificate` does. It is useful for self signed
> certificates.
> 
> 
> 
> Zhang Chao <[email protected]> 于2020年10月24日周六 上午11:04写道:
> 
>> Hello Community!
>> 
>> Recently I observed some issues and disscuss in the QQ group about the
>> support of HTTPS for ETCD cluster.
>> 
>> I think it might be a necessary feature, although since the limitations of
>> Cosocket we cannot support the mutual TLS
>> authentication, we can still support the simple TLS mode: only
>> authenticating the etcd cluster.
>> 
>> So two things we need to do to support this.
>> 
>> 1) lua-resty-etcd
>> 
>> We should enhance lua-resty-etcd to support the optional SSL handshaking
>> after connecting to one of ETCD endpoint, care must be taken here about the
>> TLS SNI extension, the Session reuse and the SSL verification.
>> 
>> 2) APISIX
>> 
>> We also should add some new items in the configuration, and use these new
>> items when creating the etcd client objects.
>> 
>> etcd:
>>  ......
>> 
>>  tls:
>>    mode: simple # TLS mode for communicating with the ETCD
>>                          # cluster, optional value can be:
>>                          #   disable: do not setup a TLS connection
>>                          #            to ETCD endpoints.
>>                          #   simple: originate a TLS connection to the
>>                          #           ETCD endpoint
>>                          # The default mode is disable.
>> 
>> Something I cannot decide is how we configure the SNI, I don’t think
>> expose a configuration item like “sni” is a good way, I’m inclined to use
>> existing items to deduce the SNI (like hosts?). On the other hand, I
>> haven’t decided yet about the SSL verification. Maybe we can add more
>> options for the mode like “weak”, “strict” or an explicit item like
>> “verify” is also OK. What’s your idea?
>> 
>> 
>> Chao Zhang
>> [email protected]
>> 
>> 
>> 
>> 

Reply via email to