There is a fundamental problem with traditional phishing reporting: if the user submits a URL and claims that it is malicious, how do you know that what you see is what the user sees? Phishing scanning is just web scraping, and services like Cloudflare are designed to prevent automated scraping with CAPTCHAs and other mitigations. In addition, most drainers now employ various forms of cloaking to ensure that the request is legitimate. This includes checking for various query parameters, the HTTP Referer header, and even requesting IP.
At SEAL, we consistently receive an overwhelming number of reports of phishing sites which were clearly malicious based on a cursory review of just the domain name. However, while we could have confidence that our users were reporting content in good faith, blindly relying on hostname-based heuristics in a world where legitimate domains sometimes look as suspicious as phishing domains is also a sure path to false positives.
In the end, we decided that we needed a new approach, one that would allow us to see exactly what the user sees, so we could accurately evaluate whether there was malicious content being served on a domain. Our solution is TLS Attestations.
TLS 101
Recall that the TLS handshake initially uses asymmetric cryptography in order to verify that the server has a valid certificate for the hostname it claims to represent. This is because asymmetric encryption allows for both a private key for signing and a public key for verifying, and certificate authorities need to allow users to verify certificates without being able to sign them.
However, asymmetric cryptography is slow and computationally expensive, so after exchanging certificates, the next step is to negotiate a symmetric key using Diffie-Hellman Key Exchange. The server signs its selected DH parameters which the client can verify. This proves the server’s identity while also allowing both parties to arrive at a shared symmetric key, even while communicating over a potentially untrusted channel. All further records are encrypted using this symmetric key.
Unfortunately, symmetric encryption shares a key for encryption and decryption. This means that once the shared key is negotiated, either party can produce a transcript of a TLS session which claims whatever they would like. The third party verifier would have no way of knowing whether the encrypted records were sent by the server, or forged by the client. This in turn makes it impossible to naively trust a TLS session transcript produced by a client, even if the initial handshake is valid.
TLS Attestation
There already exists a solution to this problem called TLSNotary, an open source protocol which uses MPC to ensure that both the user as well as a third-party notary must work together in order to encrypt/decrypt data within the TLS stream. It preserves privacy for the user, as the notary does not get to see the underlying plaintext unless it is selectively revealed, and it protects the user from a malicious notary injecting arbitrary plaintext into the TLS stream. However, TLSNotary is also computationally expensive and generates proofs which are an order of magnitude larger than the underlying data being transferred. Therefore, it is not a viable solution for high volume attestations.
Instead, we have designed TLS Attestations, a system which sacrifices the privacy and trust guarantees in exchange for efficiency and throughput. TLS Attestations features two components: a client-side HTTP proxy which the user must run, as well as a server-side attestation server which is assumed to be trusted.
First, the HTTP proxy determines whether a specific connection should be attested. If not, it directly forwards the request to the remote host. Otherwise, it terminates the TLS connection with a self-signed certificate that must be installed ahead of time. It also captures the original ClientHello and sends it to the attestation server.
The attestation server uses the captured ClientHello in order to perfectly mimic the original client, defeating potential JA3/JA4 fingerprinting techniques. The attestation server then creates a new TLS client, but crucially does not establish the underlying TCP connection. Rather, the original user is expected to open the connection, while the attestation server acts as an cryptographic oracle that handles all TLS operations, encrypting client plaintext and decrypting server ciphertext. The attestation server then sends the relevant outputs (encrypted client ciphertext and decrypted server plaintext) back to the end user. This allows the user to still interact with the remote server over TLS, but prevents the user from being able to forge responses from the server, as they do not know the shared key being used.
Even if the user opts to open a TCP connection to a completely different host, the attestation server will perform standard certificate verification routines, which means that the only thing that matters is if the server is able to present a valid signed certificate.
Once the stream is complete, the attestation server signs a message attesting to a hash of the entire TLS transcript, the observed certificate chain, and other relevant metadata. The user is now able to present this attested session as needed.
Verifiable Phishing Reports
SEAL is leveraging TLS Attestations in our new Verifiable Phishing Reports program. Through this program, users can submit attestations for sites which they believe contain phishing content. We will then verify the submission and ensure that it is both properly signed and also contains evidence of malicious activity. This allows us to focus on identifying and mitigating specific variants of phishing kits, while allowing legitimate users to perform the actual requests to the phishing kits. This makes it much harder for phishing kits to determine whether they should serve the malicious payload, or a benign cloaked website.
We have been testing Verifiable Phishing Reports in private beta for over a month now, and we’re excited to see power users and researchers incorporate it into their toolkits. To get started, click here.