A rare move showing grace on behalf of the government, but the fact that the decision was made first, followed subsequently by a backtrack is still alarming.
I'm an American working from Thailand for the past decade or so, and this strategy is relatively common for the governments around here.
It's chaotic. They will usually have mid level officials announce some new policy as if it's a done deal.
Then, if there's no public outcry, a higher level official will confirm it and maybe, eventually, details will roll out.
If the public responds very negatively, the idea will just disappear or the higher level guy can distance himself from the low level guy "who was misinformed".
I think it's how they test the water and decide if it's worth the effort.
When one tries to visit some sites like LibGen, DNS is redirected to a "no-no you shouldn't go there" page, which in turn redirects to this official finger-wagging page: https://opi.gr/edppi_block/edppi_block.html
DNS hijacking was also used during the beginning of the Ukraine affair as part of an EU-wide censorship push, blocking sites like the Kremlin and Pravda, though without further redirection.
1. Blocking or redirecting some pages when using the ISP's DNS server. This is what you're talking about. The workaround is to use a third party DNS resolver.
2. Intercepting all unencrypted DNS traffic to any DNS server and redirecting it to the ISPs' DNS servers. This is what Malaysia was planning to do.
As is Germany with the "CUII" where every relevant ISP DNS-blocks "copyright-violating" sites without a court decision. And of course EU-wide where f.e. RT is blocked (not vetoed by a court or parliament).
Tangential question: how are IP addresses in certificates validated? Cloudflare was subject to a BGP hijack of the 1.1.1/24 prefix, how does it prevent someone from running a malicious DNS server?
It’s still imperfect AFAIK. Your provider may or may not have upstream routers speaking BGP and running RPKI validation at ASN boundaries which validate prefixes against certificates blessed by the appropriate RIRs (maybe analogous to CAs for routes). Since you mentioned Cloudflare I’ll just cut to the chase and link an instance of their blog on the subject : https://blog.cloudflare.com/rpki/
First example of imperfection which springs to mind first for me are misconfigurations in the network which ultimately allow for leaks to be accepted. IMHO this compounded with the nature of DNS recursion across name authorities on the far side of any ASN boundaries (that may be out of your provider’s control) makes any assurances weak at best when searching for name resolution trust.
(Edit : oh and I think DNSSEC is probably another layer worth considering. But it’s also inconsistently deployed.)
(Second edit : Sorry! I made a mental leap to RPKI when I saw “BGP hijack”, “certificate”, & “IP addresses”. IIRC a webserver’s x509 certificates don’t contain an OID of any inaddr{,6}, nor cidr type. i.e. a browser doesn’t verify a httpd’s ip against anything in the cert vended. Only that the cert is signed by a chain leading to a CA trusted by the client/browser(s).)
Generally when you configure DoH, you either choose a provider from a list of options or enter both an IP and a hostname manually. With a host name it has enough to use to verify the identity of the server to prevent spoofing/a malicious server.
Technically it's possible to specify an IP address in a X.509 certificate. With OpenSSL you'd do something like that when issuing new certificate:
subjectAltName=IP:192.168.1.1
And that's actually exactly what Google's 8.8.8.8 and Cloudflare's 1.1.1.1 use in their certificates.
Also both issuers use certificate transparency [0], so BGP hijack shouldn't affect this — sure, your system might try to connect to hijacked IP, but TLS connection will fail due to invalid certificate (assuming certificate trust chain wasn't compromised and there are no malicious CAs installed on your system).
> sure, your system might try to connect to hijacked IP, but TLS connection will fail due to invalid certificate
I think the parent is asking if malicious actor can issue a certificate in case of BGP hijack. I think they could, but then it would be visible in the CT log.
Nah StrLght set me straight. I really didn't know how an IP address was embedded in a certificate, and I was viewing the output of the certificate from the lens of openssl s_client -connect 1.1.1.1:443 which obscures the fact that there's more than CN=cloudflare-dns.com.
I think it'd be pretty hard to get a certificate for 1.1.1.1 after a BGP hijack, unless you had some control over a CA. I don't think LetsEncrypt issues certificates for IPs.
Depends on ISP. Earlier this week before today’s u-turn:
-Digi redirected ALL traffics on destination port 53 to their own DNS server. Thus DoH unaffected.
-Maxis redirected traffics from some mainstream public DNS servers (Google, Cloudflare, Quad9) on destination port 53 to their own DNS server. Thus DoH unaffected.
-TM is the most evil, they redirected traffics from some mainstream public DNS servers (Google, Cloudflare, Quad9) on all ports to its own DNS server. DoH and DoT failed due to certificate error.
stubby is a localhost DNS proxy that can work for any app | browser | etc. on a network and use DoT or DoH to any of the common providers.
Given the ease with which national ISPs can MiTM these | intercept calls to Cloudflare | Quad9 | AdGuard etc. it might be good to extend either stubby or it's docs to let people know how to use it access | establish a much broader DNS proxy network to allow for indirect non obvious lookups.
Because I've used it as an "or" symbol in a non unique common as muck manner since 1980 at least when I was taught Boolean logic in an undergraduate university mathematics class.
It's one of many conventional symbols for OR, more common in the pure ASCII days due to a lack of ∧ , ∨ , ¬ et al.
Which rock have you lived under that you've never seen it used an OR before?
People imposing their limited experience of the wide world upon others would certainly irk some, but rest easy, I've not taken offence at your odd assumption of non existent universal convention.
To be fair, I've never seen it used in prose like that, and had trouble understanding your comment at first. I did university boolean logic 30 years ago and have been on the internet in programming communities nearly as long.
Sure, different groups have different conventions. I've been commenting on internet forums, threads, and groups since pre WWW Usenet, using | as OR (though more often as { A | B | C }, seen others use the same convention and this is the very first time anyone has ever claimed it as a unique quirk.
I appreciate | as OR because (like its non-ascii cousin ∨) it uses an lr-symmetric glyph to denote a commutative operation.
EDIT: Backus uses the asymmetric overbarred "or" in 1959, but by 1963 the | we know and love has already taken its place (that ASCII standardisation didn't start until 1961 may have something to do with this?)
It'd make sense if you were writing out some Boolean expressions or trying to present something with formal logic. But you're writing English here so it seems inappropriate to a) ditch conventional grammar and b) pass off the criticism as "imposing their limited experience".
> that can work for any app | browser | etc. on a network
That is an English clause, not a mathematical expression. You even have the abbreviated form of et cetera there.
> non existent universal convention
In English there is a convention for listing alternatives: commonly forward-slashes with no space between them, like 'this/that', or with commas and conjunctions, like 'this, or that'. Or make your life easy, and use some other collective noun such as 'platforms'.
> a lack of ∧ , ∨ , ¬ et al.
English convention dictates 'et al' (or et alia) be used to list authors or people, rather than inanimate objects. Or you could use a collective noun here, too: 'mathematical symbols'.
There is a lot of confusion in this thread and in a separate thread discussing the Malaysian DNS redirect legislation where people confound privacy with resistance to censorship. Whilst both do possess a certain degree of overlap, resistance to censorship requires a fundamentally different approach that does not fit within constraints of the DNS framework.
DNS has a decentralised architecture designed to be resilient to failures.
DoT, DoH and similar address the privacy aspect of the unencrypted by default DNS traffic.
None of the existing DNS, DNS extensions, DoT, DoH can circumvent serious censorship attempts at scale due to name resolution requests being encapsulated in an IP packet that exposes enough metadata that (destination address and port number) to allow the packet to be altered, redirected, dropped or blackholed even if the packet is encrypted or obfuscated. Traffic bound to a specific IP address or to a specific TCP or UDP port is the easiest to curb, it does not even require the manual intervention and is widely used by intrusion detection systems to automatically block the detected in real time malicious traffic.
The censorship resistance requires a complete replacement of DNS that would be akin to the GNU Naming System[0], which fulfils all three objectives: it is a decentralised, privacy-preserving, censorship-resistant domain name resolution protocol.
Having gone through https://dnsprivacy.org/ (which is very disorganised, to be fair), I fail to see how stubby could be of any help due to still requiring a upstream DNS server of sorts somewhere, which will be blocked if not automatically then very quickly albeit manually anyway.
I agree fully with the first, partially agree with the second; the DNSPrivacy site needs an overhaul and seems a few years out of date but it does cover most of the privacy related lurks.
As you said the "stubby" | "getdns" module is good enough for privacy, it's no more than a local service shim layer between anything local requiring DNS via a variety of means, all of which can be censored.
I did suggest it could use extension .. and a network of distributed peers to extend to.
It's a project for anyone minded to take it up .. create a secure obfuscated distributed stubby net that can try DoT DoH etc in situ and should they work provide that service to others else fallover to reaching out to others to find peers that can access authorised DNS.
The Windows Portmaster project is an interesting one; it provides a level of network inspection and control to advanced regular users, stubby-like getdns functionality that's a bit easier to use, and offers a VPN layer to subscribers for data.
If the Portmaster maintainers are true to their vision I can see them adding obfuscated distributed DNS to subscribers in the near to mid future depending how they allocate resources and who they onboard now they have funds for a new hire (last I checked, I could be out of date here).
> He stressed that cybercrime issues, including access to gambling, prostitution and pornography websites, are extremely concerning and demand comprehensive solutions
They are not exactly backtracking but it seems that some of the involved parties didn't like the solution proposed (DNS redirection) and want to discuss other alternatives.
I'm currently in Malaysia. TM, the biggest public facing ISP here goes a step further by also ssl mitm-ing Google dns and Cloudflare dns DoH endpoint. Their idea is to hijack and route all query intended for both to their own DoH server. Obviously browsers showed big red warning about the attack since users explicitly setup their browser to use Google or Cloudflare DoH but instead being hijacked and routed to TM's own DoH endpoint. The whole ordeal is so baffling, i wonder which senior network admin at TM give that a go, or whether TM actually got competent network admin at all.
With that single misstep, suddenly the people realized if they could (and did) mitm Google and Cloudflare dns endpoint, they could mitm Gmail, Outlook, Riotgames, Facebook, Tiktok or whatever too. Public outcry comes pouring in and the Minister of Comm backtracked.
47 comments
[ 3.1 ms ] story [ 113 ms ] threadIt's chaotic. They will usually have mid level officials announce some new policy as if it's a done deal.
Then, if there's no public outcry, a higher level official will confirm it and maybe, eventually, details will roll out.
If the public responds very negatively, the idea will just disappear or the higher level guy can distance himself from the low level guy "who was misinformed".
I think it's how they test the water and decide if it's worth the effort.
When one tries to visit some sites like LibGen, DNS is redirected to a "no-no you shouldn't go there" page, which in turn redirects to this official finger-wagging page: https://opi.gr/edppi_block/edppi_block.html
DNS hijacking was also used during the beginning of the Ukraine affair as part of an EU-wide censorship push, blocking sites like the Kremlin and Pravda, though without further redirection.
1. Blocking or redirecting some pages when using the ISP's DNS server. This is what you're talking about. The workaround is to use a third party DNS resolver.
2. Intercepting all unencrypted DNS traffic to any DNS server and redirecting it to the ISPs' DNS servers. This is what Malaysia was planning to do.
It's even been ordered to close by a US court (according to Wikipedia). Obviously they ignored that as they are not in the US...
First example of imperfection which springs to mind first for me are misconfigurations in the network which ultimately allow for leaks to be accepted. IMHO this compounded with the nature of DNS recursion across name authorities on the far side of any ASN boundaries (that may be out of your provider’s control) makes any assurances weak at best when searching for name resolution trust.
(Edit : oh and I think DNSSEC is probably another layer worth considering. But it’s also inconsistently deployed.)
(Second edit : Sorry! I made a mental leap to RPKI when I saw “BGP hijack”, “certificate”, & “IP addresses”. IIRC a webserver’s x509 certificates don’t contain an OID of any inaddr{,6}, nor cidr type. i.e. a browser doesn’t verify a httpd’s ip against anything in the cert vended. Only that the cert is signed by a chain leading to a CA trusted by the client/browser(s).)
subjectAltName=IP:192.168.1.1
And that's actually exactly what Google's 8.8.8.8 and Cloudflare's 1.1.1.1 use in their certificates.
Also both issuers use certificate transparency [0], so BGP hijack shouldn't affect this — sure, your system might try to connect to hijacked IP, but TLS connection will fail due to invalid certificate (assuming certificate trust chain wasn't compromised and there are no malicious CAs installed on your system).
[0]: https://crt.sh/?q=1.1.1.1
I think the parent is asking if malicious actor can issue a certificate in case of BGP hijack. I think they could, but then it would be visible in the CT log.
I think it'd be pretty hard to get a certificate for 1.1.1.1 after a BGP hijack, unless you had some control over a CA. I don't think LetsEncrypt issues certificates for IPs.
Not sure if it's a problem with my setup or if it's not very robust in general.
-Digi redirected ALL traffics on destination port 53 to their own DNS server. Thus DoH unaffected.
-Maxis redirected traffics from some mainstream public DNS servers (Google, Cloudflare, Quad9) on destination port 53 to their own DNS server. Thus DoH unaffected.
-TM is the most evil, they redirected traffics from some mainstream public DNS servers (Google, Cloudflare, Quad9) on all ports to its own DNS server. DoH and DoT failed due to certificate error.
https://dnsprivacy.org/
stubby is a localhost DNS proxy that can work for any app | browser | etc. on a network and use DoT or DoH to any of the common providers.
Given the ease with which national ISPs can MiTM these | intercept calls to Cloudflare | Quad9 | AdGuard etc. it might be good to extend either stubby or it's docs to let people know how to use it access | establish a much broader DNS proxy network to allow for indirect non obvious lookups.
People having their unique implementation of punctuation marks irks me...
It's one of many conventional symbols for OR, more common in the pure ASCII days due to a lack of ∧ , ∨ , ¬ et al.
Which rock have you lived under that you've never seen it used an OR before?
People imposing their limited experience of the wide world upon others would certainly irk some, but rest easy, I've not taken offence at your odd assumption of non existent universal convention.
EDIT: Backus uses the asymmetric overbarred "or" in 1959, but by 1963 the | we know and love has already taken its place (that ASCII standardisation didn't start until 1961 may have something to do with this?)
https://www.softwarepreservation.org/projects/ALGOL/paper/Ba...
https://dl.acm.org/doi/pdf/10.1145/366193.366201
> that can work for any app | browser | etc. on a network
That is an English clause, not a mathematical expression. You even have the abbreviated form of et cetera there.
> non existent universal convention
In English there is a convention for listing alternatives: commonly forward-slashes with no space between them, like 'this/that', or with commas and conjunctions, like 'this, or that'. Or make your life easy, and use some other collective noun such as 'platforms'.
> a lack of ∧ , ∨ , ¬ et al.
English convention dictates 'et al' (or et alia) be used to list authors or people, rather than inanimate objects. Or you could use a collective noun here, too: 'mathematical symbols'.
DNS has a decentralised architecture designed to be resilient to failures.
DoT, DoH and similar address the privacy aspect of the unencrypted by default DNS traffic.
None of the existing DNS, DNS extensions, DoT, DoH can circumvent serious censorship attempts at scale due to name resolution requests being encapsulated in an IP packet that exposes enough metadata that (destination address and port number) to allow the packet to be altered, redirected, dropped or blackholed even if the packet is encrypted or obfuscated. Traffic bound to a specific IP address or to a specific TCP or UDP port is the easiest to curb, it does not even require the manual intervention and is widely used by intrusion detection systems to automatically block the detected in real time malicious traffic.
The censorship resistance requires a complete replacement of DNS that would be akin to the GNU Naming System[0], which fulfils all three objectives: it is a decentralised, privacy-preserving, censorship-resistant domain name resolution protocol.
Having gone through https://dnsprivacy.org/ (which is very disorganised, to be fair), I fail to see how stubby could be of any help due to still requiring a upstream DNS server of sorts somewhere, which will be blocked if not automatically then very quickly albeit manually anyway.
[0] https://datatracker.ietf.org/doc/html/rfc9498
> I fail to see how stubby could be of any help
I agree fully with the first, partially agree with the second; the DNSPrivacy site needs an overhaul and seems a few years out of date but it does cover most of the privacy related lurks.
As you said the "stubby" | "getdns" module is good enough for privacy, it's no more than a local service shim layer between anything local requiring DNS via a variety of means, all of which can be censored.
I did suggest it could use extension .. and a network of distributed peers to extend to.
It's a project for anyone minded to take it up .. create a secure obfuscated distributed stubby net that can try DoT DoH etc in situ and should they work provide that service to others else fallover to reaching out to others to find peers that can access authorised DNS.
The Windows Portmaster project is an interesting one; it provides a level of network inspection and control to advanced regular users, stubby-like getdns functionality that's a bit easier to use, and offers a VPN layer to subscribers for data.
If the Portmaster maintainers are true to their vision I can see them adding obfuscated distributed DNS to subscribers in the near to mid future depending how they allocate resources and who they onboard now they have funds for a new hire (last I checked, I could be out of date here).
They are not exactly backtracking but it seems that some of the involved parties didn't like the solution proposed (DNS redirection) and want to discuss other alternatives.
With that single misstep, suddenly the people realized if they could (and did) mitm Google and Cloudflare dns endpoint, they could mitm Gmail, Outlook, Riotgames, Facebook, Tiktok or whatever too. Public outcry comes pouring in and the Minister of Comm backtracked.