Security and privacy online are critical to protect users from eavesdroppers and attackers. The biggest success story of the last decade is HTTPS, the protocol that ensures the connection between a reader and a website is encrypted. We’ve written about this, advocated for news organizations to adopt it, and today — thanks to projects like Let’s Encrypt — almost all web traffic is now encrypted. However, there’s still a major gap in web security: ensuring the integrity of the code that those sites provide to you. Our answer is WEBCAT, a tool for web browsers to verify the origin of code before they run it.
HTTPS only protects the channel
HTTPS does two things. It keeps the connection between a reader and a website confidential, and it guarantees that nobody in between — on your coffee shop WiFi, your internet service provider, or anyone with access to the network path — can alter what you receive. Encryption that provided only confidentiality would let an attacker rewrite a page in transit, and modify what that page can do — including removing protections such as end-to-end encryption features or sending anything you type into that site to the server.
Every time you visit a website, your web browser downloads resources from it, including JavaScript — code that your browser runs immediately, without asking you. Your browser has no way to check whether that code is authentic.
A user fetches myapp.js from a server.
HTTPS guarantees that the code you received is the code the server sent. It says nothing about whether the code the server sent is the code its developers actually published. If the server has been compromised and the code modified, HTTPS cannot help and will deliver the attacker’s version to the user.
Software you install elsewhere doesn’t work this way. When you install an app on your phone or laptop, it comes with a digital signature. Your operating system checks this signature prior to running it, and any tampering is detected.
For the web, however, website content is only as trustworthy as the server. If the server is compromised — whether by an attacker, a malicious insider, or a hosting provider under legal compulsion — it can serve whatever it wants. It can also target specific users, and serve one modified version of the website to them, while serving the original version to other users.
A user fetches badapp.js from a compromised server.
This is an unacceptable situation for a system like our whistleblower platform SecureDrop, where the confidentiality of source submissions relies on the code the server provides being authentic.
What WEBCAT does
WEBCAT is a tamper-evident seal for web applications.
Developers of web applications create a signed manifest that describes what their application should contain. When a user visits a site enrolled in WEBCAT, a browser extension verifies the code being served against the signed manifest before anything executes. If it doesn’t match, then the page doesn’t load.
The signatures and manifest data are also written to a public log. This transparency ensures that any changes to WEBCAT-enrolled sites are auditable and on the record for everyone. You know when you visit a WEBCAT-enrolled site that the code you are getting is the same code every other visitor gets.
WEBCAT verifies a site’s code against a publicly logged manifest before your browser executes it.
WEBCAT is in alpha today, with a Firefox extension available in the Firefox Add-on store. We’re developing this in an open, distributed manner, and are excited that other projects are interested in using WEBCAT. Browser vendors are also working on this problem, and eventually we’d love for this kind of verification to be built into browsers themselves.
While we built it for the next generation of SecureDrop, the problem it solves applies to the entire open web. Solving the problem of code integrity for web applications could be as important as HTTPS in keeping users safe.
