HTTP Status 301

6/17GLacé というエロゲ ブランドのサイトを引っ越した。ドメイン(glace.me)が切れるからだ。
そして元のドメインである glace.me には新しいサイトに転送するように設定しておいた。このとき、301 を返すようにしておくと、Google などの検索エンジンは引っ越し先のアドレスを登録するようになる。

glace.me が切れるのが 6/26。はて、それまでに検索エンジンに反映されるだろうか?(汗

そしたら次の日(6/22)にはちゃんと反映されていた。ありがたや。

リバース プロキシと WordPress

昨日Apache 上で PHP を動かすのに苦労したという記事を書いた。まぁ普段から Linux を使ってる人間にとってはなんてことない設定だ。Windows Server 側のボクからしても、振り返れば大したことではない。
さて、次は Windows Server でも Linux でもない、別の問題だ。

この仕事は WordPress を使う仕事だった。といってもボクはそちらには踏み入れない。ボクの仕事はフロント部分で、デザイナーさんがあげてきたウェブ デザインを CSS + HTML + JavaScript + PHP で WordPress のテーマに落とし込む仕事である。
とはいえサーバを用意するようには言われたので、昨日用意した仮想サーバに WordPress をインストールして動くようになるまではやらなければならない。

昨日も説明したが、仮想サーバはこの amatsukami.jp サーバ上にある。
インターネットからこの仮想サーバにアクセスするには、グローバル IP アドレス(インターネットの世界で重複しないユニークなアドレス)を最低でも一つ割り当てなければならないのだが、amatsukami.jp にはグローバル IP アドレスが一つしかないので、仮想サーバに割り当てることは出来ない。
そこでリバース プロキシApplication Request Routing)という仕組みを使って、仮想サーバにアクセスしに来たデータは amatsukami.jp サーバが素通しして仮想サーバに通すようにする。こうすることによって、外からはあたかも仮想サーバがインターネット上にいるかのように見えるわけである。

これ自体の設定は、とても簡単で、素通しの設定をすればいいのである。

問題は HTTPS だ。とはいえ、実はこれ自体も設定は簡単である。リバース プロキシが暗号化の処理をしてあげればいいのだ。リバース プロキシの向こう側にいる仮想サーバは別に暗号化の処理をしなくても良いのだ。
ところがここで大きな問題が生じる。それは「リンク」だ。

仮想サーバは暗号化の処理をしない。ということはどういうことになるかというと、WordPress は、自身のリンクにすべて「http://」という暗号化なしのアドレスを貼ってしまうのだ。

暗号化してある場合、ここは「https://」で始まらなければならない。でも WordPress 自身というか、仮想サーバそのものが暗号化の処理を必要としていないわけだから、https のリンクを張るわけがない。

さーて、こまった……これはどうすればいいんだ??

で、いろいろ試行錯誤した結果、WordPress が実行される一番最初のところで、ムリヤリ、HTTPS だという嘘の情報を書き込むと動くことが判明したwwww

$_SERVER['HTTPS'] = 'on';

この一行を書き加えるだけですべて解決(汗)。え、ほんとにいいのかなぁ??
たぶん解決方法としては正しくないとは思うんだけど、とりあえず動いているし、特に問題も起きてないのでよしとしよう(ぁ
プラグインとかの更新もちゃんとできるし……(^^;

2020 年最初の台風が発生した。去年より 3 ヶ月以上遅れての発生だ。というのも去年は 2/20 の段階ですでに二号が生まれているからだ。とはいえツイートで一月に発生していたというのは調査不足だ。じっさい 2029 年の台風一号がいつ発生したかは調べてない(汗

さてこの 2019 年との台風発生の違いは現れるだろうか? 去年は妙に台風の数が多かったが……今年は果たして?

CentOS で PHP を動かすのに苦労する

長編小説が進んでない……。9 月からずっと忙しいのだ。
ただコロナ禍になって、テレワークになったので、だいぶ余裕が出来た。
ちょっと合間をぬって、東京守護神の公開している部分を整理した。まぁただそれだけなんだけど……。

仕事でまた Linux を扱うことになった。うーむ……。
といってもウェブサーバPHPMySQL を立ち上げるだけっちゃぁだけなのだが……。すべて滞りなく行ったと思ったら、なぜか Web で PHP が呼び出せない。ちなみに OS は CentOS 8 だ。いろいろ調べを進めていくと、Apache(ウェブ サーバ)上で PHP を動かすには三つの方法があるらしい。

  • prefork
  • worker
  • event

このうちボクが知っているのは prefork だ。だから prefork な設定をしてしまった。ところが CentOS 8 は event らしい。ということが解ったので、ごにょごにょして Apache の Config ファイルを書き換えて event にした。もー。

ところで今回もトリッキーなことをしている。実は会社から開発環境用を作るように言われたのだが、無料でっていう指示をされたので、いろんな Cloud のお試しを使おうとしたんだが、AWS, Google Cloud ともに無料期間をすでに食い潰してしまっていた(笑)。
で、最近ちょっとかじった Oracle Cloud を試そうとしたら、これがなぜか仮想マシンが作れないというか、なんかバグなのか OS のイメージが選択できなくて何をやってもダメだったので、結局、amatsukami.jp 上に仮想マシンを立ち上げた。
しかしながら amatsukami.jp には IP アドレスが一つしか無い。

そこでリバース プロキシの出番だ。開発用に飛んで来たアクセスを amatsukami.jp サーバが仮想マシンに飛ばしてやるのだ。まぁこちらはちょっと一悶着あったので、別記事にしたいと思う。

しかし日本のゲーム業界だとサーバはもっぱら Linux だ。Windows サーバに今の所出会ったことはない。社内インフラは Windows なんだけどねぇ……。ボクは Windows Server の人なので、Linux はほんと設定するのに時間がかかる……。

iPhone の動画とか西武池袋線とか萌え時計とか

iPhone で撮影した動画を Premiere で読み込ませると、映像と音声が同期しないという記事は以前にも書いた。原因はわからないまま、現在も動画を編集するときは 60 分 あたり 2 秒ほど音声を短くするという対処方法をとっている。
でもこれをやるのはけっこうめんどくさかった。

上のツイートでは Premiere が直してくれたようにつぶやいているが、実はこれ、iPhone 7 だと問題なく、iPhone 6 ではやっぱり音と映像がずれていた。というのも Premiere 2017 でも iPhone 6 で撮ったデータは相変わらずズレているからだ。
どうやら Premiere が悪いのではなく、iPhone 側のデータに問題があるようだ。

そしてこれは iPhone 7 で解決したわけでもなかった。
2 ヶ月後の話になるが、iPhone 7 でも 60fps のデータは音ズレが発生することが判明。やはり iPhone 側に問題があるようだ。だが、ネットで検索してもこの現象に悩んでる人がいないみたいなんだよねぇ? iPhone はプロが映像作品を作る時にも使われているらしいのでこの問題にぶち当たってる人はいそうなんだけどなぁ。

もちろん気付かれていない(問題視されてない)可能性もある。そもそも音は別マイクで録っているだろうし、ズレも 60 分に 2 秒程度だ。プロの映像作品だと細切れにして撮っていることが多い。5 分や 10 分程度ではズレに気付かない(問題ない)かもしれない。

電車は 5 分くらい遅れたのでは運行情報には出ないようだ。
遅刻したけどな!

萌え時計を自分のサーバに設置せずに使う場合、amatsukami.info サーバを使うことになるのだが、コイツは HTTP で通信しているため、HTTPS なサイトに萌え時計を貼ると表示されなくなる。
う~む、最近は何でもないサイトでも HTTPS を使う傾向にあるし、そもそも Google 検索の検索結果は HTTPS を優先させる措置を執ったため、どうでもいいサイトでもどんどん HTTPS 化している。
ウチも HTTPS にすればいいじゃんと言われるとそれまでなんだけど、IIS 7.5 ではバーチャルホストのどれか一つしか HTTPS のサイトが作れないという欠点があるのだ。現在、ウチのサーバは開発者用のサイトがあるのだが、そいつが HTTPS を使っているため、他のサイトは HTTPS 化できないのである。
IIS 8.0 以降では出来ることは確認しているので、サーバを刷新してからかなぁと思っている。

疑心暗鬼な人々

NSAHTTPS を解読できるという話は、確かスノーデン氏のリーク情報が最初だったと思う。その後、NSA 長官も同じような発言があったと思うのだが、ざっと検索した限りでは明言しているところは見つけられなかった(関連記事)。

さて、何のことやらと思ってる人も多いと思うので、まずはちゃんとした説明からしておこう。
皆さんが IEGoogle Chrome などのウェブ ブラウザを使ってウェブサイトを見るとき(いわゆる、インターネットをするとき)、サーバとブラウザは HTTP という取り決めに従って見たいデータをやりとり(通信)している。
インターネットというのは色んなサーバがつながって成り立っていて、例えば、今見ている TAMA Networks のサーバから様々なサーバを経由して、あなたのパソコン(スマフォかもしれないが)に送られている。
なので、その経由しているサーバの管理者は、その内容を見ることができる。
これはウェブサイトに限らず、メールでも同じだ。

そこで、HTTPS という取り決めがある。コイツは TAMA Networks 上で暗号化しておき、あなたのパソコンにむかって情報を流す。そして受け取ったあなたのパソコンがその暗号を復号して、画面に表示する。
こうすることによって、経由しているサーバにデータは流れるものの、なんのデータかは解らなくなるわけだ。
この暗号は素数と素因数分解を用いるもので、途方もない計算量が必要なため、現在のコンピュータでは簡単に解読にできない(何百年もかかる)というのが「担保」になっている。

ところがスノーデンや NSA 曰く、すでに HTTPS については問題になってないらしい。
本当なのか!?

ボクが予想したのは、アメリカの認証局(その暗号と暗号の発信元が同一で有り、誰がその暗号を発行したのかを証明する機関)とすでに密約が交わされており、そこから秘密鍵を得て、HTTPS の通信を全て復号できるのではないかというものだ。
ただそれにしても、認証局は証明書を発行するだけで有り、秘密鍵まで知るわけではないはずだ。

ということは、NSA は暗号を解くことができるのだろうか?

実はもう一つ、暗号を回避する方法がある。それは中継されるサーバの間に簡単に言うとブラウザをかますのだ。例えばボクが Amazon で買い物をしたとする。ボクは Amazon に接続しようとするわけだが、ボクのパソコンと Amazon のサーバの間に、Amazon の証明書をもつ中継サーバを用意し、そのサーバがブラウザとなって Amazon と通信するのである。
Amazon は中継しているサーバに対して暗号化したデータを渡し、中継サーバはそのデータを盗んだ後、再度暗号化してボクの PC にデータを送るのである。
ただこの中継サーバは、本物の Amazon の証明書を持っている必要があるが、これならば秘密鍵が解らなくても、たぶんデータはぬけるんじゃないかと思う。つまり認証局と NSA が仲良くさえなれば可能ではないかと……( 間違ってたら突っ込みよろしく(汗

で、何をボクは心配しているのかというと、情報技術が進んだことによって、なんか世の中が凄い殺伐になって来ているというか、いや、もともと殺伐だったのが、よく見えるようになって来たというか……。
お花畑な思考なのかもしれないけど、科学が発達すれば、いつか労働はいらなくなり、人々は自由に時間を使い、好きなことができるようになるんじゃないかっていうことを幼少の頃からボクは考えていた。そして一部はそうなりつつある。

が、それよりも、為政者は古来からの夢を実現する方に科学技術を使う。
国民一人一人が何を考えているのか? 裏切るヤツはいるのか? 命を狙ってるヤツはいるのか? 他の国は何をしているのか?
これらが科学の力によってできるようになって来て、それをそのまま実行に移しているのだ。
国は疑心暗鬼に満ち、常にあらゆるものを監視し、あらゆるものを疑っている。そのメンタリティは紀元前から何も変わってない。

せっかくインターネットで国境そのものが少しだが意味のないものになりつつあるのに、非常に悲しいなぁと思ったのである。

とは言え、無防備では当然いられない。国益、国防、国民の財産・命……国が守っていかなければならないものはたくさんある。
これからますます人を監視することは容易くなってくる。何億、何十億という人間がいても、それらを網羅し、さらに個人を知ることもできる。もちろんその中には為政者も含まれてはいるんだろうけど……はてさて、どんな世界になっていくのやら。

アリスソフトさんのアレ

2 月に起きたアリスソフトさんの件について、色々とこちらのサーバの構成を変えるべきかも知れないと思ったので日記に記す。例の事件の時もボクは大忙しで、この事件の詳細については調べる時間がなかった。ただおおむねざっと情報を横断したところ、納品先に渡すためのダウンロード・ディレクトリが洩れてしまったというのが原因の様だった。
これはどういうことかというと、ファイルをやりとりする際、こちらから一方的に送るだけの場合、利便性も考えてブラウザで落とせるようにするのが一番よい。そのため、ウェブサイトのどこかにそのデータを置き、そのデータのアドレスを相手に知らせて、ダウンロードしてくださいね、とやるのである。
この方法は実に便利で、この amatsukami.jp サーバにもある(爆)。こう言うことを書くのは非常によろしくないのだが、とは言え、まったく書かないと話が通じないので、バラしてしまった。とにかくあるのだ。主な用途は成果物の納品や、雑誌社さんに渡す素材などだ。しかも利便性を優先して、パスワードはかけていない。
そしてこの仕組みはもう 10 年以上、使ってきている。
バレないという保証はないが、いくつかのステップは必要である。

  1. ダウンロード・アドレスの特定
    どの URI からダウンロード出来るのか、知る必要がある。基本的に外部からは推測して当てるしかないが、おおむね想像がつくことも多い。たとえば、DL や Download っていう単語が入っていたり、アップローダ的な使い方をしていれば、Upload や UL、UP など。他にも Send とか To とか From とか、その手の単語は推測されやすいかも知れない。
  2. ファイル名の特定
    ダウンロード・アドレスが解っても、ファイル名が解らなければダウンロード出来ない。というのも、ダウンロード・アドレスを指定しただけでは、404 エラーなどでハネられてしまうからだ。但しここで注意が必要なのが、ファイル名ではなく、ディレクトリが指定されると、そのディレクトリにあるファイルを返してしまうという設定がある。これが ON になっていると、目も当てられない。ダウンロード・アドレスに置いてあるすべてのファイルが見えてしまうからだ。

というわけで、上の二つの名前が分からなければダウンロードはできない。そして基本的にこのダウンロード・アドレス+ファイル名の URI を知っているのは、ボクが「ここからダウンロードしてくださいね~」って教えた相手だけのはずなのだ。だからその人が漏らさない限り解らないし、Google などの検索エンジンに乗ることもない。

今回のアリスさんの場合、なんと Google で検索すると出てしまうらしい。
ここがボクはよく解ってないのだが、当事者同士のやりとりなだけのはずなのに、なんで Goolge に載ったんだろうってことだ。もう検証サイトとかできてるのかな。もし情報を持っている人がいたら教えて欲しいです。考えられることとしては、忘れないようにか、何かの理由で、URI をどこかに貼り付けておいたのが、Google に収拾されてしまったか、たまたま URI の推測に成功した人が、どこかの掲示板か何かに載せたか……でもそんなことってあるのかなぁ??

というわけでこのようなことが起きたため、ボクもダウンロードについてはどうしようか今も考え中である。まずは、一定期間経つと、そのダウンロード・アドレスに置いたファイルは削除する様にした。もともとダウンロード用のデータというのは自分の手元にマスターがあり、それを ZIP なり CAB なりで圧縮して渡しているので、ダウンロード・アドレスにあるファイルはなくなってもかまわないものだ。なので、ファイルの更新日付をチェックし、一定期間が過ぎたファイルについては自動的に削除するスクリプトを組んだ。
さらに今後対策していこうと思っているのは、以下の通りである。

  1. ダウンロード・アドレスをランダムに生成する
    ファイルを用意するたびに、ダウンロード・アドレスはランダムに生成する様にする。もしくは、相手先それぞれにダウンロード・アドレスを用意する。この際、ワイルドカード サブドメインも利用すると、より複雑になると思われる。
  2. ファイル名もランダム生成する
    ファイル名もランダム生成し、推測できないようにする。
  3. IP 制限をする
    提出する相手はだいたい会社が多いので、固定 IP を引いているところがほとんどだ。なのでそれ以外からはアクセス出来ない様に IP で制限してしまう。

1 と 2 についてはちょっとスクリプト(今なら PHP)を書く必要がある。
どちらにせよ、数ヶ月以内には対応しないとダメかなーと思っている。