There is a way to do it, but it's fundamentally against the reasons for using HTTPS.
Here's how you'd do it.
Generate a self-signed SSL Certificate for the site you'd like to
intercept and cache the requests from.
Install and run stunnel on your proxy server, telling it that the certificate it should present is the one generated in stage 1.
Have stunnel forward the decrypted requests to squid.
You might need to have stunnel on the other side, or openssl_client to re-encrypt the request to the upstream server.
Caveats:
Your users will hate you. Every SSL request to that site will present an invalid certificate window.
You're exposing yourself to potential lawsuits for doing naughty things. (IANAL)
You'll only ever be able to get a self-signed certificate working for this, because of how the PKI web of trust for SSL Certificates is supposed to work. Saying nothing about compromised root CAs.
I'm not going to give you the exact details of how to do this, because a) I think it's somewhat unethical, and b) It's better for you to learn how to do it.
I suggest you research how stunnel and man-in-the-middle attacks work.
Just to explain why this can't be done without MITM - a proxy only sees the DNS name of the server you want to connect to when using encrypted HTTPS. It does not see the URL, nor any response headers. It cannot determine which individual resource you are accessing on a site, whether or not it is cacheable, nor what it's modification times are. All it can see is someone wants something from a remote server using HTTPS.
This means that caching cannot work as the proxy does not know what cached objects to give you, or how to get them in the first place.
No, there are not: they are encrypted... A workaround would be something like a man-in-middle deployment, but that would defeat all the reasons behind https.
Zeus (Now Riverbed's) ZTM Traffic Manager can do this as it can translate http and https traffic both ways and cache unencrypted content - it works, we use it, but it's fearsomely expensive - as in the price of a Porsche per server.
No, there is no Squid configuration to achieve this in a clean way (it must be impossible by design of HTTPS).
But yes, there is a browser configuration (HTTPS Proxy) enabling the desired behavior. Like this, the clients can make the difference between a legit proxy and a "man in the middle" attack.
Your users must be aware and agree that you are intercepting HTTPS traffic. If they are collaborators of a company, the HTTPS Proxy can be set by a policy. Have the users sign an internet usage agreement stating that you are going to intercept HTTPS traffic.
If you are an internet service/café provider, incentivize your users to activate a legit setting more or less manually, especially for visiting social media with video. Your users probably want to opt out for doing e-banking and should be able to do so.
There is a way to do it, but it's fundamentally against the reasons for using HTTPS.
Here's how you'd do it.
Caveats:
I'm not going to give you the exact details of how to do this, because a) I think it's somewhat unethical, and b) It's better for you to learn how to do it.
I suggest you research how stunnel and man-in-the-middle attacks work.
Just to explain why this can't be done without MITM - a proxy only sees the DNS name of the server you want to connect to when using encrypted HTTPS. It does not see the URL, nor any response headers. It cannot determine which individual resource you are accessing on a site, whether or not it is cacheable, nor what it's modification times are. All it can see is someone wants something from a remote server using HTTPS.
This means that caching cannot work as the proxy does not know what cached objects to give you, or how to get them in the first place.
No, there are not: they are encrypted... A workaround would be something like a man-in-middle deployment, but that would defeat all the reasons behind https.
Squid has a "hack" for just that:
https://wiki.squid-cache.org/Features/SslPeekAndSplice
Have fun. :)
Zeus (Now Riverbed's) ZTM Traffic Manager can do this as it can translate http and https traffic both ways and cache unencrypted content - it works, we use it, but it's fearsomely expensive - as in the price of a Porsche per server.
No, there is no Squid configuration to achieve this in a clean way (it must be impossible by design of HTTPS).
But yes, there is a browser configuration (HTTPS Proxy) enabling the desired behavior. Like this, the clients can make the difference between a legit proxy and a "man in the middle" attack.
Your users must be aware and agree that you are intercepting HTTPS traffic. If they are collaborators of a company, the HTTPS Proxy can be set by a policy. Have the users sign an internet usage agreement stating that you are going to intercept HTTPS traffic.
If you are an internet service/café provider, incentivize your users to activate a legit setting more or less manually, especially for visiting social media with video. Your users probably want to opt out for doing e-banking and should be able to do so.