This specification outlines the SecureBrowse protocol as designed by the MyMonero team.
SecureBrowse (SB) is a proposed protocol designed to provide clients the ability to validate the integrity of high-sensitivity and highly-targeted web UIs through side channels and prevent the subsequent client-side execution of compromised content from a domain that is otherwise trusted.
SecureBrowse was primarily designed for use cases where web services provide complex client-side code protecting sensitive information within the client browser. The goal of these designs is to prevent the transmission of sensitive data to the web service (such as the case with MyMonero and other similar crypto-currency driven web services) from being compromised via the following risks:
Compromise of 3rd Party Provider or Web Service – Given the prevalence of use of third-party providers within the chain of a web connection (such as content delivery networks, distributed denial of service protection, and web content hosting), a compromise of any account or provider within the chain could result in the compromise of the intended content.
Domain-Validated TLS certificates – As domain-validated certificates can validate based on text content on a web server in a well-known directory, a number of risks in shared-tenancy environments or attacks against routing can result in mis-issued certificates. While certificate revocation exists, its effectiveness lacks reliability in implementation, causing lasting damage to a domain when coupled with man-in-the-middle (MITM) attacks.
While DNS-based Authentication of Named Entities (DANE), HTTP Public Key Pinning (HPKP), and “Expect-CT” headers are designed to address potential attacks against malicious TLS certificates, they lack adoption and do not address compromise of a web service itself.
3. Deficiencies in current security controls addressed by protocol
To address this high impact of modifying client-side browser code, the SecureBrowse protocol sets out to address the gaps in coverage of the following security controls based on their risk models:
TLS Certificates – While serving as a primary method of identifying the integrity of a connection, compromise of the hosting web service, vulnerabilities through cross-site scripting, or modification of records can result in diminished integrity of the content presented by a validated TLS connection. While additional monitoring for changes to trusted content is possible, purely relying on TLS does not provide integrity checking of the content provided.
Site Resource Integrity (SRI) Hashes – SRI Hashes by themselves are designed to validate sub-resources of a page but not the original resource itself. As such, a compromise of the hosting pages’ HTML nullifies the effectiveness of SRI.
Content-Security Policies (CSPs) – Addressing the earlier risk model, CSPs are unable to protect against malicious client-side content when a web server is compromised, or when the compromise is otherwise within the confines of normal behavior of the application and thus allowed.
4. Implementing SecureBrowse as a Provider
To advertise the generated hashes of the resources to a SecureBrowse Client, the following DNS TXT records must be set relevant to the domain hosting the original resource:
SecureBrowse Version Information - A TXT record indicating the version of Secure Browse must be set. At the current version, this would be a TXT record containing “SECUREBROWSE 1.0”.
SRI Hashes for Primary Resources – A TXT record for the URL of each HTML resource must be registered in alignment with the record definition below.
TXT records may include multiple hashes (to support A/B testing or versioning of files) as well as multiple hashing algorithms (optional) as supported by SRI, however multiple hash algorithms are not required.
TXT records containing SRI hashes should follow the following format:
It is required to sign the TXT records using DNSSEC for a successful implementation, as SecureBrowse clients will validate the integrity of the DNSSEC signature.
5. Implementation of the SecureBrowse Protocol in the SecureBrowse Browser Plugin
SBBP functions with the following steps:
Detect if SecureBrowse should be validating – Prior to performing other validations or blocking, SBBP checks a local configuration of domains that have SecureBrowse enforced if actions should occur. If the configuration does not exist, it defers to performing a DNS TXT lookup to see if the SecureBrowse version is set for the domain. If it is, the domain is added to the local configuration. If it is not, it caches the domain to be ignored for a period of time.
Detect Phishing / Misspelt Links – To provide additional protection, SBBP performs limited checking against the presented domain name and the domain names configured within the browser plugin for punycode and typo domain names and alerts if a match is detected.
Validate primary resource’s hash – Using the DNS TXT records, a SRI-equivilant hash of the page is computed synchronously and compared against the TXT record. If the hashes do not match, the resulting content is blocked form loading. If a DNSSEC signature exists for the TXT records, it is validated on the client side and, if invalid, blocks the page from loading. Warnings for these changes are generated for the user.
Validate sub-resource integrity hashes – Using the SRI hashes provided in conjunction with the DNS TXT records, script and style sheet sub resources are loaded and validated synchronously. Similar to the primary resource’s hash, should any fail validation, the content is blocked form loading.
6. Current Design Limitations
The use of SecureBrowse is intended to validate the integrity of client-side content prior to its execution by a browser. It does not replace the necessity of TLS for confidentiality of any content sent to a server. SecureBrowse is unable to validate the integrity of a server prior to sending content requiring confidentiality (such as browser cookies, form data, or authentication headers in a web request) nor validate the integrity of a server receiving confidential information if client-side content is not otherwise changed.
SecureBrowse in its current design is unable to work with dynamic client-side content given the use of static hashes. The use of A/B testing code may function through the inclusion of multiple hashes, but is limited to reasonable size limitations of TXT records.
Given the current reliance on DNS for static hashes, SecureBrowse does not currently protect against compromise of an authoritative DNS service for a domain when DNSSEC is not enabled, or when DNSSEC signing is done automatically by the authoritative DNS service (such as the case in cloud DNS services).
SecureBrowse only works on URLs with HTTP or HTTPS, and does not secure other protocols (such as FTP or websocket) or other extensions within the browser (such as “chrome-extension”).
SecureBrowse does not protect against 302 redirects of original HTML content, and as such may not fully protect against phishing attacks.
As with any application, SecureBrowse does protect against insecure development of client-side code, and as such does not protect against DOM-based XSS or embedded eval statements against external resources.