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.
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.
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].
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.
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...)
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
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. Once you're connected, you can speak the HTTP protocol to the server manually: 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
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!).