I am a Zope user (2,4,5) not using Plone.
The public accesses my website via Cloudflare, with Pound connecting to different Zope servers, so that's pretty secure. But I still develop through the ZMI, and I like it like that. However HTTP Basic Auth is not where we should be in 2022...
How would it be possible to access the ZMI via HTTPS? Anyone doing that? Easiest way preferred 
Usually, you would run Apache or Nginx in front of Zope (and ZMI).
I have neither experience with Cloudflare nor Pound so I am not sure whether this solution applies for your situation.
I will try that (with Nginx), just for my own development access.
Cloudflare and Pound simply forward the resources to end users, so that's a different layer. Cloudflare provides a "Flexible" SSL option, meaning that they present users with a secure access and forward requests to my HTTP backend without exposing my otherwise public IP address. I believe it's sufficient considering that my users don't log in or submit any data except for search queries.
By the way, Pound load balancer is a natural companion for Zope, check it out here.
Sorry for the naive question! I had always assumed that "HTTP Basic Auth" meant HTTP and not HTTPS. Now I see that it should work.
Why does Zope not use HTTPS by default?
Sorry for the naive question! I had always assumed that "HTTP Basic Auth" meant HTTP and not HTTPS. Now I see that it should work.
HTTP basic auth works for both HTTP and HTTPS, and certainly you do not want to use it with HTTP anymore.
Why does Zope not use HTTPS by default?
I have not made the decision, but I could imagine there are many reasons:
For you setup there might be a better and easier solution, than adding a apache or nginx.
As you are using the old pound loadbalancer, I would recommend switching that loadbalancer to a current version of haproxy. That is a newer, better supported loadbalancer that could do ssl encryptions. So you could also secure the connection to cloudflare a bit more by doing that connection also via ssl.
Also haproxy has easier capabilities to add sticky sessions and other things, like health checks, loadbalancing strategies and weights. In case of development and debugging that helps a lot.
Sorry for the naive question! I had always assumed that "HTTP Basic Auth" meant HTTP and not HTTPS. Now I see that it should work.
HTTP Basic Auth is a authentication protocol, developed for the http world, but it also work for derived communication protocols like https, ws, ...
Why does Zope not use HTTPS by default?
Zope is that old, that https or ssl secured connections was not a thing.
Also Zope and ontop Plone both prefere the Unix phliosopy to do one thing and do that right and work with other tools together. Other Tools like Apache, nginx, Varnish, haproxy, ... tools that are normally used in combination with Zope and Plone are much better in specific connection optimizations, ssl encryption is one of those things. Also Zope is an application server, not a web framework or webserver. application server are traditionally much slower, as the have much more to do in their work. So a proxieng webserver, cache-proxy or loadbalancer is better for this job. Also be aware that ssl encryption was once a very load heavy function, today with TLS it is much lighter and directly supported by the cpus.
also Jürgens points of attack surface and maintaining complexity are more than valid.
The necessary to protect a Zope from direct attacks on it, by hiding it behind another tool that could do a loot of things, like set or delete http header (cors is just one example), filters (--> mod security), transport optimization like gzip compression, http2 and http3.
Everything you do not provide does not need to be maintained. So much better. And Zope could be easiely used in a best of breed setup.
I tend to agree with @jugmac00 here, but I'll phrase it differently.
HTTPS, simply put, is just a wrapper around HTTP.
No one maintaining Zope really wants to re-invent the wheel here.
They probably don't want to "bake in" the ability to talk HTTPS.
They probably don't want to maintain HTTPS support either, because security flaws happen and code needs updates and stuff. They have to 'own the work' now.
An analogy is "Why doesn't your house have it's own vegetable garden?" (Assuming you don't have a vegetable garden). A reasonable answer is "Because there is a grocery store down the road".
No one is saying you can't have your own veggie garden, but maybe you just don't want to put the effort in, and that's ok.
Thanks for all the good insights and answers! I agree that it isn't Zope's responsibility to support HTTPS, and there are different solutions that Zope users can choose from to suit their own conditions.
Even if Zope sets up by default on port 8080 (like some other frameworks), I guess nowadays people know that is not ideal. Still, this could be briefly mentioned in the installation instructions, since it is fair to assume that the default represents the best practice.
late to the thread, but I thought with Zope 4 & 5 you can configure waitress to use HTTPS?
If you do not want to add a full web-server to your setup, you could utilize stunnel.
"Stunnel is a proxy designed to add TLS encryption functionality to existing clients and servers without any changes in the programs' code." https://www.stunnel.org/
I do not think this is supported. Maybe some other WSGI server is able to to this.
When a Zope server is accessible with ssh, using a ssh tunnel is very convenient for a direct access to the ZMI.