If it were only deep packet inspection, the solution would be simply to prefix https:// and be done with it. As other posters have remarked, I suspect the article means an IP based block.
See the following link for the specifics ... but needless to say its easy to block SSL access with a transparent proxy or layer 7 firewall. (which based on the error page looks like a Palo Alto device which definitely can do this...)
https://idea.popcount.org/2012-06-16-dissecting-ssl-handshak...
Either the user installs it or not, it's their choice.
I am in no way advocating this abhorrent system of 'security'. Simply noting that it is obviously done in the workplaces and in many workplaces. That it can also be done here under 'security' pretences.
Respectfully, I disagree. This is certainly possible, but from an operational perspective this would be a nightmare. Even setting aside the likely backlash that would follow in response to such a sweeping policy change, university networks largely consist of diverse, user-managed devices, and supporting a transition through such a change would have a non-trivial cost.
Individuals at their workplace do also have user managed devices, they also are 'outraged'.
Regardless of which option you choose, you are required to install another program (unless the OUI of your MAC indicates that it is a device other than a computer) which scans your computer for malware and any software which the university does not allow you to have, such as torrenting applications, and will not allow you to connect to the network until after your machine is cleared. This program must be running the entire time you are connected to the network or you will be disconnected.
As a student who works as tech support in the dorms, it certainly is a nightmare!
I've always been leery of the mitm cert, not only from the users' perspective, but also from that of the organization. If a rogue administrator used the cert to set up a "real" mitm for a local bank's site, I think the school would be on the hook for that. That's just one example; one could imagine other variations on that theme. Whereas, if the school simply acted as a normal ISP, that whole class of vulnerabilities simply doesn't apply.
It's not a technical limitation but a moral one.
Most corporate environments typically do not "proxy" SSL, I know this from experience administrating networks and later abusing this with an SSH tunnel on port 443 allowing me unfettered access.
I'd be very interested in technical details on how that's implemented if it is.