In addition to the fact that the [clown] world relies on certificate authorities remaining honest for HTTP Secure to do what it actually advertises, there is another standing issue that erodes my zeal to keep scrapping together workarounds.
One might argue that having many sites hosted behind the same server and IP might paradoxically help to obfuscate the sites one visits from snooping ISPs, such as those which might reversely resolve domains associated to server IPs. Even the average Joe can do this with something like:
dig @<some LARGE resolver> -x <ip address> +short
However, such obfuscation gets foiled by a shortcoming in Server Name Indication. SNI introduces an opportunity during any TLS handshake for an observer to obtain which site is being requested. The indicated hostname is not encrypted within the Client Hello of TLS handshakes and, at first glance, apparently cannot be out of design necessity.
There have been attempts to extend the standard for certificate request encryption, first with eSNI and later ECH. But these standards have run up against obstacles with big tech, namely Goolag, FBIbook and Amazog, failing to support eSNI. I’ve been informed that this is deliberate as the likes of big tech are afraid of being excluded from the massive Chinese market. If unencrypted TLS hello is adequately naked for China to spy on their subjects, then what does that mean for everyone else who must use it?
This compounds the issue of global adversaries with visibility into large swaths of internet traffic. A colleague and I were discussing recent light shed on the new commercial market surrounding netflow data which raised the question as to how badly this compromises even the privacy-consious techies. Some expressed concern that this could be used to “tag” and foil traffic concealed in the likes of Tor or in VPN connections.
One of the concerns long held by Tor developers is that the size of data transmitted can itself be used to correlate traffic. This is why they recommend against large file transfer over the Tor network. It may be adequately encrypted, but a global passive observer (using something like netflow data) might be able to look at the total size of upload bandwidth entering a Guard node, and associate it to an identical usage leaving an exit node to a clearnet server at the same time.
Maybe this could be addressed by padding all Tor traffic to a common size using junk data but would also massively decrease effeciency and throughput of the already constrained network. Such a padding method is actually used in v2ray-core, a derivative of shadowsocks common at one point for circumventing the aggressive Chinese firewall. This is only to illustrate that said “tagging” doesn’t have to be done within the “tunnel” of a VPN, but only by taking and comparing notes from either end.
And data brokers are well positioned to exploit this. Team Cymru, a netflow aggregator, make some extraordinary claims in their promotional material.
“Team Cymru’s product letting users trace the activity of servers linked to an Iranian hacking group further than other datasets, such as DNS lookups.”
I would be very interested to see if that group was doing anything at all to protect their DNS queries, or if they were just foolishly using plain old naked 1970s DNS resolution.
““Are any DoD components buying and using without a court order internet metadata, including ’netflow’ and Domain Name System (DNS) records,” the question read.”
The fact that senator Wyden’s office felt it necessary to specifically mention DNS records in this question is fairly telling as to how much they probably lean on that old and yet to be fixed standard in order to amass their “broadest collection of global telemetry”. So encrypting one’s DNS requests (and not through the lazy and poorly implemented DoH!) should mitigate some of this collection method.
“Through these relationships, Cortex Xpanse has access to a sample of approximately 80% of global flows,”
A textbook global adversary. Just in case anyone thought the aforementioned techies were just being paranoid in the extent of our countermeasures.