6 ms·

Given the prevalence of TLS, how much SIGINT can actually be done by tapping internet exchanges these days?

gigel82 3y ago
Presumably a government could also requisition the private key of several root authority certificates (whether or not they "proudly announce" that is another matter).
- repelsteeltje 3y ago
  Dutch government doesn't have a good reputation there, shepherding control over security infrastructure. First, it's primary CA lost is signing key to Iran, and recently they meant to outsource control over their ".nl" TLD to AWS.
  - mrngm 3y ago
    Small addendum on that, DigiNotar was one of the four CA's handing out "PKIoverheid" certificates, so certificates for governmental purposes. See this archived copy of the FAQ (in Dutch) after the DigiNotar breach, specifically the question "Hoe weet de overheid dat certificaten van de 3 andere bedrijven in Nederland die PKI-overheidscertificaten uitgeven wel betrouwbaar zijn?": https://web.archive.org/web/20111019224308/http://www.rijksoverheid.nl/documenten-en-publicaties/brochures/2011/09/05/vraag-en-antwoord-over-diginotar.html https://web.archive.org/web/20111019224308/http://www.rijkso...
- amenghra 3y ago
  A root CA key doesn't automatically decrypt the TLS traffic. You just need a single root CA key for a widely trusted CA to perform an active MITM attack. The attack is however likely to show up in Certificate Transparency logs.
vmoore 3y ago
Other metadata like DNS, device fingerprints, SNI-leakage[0], timestamps, connection history, etc You can encrypt DNS with DoH if you want, but the DoH provider still sees its you. You can take it a step further with Oblivious DNS over HTTPS if you really want to conceal DNS activity[1]. Note: this technology is rather new and experimental. [0] https://en.wikipedia.org/wiki/Server_Name_Indication https://en.wikipedia.org/wiki/Server_Name_Indication [1] https://research.cloudflare.com/projects/network-privacy/odns/ https://research.cloudflare.com/projects/network-privacy/odn...
- varenc 3y ago
  Another option is dnscrypt-proxy[0]. It will easily let you load-balance your DNS queries against a large set of resolvers, ensuring that no resolver gets the full picture. And enforces encryption of course. [0] https://github.com/DNSCrypt/dnscrypt-proxy https://github.com/DNSCrypt/dnscrypt-proxy
  - 1vuio0pswjnm7 3y ago
    "... ensuring that no resolver gets the full picture." Unless the resolvers share data with each other. These public DNSCrypt resolvers will publish claims like "no logging" but how does one verify this is a true statement. It may be better to use mutiple third party DNS resolvers, whether DoH or DNSCrypt, than to only use one, but the best course of action is not to use third party resolvers at all. The question I have for DNSCrypt fans is _why_ AFAICT no authoritative DNS servers are using it, e.g., https://github.com/cofyc/dnscrypt-wrapper https://github.com/cofyc/dnscrypt-wrapper Personally, instead of DNSCrypt, I prefer CurveDNS, https://github.com/curvedns/curvedns https://github.com/curvedns/curvedns There is at least one DNS forwarding service that offers CurveDNS. For those who might be confused: From https://dnscurve.org https://dnscurve.org "Do you run a DNS server that sends out DNS data? For example, do you run an "authoritative DNS server" such as tinydns or PowerDNS Server or BIND or NSD or MaraDNS or Nominum ANS to publish the IP addresses of your web server and mail server? This page explains the benefits of adding DNSCurve protection to your outgoing DNS data." DNSCurve protects outgoing data from authoritative DNS servers. I use CurveDNS experimentally in homelab in front of tinydns and nsd. It is easy to set up and it works great. Unfortunately not many authoritative DNS servers on the internet are using it even though it is easy to set up and works great (based on own experiments). As stated above, the best course of action is to avoid using third party DNS resolvers, i.e., public, shared caches. Instead one can run a local cache that sends DNSCurve-encrypted queries to remote authoritative DNS servers. For example, https://github.com/janmojzis/dq https://github.com/janmojzis/dq When using dq or dqcache, packets are _not_ sent "in the clear" for an ISP to sniff. But, as above, the number of authoritative DNS servers using CurveDNS is unfortunately small. The problem I see with DNSCrypt is it encourages use of third party DNS resolvers, i.e., shared caches. I use locally-stored DNS data. When I retrieve DNS data from the interet I retrieve it in bulk using a variety of methods and sources. An unconventional approach perhaps but it works great for me. Encrypted DNS is arguably pointless if one is using a popular browser that always sends SNI, even when SNI is not required, e.g., websites not using a CDN, or when visiting websites that do not support encrypted SNI, e.g., websites not using a CDN that supports encrypted SNI (ECH). Glad to see that the grandparent comment mentioned SNI.
repelsteeltje 3y ago
Start with phone lines. Or IP addresses. Even without looking into the encrypted payload there is so much you can learn from graphs connecting and the metadata.
mk89 3y ago
Considering they exchange technology with the USA and other states, I am pretty sure that you can find some malware to install on specific actors's devices (routers/phones/etc.) to have traffic decrypted. I am decently sure that some state agencies help design routers.... if you know what I mean :)
jrockway 3y ago
In addition to what's mentioned in the comments, timing attacks are also possible. If you see what time every packet is sent and received, then you can correlate streams with each other. This is how they figure out who is visiting what Tor websites; you compromise the network of the website, then the network of potential clients, and then you match up the packets. Now they know you visited the website even though you never actually sent a packet addressed to it.
jasonvorhe 3y ago
Just being able to analyze the network connections to apply filters and visualizations upon, providing optional deep dives into certain cohorts to create reports or even forecasts is a totalitarian wet dream.

Presumably a government could also requisition the private key of several root authority certificates (whether or not they "proudly announce" that is another matter).

repelsteeltje 3y ago
Dutch government doesn't have a good reputation there, shepherding control over security infrastructure. First, it's primary CA lost is signing key to Iran, and recently they meant to outsource control over their ".nl" TLD to AWS.
- mrngm 3y ago
  Small addendum on that, DigiNotar was one of the four CA's handing out "PKIoverheid" certificates, so certificates for governmental purposes. See this archived copy of the FAQ (in Dutch) after the DigiNotar breach, specifically the question "Hoe weet de overheid dat certificaten van de 3 andere bedrijven in Nederland die PKI-overheidscertificaten uitgeven wel betrouwbaar zijn?": https://web.archive.org/web/20111019224308/http://www.rijksoverheid.nl/documenten-en-publicaties/brochures/2011/09/05/vraag-en-antwoord-over-diginotar.html https://web.archive.org/web/20111019224308/http://www.rijkso...
amenghra 3y ago
A root CA key doesn't automatically decrypt the TLS traffic. You just need a single root CA key for a widely trusted CA to perform an active MITM attack. The attack is however likely to show up in Certificate Transparency logs.

vmoore 3y ago

Other metadata like DNS, device fingerprints, SNI-leakage[0], timestamps, connection history, etc You can encrypt DNS with DoH if you want, but the DoH provider still sees its you. You can take it a step further with Oblivious DNS over HTTPS if you really want to conceal DNS activity[1]. Note: this technology is rather new and experimental. [0] https://en.wikipedia.org/wiki/Server_Name_Indication https://en.wikipedia.org/wiki/Server_Name_Indication [1] https://research.cloudflare.com/projects/network-privacy/odns/ https://research.cloudflare.com/projects/network-privacy/odn...

varenc 3y ago
Another option is dnscrypt-proxy[0]. It will easily let you load-balance your DNS queries against a large set of resolvers, ensuring that no resolver gets the full picture. And enforces encryption of course. [0] https://github.com/DNSCrypt/dnscrypt-proxy https://github.com/DNSCrypt/dnscrypt-proxy
- 1vuio0pswjnm7 3y ago
  "... ensuring that no resolver gets the full picture." Unless the resolvers share data with each other. These public DNSCrypt resolvers will publish claims like "no logging" but how does one verify this is a true statement. It may be better to use mutiple third party DNS resolvers, whether DoH or DNSCrypt, than to only use one, but the best course of action is not to use third party resolvers at all. The question I have for DNSCrypt fans is _why_ AFAICT no authoritative DNS servers are using it, e.g., https://github.com/cofyc/dnscrypt-wrapper https://github.com/cofyc/dnscrypt-wrapper Personally, instead of DNSCrypt, I prefer CurveDNS, https://github.com/curvedns/curvedns https://github.com/curvedns/curvedns There is at least one DNS forwarding service that offers CurveDNS. For those who might be confused: From https://dnscurve.org https://dnscurve.org "Do you run a DNS server that sends out DNS data? For example, do you run an "authoritative DNS server" such as tinydns or PowerDNS Server or BIND or NSD or MaraDNS or Nominum ANS to publish the IP addresses of your web server and mail server? This page explains the benefits of adding DNSCurve protection to your outgoing DNS data." DNSCurve protects outgoing data from authoritative DNS servers. I use CurveDNS experimentally in homelab in front of tinydns and nsd. It is easy to set up and it works great. Unfortunately not many authoritative DNS servers on the internet are using it even though it is easy to set up and works great (based on own experiments). As stated above, the best course of action is to avoid using third party DNS resolvers, i.e., public, shared caches. Instead one can run a local cache that sends DNSCurve-encrypted queries to remote authoritative DNS servers. For example, https://github.com/janmojzis/dq https://github.com/janmojzis/dq When using dq or dqcache, packets are _not_ sent "in the clear" for an ISP to sniff. But, as above, the number of authoritative DNS servers using CurveDNS is unfortunately small. The problem I see with DNSCrypt is it encourages use of third party DNS resolvers, i.e., shared caches. I use locally-stored DNS data. When I retrieve DNS data from the interet I retrieve it in bulk using a variety of methods and sources. An unconventional approach perhaps but it works great for me. Encrypted DNS is arguably pointless if one is using a popular browser that always sends SNI, even when SNI is not required, e.g., websites not using a CDN, or when visiting websites that do not support encrypted SNI, e.g., websites not using a CDN that supports encrypted SNI (ECH). Glad to see that the grandparent comment mentioned SNI.

repelsteeltje 3y ago

Start with phone lines. Or IP addresses. Even without looking into the encrypted payload there is so much you can learn from graphs connecting and the metadata.

mk89 3y ago

Considering they exchange technology with the USA and other states, I am pretty sure that you can find some malware to install on specific actors's devices (routers/phones/etc.) to have traffic decrypted. I am decently sure that some state agencies help design routers.... if you know what I mean :)

jrockway 3y ago

In addition to what's mentioned in the comments, timing attacks are also possible. If you see what time every packet is sent and received, then you can correlate streams with each other. This is how they figure out who is visiting what Tor websites; you compromise the network of the website, then the network of potential clients, and then you match up the packets. Now they know you visited the website even though you never actually sent a packet addressed to it.

jasonvorhe 3y ago

Just being able to analyze the network connections to apply filters and visualizations upon, providing optional deep dives into certain cohorts to create reports or even forecasts is a totalitarian wet dream.