From 69abec5a2881afe5525f45ffdbd8f4fb23cc53ff Mon Sep 17 00:00:00 2001 From: Eric Anderson Date: Wed, 22 Jun 2022 13:16:42 -0700 Subject: [PATCH] api: Explain security constraints of ATTR_AUTHORITY_OVERRIDE Half of the text was copied from NameResolver.getServiceAuthority(). However, that method can't perform I/O (which would block) so more text was appropriate here to mention the implications of having a remote service provide the authority. I noticed the text was lacking while discussing #9266. --- api/src/main/java/io/grpc/EquivalentAddressGroup.java | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/api/src/main/java/io/grpc/EquivalentAddressGroup.java b/api/src/main/java/io/grpc/EquivalentAddressGroup.java index 915907d64b..969c82e010 100644 --- a/api/src/main/java/io/grpc/EquivalentAddressGroup.java +++ b/api/src/main/java/io/grpc/EquivalentAddressGroup.java @@ -40,6 +40,11 @@ public final class EquivalentAddressGroup { * However, if the channel has overridden authority via * {@link ManagedChannelBuilder#overrideAuthority(String)}, the transport will use the channel's * authority override. + * + *

The authority must be from a trusted source, because if the authority is + * tampered with, RPCs may be sent to attackers which may leak sensitive user data. If the + * authority was acquired by doing I/O, the communication must be authenticated (e.g., via TLS). + * Recognize that the server that provided the authority can trivially impersonate the service. */ @Attr @ExperimentalApi("https://github.com/grpc/grpc-java/issues/6138")