When no config is specified use the application's usesCleartextTraffic
flag when building the default config.
Change-Id: I07378f88da47b49f63e9089fca7f1e99efede272
Even if the hostname aware method is called if the hostname is null then
the destination is unknown and the configuration can be ambiguous.
Change-Id: I7cacbd57a42604933fdc882371f143dc0a20902d
This allows us to keep the logic for the NetworkSecurityPolicy in the
framework instead of in libcore.
Change-Id: I4bf494f79c27729cb17d93d90a91319492270ce9
Providing a TrustedCertificateStore to TrustManagerImpl avoids loading
all of the trusted certificates into memory and indexing them. This
is mainly for the system certificate store where loading all of the
store into memory is wasteful for most applications.
Change-Id: I9e6057f6a13d38ea7762fcac2f62bd3ff475af39
This will be used to create a custom conscrypt TrustedCertificateStore
to avoid loading all of the trusted certificates into memory in a
keystore.
Change-Id: Iaf54b691393ecadae6c7ff56b8adc6a2a2923d29
This allows for faster lookups of TrustAnchors when checking pin
overrides without needing to iterate over all certificates.
Currently only the system and user trusted certificate store are
optimized to avoid reading the entire source before doing the trust
anchor lookup, improvements to the resource source will come in a later
commit.
This also refactors System/UserCertificateSource to avoid code
duplication.
Change-Id: Ice00c5e047140f3d102306937556b761faaf0d0e
This was returning false on some test keystores even when
getCertificate would correct return a certificate. Remove the check to
be consistent with how conscrypt loads trust anchors from the keystore.
Bug: 25897324
Change-Id: Ie87658a261ee7ba1cca6896e34b6c53b8abfba85
This defers looking up the meta-data from the install call to when the
rest of the config is lazily initialized.
Change-Id: I008a86f885e158ebe06a2bacdc358cd217635d05
When getting trust anchors we need to dedup them based on the
certificate to avoid having multiple trust anchors with the same cert
but different pin override behavior. If there are multiple trust anchors
with the same cert, the trust anchor which overrides pins wins.
Change-Id: Ida31f2551f56997418b8b091bb2598c5593cb069
Debug overrides are only used if the application is debuggable in
order to help local debugging and development by trusting additional
CAs. In a non-debuggable version of the application the debug-overrides
are ignored.
Trust anchors in the debug override configuration have two key
differences from those in base-config and domain-config:
1) trust anchors in the debug-overrides are trusted for all connections
in addition to any trust anchors included in the relevant base/domain
configs.
2) By default trust anchors in the debug config override pins, as their
purpose is for connecting to non-standard servers for debugging and
testing and those servers should not be pinned in the production
configuration.
Change-Id: I15ee98eae182be0ffaa49b06bc5e1c6c3d22baee
Nested domain-config inherit unset parameters from the domain-config
they are nested in. This helps avoid copy and pasted configs that are
almost the same except a few minor differences for a domain with
slightly different requirements.
For example: Consider a domain-config for example.com that, among other
settings, does not enforce hsts. Now if you want the rules for
example.com to apply to secure.example.com except that hsts _is_
enforced you can make a nested domain-config for secure.example.com
under example.com that sets hstsEnforced="true" and nothing else.
Change-Id: I9e33f7e62127fd7f4f15c3560fff2f2626477bd4
XmlConfigSource parses an ApplicationConfig from an xml resource.
Currently this supports app-wide default configuration via the
base-config element, per domain via the domain-config element and
inheritance of unset properties at parse time.
Inheritance of unset properties is currently only:
domain-config -> base-config -> platform default configuration
Where the most specific value is used.
For example: If the base-config specifies trust anchors, all connections
will use those anchors except for connections to a domain which has a
domain-config that specifies trust anchors, in which case the
domain-config's trust anchors will be used. If the domain-config or
base-config don't set trust anchors, or don't exist, then the platform
default trust anchors will be used.
Nested domain-config entries, debug-overrides, and thorough
documentation of the xml format will follow in later commits.
Change-Id: I1232ff1e8079a81b340bc12e142f0889f6947aa0
