| Age | Commit message (Collapse) | Author |
|---|
|
Privileged applications provide core system functionality and as such a
MiTM in one can put the entire system at risk. These applications should
not be trusting user added CAs by default.
Bug: 65406503
Test: runtest --path framework/base/tests/NetworkSecurityConfigTest
Change-Id: I033258fe1c66ad245d172899df52e9cd02e9ca75
|
|
The new attribute allows both ephemeral and non-ephemeral apps to
opt into a new, tighter security model.
Test: Manual; built app w/ targetSandboxVersion and verified the security domain
Change-Id: I8fcaf84e25f0519b438ba51302f79790e680e025
|
|
Test: NetworkSecurityPolicy.isCleartextTraffic permitted returns the
expected defaults.
Change-Id: I7d6577f8461bbf1f44eb21b4d813dba1746449fa
|
|
This pruns all the stored trusted issuers so that changes to the system
or user CA store are detected. Currently this is only exposed as a
TestApi, but it can be hooked up to the trusted storage change event
in a future commit.
Bug: 27526668
Change-Id: Ic426254babab9a3177c968bc05b45e95eaac1fdd
|
|
Domain entries can contain whitespace (or newlines) which should be
ignored to avoid unexpectedly failing to match a domain.
Bug: 27816377
Change-Id: I3691aa4abd409e7be97ad0cf1eb0195725e1b0ab
|
|
An application can specify its debug-overrides in an extra resource with
the same name suffixed with "_debug" (e.g. res/xml/security_config.xml and
res/xml/security_config_debug.xml).
By specifying the debug-overrides in an extra file release builds can
strip out the file (and any certificate resources that the
debug-overrides depend on) to prevent including testing configuration
information in the release build of an application.
Bug: 27418003
Change-Id: Ibfebc376360ca474fc0f9f2fd565faa0cffd9549
|
|
Android's security model is such that the applications data is secure by
default unless the application specifically grants access to it.
Application data in transit should have similar security properties.
Bug: 27301579
Change-Id: I72f106aefecccd6edfcc1d3ae10131ad2f69a559
|
|
Change-Id: I176ec42c9907e50ee218e4fb352b530ca797be46
|
|
|
|
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 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
|
|
Change-Id: I321e3ca94cc2a8d5e0e5d82a83b255ff5b8a71d2
|
|
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
|
|
The builder supports all the standard builder set* methods as well as
setting a parent builder to use when values are not set (recursively).
This allows us to have a level of inheretence in configurations without
complicating the lookup and trust checking logic by doing inheretence
when building the configs.
Change-Id: I054af83451e52761227479eadf9cb9803437505f
|
|
Initial implementation of a unified application wide static
network security configuration.
This currently encompases:
* Trust decisions such as what trust anchors to use as well as static
certificate pinning.
* Policy on what to do with cleartext traffic.
In order to prevent issues due to interplay of various components in an
application and their potentially different security requirements
configuration can be specified at a per-domain granularity in addition
to application wide defaults.
This change contains the internal data structures and trust management
code, hooking these up in application startup will come in a future
commit.
Change-Id: I53ce5ba510a4221d58839e61713262a8f4c6699c
|
