(71) Protocol error (TLS code: X509_V_ERR_CERT_HAS_EXPIRED) SSL Certificate expired on: May 30 10:48:38 2020 GMT

 https://medium.com/@yowatari/addtrust-external-ca-root-%E6%9C%9F%E9%99%90%E5%88%87%E3%82%8C%E3%81%AB%E4%BC%B4%E3%81%86%E5%95%8F%E9%A1%8C%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6-7ca0286ea3ff

 

いやまじでこれ。 squidでエラーが起きてるなあと思ったら、こんなことでした。

 redhat系での対応 https://twitter.com/ChristianHeimes/status/1266800555978039296?s=20 を参考にしてください

とのことで 

# trust dump --filter "pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert" > /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit

 

# update-ca-trust extract

と

 # trust list | grep -C2 "AddTrust External" pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert type: certificate label: AddTrust External Root trust: blacklisted category: authority

それからsquidを再起動したら通った。 

マジで助かりましたわー・・・。

X-Forwarded-Forとウェブサイトのよく分からない関係。

adobeが環境変数を読んでいる事件以来、環境変数を出しっ放しにしていたのだけれども、（目立つところで）「マイクロソフトコミュニティ」と「note」に接続できなくなった。
具体的には、マイクロソフトコミュニティhttps://answers.microsoft.com/ja-jpにアクセスすると、「申し訳ございません　現在このページは利用できません」と出る。
また、noteは、https://note.mu（今はhttps://note.comか）にアクセスすると、「申し訳ありません、ただ今障害が発生しております。復旧作業中ですのでしばらくお待ち下さい。
このページが繰り返し表示される場合は問い合わせフォームまでご連絡下さい。」と出る。
この問題は、自分がプロキシ環境下に居る際のみ発生する現象なので、間違いなくプロキシが何らかの影響を及ぼしている筈である。
正直、noteは全く困らないのだけれども、マイクロソフトコミュニティは困る。
noteはたまにquiita代わりに使っている人が居る位だが、マイクロソフトはガチ目である。
で、探ってみたところ、どうもX-Forwarded-Forを漏らしていると、両サイト共に、上記のような意図しない画面になることが分かった。
不思議な話である。
別にX-Forwarded-Forが漏れていたところで、プロキシ経由でアクセスしているんだよということが分かるだけで、何の影響も無いはずだからである。
大体漏れているX-Forwarded-Forの内容もunknownである。
むしろプロキシが兎に角嫌いなのかと思ったのだけれども、HTTP_VIAは漏れている（しかもばっちりsquidの名前とバージョンまで出ている）ので、そういうわけでは無いらしい。
何にしろ、X-Forwarded-Forが元凶なので、取り敢えず漏れないようにする。
squid.confに

request_header_access X-Forwarded-For deny all

を追記。

adobeのアクセスに関係が無いことを確認して終了。

SSL通信は透過するけれども、http通信は透過しないという不思議状況に悩まされる FATAL: mimeLoadIcon: cannot parse internal URL:

CENTOS8で、透過SSLプロキシを建てようとしたはいいものの、諸々はまって、最後に原因が分からないけれども
何とかなったという、誰か真面目に説明して欲しい位の何かにはまったので書いておく。

はまりポイント1

nftablesの意味が分からなかった。
8からnftablesに変わるから覚えなきゃ、で始めたのだけれども、
iptablesのノリで出来る物だと思っていたら、何か御作法が全然違う。iptablesをnftablesの設定に変換できるので、
変換してみたのだけれども、同じ文法で書いてみても適用時にエラーが出る。
なので、3日間位がっつり調べたり試したりしたが、nftablesは未だ早いという結論に至った。
nftablesは書籍は勿論、ウェブページでも扱っているところが少なすぎて、何をどうすればこうなるが全く頭に入らなかった。
結局nftablesを覚えなくても、iptablesがそのまま使える（内部的にはnftablesに変わっている）ので、iptablesで進めることにした。

はまりポイント2

firewalldを無効にしなかった。
どうせ中身はnftablesなのだから、と思っていたら、思いっきり相互干渉してしまっていた。
全く用を為さないわけでは無く、部分的に効いたりするからタチが悪い。
しかもエラーメッセージはないので、原因解明に1日潰した。
firewalldだけ潰して再起動をかける。（似たあるあるで、selinuxの無効有効を忘れるとか）。

はまりポイント3

squidのhttp_portを2つ入れなければならなかった。
これが謎の大元。何回やっても、https（SSL)は通っているが、httpが兎に角通らなかった。
squid.confの設定で、http_portを指定するところがあるのだけれども、

http_port 3128 intercept

のように、intercept（透過指定）すると、
squid自体は立ち上がっているように見えるが、実際はエラーで起動しておらず、

systemctl status squid

でエラーを見ると、
FATAL: mimeLoadIcon: cannot parse internal URL:～というエラーがでて、ずっと悩んでいた。
これの答えは、
https://tutorialmore.com/questions-290758.htm
のように、

http_port 3127
http_port 3128 intercept

と、２つ指定しなければならないと言うことだった。
・・・これ、何故指定しなければならないのか、指定したらどういう風に通信処理されるのかさっぱり分からないんだよね・・・。
iptablesでは、3127ポートに関しては一切触れていないので、内部処理なんだろうけど・・・。
※3127とか3128とかのポートは任意なので一応注釈。
squid3だと、ポートを2つ指定したことが無かったので、新しい御作法なんだろうけれども・・・。

切り分け別個の話として、intercept指定しなければ、ブラウザにプロキシを噛ませる必要があるので、
もし噛ませなかったら

    不正なURL

指定されたURLに正しくない部分があります。

考えられる問題:

    ("http://"または同類の)アクセス・プロトコルが抜けているか不正です。

    ホスト名がありません。

    不正な二重のエスケープがURLパスに含まれています。

    ホスト名に不正な文字が含まれています: アンダースコア(下線)は使えません。

というエラーがsquidから出る。
英語だとinvalid urlか。

続。squid越しにadobe Creative Cloud Desktopが使えない(spliceのご使用は計画的に）

とりあえず端的に書くと、adobe creative cloudデスクトップアプリケーションをインストールする際に、見に行くサーバが特定できていない。
恐らくは全てspliceしたはず（エンドポイントのurlは全てnobumpに加えた）で、それでもぐるぐる回ってインストールが進行しなかったりする。

挙動だけを見ていると、どこかに接続しようとしてタイムアウトした際に、次のステップに進んでいるような印象。
 悩みに悩んで、ブラウザでもアドビに接続が若干困難だったことから、取り敢えずブラウザで見えるadobe.comをみることにした。
...結論から書くと、doubleclickやらlinkedinやらの追跡ビーコンが読み込みを阻害していたのだけだった。
ただ、これはこれで無駄ではなかった。
何故かtwitterの表示がおかしいことに気づき、squidを参照したところ、twimg.comのみを「splice」していたのである。
そしてその際のtwitter.comの証明書は、僕のオレオレ証明書ではなくdigicert.com。そう、どうやら証明書はバッティングする。そして、バッティングしたら読み込みに障害が出るらしい。
これに気付けば後は簡単、逆にadobe関係のウェブサイトを「splice」リストから除外すればいいだけ。

ブラウザの挙動恐るべし。
ただ、逆を言えば、adobe ccが要求してくるurl（というかドメイン）を全てspliceできていれば、こんな問題は起きないわけである。
wiresharkと超睨めっこしたのに、なかったんだよなあ。。。

squid越しにadobe Creative Cloud Desktopが使えない（user-agentをみてる）。あとプロプリエタリへの恨み言。

いや本当に勘弁して欲しい。
squidでプロキシしている環境からadobe creative cloudのインストールをしようとしたら、さっぱりインストールできない。
p201エラーとかいいやがりまして、インターネットにはつながっているのに、繋がっていないことになる。
本腰を入れて調査したところ、どうも環境変数を読む臭くて、
squidでrequest_header_access User-Agent deny all
を指定すると、見事にはぶられることが分かった。
ということは、user-agent偽装もリスクになるわけで、選択的にadobeだけ、みたいな事もできないわけではない（はず。試していないけど、ssl_bumpのステップか、多段プロキシかでできると思う）が、
調べるのが面倒だし、くそみたいな仕様のソフトウェアで管理させようとするadobeに憤りしかない。
 だったらスタンドアロンインストーラをどうどうと公開しろと言いたい。

あと、関連で、apple iosもメール添付ファイルバグを直そうともしない。
先方は、iphoneやipadで、メールに添付して送信してるつもりなのに、僕の手元には添付されていないようにみえた状態で送られてくる。
これ。
https://forums.mozillazine.jp/viewtopic.php?f=3&t=16494

WADAさんの返信をまま引用

「添付ファイルが消えている」のではなくて、
そもそも、メールのデータ構造には「添付ファイル」なるものは存在せず、
Thunderbirdは、それに関しては規則通りに表示しないが、
iPhoneのメーラーやWebメールだと、正しくないメールのデータ構造であっても、multipart/alternativeの下の一部のパートを、あたかも「添付ファイル」であるかのごとく見せている、
ということだと思います。

ちゃんとしたメーラーではなく、multipart/mixed、multipart/related、multipart/alternative、などの違いなんて知らない・気にもかけないお粗末なプログラマーによって書かれたメールアプリケーションやWebアプリケーションが、multipart/xxxのデータ構造の中の不適切な場所に「添付ファイル」として送りたいデータを置いた、というのが、多くの場合の原因です。
こういった問題が多く報告されて、
multipart/relatedの下でHTMLが参照していない、使われないパートに関しては、
そのデータをファイルに保存できるようにするために、正規の「添付ファイル」と同様に、Thunderbirdも表示しています。
しかし、multipart/alternativeに関しては、
multipart/alternativeの下の各パートの定義は、全く同じ内容物の異なる表現(HTMLとtext、というような)、ですから、
Thunderbirdの仕様は、multipart/alternativeの下のパートの一つだけを選択して表示する、
であって、これは変更されていません。
Thunderbirdにおいてmultipart/alternativeの下のパートで表示に使えるものはtext/htmlとtext/plainなどだけだから、multipart/alternativeの下のパートでtext/xxxではないものは、「添付ファイル」として表示して欲しい、という要望は、すでに出ています。

あまりにも多くのお粗末なプログラマーが存在してそういったメールを多く作り出すので、正常に表示されないデータをファイルに保存できるようにするための手段を提供してほしい、という要望があって、それで作られた機能が「show_all_body_parts」です。
設定エディタ(Config Editor、知らなけれ自分でグーグル検索してください)
mailnews.display.show_all_body_parts_menu : false ⇒ true
に変えると、
View/Message Body As(表示/メッセージ、かな)に、HTMLやテキストに加え、「All Body Parts」が出てきます。
これを選択すると、全てのmultipart/xxxをmultipart/mixedとして解釈して表示するので、
multipart/alternativeの下の不正な場所に置かれたパートや、multipart/relatedの下の不正な場所に置かれたパートなどが、
multipart/mixedの下におかれた、正規の「添付ファイル」として表示されます。

まずは、この機能で確認してみましょう。
後は、メッセージのソースを見て、どのような構造になっているかを調べればいい。
multipart/mixed,related,alternativeなどに関しては、自分でグーグル検索してください。

appleも本当にクズ。これのせいで何度も添付させてしまったことがあり申し訳ない気分になる。
なんていうか、プロプリエタリの悪い所がこんなところなんだろうなあ。
別に囲い込まれてもいいけど、変更できるようにしておいてほしい。

追記
関連で最終解決。全部のドメインをspliceしようとしていたら、spliceが逆にまずかったでござるの巻。
 https://roserogue.blogspot.com/2018/11/squid-adobe-cc-dont-splice.html

onenoteをインストールしようとしてはまった。akamaiとmicrosoftはツーカー

onenoteをインストールしようとしてはまったのでメモ。
プロキシでばしばしいろいろなところを切っているのだけれども、色々切りすぎて最近のインターネット様に対応できなくなっていたオチ。
edgesuite.net
がアカマイで、こいつを根元から切っていたのが原因だった。
 更に、wiresharkでログ取りして、http通信を眺めていたところ、
onenote.com
も開けないと同期が取れない事も判明。
microsoft officeは使用ドメインをきちんと書くべきだと思う。
そういえばazureもakamai提供だし、クラウドはマイクロソフト≒アカマイ関係なんだろうなあ。

Proselfを弄ってみた。

Proselfを弄ってみた。
詳しいことは書かないけど、弄る機会がありまして。
UIは、なんというか、owncloudチック、というか丸パクリ感。
使いやすいUIをまんまパクるそのスタイル、嫌いじゃ無いです。
ver.4はまだ昔のストレージ感あるのにね。
機能面では、痒いところに手が届く感じはしました。gigaccとは大違い。
なんというか、Proselfは、ユーザフレンドリーなのに対して、gigaccは大上段に構えてる感じ。
詳しく弄ってない前提で、印象だけ語ると、色んな意味でがちがちなのはgigacc。組織ベース。上長確認システムとか旧態歴然とした組織にはがっつりはまります。でも融通は利かない。
Proselfは、ファイル主体。組織システムにがっちり合わせるというよりも、個人とグループというまとまりで管理するから、昔のはんこ回しとかはやらないよ、という。
FAQにもそれは現れていて、きめ細かいFAQが載っているのがProselfの方だったり。

FAQの話ついでに。
SSLプロキシを設定してから分かってきたことは、XSS対策としてリファラの参照を用いることが多いようなこと。
詳しく見てないけど、恐らくadobeもgoogleも画面遷移させる上でやってる。
Proselfもそうで、
https://www.proself.jp/support/faq341/
https://www.proself.jp/support/faq335/
とのこと。うちは勿論リファラ全切りなので（ブラウザは偽装だし）、勿論引っかかる。
ただ、リファラの偽装は昔からの手段で、携帯サイトを覗きたかったり、ブラウザ指定を回避する際にも弄る場所（だよね？）
XSS対策で入れるのは分かるけど、コントロールしたい人や企業は相当苦労しそう。
だからProselfは外せるようにしているんだろうし。

ntpを設定するのと、squidプロキシを噛ませてyum出来るようにする

最近ファイルスタンプのずれが気になるという声が「やっと」聞けたので、ntpを設定していこうと思い立った。
もののついでに、SSLプロキシがはまったせいで、yumさえ出来なかったサーバプロキシの設定をしてyum出来るようにする。

まずゲートウェイサーバをNTPサーバにする。と言っても、外部NTPサーバと同期させるというだけである。
詳しいNTPについては
http://tech.ckme.co.jp/ntp.shtml

環境はcentos5~7、192.168.168.1がプロキシ兼NTPサーバとする。

yum install ntp

設定ファイルを編集

vi /etc/ntp.conf
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap　＜これをコピーして下で編集
restrict 192.168.168.0 mask 255.255.255.0 nomodify notrap

あと同ファイルで

server ntp.nict.jp#<<公開NTPサービス
server ntp1.jst.mfeed.ad.jp#<<公開NTPサービスに同期している会社の公開NTP
server ntp2.jst.mfeed.ad.jp
server ntp3.jst.mfeed.ad.jp
server 契約しているISPのNTPサービス
#server 0.centos.pool.ntp.org iburst#デフォルトのはコメントアウトして負荷を減らす
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst

これで設定終了。

ntpdate ntp.nict.jp

で手動同期。

systemctl start ntpd
systemctl enable ntpd

で自動起動させる。

iptablesでFW機能をさせているので、iptablesにローカルから自機へのNTP問い合わせ許可設定をする
iptables -I INPUT -p udp --dport 123  -s $trusthost -d $mylanip -j ACCEPT
*$trusthostはローカルIP群、たとえば192.168.168.0/24、$mylanipは、LAN側のIP（この場合は192.168.168.1）。厳密にしないなら-sと-dは無くても良い。

次に、クライアント側設定。
プロキシを通すので、yumの設定ファイルにプロキシを追加

vi /etc/yum.conf

で

#proxy=http://PROXY-SERVER.ADDRESS:port
proxy=http://192.168.168.1:8080

プロキシの噛ませ方は、以下のページが詳しい
http://fj.hatenablog.jp/entry/2014/08/20/204554

で、サーバと同じようにyumでNTPを入れる

yum install ntp

設定ファイルを編集

vi /etc/ntp.conf
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap　＜これをコピーして下で編集
restrict 192.168.168.0 mask 255.255.255.0 nomodify notrap

更に、サーバはnictを登録したけど、クライアントはnictを参照させず、NTPサーバを参照させるので

server 192.168.168.1

とする。

ntpdate 192.168.168.1

で手動同期。

systemctl start ntpd
systemctl enable ntpd

で自動起動させる。

追記
上記でも良いけど、設定しながら「これってntpdateをcronで動かした方がリソース消費しなくね？」という事実に気付き、上記の設定ファイルの編集をせず、たとえば
vi /etc/cron.daily/ntpdate_update.sh
とかで新規ファイルを作って
#!/bin/sh
ntpdate 192.168.168.1
で保存し、
chmod +x ntpdate_update.sh
で実行権限付けて、デーモンは動かさないことにした。クライアントなんだから走らせ続ける意味はないわな。
まあ別に走らせても良いと言えばいいわけで（どうせローカル参照だし）、取り消し線で済ませておくことにする。

手動あわせしようとした際に出る「the NTP socket is in use, exiting」というエラーメッセージは、読んで字のごとく、「NTPソケットはもう使ってるから！」と言われている。
おとなしく
systemctl stop ntpd
なり
service ntpd stopなりでNTPを止めてから再度実行して下さい。

備忘録
オレオレ証明書等ルート証明書をlinuxに読ませる場合
centos7
https://cloudpack.media/14148

/usr/share/pki/ca-trust-source/anchors

に証明書をコピーして

update-ca-trust extract

を実行

centos5~6
https://wp.kaz.bz/tech/2013/05/02/1651.html

/etc/pki/tls/certs/にコピーか、
/etc/pki/tls/certs/ca-bundle.crtに追記する。

SSLプロキシとして動作中のSquid内ネットワークでwindows機にwindows updateさせたい

もう透過プロキシなんて全く考えなくなってしまった僕です。
SSL対応させて分かったことは、もう透過させて何とかしようっていうのが無意味に感じたこと。
証明書読ませる時点で何やってるか自明ですやん・・・。

で、表題の件。
SSL bumpでSSL対応プロキシとして動作しているSquidを頂点としたネットワーク内から、windows updateさせようとしてはまった。
構成は

インターネット　－　Squid入りゲートウェイ　－　ハブで分かれたPC群（ほぼwindows10）

まず、Squid公式で、windows updateの項目を見る
http://wiki.squid-cache.org/SquidFaq/WindowsUpdate#Squid_with_SSL-Bump_and_Windows_Updates

To pass WU check through Squid splice, you only need to splice next MS servers:

update.microsoft.com
update.microsoft.com.akadns.net

For use in real setups, write file url.nobump:

# WU (Squid 3.5.x and above with SSL Bump)
# Only this sites must be spliced.
update\.microsoft\.com
update\.microsoft\.com\.akadns\.net

Just add this file as Squid ACL as follows:

acl DiscoverSNIHost at_step SslBump1
acl NoSSLIntercept ssl::server_name_regex -i "/usr/local/squid/etc/url.nobump"
ssl_bump splice NoSSLIntercept
ssl_bump peek DiscoverSNIHost
ssl_bump bump all

どうやらurl.nobumpに正規表現で書いたドメインをプロキシから除くということらしい。



centos7のrpmインストールなので、/usr/local/squidは/etc/squidに読み替え。
update.microsoft.com
update.microsoft.com.akadns.net
だけ接いでやればいいから！と読めるが、実はそうでも無かった。
実行すると、

一部の署名ファイルが正しく署名されていません。
エラー コード: (0x800b0109)

とでる。
恐らくオレオレ証明書を参照しているからだろうと推測できるが、となると全く接げてないじゃん。
で、更にgoogle先生にお伺いを立てると
https://blogs.technet.microsoft.com/jpwsus/2017/02/27/wu-mu-list/
結構あるぞ・・・。
全部上記に追加して、Squidを再起動してみるが、駄目。
割り切って

windows\.com
windowsupdate\.com
microsoft\.com

とすると、繋がった。がばがばである。
ただ、アップデータをダウンロードするところまで見られていないので、もしかしたらダウンロードに失敗するかもしれない。
等と思っていたら、

が出た。
Squidログを見ていると、
live.net
live.com
宛てにも接続しようとしている。
なので

live\.net
live\.com

を追加して、事なきを得た。
筈だった。
たまたまonenoteを立ち上げたら、onedriveと同期できない。
で、google先生に再度お伺いを立てると、
https://support.microsoft.com/ja-jp/help/2894304
という、winhttpという機構にもプロキシを噛まさなければならないことが判明。
どういう理屈なんだろう・・・・・・・。
プロキシを通せば良いので、

netsh winhttp set proxy proxy-server="server-domain-or-ip-address:12345"  bypass-list=""

としてあげると繋がった。必ず管理者権限で動かすこと。バイパスは多分ローカルだけで良いと思う。
※12345はポート番号。
winhttpについては
http://www.maruko2.com/mw/WinHTTP%E3%83%97%E3%83%AD%E3%82%AD%E3%82%B7%E3%81%AE%E8%A8%AD%E5%AE%9A%E6%96%B9%E6%B3%95

さて、SSLゲートウェイを通すためにユーザに配布するものを整理しよう・・・。
・自己署名証明書ファイル（.derファイル。ブラウザに読ませる）
・winhttpを設定するバッチファイル(管理者権限で動かすこと）
・windowsのプロキシ設定ファイル（設定のネットワークとインターネットから設定するシステムのプロキシをレジストリ直で書くもの。）
この３つかな。
多分透過で上手く動くのであれば、下２つは要らない。
最後の一つのレジストリ上プロキシの場所は
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]

squidをSSLに対応させたい。https通信なんて大っ嫌いだ・・・。

今回何をやったかというと、SquidのSSL対応である。その備忘録。やり方は後日ここにも書きます。ひとまずわかりやすいpslaboさんの記事の方へ

元々
http://pslabo.hatenablog.com/entry/20150703/p1
で、https通信、しかも透過型で噛ませられることは認識していた。
ただ二の足を踏んでいたのは、
・作っている暇が無かった。
　作るならゲートウェイサーバをすげ替えることになるので、何より面倒くさかった。
・透過型なのだけれども、証明書をクライアントにインストールしなければならなかった。
　実は結構これが大きくて、今はプロキシが噛んでいることをユーザは認識せずに使っているのだけれども、証明書を入れなければいけない時点で認識されてしまう。
　また、ゲストネットワークをどう認識させるかという問題もあった。ゲストがネットワークに繋ごうとすると、証明書のインストール必須だと、まあ誰も接続しないだろうし、接続したいと言い張られてサポートに人手が必要とか、切ないことになりそうだったので。

でももう背に腹は代えられなくなってしまった。
どうも社内ファイルがgoogleドライブで作業されているようなのである。
せめてoffice onlineなら分かる。お漏らし回数で考えると、圧倒的にまだマイクロソフトに分があるから。
googleはあくまでも自己責任ツールの集合体で、信用しても信頼してはならない。
大企業だからって信頼してはならないことを知っているはずなのに。
また、銀行系マルウェアに感染した人が居て、大騒ぎになった。愚かとしか言い様がないが、いとも簡単に感染してしまっているのが現実。
で、そのマルウェア、誘導にSSL使っていやがります。
今のままだと、まず間違いなくやられる。
ということで、以下を実行。
pslaboさん本当にありがとうございます。。。見ず知らずなのに即行エントリ書いてもらいました・・・。
http://pslabo.hatenablog.com/entry/2017/06/18/CentOS7%E3%81%A7squid%E3%81%A7SSL%E3%82%92%E3%83%95%E3%82%A3%E3%83%AB%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%99%E3%82%8Bproxy%E3%82%92forward_proxy%E3%81%A7%E8%A8%AD%E5%AE%9A%E3%81%97%E3%80%81

はまったところは、透過プロキシとフォワードプロキシで動作が違うらしく、google「だけ」HSTS通信と見なされ、証明書エラーで通らないこと。facebookもtwitterもHSTS通信でも大丈夫だったのに。
透過プロキシだとどうしても通らなかったのが、通常のプロキシだと通るという・・・。
ここからカスタムしていくことになるのだけれども、まずはOK/NGという初期段階まではいけたということで。
#検証前だけど、googleがリダイレクト動作をしているので、そこで引っかけている可能性が高そう。どう回避するかなあ・・・。

squid.conf設定(squid3のコンフィグレーションファイル）

一寸前のsquid設定を。
今はこれよりもっと書いてしまっているが、収拾が付かなくなりそうなので一度上げとこうかと。
透過プロキシで、httpアクセラレーター設定。
iptablesでポートの転送設定しないといつまでも繋がらないので注意。
あとhttps（ssl通信）をsquidで乗っ取ろうとしたけど断念。
理由は透過プロキシだとman inthe middleになってしまうので、sslbumpを入れないといけなくなる（入れたら入れたで、証明書が違うと警告がユーザークライアントに多発するので現実的では無いという判断）。
結局iptablesで、どうしてもはじきたい所をはじくという、苦肉の策になる。
どうにかならないものかなあ・・。


http://roserogue.blogspot.jp/2014/12/1e100netgoogle.html

 を参照のこと。


#squid3
#
#http://squid.robata.org/
#が一番情報載ってる
#
# Recommended minimum configuration:
# ここら辺はデフォルト設定をそのまま
#
#acl cache object localhost
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1


#acl ipv4local address ipv6 local unicast address
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7       # RFC 4193 local private network range
acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines

acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT

#
# Recommended minimum Access Permission configuration:
#
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager

# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed

#user user
cache_effective_user squid
cache_effective_group squid



###########################################
#user blacklist
###########################################
#接続させたくないURL、IPアドレス、URLパス
#
#dstdomain ドメイン名を正規表現で表記。ドットから始めればサブドメインも含まれる
#ダブルクォーテーションでくくってファイル参照
#regex
#path
#user blacklist

acl blacklist dstdomain "/etc/squid/blacklist"
acl blacklist_regex url_regex "/etc/squid/blacklist_regex"
acl blackpath urlpath_regex -i "/etc/squid/blackpath"
#blacklist deny list
http_access deny blacklist
http_access deny blacklist_regex
http_access deny blackpath


###########################################
#deny user
###########################################
#接続させたくない特定のユーザー（クライアント）を指定。ローカルIPアドレスで指定する。

acl deny_userlist src "/etc/squid/userlist_deny"
#acl deny_userlist src 192.168.1.255 192.168.1.254
http_access deny deny_userlist


###########################################
#limit user
###########################################
#限定的に接続させたい任意のユーザー（クライアント）を指定。ローカルIPで指定する。

acl limit_userlist src "/etc/squid/userlist_limit"
acl limit_domain_url dstdomain "/etc/squid/url_limit_domain"
acl limit_regex_url url_regex "/etc/squid/url_limit_regex"
http_access allow limit_userlist limit_domain_url
http_access allow limit_userlist limit_regex_url
http_access deny limit_userlist


###########################################
#特定URL等。遅延プール
###########################################
#http://www.itmedia.co.jp/enterprise/articles/0812/01/news024_2.html

#acl peakperiod time 10:00-16:00

#Delay_Pool
delay_pools 3

#-----------pool 1 ----------------
#userlist_delayの中のIPアドレスユーザーを遅延させる
delay_class 1 1 # pool 1 is a class 1 pool
acl delay_userlist src "/etc/squid/userlist_delay"
#
# SPEED
delay_parameters 1 320/320
#
delay_access 1 allow delay_userlist
delay_access 1 deny all


#-----------pool 2 ----------------
#リストに表記されているURLなどへのアクセスを遅延させる
delay_class 2 1 # pool 1 is a class 1 pool

acl dstdelaylist dstdomain "/etc/squid/delaylistdst"
acl regex_delaylist url_regex "/etc/squid/delaylist_regex"
acl pathdelaylist urlpath_regex -i "/etc/squid/delaylistpath"

#1408kbit/s
delay_parameters 2 176000/176000
#896kbit/s
#delay_parameters 2 112000/112000
# 64 Kbit/s
#delay_parameters 2 8000/8000

delay_access 2 allow dstdelaylist
delay_access 2 allow regex_delaylist
delay_access 2 allow pathdelaylist
delay_access 2 deny all


#-----------pool 3 ----------------
#特定のブラウザ使用者を遅延させる
delay_class 3 1 # pool 1 is a class 1 pool
acl delaybrowser browser -i Chrome
acl delaybrowser browser -i Safari
# 128 Kbit/s
delay_parameters 3 16000/16000

delay_access 3 allow delaybrowser
delay_access 3 deny all


#----------delaypool end------------------#

###########################################
#user FTP
###########################################

acl FTP proto FTP
always_direct allow FTP


###########################################
#最終許可
###########################################

http_access allow localnet
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all

######################################################################################
###########################################


# Squid normally listens to port 3128
#user
#http_port 3246
http_port 3246 transparent
#http_port 3128 transparent
#http_port 3128

# We recommend you to use at least the following line.
hierarchy_stoplist cgi-bin ?

#--------------------------
# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/spool/squid 100 16 256
#user

#cache_dir 32GB
cache_dir aufs /var/spool/squid/cache_l 32768 16 256

#maximum_object_size 128MB
maximum_object_size 131072 KB

#cache_mem 1GB(total 3GB or so)
cache_mem 1024 MB
memory_pools_limit 0

# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid
#--------------------------------

# Add any of your own refresh_pattern entries above these.
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
#refresh_pattern .              0       20%     4320
##################################
#USER ADD REFRESH PATTERN
##################################
refresh_pattern -i \.(gif|png|jpg|jpeg|ico)$ 10080 80% 43200 override-expire ignore-no-cache ignore-no-store ignore-private
refresh_pattern -i \.(iso|avi|wav|mp3|mp4|mpeg|3gp|swf|flv|x-flv)$ 43200 90% 432000 override-expire ignore-no-cache ignore-no-store ignore-private
refresh_pattern -i \.(deb|rpm|exe|msi)$ 10080 90% 43200 override-expire ignore-no-cache ignore-no-store ignore-private

refresh_pattern -i \.index.(html|htm)$ 0 40% 10080
refresh_pattern -i \.(html|htm|css|js)$ 1440 40% 40320
refresh_pattern . 0 40% 40320
##################################


#user
#LOG
logfile_rotate 14
cache_access_log /var/log/squid/access.log
cache_log /var/log/squid/cache.log
cache_store_log /var/log/squid/store.log
access_log /var/log/squid/access.log

#user
#auth_param basic program
auth_param basic children 10
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

#user
pipeline_prefetch on

###########################################
#user anonymize
###########################################
icp_port 0
forwarded_for off
client_db off
#user HEADER ANONYMIZING
#header_accessは30系で無くなったらしい
request_header_access X-Forwarded-For deny all
request_header_access Via deny all
request_header_access Cache-Control deny all


###########################################
#SQUID3 HEADER REPLACE###
###########################################

request_header_access From deny all
request_header_access Referer deny all
request_header_access User-Agent deny all
header_replace User-Agent Mozilla/5.5 (Windows NT 55.0; Win64; x64) AppleWebKit/555.55 (KHTML, like Gecko) Chrome/55.0.0005.05 Safari/555.55 Edge/15.0

#user
visible_hostname none

#header_replace Referer google.com

1e100.netというgoogleの踏み絵

chrome汚染が酷いので、googleサービスを取捨選択して使用しようと思い立った。
まずchrome自体をダウンロードできなくするために、dl.google.comへのhttp、httpsアクセスを止めた。
あと広告配信を1e100.netからやっているようなので、これも止めた。
するとどうだろう。ssl通信を必要とするほぼほぼ全てのgoogleサービスにアクセスできない。
アクセスしてもタイムアウトする。iptablesがうまく動いている証拠と言えば証拠だが・・・。
慌ててsquidのログを確認すると、216.58.216.XXXを恐ろしい回数ドロップしている。
1e100.netである・・・。

1e100.netについて調べると、http://www.herdprotect.com/に行き当たった。

docs.google.com
http://www.herdprotect.com/domain-docs.google.com.aspx
dl.google.com
http://www.herdprotect.com/domain-dl.google.com.aspx

結局1e100.net（のサブドメイン）を使っているのだ・・・。
なので、iptablesで1e100.netをはじくとさっぱり繋がらなくなる。
また、docs.google.comやdl.google.comをブロックしても、同じ状況に陥る。
ただし、必要な1e100.net群をブロックしていなければ、そこそこ繋がるという不思議状況にもなる。
ワンチャンかけてdl.google.comをブロックするのもありだが、あまりお薦めはしない。
また、何回か試していると、いつも決まった1e100.net（のサブドメイン）を参照している「わけではない」ようなので、余計にたちが悪い。

結局squidでhttpのみdl.google.comや1e100.netをはじく対処で落ち着いた。
落ち着いた？気休めである。そう、問題は何も解決していない。
googleはSSLを推奨しており、わざわざhttp接続にしても、ご丁寧にhttps接続に切り替えてくれる。

https://support.google.com/drive/answer/1211661?hl=ja
で、ファイヤーウォールの設定が書いてあるが、
結局大元の1e100.netを止めてしまっては元も子もないということである。不親切。
また、
https://support.google.com/faqs/answer/174717?hl=ja
に1e100.netについて書いてある（が、日本語にならない。）

we started using a single domain name to identify our servers across all Google products

と記述されているので、まあ「そういうこと」なのだろう。
googleサービスを使うのであれば、1e100.netへのSSLアクセスは必要で、拒否することは出来ない。

そう、抵抗は無意味だ。

iptablesで特定の外部サーバへのSSL接続を制限・禁止したい

やっと念願のSSL接続を遮断することが出来た。
元々squidでフィルタリングする予定だったが、どうも透過プロキシを使用する場合はNGらしく
http://lists.debian.or.jp/debian-users/200909/msg00065.html
じゃあどうやって切るんだと言われると、iptablesくらいしか思いつかなかった。
そこで

iptables -I OUTPUT -d 31.13.64.0/18 -p tcp --dport 443 -j DROP

という感じで記述したのだけれども、結局箸にも棒にも、iptablesにも引っかからなかった。
人に聞いてみても応えてくれないし、正直お手上げだった。
というか、みんなデフォルト設定でOUTPUTはACCEPTの人が多いんですよねー・・・。

で、google先生に力一杯調べて貰って5年越し（5年間分からなかった）の回答を得た。
http://www.linkedin.com/groups/HOW-block-HTTPS-sites-32612.S.107118452
流石linkedin。実名で且つ仕事してる人たちの集まり。
Pramodさん流石すぎる。

iptables -I FORWARD -s 192.168.1.0/24 -d 31.13.64.0/18 -j DROP

FORWARDなのね・・・。
真逆の展開。というか、よく考えればその通りで、ローカルからディスティネーションへの転送だから、ああ、なるほど。
443だけ蹴りたいので、

iptables -I FORWARD -s 192.168.1.0/24 -d 31.13.64.0/18 -p tcp --dport 443 -j DROP

となる。かな。

ということで、まずはじきたいurl群を書いたファイル「denysslURL」を用意する。
で、以下のシェルスクリプトファイルを作る。
vi BANSSH.sh

#!/bin/sh
#スクリプト起動時にファイル「denyssllist」を消して再作成
rm -rf ./denyssllist
touch ./denyssllist

#########このシェルスクリプトは、必ずきちんとしたiptablesの設定を読み込んでから実行###################
#SSLをはじくurlを書いたファイル「denysslURL」を読み込んで、ipアドレスをdenyssllistに書き込む
############################
if [ -s ./denysslURL ]; then
  for dnysslurl in `cat ./denysslURL`; do
     host -W 2 $dnysslurl | grep "has address " | cut -d' ' -f4 >> ./denyssllist
  done
fi

host命令にに-W 2が入っているのは、もしurlが値を返さなかった場合（筆記ミスとか、休止したとか）、凄く待たされるので、2秒経ったら諦めるようにしているということ。
そこからの

iptables -N IPDENYSSL
iptables -A IPDENYSSL -j LOG --log-tcp-options --log-ip-options --log-prefix '[IPTABLES IPDENYSSL]: '
iptables -I IPDENYSSL -j DROP
if [ -s ./denyssllist ]; then
  for denysslip in `cat ./denyssllist`; do
   iptables -I FORWARD -s 192.168.168.0/24 -d $denysslip -p tcp --dport 443 -j IPDENYSSL
  done
fi

みたいな。
これで安心してdropboxを蹴り出せるし、何よりLINEの認証を止められる。
LINEはサーバに繋ぎすぎ。
0点。

シェルスクリプトの突っ込み大歓迎です。多分もっと短くなるはずなので。というか、眠い・・・・・。

追記

#!/bin/sh

################################
#

mv /usr/local/sbin/denyssllist /usr/local/sbin/denyssllisttmp

############################
#change URL(need file  >>>   denysslURL
############################
if [ -s /usr/local/sbin/denysslURL ]; then
  for dnysslurl in `cat /usr/local/sbin/denysslURL`; do
     host -W 2 $dnysslurl | grep "has address " | cut -d' ' -f4 >> /usr/local/sbin/denyssllisttmp
  done
fi

#########
#
#facebook
#echo "31.13.64.0/18" >> /usr/local/sbin/denyssllist
#dropbox
echo "108.160.0.0/16" >> /usr/local/sbin/denyssllist
#LINE
echo "119.235.235.91" >> /usr/local/sbin/denyssllist

##################
#SORT&UNIQ
##################
sort /usr/local/sbin/denyssllisttmp > /usr/local/sbin/denyssllist
rm -f /usr/local/sbin/denyssllisttmp

 これはcron.dailyに読ませる

squidのblacklist内容。URLだったり

表題の通りで、squidのblacklistを以下に。
参考にしたURLは
 http://yanmoo.blogspot.jp/2011/12/vpsopenbsd-squid.html
人によっては使いにくいかも知れないけど、そこら辺は変えて下さい。
初っ端からdropbox蹴ってます。マカフィーも蹴ってます。皆さん黙ってESET入れておきましょう。
基本方針は、広告系をまず蹴り出す、次に中韓製でやばそうなものを蹴り出す、スパイウェア系を蹴り出す、という拒否リストです。

#squid blacklist 20140611

.getdropbox.
.dropbox.com
^www.dropbox.com:443
.cloudfront.net:443
.adlantis.jp
.googlesyndication.com
.doubleclick.net
.woopiedesktop.com
.impact-ad.jp
.advertising.com
.adjust-net.jp
.serving-sys.com
.linksynergy.com
.valuecommerce.com
.microad.jp
.atdmt.com
.veoh.com
.kh.google.com
.adplan-ds.com
.akamaihd.net
.link-trade.net
.zerofactory.co.jp
.ad-recommend.com
.dmm.co.jp
.adgene.net
.afisapo.com
.blogparts.dmm.com
.ha123.com
.baidu.co.jp
.baidu.jp
.baidu.com
.i-mobile.co.jp
.agilemedia.jp
.kau.li
.ad.adresult.jp
^adcdn.goo.ne.jp
.bearshare.com
.jword.jp
.ai.yimg.jp
.im.c.yimg.jp
.criteo.com
.ads.nicovideo.jp

.baiduime.jp

.gomlab.com
.gomplayer.jp
.testqweasd.tk

.mcafee.com

.vipstar23.com

#2ch_incidents
.vipsister23.com

#yoshida
.lemurleap.info
.babylon.com
.ask.com
.weblayers.co
.browsefox.com
.webconnect.co
.linkswift.co
.swiftbrowse.net
.lizardlink.biz
.saltarsmart.biz
.luckyleap.net
.wunderweb.biz
.rolimno.net
.websparkle.biz
.diamondata.net
.hao123.com
.hao123.jp
.systweak.com


#yamaguchi
.gfxpeers.net
.torrentus.to
.torrentz.pro
.torntv-tvv.org
.netdna-cdn.com
.pinimg.com
.great-appdownloads.com
.downlist.eu
.sendspace.com
.emsisoft.com
.spccint.com
.cheesestream.com
.exelator.com
.56.com
.v-56.com
.liverail.com
.adnxs.com
.userlocal.jp
.nakanohito.jp

#incidents_freephone(viber,LINE)
.viber.com
dl.desktop.line.naver.jp
gd2.line.naver.jp
dl.profile.line.naver.jp
me2day.net
gw-beta.line.naver.jp
nid.naver.com
help.naver.com
appauth.naver.com
ndrive1.nave.com
desk.talk.naver.com
dl.desktop.line.naver.jp.edgesuite.net
a1896.g.akamai.net
openapis.jboard.naver.jp
a1284.g.akamai.net
dl.profile.line.naver.jp.edgesuite.net
cac-dl.profile.line.naver.jp.line-zero.akadns.net

#http://yanmoo.blogspot.jp/2011/12/vpsopenbsd-squid.html
^http://banner
^http://.*Count
^http://count
^http://analyze
e-kaiseki\.com
google-analytics\.com/ga\.js
.*adsense
.*adwords\.google
.*\.google\.*/adfetch
.*google_ad
.*\.googlesyndication
^http://rcm.*\.amazon
.*\.assoc-amazon
.*ws\.amazon\..*/widgets
.*\.amazonaws\..*/widget
.*\.amazon\.*/tipbox
^http://richmedia\.yimg\.
.*\.yimg\.com.*/ysc_csc_
.*\.yimg\.com/ad
.*\.toto\.geo\.yahoo\.
.*\.ov\.yahoo\.
.*\.overture\.
.*/overture_*
.*/ard\.yahoo\.
.*\.geocities\.*/js.*/.*\.js
.*\.yimg\.jp/bdv/
.*/yjaxc\.yahoo\.co\.jp/js/yjaxc\.js
^http://xml\.affiliate\.rakuten\.co\.jp/
^http://.*\.afl\.rakuten\.co\.jp/
^http://.*\.rakuten\.co\.jp/js/.*\.js
^http://api\.rakuten\.co\.jp/.*affiliateId
^http://.*\.ias\.rakuten\.co\.jp/
^http://ad-hatena\.jp/
^http://.*\.avatar\.livedoor\.com/
^http://.*\.blogdeco\.jp/
^http://.*\.blogpartsgarden\.jp/
^http://.*\.blogpet\.net/
^http://.*\.blogranking\.net/
^http://.*\.blogtoy\.net/
^http://.*\.floq\.jp/
^http://.*\.livedoor\.jp/js/
^http://parts\.logoole\.yahoo\.co\.jp/parts/
^http://www\.tweetswind\.com/twitterwind\.php
^http://twitstat\.us/twitstat\.us-min\.js
^http://.*\.sakuratan\.biz/js
^http://rss\.rssad\.jp/rss/
^http://www\.seesaa\.jp/r\.pl
.*\.pheedo\.jp/html
.*\.overture\.
.*/overture_*
.*/ard\.yahoo\.
.*\.geocities\.*/js.*/.*\.js
.*\.yimg\.jp/bdv/
.*/yjaxc\.yahoo\.co\.jp/js/yjaxc\.js
^http://xml\.affiliate\.rakuten\.co\.jp/
^http://.*\.afl\.rakuten\.co\.jp/
^http://.*\.rakuten\.co\.jp/js/.*\.js
^http://api\.rakuten\.co\.jp/.*affiliateId
^http://.*\.ias\.rakuten\.co\.jp/
^http://ad-hatena\.jp/
^http://.*\.avatar\.livedoor\.com/
^http://.*\.blogdeco\.jp/
^http://.*\.blogpartsgarden\.jp/
^http://.*\.blogpet\.net/
^http://.*\.blogranking\.net/
^http://.*\.blogtoy\.net/
^http://.*\.floq\.jp/
^http://.*\.livedoor\.jp/js/
^http://parts\.logoole\.yahoo\.co\.jp/parts/
^http://www\.tweetswind\.com/twitterwind\.php
^http://twitstat\.us/twitstat\.us-min\.js
^http://.*\.sakuratan\.biz/js
^http://rss\.rssad\.jp/rss/
^http://www\.seesaa\.jp/r\.pl
.*\.pheedo\.jp/html
.*\.www\.pheedo\.jp/img\.phdo*
^http://.*\.impact\-ad\.jp/
^http://.*\.2mdn\.net/
^http://.*\.doubleclick\.net/
^http://.*\.atdmt\.com/
^http://.*\.advg\.jp/
^http://.*\.disqus\.com/
^http://.*\.affiliate\.rakuten\.co\.jp/
^http://ad\.yieldmanager\.com/
^http://.*\.dmm\.co\.jp/dmmad/
^http://ads\.adjust-net\.jp/
^http://.*\.admeld\.com/
^http://.*\.advertising\.com/
^http://.*\.trustclick\.ne\.jp/
^http://click\.dtiserv2\.com/
^http://affiliate\.dtiserv\.com/image/
^http://.*\.accesstrade\.net/
^http://ad\.agilemedia\.jp/
^http://spdeliver\.i-mobile\.co\.jp/ad
^http://aqua\.dmm\.co\.jp/dmmad/
^http://www\.google\.com/uds/Gfeeds
^http://ad\.kau\.li/
^http://www\.amiami\.jp/images/
^http://.*\.ziyu\.net/
^http://cast\.ads\.jlisting\.jp/
^http://minkch\.com/js/
^http://mmaaxx\.com/
^http://.*\.i2i\.jp/
^http://.*\.i2iserv\.com/
^http://js\.addclips\.org/
^http://www2\.liveads\.jp/
^http://ranklink\.s2ch\.com/
^http://g-ec5\.images-amazon\.com/images/G/09/ui/loadIndicators/loadIndicator-large\._V192261612_\.gif
.*\.akamaitechnologies\.com/
.*\.amazonaws\.com/
.*\.prod\.millennialmedia\.com
^http://.*\.admob\.com/
^http://.*\.adwhirl\.com/
^http://.*\.mydas\.mobi/
^http://ads\.osdn\.jp/
^http://.*\.adlantis\.jp/
^http://.*\.adimg\.net/
^http://.*\.xmax\.jp/
^http://www\.facebook\.com/plugins/
^http://www\.yomiuri\.co\.jp/i1/
^http://www\.yomiuri\.co\.jp/g2/
^http://l\.popin\.cc/
^http://www\.yomiuri\.co\.jp/.*\.js

squidに負荷をかけてみる（abコマンドでプロキシサーバの負荷テストをしたい）

squidでリバースプロキシ（httpアクセラレータ）＋透過プロキシを立てている。
最近キャッシュの量とかメモリ関係をいじったので、果たして使い物になるのだろうか、ということを確かめたかった。

プロキシの負荷テストに、apache同梱のabコマンドが使えると言うことを目にしたので、早速試す。
virtualboxのcentosにapacheをyumでインストール

yum install httpd

その後、squidの入ったサーバに対し、無線LAN経由で早速試したが書式に困る。
-Xでプロキシ指定と書かれている
http://www.omnioo.com/record/ubuntudebian/web_apache_ab_command/
が、何故か通らない。
と思ったらそりゃそうだ。透過プロキシなんだもん。
普通にアクセスしてやればいいのではないか。
で、普通にアクセスすると、やっぱり通らない。
首を捻りながら他の書式を参考に、接頭として「http://」、接尾に「/」を入れると通る。
ううむ・・・。

ということで、通った書式は

ab -c 100 -n 10000 http://192.168.168.168/

192.168.168.168は、squidプロキシサーバのIPアドレス
-cは同時接続数、-nは総リクエスト数

-cの値を400でやってみた時のログが下。500にするとfaildがかなり出たのでそこまでは使えないんだろうけど、
400台からリクエスト受けることなんて無いので、十分満足な結果。また、総リクエスト数は10,000だろうが100,000だろうがエラーは出なかった。

# ab -c 400 -n 10000 http://192.168.168.168/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.168.168 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        squid/3.1.10
Server Hostname:        192.168.168.168
Server Port:            80

Document Path:          /
Document Length:        3149 bytes

Concurrency Level:      400
Time taken for tests:   21.348 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Non-2xx responses:      10065
Total transferred:      35295756 bytes
HTML transferred:       31642161 bytes
Requests per second:    468.43 [#/sec] (mean)
Time per request:       853.912 [ms] (mean)
Time per request:       2.135 [ms] (mean, across all concurrent requests)
Transfer rate:          1614.62 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2  248 621.4     60    4298
Processing:   106  533 1064.4    215   11993
Waiting:      104  357 591.2    197    9319
Total:        113  781 1367.8    294   12831

Percentage of the requests served within a certain time (ms)
  50%    294
  66%    592
  75%    806
  80%    975
  90%   1493
  95%   3182
  98%   4819
  99%   6595
 100%  12831 (longest request)

topで観察していると、cpuは40%から50%ぐらい使っている。
システム的にはceleron1037uでメモリ8GB。
squidのキャッシュ設定は

cache_dir ufs /var/spool/squid/cache_l 8192 16 256
maximum_object_size 131072 KB
cache_mem 1024 MB

追記
http://okwave.jp/qa/q9003206.html
で貼られていたので・・・

ベンダーさんの100台まで発言は見過ごせませんね・・・。
僕の稼働実績としては200台近くまでありますよ。
スループットも特に問題になったことはありません。
忌々しいchache.google.comにどれだけ接続されようとも・・・！
因みにその時は、core2quadで8GB環境、NICは4ポートintelでした。
瞬間同時接続数（よーいどんで一気に接続する）は見てませんが、上記のテストを信じるのであれば、400台近くまではいけるはずです。
しかもセレロン（ニアリーcore2duo）8GBRAM環境でこれなので、
ベンダーさんがきちんと組めば、普通に組めるはずです。
是非このベンダーさんには、論拠をご教示頂きたいですね。

あと質問者さんが言っているファイルディスクリプタのことは
http://takeda-h.hatenablog.com/entry/2014/12/09/005533

http://d.hatena.ne.jp/rougeref/20130424

みたいな所に書いてあります。
因みに1037Uのこのsquidは、ファイルディスクリプタ弄ってません。で、常時90台程度接続のhttpアクセラレータです。

参考になれば。