aboutsummaryrefslogtreecommitdiffhomepage
path: root/test/core/security
diff options
context:
space:
mode:
authorGravatar David Cowden <dcow@eero.com>2018-02-08 22:58:53 -0800
committerGravatar David Cowden <dcow@eero.com>2018-04-26 12:25:38 -0700
commit116fd29a36b1b5af454de11bda6d100f9565be91 (patch)
treeb90765f1675758d7759e5a7e05bc91d01b47ce99 /test/core/security
parent8acece911a6666ac29040451622db4032f4ce5f9 (diff)
gRPC core: strip zone-id from IPv6 hosts before TLS verification
When initiating a connection to an IPv6 peer using an address that is not globally scoped, there may be ambiguity regarding which zone the destination address applies to when multiple links of the same scope are present. The scoped address architecture and zone-id syntax are described in rfc4007 and rfc 6874, respectively: * https://tools.ietf.org/html/rfc4007#section-6 * https://tools.ietf.org/html/rfc6874 This patch allows host name verification performed during TLS session establishment, and on a per-call basis, to work correctly when the peer presents a certificate with a non-global IPv6 address listed as one of its alternate names. Whether arbitrary certificate authorities choose issue certificates of this nature, or not, is outside the scope of gRPC. The zone-id is separated from the address using a percent (%) character. It is considered a system implementation detail and guidance suggests it be stripped from any paths or addresses egressing a host because it is irrelevant and meaningless otherwise. It would not make sense for a server to present a certificate containing non-global IPv6 addresses with zone-ids present nor would it work unless two hosts happened to be using the same zone-id. ssl_host_matches_name is prefixed with grpc_ because it has been promoted to the global namespace for testing. Resolves #14371
Diffstat (limited to 'test/core/security')
-rw-r--r--test/core/security/security_connector_test.cc21
1 files changed, 21 insertions, 0 deletions
diff --git a/test/core/security/security_connector_test.cc b/test/core/security/security_connector_test.cc
index f03f4ccdbd..c78d2ae41f 100644
--- a/test/core/security/security_connector_test.cc
+++ b/test/core/security/security_connector_test.cc
@@ -340,6 +340,26 @@ static grpc_ssl_roots_override_result override_roots_permanent_failure(
return GRPC_SSL_ROOTS_OVERRIDE_FAIL_PERMANENTLY;
}
+static void test_ipv6_address_san(void) {
+ const char* addresses[] = {
+ "2001:db8::1", "fe80::abcd:ef65:4321%em0", "fd11:feed:beef:0:cafe::4",
+ "128.10.0.1:8888", "[2001:db8::1]:8080", "[2001:db8::1%em1]:8080",
+ };
+ const char* san_ips[] = {
+ "2001:db8::1", "fe80::abcd:ef65:4321", "fd11:feed:beef:0:cafe::4",
+ "128.10.0.1", "2001:db8::1", "2001:db8::1",
+ };
+ tsi_peer peer;
+ GPR_ASSERT(tsi_construct_peer(1, &peer) == TSI_OK);
+ for (size_t i = 0; i < GPR_ARRAY_SIZE(addresses); i++) {
+ GPR_ASSERT(tsi_construct_string_peer_property_from_cstring(
+ TSI_X509_SUBJECT_ALTERNATIVE_NAME_PEER_PROPERTY, san_ips[i],
+ &peer.properties[0]) == TSI_OK);
+ GPR_ASSERT(grpc_ssl_host_matches_name(&peer, addresses[i]));
+ tsi_peer_property_destruct(&peer.properties[0]);
+ }
+ tsi_peer_destruct(&peer);
+}
namespace grpc_core {
namespace {
@@ -416,6 +436,7 @@ int main(int argc, char** argv) {
test_cn_and_one_san_ssl_peer_to_auth_context();
test_cn_and_multiple_sans_ssl_peer_to_auth_context();
test_cn_and_multiple_sans_and_others_ssl_peer_to_auth_context();
+ test_ipv6_address_san();
test_default_ssl_roots();
grpc_shutdown();