Ist es möglich, für HTTPS einen Proxy zwischenzuschalten, so wie dies für HTTP möglich ist? Also, dass Dateien, die durch mehrere Clients zeitnah angefordert werden, gecached werden?
Ja. Die Kommunikation zwischen Proxy und dem eigentlichen Server läuft so als sei der Proxy der Client: Der Proxy entschlüsselt also die Daten und verschlüsselt die wieder für den Client. (und visa versa)
Der Client verbindet sich mit dem Proxy, schickt die Anfrage an diesen als wäre dessen IP bei der Namensauflösung herausgekommen. Demnach kommuniziert der Client mit dem Proxy und muss dem alles glauben - also dessen Public-Key, insbesondere der neuen, privaten Zertifikatskette vertrauen: Weil der Proxy verschlüsselt hat muss dem Client vorgemacht werden, dass die für diese zweite Verschlüsselung genutzten Schlüssel für den ursprünglichen Server gültig seien. Das geht also durchaus, birgt aber die Gefahr, dass, wenn der Proxy gehackt wurde, jegliche Kommunikation aller Netzteilnehmer zu jedem Webserver betroffen ist.
Das ist im Vergleich wie ein "sicheres" Atomkraftwerk.
Ansonsten kann für Kommunikation zum Port 443 z.B. in der Default-Squid-Konfiguration festgelegt werden dass diese einfach direkt durchgeleitet (getunnelt) wird ohne die Verschlüsselung „anzufassen“. Freilich kann dann auch nichts gechached werden und niemand kann sagen, was da getunnelt wird. Das macht man also NICHT bei einem Reverse-Proxy, weil man damit ein ganz nettes Loch in die Firewall bohrt.
Zurück zu Deinem Anliegen: Da die Browser selbst cachen ist der Gewinn hier in Verhältnis zum Aufwand und zu den entstehenden Gefahren sehr klein.
Darüber, was passiert, wenn der Client das Netzwerk wechselt (Laptops, Tablets, ...) und dann die Kommunikation mit dem selben Server nicht mehr nur zu einer anderen IP sondern auch plötzlich mit anderen Keys laufen soll denke ich jetzt mal nicht nach. Wäre ich Browser würde ich mich sehr unwohl fühlen und das den Benutzer auch wissen lassen.