Ask HN: How does my school block DoH?

It's possible that they're now telling the firewall to block sites based on SNI or IP address, which is separate from the DNS mechanism.

If you know the correct IP address for a site, you can use curl or openssl to connect to the blocked site by IP address (but still sending SNI), like

  openssl s_client -connect 93.184.215.14:443 -servername example.com

You can also try not sending SNI, which will remove one means that the firewall might be using to block your connection, but will also likely make the connection not work for server-side reasons if it's hosted on a shared server or CDN.

  openssl s_client -connect 93.184.215.14:443 -noservername

Once you're connected, you can speak the HTTP protocol to the server manually:

  GET / HTTP/1.1
  Host: example.com
  Connection: close

and see what HTML home page content you get.

The output from the openssl s_client command will also show what certificate(s) were sent to you by the other end, and you can look at them using the openssl x509 command for more details about their contents. But you can see very quickly whether the purported issuer is Fortinet or a public certificate authority.

The curl version looks like

  curl -v --resolve example.com:443:93.184.215.14 https://example.com/

There you're telling it what IP address to use (rather than querying DNS for it).

> Is this some kind of MITM-Attack on me (I do not remember having had to install any special certificates, but I do not know how to check this)?

If the MITM attack were successful, you would not get a certificate error. The certificate error is the intended result of a failed attack, because it shows that you did not get a secure connection to the site you were trying to reach.

> Is there a convenient way to bypass this (i. e. not Tor et al.)?

If you have an account on a Unix server elsewhere, you can use ssh -D to create a local SOCKS proxy that forwards web requests through the remote server (assuming that the network doesn't also prevent you from making SSH connections to the server!).

> (assuming that the network doesn't also prevent you from making SSH connections to the server!)

SSH-over-HTTPS is a pretty foolproof way to get access in most settings like airports and hospitals that often indeed prevent SSH tunnels. Most webservers have proxy support, and there are many guides to glue something together.

A production implementation targeted towards anti-censorship is the Pluggable Transports project, part of Tor but separately usable [1].

[1] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-...

SSH Socks over 443 could be a solution.

But Firefox claims to do encrypted hello (ECH) since 119:

https://support.mozilla.org/en-US/kb/faq-encrypted-client-he...

Sure, but the vast majority of sites don't support it, and it's necessary to have explicit support from both client and server in order to perform an ECH negotiation. It can't be performed against existing HTTPS implementations without deliberately enabling the functionality.

I would guess that ECH server-side support is still only a few percent of sites at most, although maybe Cloudflare is going to enable it by default at some point? (I don't think they have done so yet...)

I tried those commands using the hrw.org ip address and sure enough, with SNI I am getting Fortinet Certificate, without I am getting the legitimate one. I guess that settles the matter.

Wrong / unsafe cert warning means you haven't installed their certs. They're trying to mitm you, but your browser is protecting you.

It's almost certainly SNI, it's the plaintext hostname. Servers rely on it being present to route, so the only way around it is to tunnel through the firewall with a vpn

From my understanding, they are somehow able to intercept DoH and block queries to restricted domains. Perhaps it is through unencrypted Server Name Indication, hard IP blocking, or otherwise.

If you have access to a cloud VPS server, I would suggest you try running an Outline VPN Server instance. https://getoutline.org. By far, it is the most resilient to interception tactics. It was designed for easy use by journalists to bypass censors. Shadowshocks is harder to detect them other VPN types like Wireguard because those don't try to hide themselves at all. They (the IT department) would need some serious kit to detect that kind of traffic and differentiate it from https.

Although, beware that using it 24/7 will still look suspicious to any IT Admin because then all your traffic is going to a single weird server.

VPN are easy to block even if they run on HTTP\HTTPS ports and are encrypted

Connection characteristics for VPN connection are very different from a legit HTTPS connection..

They cannot prevent you from connecting on the port, but HTTPS connection does not stay connected for long and any long lasting connection can be dropped by their router preventing you from keeping the VPN for longer then a few seconds\minutes.

how I've seen it done is by blocking all public DoH servers at the DNS and ip+port level. This isn't hard at all and there are plenty of public and non-public sources that maintain such lists. Since you mentioned forti* and block pages, it is likely that they're using their internal CA instead of a public one which explains the warning you're getting on your device. Fortinet also has the ability to categorize, inspect and block DoH/DoT, check this out:

https://docs.fortinet.com/document/fortigate/7.0.0/new-featu...

For German law, as I understand it, so long as they don't keep logs of traffic they can block whatever they want. Or, they can keep logs that anonymize the source ip and user completely. What they can't do is block a website and record the IP that was making the request without permission from the user that generated the traffic.

Thanks for all the great answers, I will have to do some reading and testing tomorrow. I knew about the possibillity of IP blocks, but I did not know about SNI, I will have to look into it.

As far as I now understand Forti* seems to be pretty advanced software, so I will see if I can get around it. I have my own cellular, I mostly want to know what they are doing behind the scenes.

Do I understand it correctly that they are deciding based on SNI/IP whether to let my packets through to the destination server - which provides me with an encrypted connection and the correct SSL Certificate such that they can not decrypt my data - or, in the case of a blocked site, reroute my packets to the Forti-Blockpage using the Forti Certificate such that I get a warning? So this is in essence completely decoupled from the DoH step, as at least one person commented.

I do not really have practical experience with networking apart from having ssh'd into a machine inside the same network a few times, so I might use my cellular to see whether its the firewall blocking me or my own stupidity.

What is the general practice on HN for updates, should I find some interesting results? Do I just post comments in this same thread?

Oh, I am also not really sure if I can even ssh into my home network at all. So far I have not been to keen on screwing around with my parents router configuration, I might just have to do that to open the relevant ports.

The DoH server is just adguard, nothing fancy there.

AWS free tier will get you your own Linux box to route traffic through for free.

You're well on your way to excelling in this world!

Hopefully their parents trust them to use a cc. Not sure if anyone offers a free tier without payment info.

> Do I understand it correctly that they are deciding based on SNI/IP whether to let my packets through to the destination server - which provides me with an encrypted connection and the correct SSL Certificate such that they can not decrypt my data - or, in the case of a blocked site, reroute my packets to the Forti-Blockpage using the Forti Certificate such that I get a warning? So this is in essence completely decoupled from the DoH step, as at least one person commented.

I believe this is all correct (I might have been one of the commenters who suggested parts of it).

A reason they might use IP address is that it's hard to circumvent (without going through a proxy, tunnel, VPN, etc.). A reason they might use SNI is that it works against CDNs and sites that might change IP address frequently.

In terms of the replies, you can log into your account and click the "threads" button at the top to see your own posts on HN and all replies to them. This is a common way to keep conversations going after a story is no longer on the front page.

In my experience some HN threads continue to have active discussion for up to a week after they're on the front page, and rarely much beyond that.

Instead of all that..

Please use a VPN, this will circumvent any local limitations..

If they block VPN services you could try using a VPS to configure your own server.

That unless they drop connections they detect as behaving like a VPN, something those devices can do..

But i can say for sure that if i was the manager for that network and i caught you circumventing the protections in place you would be in trouble...

If you want to access stuff that is not authorized in the network use your cellular connection for that.

At least Firefox supports a way for LANs to disallow DoH usage via regular-DNS responses: https://kb.isc.org/docs/using-response-policy-zones-to-disab...

Possibly, Chrome/Edge support the same or similiar mechanisms, but I haven't checked recently.

Alternatively, your school uses a HTTPS middlebox that knows how to distinguish DoH requests from regular SSL traffic to 1.1.1.1.

In any case, this is most likely not an 'attack' on you, and characterizing it as such is unlikely to lead to fruitful discussions around the policy.

In a computer security sense it is an attack, because there are parties with conflicting goals and one party is trying to use technical means to stop another party from achieving its goals. (The students can also be viewed as attackers by the network operator when they try to circumvent the blocking by disguising the nature of their communications.)

It's true that it would be socially awkward to say to school officials that they are carrying out an "attack" against students.

If you are getting a certificate warning then the dns lookup is succeeding but the (tcp) packets are under inspection (decrypted by the firewall and then re-encrypted). DoH only encrypts the DNS name resolution, which is only one method used by orgs to inspect traffic.

To solve this you need a VPN so that the packets are encrypted by something in addition to TLS

CF Warp would probably work too I think?

yeah. What OP is describing isn't DoH being blocked.

The simple answer is that it works as you suspected by performing a MITM attack on you (after all, your traffic flows through it), which permits the firewall to snoop on your traffic and perform various analyses.

As others have said, the SNI is not encrypted, so it can do basic category blocking even if your browser doesn't trust the certificate you saw. If it was a school-issued device, the certificate would have been preinstalled as a trusted certificate in the device's root store.

Your options are limited - why not try and see if you can find a gap in the rules via a tunnel or VPN from your device? You could try commercial offerings like Proton, or setup your own OpenVPN, Wireguard, or even try an SSH tunnel. Modern next-gen firewalls (NGFWs) like Fortinet are going to able to detect and block (if configured) many of these techniques, but you never know what's actually configured until you try.

TLS (websites) on your personal device is not being MITM by the Fortigate. TLS on your school's devices are.

The page you're not seeing with the certificate error is just the "This site is blocked by FortiGuard" page. You're not seeing it because you don't have their cert installed in your device (which is good, don't install it). If you visit a blocked site on a school device, you'll see the page.

Sorry, I don't know how the Forti's block DoH.

To everyone recommending VPNs, SSH, etc: the Fortigate does application control and is going to catch like 99% of those shenanigans.

Side note: Bypassing the network guardrails setup by a school or workplace is usually against their usage agreement. Even if you're not bypassing for nefarious reasons, it's probably not worth the potential consequences of getting caught.

Sydney Airport free wifi has the same setup with Fortigate/Fortinet. They whitelist acceptable domains/websites and prevent access to everything else by supplying their own certificate etc. I couldn't find a way to escape the hostile network, so I resorted to tethering.

I know this to be the case because I couldn't access https://mydomain.net - as it was deemed unacceptable content on their mitm splash page.

I have defaulted to tethering for about ten years. It’s more consistent than public WiFi. I will give up theoretical speed for not having to think about arbitrary requirements and limitations.

and prevent us learning about computer networks in class by blocking school-pc-to-school-pc connections in the firewall

That usually tends to cause people to learn more about networks to circumvent those blocks, at least in my experience a few decades ago; but perhaps the population has become too subservient now for most of them to do so.

They are very likely keeping track of blocked domains'/DoH servers' IP addresses and have a routing rule that routes packets to those websites to somewhere else, very likely something like "this site is blocked" kind of informational webpage on their servers, but since this is HTTPS the certificates don't match (since the IP department doesn't have the private key of the actual website's certificate) so you get a certificate warning.

I wouldn't accept that certificate, and if you have already done so, I'd remove it immediately from my device's certificate store.

Are you sure you're using DoH? Try to monitor the traffic with Wireshark. Then make sure that your school is not just MiTM-ing the DoH server you've set up.

OP stated they didn’t remember installing any certificates. I doubt DoH would be successful if the DoH server was MITM’ed

> My school has a bring-your-own-device wifi which obviously necessitates blocking of certain categories of websites

With cell phones able to access whatever outside your network, what is the purpose of blocking if it's bring-your-own-device? I appreciate the need to follow "policy" and CYA, but this seems a bit pointless if you've already done the basics of your Wifi's default DNS with a blacklist of certain sites.

Probably some quasai legal concern like "this user is accessing this illegal content and now it's on some cache server"

There's also just network/bandwidths costs someone doesn't want to pay for.

Are you sure it's a DNS problem? The school might just be blocking TLDs or even known IPs before routing the correctly resolved addresses back to you.

It would have to be IP blocks since the point of DoH is that the DNS response is encrypted.

It’s probably the firewall attempting to MITM any outgoing traffic on 80/443 for inspection. The OP’s device doesn’t trust the CA the Fortinet uses to decrypt

DoH = DNS over HTTPS

https://support.mozilla.org/en-US/kb/configuring-networks-di...

(You need to setup your DNS to respond in a certain way for a canary domain)

If I recall correctly, DoH makes calls to IP addresses like https://1.1.1.1 . I assume the security device is able to detect the lack of hostname/SNI and block accordingly.

> if they are able to read my private data that flows through the network

IMO if you are connected to somebody elses network, you should always assume they can read your private data or any data sent over that network.

Should you really assume that in the age of TLS?

Probably SNI in HTTPS not being encrypted.

Commenters seem to be convinced the school is filtering on SNI. That could be true. Based on past replies I have received, some HN commenters also believe that the entire web requires SNI. This is not true.

For example, the website hrw.org cited by the OP does not require SNI. The following request succeeds:

   printf 'GET / HTTP/1.1\r\nHost: www.hrw.org\r\nConnection: close\r\n\r\n' \
   |openssl s_client -connect 23.185.0.2:443 -ign_eof -noservername

Unfortunately so-called "modern" browsers disregard this fact and the implications of SNI on web users. They send SNI to every website, irrespective of whether it is required or not. One CDN may offer ECH to encrypt SNI if TLS1.3 is used and the client supports ECH. But one CDN is not the entire web. Needless to say, hrw.org is not using this CDN.

Personally I use clients that do not send SNI by default and localhost-bound forward proxies that allow me to enable or disable sending SNI for any given website.

Interesting that a student would be familiar with "MITM" and "DoH" but oblivious to SNI. SNI predates and defeats any alleged "DNS privacy" of DoH. No MITM needed.

Another test would be to run a local DoH proxy, e.g., AdGuard's "dnsproxy". This way one can avoid the remote certificate check that the so-called "modern" browser is probably trying to perform periodically when using DoH. The computer owner can serve their own self-signed certificate.

Yeah, people were shocked when my service allows people to login with any email, but after a while, you need to certify you are the owner by clicking a link only that e-mail can get. What's not to love.

> Instead, trying to access a blocked website gets me a wrong/unsafe certificate warning followed by a Fortinet/Fortiguard blockpage when I click continue.

This is likely the Fortigate SSL/TLS deep inspection (<https://docs.fortinet.com/document/fortigate/7.6.0/best-prac...>). In short: The Fortigate conducts an organizationally sanctioned MITM attack on your web browsing. You would not get any warning if the public key of the certification authority on the Fortigate had been installed on your client. In corporate Windows environments this is usually done via group policies.

Some websites may appear not to be subjected to deep inspection if those websites were exempt from SSL/TLS deep inspection. They'd be using SNI or the CN / SAN contents of the certificate presented by the website to make a policy decision against an allow or deny list of sites.

Another possible scenario would be that you have the MITM CA installed but the block page your browser gets redirected to by the Fortigate was signed by another CA / self signed. But that would certainly be a misconfiguration on the Fortigate.

Anyway. Your web browser allows you to inspect the certificate and more crucially the certificate chain used to verify the validity of a certificate. Look at the root certificate when you suspect a connection to be inspected. If the name of the root CA isn't already giving it away, you should be able to verify that it is a benign public CA by googling for it.

Given the rest of your experience, I'm guessing the IT staff wants to increase control over what applications and sites can be used over the school network. It is rather easy to detect and block DoH and other possible filter evasions when you can decrypt all communication.

> Also I find it disconcerting that my school blocks hrw.org (i. e. human rights watch) which I believe sends a wrong message.

You can check how a site is categorized by the Fortigate here: https://www.fortiguard.com/webfilter

Currently https://www.hrw.org/ is categorized as "Advocacy Organizations" in the group "Adult / Mature Content". I'm going to guess the whole "Adult / Mature Content" group has been blocked and you found a striking example of over blocking.

Now... what can you do about it? The easiest and least troublesome solution would be to just ignore the nosy IT infrastructure and use the school computers and their network just for the work assigned to you. I'm guessing you have unfiltered access to the Internet off campus anyway. Or you could tether you device to your mobile phone and bypass all filtering that way.

Subverting the school's attempts to limit your access is certainly a possibility given sufficient tenacity to learn and a certain kind of creativity with a tendency to cause mischief. But I'll leave it to you to figure out the details. When your actions get you into trouble: You have asked for it. Act accordingly.

> Also I find it disconcerting that my school blocks hrw.org (i. e. human rights watch) which I believe sends a wrong message.

There are many organizations more worthy of attention and respect than the grifter.

https://en.m.wikipedia.org/wiki/Criticism_of_Human_Rights_Wa...

I would be more concerned if a human rights watchdog didn't have critics.

In this case it is simply blocked by category of "Advocacy Organisations". I mostly find peoples reactions interesting when I tell them that my school blocks human rights watch, we are not in North Korea after all... I am more sad about the block of "uncategorized sites" which my own site that I recently set up sadly falls under :(.

Keep it for a while so it’s not “new” and I think you will find that it changes category. (My own experience with a similar setup.)

This approach depends on not being in a rush.