Network data isn't supposed to be secret, and in fact I wish more networks would publish samples of data that passes through the network so users inadvertently not using encryption can be alerted.
> The faulty signatures we observed allowed us to compute private RSA keys associated with a top-10 Alexa site, several browser-trusted wildcard certificates for organizations that used a popular VPN product, and a small sporadic population of other web sites and network devices.
> It is well known in the cryptographic literature that the most common digital signature schemes used in practice can fail catastrophically in the presence of faults during computation. We use passive and active network measurements to analyze organically-occuring faults in billions of digital signatures generated by tens of millions of hosts. We find that a persistent rate of apparent hardware faults in unprotected implementations has resulted in compromised certificate RSA private keys for years. The faulty signatures we observed allowed us to compute private RSA keys associated with a top-10 Alexa site, several browser-trusted wildcard certificates for organizations that used a popular VPN product, and a small sporadic population of other web sites and network devices. These measurements illustrate the fragility of RSA PKCS#1v1.5 signature padding and provide insight on the risks faced by unprotected implementations on hardware at Internet scale.
However, I do not believe modern computational devices are so unreliable. If I computed 200 million TLS exchanges on my home PC over a few days, I wouldn't expect a single one to be miscomputed. Servers with ECC memory ought to be another order of magnitude more reliable.
So why do we see such high rates of miscomputation?
> The three private keys revealed by the 11 faulty [RSA] signatures in our [passively observed] data were associated with three certificates that were served from four different IP addresses associated with Baidu. [...]
> After we disclosed to Baidu, they informed us that the traffic we observed was between the clients and Baidu’s golang-based L7 load balancer BFE which offloads cryptographic operations like signature generation to a hardware accelerator. [...] Based on the temporal pattern of signature errors we observed, we hypothesize that the errors may have been due to a single failing hardware component which then passed vulnerable signatures through the unprotected software implementation.
https://github.com/golang/go/issues/13515 https://github.com/golang/go/issues/13907
Peter Gutmann mentions in the cryptlib documentation that the extra check makes RSA signatures 10% slower, so I assume it's tempting to patch it out (or not add it in the first place).
