Last days I got a fishing mail that tries to direct me to a faked banking website ('Volksbank Berlin').
The site looks exactly like the real banking login page. So I blacklisted the domain in pi-hole.
However, the blocked page is using https, so I do not see the pi-holes 'Website Blocked'-site, but only a network connection error in Web Browser.
So it would be great if I get the same 'Website Blocked'-site on https-requests.
Pi-hole cannot show your browser a valid HTTPS certificate for the site you are requesting. Hence, a HTTPS connection cannot be established and showing you the requested page is technically impossible. There is also no trick we could apply to circumvent this - in the end it is one of the major security features of HTTPS.
Therefore, the network error is the best that can happen (it will at least prevent you from being able to access the fishy website).
Hmmm i am running services on 443 TCP so thats for me not useful. [quote="DL6ER, post:2, topic:2628"]
Pi-hole cannot show your browser a valid HTTPS certificate for the site you are requesting.
[/quote]
The PiHole could offer a CA-Certificate but i don't know, if that was the advantage compared to the expense.
Yes, that would be possible, but I see a number of issues - each time a page is visited (for the first time?) a certificate would have to be generated. Not even that I don't know how to setup a clever hook for doing that off the top of my head, but also wouldn't that take too much time? Generating a cryptographic certificate is nothing that can typically be done within a few milliseconds - especially not if you are on low performance hardware.
Yeah that's what i mean with "advantage compared to the expense"
So what about a self created certificate only?
On visiting such a blocked site, the browser would tell you that the connection is not trusted and then you could chose to go back or open the site anyway to see the 'blocked'-site by pi-hole.
You would still need to generate one certificate for each domain, and then you'd need to have a Certificate Authority (even if it is a self-signed certificate, still needs an authority.) It's really not feasible or trivial to spoof or attempt to spoof a HTTPS session. I see that this came about from a phishing attack attempt. The easiest solution is to check your sensitive sessions and make sure you are going where you think you are going. The Pi-hole is not a security product and we do not approach the realm of being in the world of security. We block ads, that's it, and while we do appreciate the feature request, the likelihood of it being implemented are very low.
The other issue with making our own CA would be how to install that CA into devices like SmartTV's or e-readers, appliances and other IOT devices.
They doesn't matter for me 
Why does my fridge need to see the blocked Site? The Problem that i see is: Many Guests or "foregin" devices have to accept the CA. Not everyone likes that because it is a security risk and it go on nerves to add the CA to the local trusted storage. Just ask your father or grandfather how he would do that 
So @TheME: It is not worthwhile for many aspects
I also brainstormed this idea of creating your own CA + public SAN cert.
A SAN cert (Subject Alternate Name) allows you to add aliases for the common name (CN) in the cert eg:
CN = pi.hole
SAN = doubleclick.com , googleadservices.com, etc etc etc
So everytime gravity runs to create the blacklist, the one SAN cert would need to be updated to include all the blacklisted domains as SAN entries.
But as this means the cert is generated new everytime the blacklist is updated, all the devices would start complaining about the untrusted cert again and you will need to trust/install the cert everytime on all your systems that use Pi-Hole.
And I am not sure how many SAN entries can fit in a SAN cert and how large the cert would be if it included all the blacklisted domains.
Maybe the clients wont complain about the new cert everytime if you use some sort of CA chaining but I have not looked into that yet.
My 2cts.
Well, if you went the SAN route, I think you may be able to set the cert to apply all the way up to the tld. I believe it's legal to have a SAN of *.com, you'd just never find an Authority of any kind of reputation that would issue that cert. (Other than your own CA.)
But then if you leave the CA on the Pi-hole, if it's compromised, then all bets are off as the foreign actor can now issue certs for the phishing domain and we're back to square one.
I am a bit late to the party, but here is just a thought I had, you could have the option to have the user set up a block site and have pi hole redirect to that site, so it is up to the user to setup ssl, or you could have a site hosted elsewhere that pihole redirects to. (ex a github.io site or a subdomain of the pihole website) have the back to safety button redirect to a new tab and have the whitelist button link to the admin page (pi.hole/admin/groups-domains.php?type=white).