どさにっき IoT

by やまや
9月上旬

2016年9月9日(金)

サブドメイン管理者が親ドメインの SSL 証明書を取得する

_ 中国最大級の認証局「WoSign」がニセの証明書を発行していたことが判明。サブドメインの管理権限がある人が親ドメインの SSL 証明書が取得できちゃったんだって。この問題、他の CA でもあるんだよね、実は。

_ 具体的に言うと Let's Encrypt がそれ。 この記述。example.com ドメインの所有者かどうか判断する方法のひとつとして、_acme-challenge.example.com の TXT レコードに指定のトークンを記述せよ、というのが挙げられている。ということで、ユーザが自由にサブドメインを作れるサービス上で _acme-challenge というサブドメインを作成すれば親ドメインの証明書を発行してもらえる。今回の WoSign の件のように任意のサブドメインでいけるわけではなく、ラベルにアンスコが含まれるのでちゃんとしたサービスであればバリデーションで弾かれる可能性も大きいけど、でもそれさえクリアできれば親ドメインの所有者に気付かれることなく Let's Encrypt (あるいは他の ACME プロトコルを実装した CA)から証明書を取得できちゃう。

_ https://maya.st/には Let's Encrypt から発行された証明書が入ってるけど、これは実際にこの方法を使って取得した。具体的には、maya.st ゾーン内に _acme-challenge というレコードを作るのではなく、maya.st から NS を*委譲されていない* _acme-challenge.maya.st というゾーンを maya.st ゾーンと同じサーバ上で作成することによって取得した( 参考)。親ドメイン(maya.st) も子ドメイン(_acme-challenge) も管理してるのは同じ人間なんでひとり2役だけど。

_ この件は今年の6月に気がついて7月には Let's Encrypt には報告済み。が、なんかトンチンカンな返答 (*1)が返ってきて、いや、そーじゃねーよ、というやりとりを何回か繰り返して結局無視されて対応されず。こっちの英語がおかしかったのかなー。そんなわけで、これまで黙ってたけど晒してみた。


(*1): 「appending the label "_acme-challenge" と書いてあるだろ(prepending じゃなくて)、だから _acme-challenge.example.com じゃなくて example.com_acme-challenge というレコードを作ってくれ」という返事が来た。マジで。

2016年8月28日(日)

槍ヶ岳に行ってきた

_ 登ってない。

_ いわゆる表銀座縦走。まず初日、8/24。中房温泉から入って燕岳まで。登ってる間はずっと曇ってたけど、稜線まで達すると晴れ間も見えて。写真で見るとこんな感じ↓

この雲の方から登ってきたわけで。ひと山越えると天気がぜんぜん違うってのはふだんはピンとこないけど、こういうときには実感できる。ただ、晴れ間は見えてても雲も多く、目指す槍ヶ岳の方向は厚い雲にブロックされてまったく見えず。

_ 2日目、8/25。朝、テントから。

目的地がやっと見えたけど、まだまだ遠い。で、こんな道↓を歩いていくわけですが、

晴れてるのは朝のうちだけで、昼近くになるとやっぱり雲が出てきて、↓こうなっちゃうわけで。

それはそれでかっちょええ姿も見えたりするのだけれど。

あとブロッケン現象。

_ 3日目、8/26。朝はやっぱり晴れるわけですよ。


あんなに遠かった槍もずいぶん近づいてきたなぁ。

表銀座ってのは超メジャーな縦走コースなんで、気軽にほいほい歩ける道なんだろと思ってたら大間違い、実は足を一歩踏み外したら死にそうな場所ばっかりで、目の前の一歩を確実に進めるのに集中してのんきに景色を楽しんでる余裕などなく、気がついたら、やっぱり雲が。槍の肩まであと 1km なのに。

肩の小屋まで到着してテント張り終えたころには完全に雲の中。登れなくはないけど、景色を楽しめるわけじゃないので、あきらめて翌日がんばろうか、と。ビールを飲み始めると雲がなくなったりするわけだが、これもほんの数分のことだけで、この数分にしても、山頂のまわりの雲がなくなっただけでろくな景色が見えるわけじゃないし。

_ で、最終日、8/27。朝のうちは晴れるんですよ、ふつーは。が、この日は朝から雨。きのうは登れるけど景色が残念だから登らなかったけど、この天気で登るとスリップして死にかねない。ということで、撤収。雨に濡れてよけいに重くなったテントを畳んで上高地まで一気に下る。写真なんて1枚もなし。

_ ちうことで、槍ヶ岳に行ったけど登らずに帰ってきたわけだけど、あんまり残念だとは思ってなかったり。いつも遠くから見てた槍を近くから見たかったのであって、てっぺんまで登ることに対する執着はほとんどないので。また機会はあるさ。


2016年7月25日(月)

httpoxy つづき。

_ えーと、 この前 freebsd の libfetch にも穴あるよと書いたんだけど、一向に動きが見えないので自分で pr 投げた。既知の脆弱性だと、詳細が公にならない連絡窓口をいちいち探さなくていいし、脆弱性の詳細をいちいち説明しなくていいしラクチンだわ。

_ 結果。

httpoxy is a server-side vulnerability, not client-side. If a CGI script or similar uses libfetch(3) or fetch(1) internally without first sanitizing the environment, that's a bug in the script, not in libfetch.
ということで修正されずに close されますた。えー。libfetch を CGI から使うような場合でも、libfetch では対応しないので外側で何とかせよ、と。いや、libfetch をそういう使い方するのはかなりのレアケースであることはわかってるけどさ、もし CGI で使うとなれば libwww-perl や libcurl と同じ使い方になるのは明白でしょ。スクリプトのバグであってライブラリのバグじゃない、と言ってしまっていいのかなぁ? 同じ対応が必要なんじゃねーの? それでいいのかなぁ。


9月上旬
やまや