色々分かってなかったが同僚に詳しく教えてもらって理解が進んだ。
- 通常のプロキシ or MITM プロキシ
- 透過型プロキシ or 明示型プロキシ
- http proxy or https proxy
という三つの直交した分類がある。
1. 普通のプロキシ or MITM プロキシ
普通のプロキシ = クライアント <-> 接続先サーバーのリクエスト/レスポンスの中身を覗かず弄らず、そのまま渡す。プロキシサーバーは土管。便宜上「パススルー型」とでも呼びたいが、どうも一般的な呼称ではなさそう。
【図解】httpプロキシサーバの仕組み(http GET/https CONNECTメソッド)や必要性・役割・メリットデメリット・DNSの名前解決の順序 | SEの道標の二つ目の図（シーケンス図）参照。
MITM = クライアント <-> 接続先サーバーのリクエスト/レスポンスを覗き弄る。クライアント <-> 接続先サーバーが HTTPS リクエストであれば、プロキシサーバーが TLS を終端して接続先サーバーに改めて HTTPS リクエストを送信し、あたかもプロキシサーバー自身が接続先ホストであるかのように偽装して（偽のそれっぽい TLS 証明書をオンザフライで作成したりして）クライアントに返却する。
https_proxy=httpとhttps_proxy=httpsは何が違うのか？ #curl - Qiitaの ネットワークスペシャリスト 平成26年秋期試験問題 午後Ⅱより引用 の図参照。
この図でいう「サーバ証明書2」は、MITM プロキシサーバーがクライアントに（改変済みの）HTTPS レスポンスを返却する際にその内容を暗号化するために必要なので、この場合クライアントの端末に「サーバ証明書2」のルート証明書なり証明書自体なりをインストールして検証できる状態になってる必要がある。そうでないと HTTPS 接続エラーになる。
2. 透過型プロキシ or 明示型プロキシ
「透過型」という言葉を間違って使っていた。パススルー型の意味で使っていたが間違いで、一般的に透過型プロキシというと、ネットワーク経路上に配置されてクライアント側で特に設定せずとも通信がプロキシサーバーを経由するようなタイプのものを指す。
明示型プロキシは、クライアントが使用するプロキシサーバーのホスト名とポート番号を明示的に指定する。curl なら -X オプションで指定したり、ブラウザのプロキシ設定で host/port を指定するようなやつ。
3. http proxy or https proxy
クライアント <-> プロキシサーバー間の接続が HTTP か HTTPS か、という話。HTTPS であれば当然プロキシサーバーの TLS 証明書も必要だし、クライアントはプロキシサーバーの TLS 証明書を検証できる必要がある。プロキシサーバーがいわゆるオレオレ証明書や自己署名証明書を使ってる場合はクライアントの端末にオレオレ証明書のルート証明書なり自己署名証明書そのものなりをインストールする必要がある。
1. 通常のプロキシ or MITM プロキシ における「サーバ証明書2」およびそのルート証明書の必要性は、3. http proxy or https proxy とは独立直交しているので、「HTTP プロキシだけどクライアント端末にカスタム証明書のインストールが必要（MITM プロキシなので）」という状況はあり得る。
同様に、透過型プロキシであるかどうかと MITM プロキシであるかどうかも独立直交しているので、「透過型プロキシなので全ての通信がプロキシサーバーを経由するがパススルー型なので単に通過するだけ」というケースもあり得るし、「透過型の MITM プロキシなので全ての通信がプロキシサーバーを経由する上にリクエスト/レスポンスの内容は閲覧/改竄され得る」というケースもあり得る。
それ以外にさらにフォワードプロキシとリバースプロキシという分類もある。が、カスタム証明書がらみの話題とはあまり関係ないため（クライアント起点の接続においてはフォワードプロキシだけ考慮すれば十分なため）、ここでは突っ込んで触れない。
