Hi List,
URL filtering works well, but :
With a http request, OK, I get the Ipifre template “access denied” page.
But with a https request, I get a “normal” page “The connection failed”, or “This site is inaccessible” with “ERR_TUNNEL_CONNECTION_FAILED”
Since IpFire knows the domain (it appears in the log), why this difference ?
I miss something ? Is it a bug ?
Tested with a fresh install of v.182, non transparent mode of course.
Thanks !
Hello @tx0666 Welcome to our community.
When you try to access a blocked website using HTTP, IPFire can easily intercept the request and display the custom “access denied” page. This is because HTTP traffic is unencrypted, allowing IPFire to read and modify the content of the web request.
The scenario is different for HTTPS requests due to the encrypted nature of these connections. When you try to access a blocked HTTPS site, IPFire cannot intercept and modify the content of the encrypted request in the same way as it does for HTTP. Therefore, it cannot display the custom “access denied” page. Instead, IPFire blocks the connection, and your browser displays a generic error message like “The connection failed” or “ERR_TUNNEL_CONNECTION_FAILED”. This behavior is not a bug but a limitation when dealing with secure, encrypted traffic.
To achieve similar behavior for HTTPS sites as with HTTP, IPFire would need to perform SSL/TLS inspection. This process involves decrypting and re-encrypting HTTPS traffic, which was typically handled by the SSLBump module. However this module was removed in core update 90 due to security concerns. For the same reason it is not possible to have a transparent proxy over HTTPS connections. Also, any encrypted traffic cannot be cached but only forwarded (or blocked).
Hello @cfusco,
And many thanks for your quick answer.
Yes, I know the limitation of filtering with https due to encryption.
But I thought, since I can see in the logs of IpFire that he knows the domain I tried to connect to, and knows that it is in the blacklist, it was easy for him to display the access denied page. This part is not clear for me.
And sorry for my english…
@tx0666 EDIT: I rewrote my answer for better clarity.
In the case of unencrypted connections, Squid intercepts HTTP requests and can forward an HTTP page with a Block Notice to the client. However, for HTTPS connections, where the client expects encrypted traffic based on the key negotiation with the target server, the situation is more complex.
Technically, Squid could generate an HTTPS-compliant block page using intercepted keys to encrypt the page for requests directed to an entire domain. Nevertheless, this method, which I believe is not in line with standard web operation procedures, would still require the use of the SSLBump module for encrypting the traffic to the client. Furthermore, serving an HTTP page in response to an HTTPS request is not a viable option, as it would result in security warnings being triggered in the client’s browser.
Thanks a lot @cfusco for your detailed and very quick replies, totally clear now. Highly appreciated !