Privacy Canaries: A better tweety bird

Warrent Canaries

A warrant canary is a statement that declares that an organization has not taken certain actions or received certain requests for information from government or law enforcement authorities. Many services use warrant canaries to let users know how private their data is. There are even attempts to formulize to a standard such as Canarytail.

Though the standard exposes a lot of meta data about the types of request of information and related nature of hush order issued doing the case which could potentially lead to legal issues.

What Warrent Canaries are trying to solve is a public trust and disclosure issue with a simple ascii text file that disclosures as of a date and time that an entite has not been issued any legal actions to disclosure user data to law enforcement or intelligence agencies. Tipically this statement includes a timestamp, a text block of the attestation, and a pgp signature of the attestation. The text file is usually located as canary.txt in the same locations as a robots.txt, security.txt, and humans.txt either /.well-known/canary.txt or / of the site.

How to improve

While having a statement in one’s Privacy page is a great start. It is in this author’s option that any url and pgp signed content can been exploited in some manner or gone unnoticed.

So lets break down the solution. We have:

1. a timestamp
2. an attestation that when exists is trusted but missing the whole service is invalid
3. an cryptographic signature with of the above attributes
4. a cryptographic varifable issuer identy
5. a ring of trust been service provider and end user

Sounds lot like two established core systems in a trusted computing network. SSL and DKIM.

Adding a signed attestation to a TXT record for DNS record on the root of the domain then extending the SSL certificate’s SAN attibutes to include the attestation automatically bakes the Canary into the existing infrastructure.

Why DNS and SSL Certs

Simplely put we have well established the network is a source of truth. Not the endpoint or client. Canarytail sets up yasaas with client and endpoint trust plus exposes risk of legal recourse. While using a text file places trust in users to actively validate on thier own or even have the issuing body publicly announce the canary and its removial. We known by now a Human factor is always falable.

Instead by adding a single attribute to the domain’s SSL certificate and an attestation DNS record then when the Canary is triggered the issuer only needs to remove the DNS record for both the SSL certificate and Canary to be invalid. Further more when one revokes the Canary attribute and reissue the certificate all end clients will receive instant notice of when the Canary and service is no longer trusted.

Why not a response header, just a DNS record, or blockchain

First both response headers and DNS records are able to be intercepted, overwriten on the fly, misconfigured, or even generated dynamically.

While DNS is a distributed ledger and with Proper DKIM and domain security setup one can trust the zone of authority for the attestation but misses half the solution’s goals. Having a SSL certificate involved solves for end clients instantly being alerted at the handshake.

As for a blockchain that in itself is not intergrated into the common every day web. Only #cryptobros and cypherpunks would look to very an attestation which is exactly the same issue using a canary.txt file minus any sort of logging/monitoring infrastructure on the canary.

Logging

SSL certificate failures are well known and how to fix.

Logging for HTTP Status code 526 is an instant alert for both servers and clients that the Canary has died. This works even with WAFS since some of the common causes of this are:

• The certificate has expired
• The certificate has been revoked
• The certificate is self-signed
• Your website configuration is serving a certificate for the wrong domain

Note two key parts hear; certificate been revoked and/or invalid domain. The exact parts we are looking to validate of the canary’s attestation.

Examples

Given a canary has died and an issuer has revoked the certificate then one will see something like the following.

$ getent host canary.dapla.net

<pgp ascii armor attestation>

$ openssl s_client -connect canary.dapla.net:443 -status -msg -debug

<<< TLS 1.3, Alert [length 0002], fatal handshake_failure
    02 28
4027024682740000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:../ssl/record/rec_layer_s3.c:907:SSL alert number 40

In this Case the domain still exists within DNS Caches but the attesation is instantly failed when revoked and the ascii armor signature no longer matches.

Revoking the DNS record still has the same effect but incures a delay of Propergation.

Adding the records is simple. The certificate SAN is updated with the Canary sub domain then the fingerprint of the certrtificate is added to the DNS domain as a TXT record.