In raising this issue, I confirm the following: {please fill the checkboxes, e.g: [X]}
How familiar are you with the source code relevant to this issue?:
1
Expected behaviour:
Block page showing on HTTP & HTTPS requests.
Actual behaviour:
Block page only shows on HTTP, not HTTPS requests
Steps to reproduce:
1) Make sure the device you are using is routed through a Pi Hole DNS.
2) Go to a blocked site, whether it be blacklisted manually or from a list (for this example, we are using t.co)
3) Go to the site using HTTP, you should get a page like this (CSS or something seems broken, but that's not what we are focusing on right now.) 
4) Now try going to the site using HTTPS. Instead of a block page, you are just given a connection error. Now this is an issue considering most sites use HTTPS and this simply gives a false understanding to the user. 
Debug token provided by uploading pihole -d log:
0mxms9cw9u
Troubleshooting undertaken, and/or other relevant information:
N/A
This is as intended, you can not intercept HTTPS/TLS traffic without presenting a TLS certificate in the name of the site. This is not operationally feasible and would be considered a breach of security as a man-in-the-middle attack.
Most helpful comment
This is as intended, you can not intercept HTTPS/TLS traffic without presenting a TLS certificate in the name of the site. This is not operationally feasible and would be considered a breach of security as a man-in-the-middle attack.