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

  openssl s_client -connect 93.184.215.14:443 -noservername

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

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/

> 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!).

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-...

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

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...)

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

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.

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.

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.

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?

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.

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.

The DoH server is just adguard, nothing fancy there.

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

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.

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

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

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.

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.

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.

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.

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

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.

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

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

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

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.

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

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.

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.

This approach depends on not being in a rush.