How does this work? 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)? Is there a convenient way to bypass this (i. e. not Tor et al.)?
I respect the IT companys efforts to secure the schools network (The IT company is universally hated by the entire school - They block the sites the teachers want to use, the youtube videos sometimes used for lessons, make the schools computers slow through McAfee and other bloat and prevent us learning about computer networks in class by blocking school-pc-to-school-pc connections in the firewall. Oh, and they also recently took in all the school issued I-Pads for an update only to delete all personal files on them; fortunately I do not use these out of principle, although I believe everyone managed to recover from cloud backups), but I would like to understand what they are doing to the network. Furthermore I am concerned about the legality of what they are doing (German law) and if they are able to read my private data that flows through the network (the network is personal login only, which would make that even worse). Also I find it disconcerting that my school blocks hrw.org (i. e. human rights watch) which I believe sends a wrong message.
If there is any testing I can/need to do for further analysis I would appreciate you telling me. Thank you! This is actually my first post here on HN as a long time lurker.
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!).
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.
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?
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.
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.
(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.
There are many organizations more worthy of attention and respect than the grifter.
https://en.m.wikipedia.org/wiki/Criticism_of_Human_Rights_Wa...