HTTPだったらSquidでキャッシュしてWAN側のトラフィックを節約できたけれど
HTTPSだとプロキシでキャッシュ出来ないから
Apple Update・Microsoft Update・Youtubeなどは署名されたキャッシュをLAN内で提供できる「オープンな」仕組みを提供して欲しい。
Mac miniに2,400円の「OS X Server」を入れれば「キャッシュサービス」でアップデートをキャッシュ出来るし、
Windows Serverを購入すれば「Windows Server Update Services」でアップデートをキャッシュ出来るけれど、
Youtube辺りはどうだろう、校内にAkamaiノードを招待するかな。…無理だよね。
HTTPSだとプロキシでキャッシュ出来ない (スコア:1)
HTTPSだとプロキシでキャッシュ出来ないから
Apple Update・Microsoft Update・Youtubeなどは署名されたキャッシュをLAN内で提供できる「オープンな」仕組みを提供して欲しい。
Mac miniに2,400円の「OS X Server」を入れれば「キャッシュサービス」でアップデートをキャッシュ出来るし、
Windows Serverを購入すれば「Windows Server Update Services」でアップデートをキャッシュ出来るけれど、
Youtube辺りはどうだろう、校内にAkamaiノードを招待するかな。…無理だよね。
SSL/TLS対応サービスが増えるごとに、費用をかけてサービス専用のキャッシュサーバーを用意しなけ
Re:HTTPSだとプロキシでキャッシュ出来ない (スコア:0)
ほにゃらら update の類では、バイナリが本物かどうかは署名で確認するでしょう。https で送るメリットがないので、でかいファイルは http で送って普通のプロクシでキャッシュするのが前提になっているのではないですかね。
Re: (スコア:0)
あるパッチをダウンロードしているということは、そのパッチが塞ぐセキュリティホールが残っているPCである可能性が高い。
ということは非常に攻撃しやすいので、パッチのダウンロードには暗号化通信を原則適用すべきだと思います。
自動化できるぐらいのやり口だと思いますが。
Re: (スコア:0)
バイナリの署名が信用できない状況では、https も信用できないですね。どうやって通信相手が本物か確認するのですか。それに、https を使ってバイナリを配布すると、マイクロソフトがパッチを出すたびに、大企業のネットワークで proxy がパンクして多数のマシンが脆弱性を残したまま長期間放置される危険性があるわけですが、その危険性は無視ですか?
実際、windows update では、バイナリを http で送ります。 マイクロソフトが提供しているWSUSの資料 [microsoft.com]には、以下のように書いてあります。