search

envoyproxy / envoy

Cloud-native high-performance edge/middle/service proxy
https://www.envoyproxy.io
Apache License 2.0
24.75k stars 4.75k forks source link

tls: support ed25519 for client cert digital signature #25727

Closed kyessenov closed 1 year ago

kyessenov commented 1 year ago

Seems that Envoy cannot verify client certificates signed with ed25519 in TLS1.3:

(from server hello)

Acceptable client certificate CA names
CN = localhost
Requested Signature Algorithms: ECDSA+SHA256:RSA-PSS+SHA256:RSA+SHA256:ECDSA+SHA384:RSA-PSS+SHA384:RSA+SHA384:RSA-PSS+SHA512:RSA+SHA512:RSA+SHA1
Shared Requested Signature Algorithms: ECDSA+SHA256:RSA-PSS+SHA256:RSA+SHA256:ECDSA+SHA384:RSA-PSS+SHA384:RSA+SHA384:RSA-PSS+SHA512:RSA+SHA512
Peer signature type: Ed25519
Server Temp Key: X25519, 253 bits
adazzi93933 commented 1 year ago

Here is the envoy debug log when testing with a ed25519 client cert.

[2023-02-24 15:02:14.384][11395773][debug][conn_handler] [source/extensions/listener_managers/listener_manager/active_tcp_listener.cc:147] [C0] new connection from 127.0.0.1:50183 [2023-02-24 15:02:14.392][11395773][debug][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:233] [C0] remote address:127.0.0.1:50183,TLS error: 268435648:SSL routines:OPENSSL_internal:PEER_DID_NOT_RETURN_A_CERTIFICATE [2023-02-24 15:02:14.392][11395773][debug][connection] [source/common/network/connection_impl.cc:656] [C0] remote close [2023-02-24 15:02:14.392][11395773][debug][connection] [source/common/network/connection_impl.cc:250] [C0] closing socket: 0 [2023-02-24 15:02:14.392][11395773][debug][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:233] [C0] remote address:127.0.0.1:50183,TLS error: 268435648:SSL routines:OPENSSL_internal:PEER_DID_NOT_RETURN_A_CERTIFICATE [2023-02-24 15:02:14.392][11395773][debug][conn_handler] [source/extensions/listener_managers/listener_manager/active_stream_listener_base.cc:120] [C0] adding to cleanup list

ldemailly commented 1 year ago

Please see https://github.com/ldemailly/envoy-ed25519-mtls-issue for complete and detailed repro (done by Alain & team, I just added the comparison with fortio tls working with same curl)

key parts being

      transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
          require_client_certificate: true
          common_tls_context:
            validation_context:
              trusted_ca:
                filename: certs/ca-ed25519.crt
            tls_certificates:
              - certificate_chain:
                  filename: certs/server-ed25519.crt
                private_key:
                  filename: certs/server-ed25519.key

generated using

openssl genpkey -algorithm ED25519 -out client-ed25519.key

# create client CSR 
openssl req \
  -new \
  -key client-ed25519.key \
  -subj '/CN=ED25519Client' \
  -out client-ed25519.csr

# sign CSR with root CA
openssl x509 \
  -req \
  -in client-ed25519.csr \
  -CA ca-ed25519.crt \
  -CAkey ca-ed25519.key \
  -CAcreateserial \
  -days 365 \
  -out client-ed25519.crt

# check client cert
openssl x509 \
  --in client-ed25519.crt \
  -text \
  --noout
adazzi93933 commented 1 year ago

using the same set of certs here is the openssl behavior ... openssl s_server -accept 3000 -CAfile ca.crt -cert server.crt -key server.key -state & (or in one window) openssl s_client -connect 0.0.0.0:3000 -key client-ed25519.key -cert client-ed25519.crt -CAfile ca.crt -state (in another window)

... Shared ciphers:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224:DSA+SHA224:DSA+SHA256:DSA+SHA384:DSA+SHA512 Shared Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224 Supported groups: x25519:secp256r1:x448:secp521r1:secp384r1:ffdhe2048:ffdhe3072:ffdhe4096:ffdhe6144:ffdhe8192 Shared groups: x25519:secp256r1:x448:secp521r1:secp384r1:ffdhe2048:ffdhe3072:ffdhe4096:ffdhe6144:ffdhe8192 CIPHER is TLS_AES_256_GCM_SHA384 Secure Renegotiation IS supported

the key difference is the shared signatures -> Ed25519:Ed448 which we do not see when handshaking with envoy/boringsll.

and the error reported in the envoy debug log shows:

[2023-03-02 10:13:51.541][40819886][debug][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:234] [C17] remote address:127.0.0.1:64624,TLS error: 268435648:SSL routines:OPENSSL_internal:PEER_DID_NOT_RETURN_A_CERTIFICATE

i traced it down to the boringssl handshake_server.cc and/or tls13_both.cc code. My feeling is that support for ed255519 client certs is not enabled in boringssl and it is probably not an envoy issue.

ldemailly commented 1 year ago

looking at https://bugs.chromium.org/p/boringssl/issues/detail?id=530&q=Ed25519&can=1 -> https://github.com/grpc/grpc/issues/24252#issuecomment-909916002 -> https://github.com/google/boringssl/blob/master/ssl/extensions.cc#L437 -> https://github.com/google/boringssl/blob/master/ssl/extensions.cc#L482

it seems we might just need to configure hs->config->verify_sigalgs

is that somewhere in envoy's code?

kyessenov commented 1 year ago

Good find. It's not called anywhere. Not sure if this needs to be another knob in xDS.

On Fri, Mar 10, 2023 at 10:06 AM Laurent Demailly @.***> wrote:

looking at https://bugs.chromium.org/p/boringssl/issues/detail?id=530&q=Ed25519&can=1 -> grpc/grpc#24252 (comment) https://github.com/grpc/grpc/issues/24252#issuecomment-909916002 -> https://github.com/google/boringssl/blob/master/ssl/extensions.cc#L437 -> https://github.com/google/boringssl/blob/master/ssl/extensions.cc#L482

it seems we might just need to configure hs->config->verify_sigalgs

is that somewhere in envoy's code?

— Reply to this email directly, view it on GitHub https://github.com/envoyproxy/envoy/issues/25727#issuecomment-1464183230, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACIYRRSYB6HJMLA5X7FSCLTW3NUSVANCNFSM6AAAAAAVEYQ2RE . You are receiving this because you authored the thread.Message ID: @.***>

ldemailly commented 1 year ago

Alain confirmed on a side build (forcing the constant in the defaults, pending actual config option) that it works so yes, it seems "just" a matter of making that list configurable (or tbh, I wouldn't mind either that boringssl included with envoy would just get patched)

adazzi93933 commented 1 year ago

here are some details ... I struggled a bit with the envoy/boringssl integration. I first compiled bssl with cmake/ninja on main but envoy has 2 boringssl patches that got in the way. so i used the main-with-bazel branch to create a boringssl.tar.gz archive.

The patch is simply ...

`✔ XF4P4GJTCF ~/src/envoy/boringssl-git remotes/origin/main-with-bazel > git diff diff --git a/ssl/extensions.cc b/ssl/extensions.cc index ba9236035..73f4820e4 100644 --- a/ssl/extensions.cc +++ b/ssl/extensions.cc @@ -436,6 +436,7 @@ bool tls1_check_group_id(const SSL_HANDSHAKE *hs, uint16_t group_id) { // algorithms for verifying. static const uint16_t kVerifySignatureAlgorithms[] = { // List our preferred algorithms first.

and in envoy i referred to it as a file in bazel/repository_locations.bzl.

github-actions[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

github-actions[bot] commented 1 year ago

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.