ラベル SSL の投稿を表示しています。 すべての投稿を表示
ラベル SSL の投稿を表示しています。 すべての投稿を表示

2021年8月13日金曜日

chaos groupにはうんざりだ。(オンライン認証が通らない)

 Chaos groupのオンラインライセンス認証が通らない。
v-rayなどのメーカーchaos groupの製品を使っているとオンライン認証させられるのだけれども、こいつが兎に角通らない。
ただ環境を変えると通るので、恐らくセキュリティ的に拙い何かをこいつがやっていることになる。
調べると、ols.chaosgroup.comというドメインとaccounts.chaosgroup.comというドメインの443を通せと書いてあるページを見つけた。
https://accounts.chaosgroup.comは普通に通る。だがhttps://ols.chaosgroup.comは違った。ブラウザでセキュリティ警告が出る。
・・・オレオレ証明書である・・・。
本当に糞なのでどうにかして頂きたい。結局このドメインをホワイトリストに登録して通したが、証明書位買えよと。
よくそれでオンラインサービスやってるなと。大体代理店がまず指摘しなきゃいけないと思うのだけれども。
そんな製品売れないよと。

とか思ってたらhttps://v-ray.jp/ が証明書切れ。え、何これオークがやる気無いからって事?会社の全部アスクに乗り換えようかしらん。

2020年10月2日金曜日

(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を再起動したら通った。 

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

2020年2月6日木曜日

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

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


    不正なURL

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

考えられる問題:

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

    ホスト名がありません。

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

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

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

2017年7月10日月曜日

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は外せるようにしているんだろうし。

2017年6月26日月曜日

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のプロキシ設定ファイル(設定のネットワークとインターネットから設定するシステムのプロキシをレジストリ直で書くもの。)
この3つかな。
多分透過で上手く動くのであれば、下2つは要らない。
最後の一つのレジストリ上プロキシの場所は
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]

2017年6月23日金曜日

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がリダイレクト動作をしているので、そこで引っかけている可能性が高そう。どう回避するかなあ・・・。