This recomputes the blocking status of the signal measurement in the data pipeline by doing TLS certificate chain validation using the two known root CAs of signal.
It has the following caveats, which I defer to future work:
It's not taking into account any sort of ground truth for DNS consistency checks. It's only able to say something is consistent or inconsistent based on the results of the TLS handshake, but the issue is that we don't measurement the TLS reachability of all the IPs which we resolved, so we might be missing some of them. In the future we might want to use data coming from other measurements as a source of ground truth for consistency checking.
The TLS chain validation logic is fairly basic and should not be used for anything too serious. We might want to in the future enrich it. We also don't do any checks on the common name or SAN list in the leaf certificate. Probably this is fine for Signal, but if we are to use something similar for other tests we should practice care when implementing that.
This recomputes the blocking status of the signal measurement in the data pipeline by doing TLS certificate chain validation using the two known root CAs of signal.
It has the following caveats, which I defer to future work: