Add Android ECH support#9573
Conversation
|
@swankjesse my biggest question is how to deal with NetworkSecurityPolicy for both I previously ended up with EchModes (disabled, strict and so on) read from the policy |
| private val network: Network? = null, | ||
| /** | ||
| * True to also query the `HTTPS` record for service metadata such as ECH. Set this to false to | ||
| * save a query when only IP addresses are needed. |
There was a problem hiding this comment.
I wonder if there’s a way to phrase this documentation to encourage people to keep it on.
‘Set this to false to omit the service metadata query. This will disable privacy features in the HTTPS call.’
There was a problem hiding this comment.
I think maybe we end up defaulting to the networkSecurityConfig, but let developers opt-out, or opt-in.
For now, likely opt-in while we confirm it works.
GREASE means it should never cause failures just by being enabled.
There was a problem hiding this comment.
I'll ask tomorrow if that mode still exists.
There was a problem hiding this comment.
Yep, I'll update the wording. But also think if we want this we should make AndroidDns the default on API 37+ and when network security policy isn't globally disabled?
I think effectively the modes are (potentially per host)
UNSPECIFIED
DISABLED
ENABLED
So maybe that default once we are confident is the right option?
There was a problem hiding this comment.
BTW if we ignore or override the NSP, Conscrypt still checks it.
My preference is we assume DNS is where this should be configured. If there’s a ECH parameter on the TYPE_HTTPS record we should use it, and if there isn’t then we should assume the site operators don‘t care. Configuring it on the client is too difficult for large organizations, because the team that ships services and apps is far detached from the team that manages DNS and HTTPS. |
But there is a developer API that we should honour. https://developer.android.com/privacy-and-security/security-config#EncryptedClientHelloSummary |
|
Still tests to go |
|
Need to put this catch back |
|
Where does Android implement the policy in that XML file? Presumably we act as if it's always enabled, and the XML config overrides our preferences? |
But then we do extra work fetching ECH records that won't be used. But I think the test is that we do the correct, secure, optimal thing with DnsOverHttps enabled? So it can't be inside AndroidDns then? Not sure where exactly - one of these cc @swankjesse not sure if you see non threaded comments. |
Adds AndroidDns, backed by the system resolver and Android's DnsResolver for HTTPS/ECH records, driving okhttp's StateMachineDnsCall as a transport. Adds Android17SocketAdapter for platform ALPN/session-ticket/ECH setup on API 37+. Pins Robolectric android-test to SDK 36.
| * [Network.getAllByName] when a [network] is set. Internally this drives OkHttp's | ||
| * [StateMachineDnsCall] through a private transport: a single `A` query stands in for the blocking | ||
| * address lookup (which returns both address families), plus an optional `HTTPS` query for service | ||
| * metadata such as ECH. |
| * | ||
| * `WrongConstant` is suppressed because okhttp's [TYPE_HTTPS] is the DNS wire value (65), the | ||
| * same as the platform's `DnsResolver.TYPE_HTTPS`. We use ours so the query stays valid on | ||
| * API 29+; `DnsResolver.TYPE_HTTPS` was only added in API 37. |
Initial version before dealing with NetworkSecurityPolicy,
instead just activated by developer using AndroidDns, and a server having HTTPS records with ECH.