If they're installed on the computer, then they can easily use a self-signed cert to intercept (like Superfish, but hopefully generating a new one for each device).
But they generally just block domains, or use extensions, neither of which care about http/s.
My question is more in the line of - wifi provided by school that blocks/filters content. But thanks for the other answers too!
(I'm concerned if a kid browses with iPad, some telephone, etc., and the concern is more on whoever provides the service that might be liable in some way).
They could block whole domains, which https doesn't change.
The only time it makes a difference is if you want to block part of a ___domain and not other parts. I can think of some use cases (block Google unsafe search, but not safesearch), but generally they just block the whole ___domain and have a separate ___domain for the "good" part. (See http://www.safesearchkids.com/, for example.)
And it's not like this isn't the same situation now. Whatever would be possible then would also be possible now, just by using https. This is just making http harder to use.
Schools do strange things all the time; they'll want to allow YouTube and block Google Drive and Dropbox (because, heaven forbid a student download an arbitrary .exe onto the school's Windows computers and run it, but for some reason opening notepad to create a .bat file locally is perfectly OK).
Only ___domain/IP-level blocking would work for public/free WiFi-style connections. The filtering wouldn't be able to inspect the contents of the pages that are transferred without perform MITM decryption/encryption, and to do that you need a certificate installed on the user's device.
I'm not familiar with how those typically work, but intuitively from an architecture standpoint, that sounds like something that should sit as a filter between the browser and the outside world. Browser as monolith of functionality seems undesirable.
Trusted filters (such as ad blockers, parental censorware, network monitoring) must to be inside the trust boundary to be effective. That is the best way to ensure they are not imposed en masse against people's will.
In-path filters outside the trust boundary are, I'm afraid, the very first casualty in our efforts to mitigate the threats of nation state adversaries, as they resemble the attacks used there too much to survive. I, for one, will not mourn them.
Reason being that with SSL you can't read the contents of the Request/Response (including page content) without MITM, which would require you to install a certificate on the user's device. That may be an option in some situations.
With a browser extension (which you would also need to get installed on the device in some manner) you can inspect the pages as they are displayed.
