日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

JavaScriptを有効にし、Cookieを受け入れ、以下のブラウザを使うことで完全なコンテンツが楽しめます。
Mozilla Firefox 3.0(Get Firefox)・Opera 9.6・Safari 3.2・Lunascape 4/5(Gecko)・Lunascape 5(WebKit)
Internet Explorer 7/8とそれを使うIEコンポーネントブラウザ(Lunascape・Sleipnirなど)

<< 過去

なぜ常時SSL化をするか

最近、常時SSL化という流れがあるらしい。

BASEが独自ドメインも常時SSL化、グーグルの「SSL推し」に対応 (ITpro)

確かに、いろんなWebサイトでHTTPS使ってるよなぁ。


これまでも、パスワードや個人情報をやりとりするWebサイトではHTTPSを使うことは一般的だった。

HTTPSはHTTPの通信内容をSSLで暗号化してやりとりするもの。

この仕組みによれば、他に知られると困るような情報を安全にやりとりすることができる。

自分のサーバーでも、パスワードをやりとりするところ、プライベートなコンテンツはHTTPSを使っている。

クライアント証明書で通す

これはHTTPSのちょっと変わった使い方だけど、必要なところでピンポイントで使うという発想に違いはない。


それに対して常時SSL化というのは、必ずしも秘密にする必要が無い内容でも暗号化すると。

一般的に知られてるような内容をわざわざ暗号化するのは無意味と思うかも知れないが、

SSLには盗聴を防ぐ以外の目的もあって、そこに期待しているという話である。


盗聴を防ぐ以外のSSLの役割、それは改ざん防止という役割である。

SSLではサーバー証明書で相手が信頼できるか確認してから、End to Endで暗号化通信を行う。

以前、TwitterがEV証明書を使ってるって話を取り上げたことがあるけど(cf. そこでEV証明書がくるとは)、

TwitterにHTTPSでアクセスすると、ブラウザ上に「Twitter, Inc (US)」と表示され、相手が確かにTwitterであることを確認出来る。

そして、その内容はTwitterのサーバーを出てから、改ざんも盗聴もされていないことが保証されているわけである。

TwitterのWebサイトの内容が改ざんされていないということに価値を感じるかと言われると、それは微妙だが、

これがもし銀行のWebサイトだったり、行政機関のWebサイトだったら、改ざんされていないというのは重要な気がする。


常時SSL化の難点としては、通信のオーバーヘッドが増えることがある。

その一方でHTTPS限定の高速化技術もあるので、レスポンスが悪くなるとも限らないらしいのだが。

常時SSL化しても割が合うという算段は十分なり立つようだが、注意は必要だよと。


End to Endでの暗号化というのはけっこうメリットがあるという話を書いたわけだが、

逆に暗号化されていないからこそできることというのもある。

それがGoogle Chromeのデータセーバー機能である。

これはWebサイトのアクセス時、中間にGoogleのサーバーを介して、データを圧縮することで通信量を削減する仕組みだ。

Googleのサーバーが中間に入り、データの圧縮(ある種の改ざん)を行うということで、中間者攻撃と同じ仕組みである。

なので、この機能はEnd to Endでの暗号化を行う、HTTPSでのアクセス時は無効化されることになっている。

End to Endでデータの完全性を保証するということは、途中にデータセーバーの入る隙はないということである。


SSLを使わないと、データセーバーの恩恵は受けられるが、データセーバーと同様に中間者攻撃が入る隙がある。

逆に常時SSLを使うことで、盗聴防止・改ざん防止に強い効果があるが、その一方でデータセーバーのような存在は認められない。

常時SSL化の意味を理解するには、これがいい説明なんじゃないかなぁ。

その上でどっちがよいかというのは各自考えるべきということである。

世の中はGoogleの方針もあって、常時SSL化に傾いているようだけど。


Author : hidemaro
Date : 2017/03/24(Fri) 23:27
Linux・Net・Web | Comment | trackback (0)

3Gと4Gと4G+

Androidもバージョンによるんだろうけど、僕が使っている端末では、

携帯電話の電波表示に「4G」とか「4G+」と表示される。

今使っている通信方式が表示されるんだね。


ここで言う「4G」というのはLTEという意味で、FDD-LTEでもTD-LTE(AXGP)でも該当する。

このあたりの用語の使い方はわりといい加減である。

特にNTT docomoは真の4G、LTE-Advancedまで4Gという言葉を使うのを見合わせてきた経緯があるのだけど。

そもそもLTEを4Gと言えるか言えないかは通信速度の差だけなので、全部4Gと呼ぼうというのがSoftBank・auの考えだったのだろう。

Androidの解釈もLTE=4Gという解釈のようだが、通信会社の間で見解に差があるというのが気になるところである。

なお「3G」という表示もあるそうだが、HSPA+を含めた3Gネットワークだけに接続しているときはこの表示になる。

このあたりだとあんまり見ないかもねぇ。FDD-LTEのカバーエリアを見ると山間部の一部で入るぐらいかも。


問題は「4G+」という表示である。

これ調べてみたんだけど、キャリアアグリゲーションが適用されているということを表しているみたいね。

キャリアアグリゲーションは複数の周波数帯でLTE通信をして通信速度を上げる技術である。

実はSoftBankとY!mobileの合併を後押ししたのはキャリアアグリゲーション技術という話があって、

同じ会社になってれば、2.1GHz帯・900MHz帯(旧SoftBank)と1.7GHz帯(旧EMOBILE)のFDD-LTEを組み合わせることができると。(cf. “ついに来た”ソフトバンク合併でワイモバイルの運命は?(石川温氏寄稿) (週アスPLUS))

一方でAXGPも2.5GHz帯の中で2つの電波を束ねるという形でキャリアアグリケーションをやっていて、確かこっちの方が先行してたはず。

AXGPとFDD-LTEの組み合わせはやらないらしい。(AXGP網を提供するWireless City Planning社は別会社だから)

FDD-LTEの組み合わせで4G+になってるのか、AXGPの組み合わせで4G+になってるのかはわからないが、

1波だけ使う場合よりも速いスピードで通信できるって話らしい。


本当に速いんですかね?

理論上の最高速度は足し算だから速くなるんだけど、本当にその通りに行くのって?

キャリアアグリケーション対応・非対応の比較をした事例も見あたらないし、さっぱりわからんよね。

あと、同じ場所でも「4G」であるか「4G+」であるかはその時々で変わっちゃう。

複数の電波を使う都合、不安定になってるというのもあるのかもしれないし、利用状況に応じて使い分けさせたりしてるのかもしれない。

どちらにしてもBB.exciteモバイルLTEの頃よりは速くなってるしいいやって。

あれは端末の問題でLTEにありつけないことすら多かったから。本当のNTT docomo向け端末はそんなことないと思うけど。


「3G」と「4G」と「4G+」の表示があるAndroidだが、これまで使ってた電話も「3G」という表示があった。

「3G」以外の表示があるのかって? 海外ローミング向けにGSM(2G方式の一種)に対応してたから、そのときは「G」と表示されてたらしい。

日本以外では3G(W-CDMAまたはCDMA2000)と2G(GSM)併用の端末が多かったから、こういうのが重要だったんだよな。

VoLTEの時代がやってきたら、3Gと4Gの識別もしなくなるのかもなぁと、

2Gサービスを終えてしまった日本で表示されない「G」マークを思い出したのだった。


Author : hidemaro
Date : 2017/01/11(Wed) 23:20
Linux・Net・Web | Comment | trackback (0)

世界標準の絵文字たち

「PCでも絵文字打ったり表示したりできるんだね」って言ってる人がいたけど、

確かに最近はPCでも絵文字見るよねぇ。

Thunderbirdでメールを見てると時々絵文字が入ってたりするしね。文字化けしないし、ちゃんと表示される。


ご存じの方もおられるかと思うが、日本の携帯電話の絵文字はUnicodeに収録されている。

Unicode6.0の携帯電話の絵文字の一覧 (Wikipedia)

例えば自転車の絵文字は U+1F6B2 に登録されていて、それをUTF-8でエンコードすれば「🚲」と表示できる。

フォントが対応してるか知らんけど、たいていの環境ではなんかそれっぽいのが表示されるでしょう。


なぜ、Unicodeに絵文字が収録されたのか。理由はiPhoneとAndroidのスマートフォンが日本市場に乗り込むために必要だったからである。

日本では以前より携帯電話のメールで絵文字が使われていた。

当初は通信会社ごとに独自の絵文字体系を持っていたが、メールのシステムも閉じていたから問題は無かった。

後にPCや他の通信会社とメールのやりとりができるようになったが、互換性がないから「〓」に変換するなどの対応を取っていた。

2005年以降、通信会社間で絵文字の置き換えを行う仕組みができたので、携帯電話間では一定の互換性が得られるようになった。

ボーダフォン、3G端末から他社宛に絵文字入りメールを送信可能に (ケータイWatch)

ただし、PCは相変わらず絵文字対応ではないですから、「〓」への変換が続いていた。


スマートフォン時代となり、通信会社ごとに異なる絵文字体系をどうやって吸収するかということが問題となったのだろう。

その答えがUnicodeへの絵文字の収録で、AppleとGoogleの提案により絵文字がUnicodeに登録されたのだという。

iPhone3Gのときは、絵文字を使う通信会社はSoftBankしか想定されないので、SoftBankの絵文字だけに対応したのだそうだが、

iPhone4からはUnicodeの絵文字体系で処理するようになったとのこと。

各社独自の絵文字体系とUnicodeの絵文字体系が並立するという状況は続いているものの、

その一方でUnicodeに登録されたことで、Gmailを筆頭に携帯電話以外でも絵文字を使うことができるようになったし、

あと日本以外でも日本発祥の絵文字を活用するという動きが生まれた。日本向けに対応したが日本以外でも使えるようになっちゃったと。


そして気づいてみればPCでも絵文字が使われることがちょっとずつ増えていると。

Twitterではけっこう絵文字使ってる人を見るんだけど、Web上の画面では絵文字を選択して入力できるようになってるのよね。

Unicodeで選んで打ち込んでもよくて、ATOKパレットで探して打ち込めば、それでちゃんと表示される。

独自の絵文字体系ではなく、Unicode準拠であることの表れである。


このBlogの文字エンコーディングはUTF-8だから、上に書いたように絵文字を織り交ぜることは技術的には問題ないのだが、

PC用のATOKでは絵文字が打ち込みにくいですから。(Android用のATOKは簡単に打ち込める)

一方でこのBlogシステムは独自の絵文字システムがあって、Web上ではその絵文字は選んで打ち込めるのよね。使ったことないけど。

今だとUnicode準拠の絵文字を選んで入力できるUIにするんだろうなぁ。

僕は絵文字を使う習慣はずっとないんだけど、世の人々が使っているのを見るとアクセントにはいいのかもしれない。


Author : hidemaro
Date : 2017/01/09(Mon) 21:59
Linux・Net・Web | Comment | trackback (0)

いろんな周波数帯を持っていた

昨日、SoftBankとEMOBILEが合併直前から互いのネットワークに依存し、

合併してから3G網の集約を行っているということを少し書いた。

Y!mobileに帰ってきた

調べてみると、現在のソフトバンクはいろんな会社が獲得した周波数帯を使っていることがわかった。


現在のソフトバンクが使う周波数帯で一番古くから使ってるのが1.5GHz帯、

これは1991年からデジタルホン・デジタルツーカーがPDCサービス(2G)のために割り当てを受けたものである。

デジタルホンは後にJ-Phoneとなった会社である。

もう大昔のことだから忘れている方も多いだろうけど、かつてツーカーはJ-Phoneのネットワークにローミングを行っていた。

その都合、スカイメールは同一のシステムで、父の携帯電話がJ-Phone、母の携帯電話がツーカーだったときも相互にスカイメールが使えた。

デジタルツーカーというのはJ-Phoneとツーカーの合弁会社のような位置づけだったが、後に完全にJ-Phoneになっている。

その後、J-PhoneはイギリスのVodafoneに買収され、Vodafoneブランドに改め、国際標準の3G方式、W-CDMAによる3Gサービスを始めた。

2.1GHz帯はこのときに割り当てを受けたものだった。(なお、NTT DoCoMoのW-CDMAサービス、FOMAも2.1GHz帯である)

2.1GHz帯での3Gネットワーク充実には時間がかかったが、僕がVodafoneと契約した2006年頃には2Gサービスを上回るカバレッジとなった。

2010年の2Gサービス廃止後は、この跡地を3Gに転用して2011年にDC-HSDPAによるULTRA SPEEDを始めた。


2012年に2.5GHz帯でWireless City Planning社がAXGPサービスを開始したので、これをSoftBank 4GとしてAndroid端末で展開し始めた。

AXGPはかつてWILLCOMが開発してきたXGPが元になっている。Wireless City Planning社はWILLCOMからXGP事業を譲り受けてスタートした。

国際標準ということになっていたTD-LTEに準拠した方式なのだが、当時TD-LTEはほとんど普及しておらず、

これほど大規模なTD-LTEネットワークを構築したのはこれが初めてだったらしい。

一方で2012年、2.1GHz帯の一部でiPhone5用にFDD-LTEサービス、SoftBank 4G LTEのサービスを開始した。

FDD-LTEってNTT DoCoMoが2010年にサービス開始していたXiと同じ方式で、すでに世界的に普及していた。

iPhone5はTD-LTEには対応していなかったので、iPhone用にわざわざ3Gを削ってまでFDD-LTEサービスを開始させるという荒技に出たわけだ。

さらに2012年には、900MHz帯の割り当てを受けて、プラチナバンドと銘打って3Gサービスの充実を進めた。

NTT DoCoMoとauはアナログ時代から800MHz帯を持っており、3GではauはCDMA2000方式導入時から、NTT DoCoMoはPDC廃止後から使っていた。

SoftBankは過去の経緯からこの帯域を持っていなかったのだが、これは不利だと言ってなんとか900MHz帯の割り当てを受けた。

この結果、郊外を中心にカバレッジが上がったので、これをきっかけに僕も携帯電話を買い換えている。(cf. PANTONE 4が欲しいと言いますが)


ここまではJ-Phone→Vodafone→SoftBankが獲得した周波数帯を取り上げてきた。(AXGPは別会社ではあるが)

次にEMOBILEだが、こちらは2007年の参入時に1.7GHz帯の割り当てを受けて、3Gの高速データ通信方式HSDPAを導入してスタートした。

1.7GHz帯は当時の新規参入事業者向けの周波数帯で、実はソフトバンク’傘下のBBモバイルも一時は割り当てを受けていた。

ただ、ソフトバンクはVodafoneの買収で携帯電話参入することにしたので、結局はこれを返上している。

この返上したものは結果的にEMOBILEに割りあてられ、2010年から3Gの高速データ通信方式DC-HSDPAに使われ、

さらに2012年からのFDD-LTEサービスにも使われた。

このEMOBILEのFDD-LTEサービスに目を付けたのがSoftBankで、2012年にiPhone用LTE網としての活用のために提携を強化した。

当時のSoftBankではiPhoneで使えるLTEは2.1GHz帯のFDD-LTEしかなかったので、iPhoneユーザーが増えると対応できないぞとなった。

ここでiPhone5のハードウェアそのままで対応できる、1.7GHz帯FDD-LTEサービスを提供しているEMOBILEに頼ったわけだ。

今にして見ればLTE黎明期ゆえの奇策だったような気もするが、EMOBILEとしても悪い話ではなかったのは確かか。


ここからは3GからLTEの転換という形で話が進んでいく。

900MHz帯によるFDD-LTEサービス、プラチナバンドLTEを2014年にスタートさせ、FDD-LTEのカバレッジが上がった。

同時期、TD-LTEに対応したiPhone6が出て、これまでFDD-LTEを使ってこなかったAndroid端末でもFDD-LTEを使うようになった。

こうしてiPhone・Androidいずれも始まった、AXGP(TD-LTE)とFDD-LTEの両対応のサービスをHybrid 4G LTEとして宣伝している。

確かプラチナバンドLTE開始前でもFDD-LTEの方がエリアが広かったはずなので、Androidユーザーにとってはメリット大だったはず。

iPhoneもAXGPを使うようになるから、それでFDD-LTEにも余裕が出るでしょうという判断があったんだと思う。

次に1.5GHz帯・1.7GHz帯の3GサービスをFDD-LTEに転換する計画を立てている。

旧SoftBankにとっては1.5GHz帯は3Gの高速データ通信用のものだから、LTE時代となってはもはや過去のもの。

旧EMOBILEにとっては1.7GHz帯は唯一の3Gサービスだったから廃止になるとLTE以前の端末は使えなくなっちゃうのでそれなりに影響はある。

とはいえ、ほとんどデータ通信端末ですからね。LTEに移行するメリットも大きいので、そんなに移行には困らないだろうと。

これが完了すると、3Gは2.1GHz帯と900MHz帯に集約される。歴史の長い2.1GHz帯とプラチナバンドの900MHz帯さえ残しとけばいいよね。


今後は、かつてY!mobileが獲得していた700MHzでのFDD-LTEサービスの拡大(一部スタートしているが、基地局も対応端末も少ない)、

旧SoftBankが獲得していた3.5GHz帯でのTD-LTEサービスの開始が予定されている。

もはやLTEまみれの状況でさらにLTEが増えるということで、なんのこっちゃという話だが。

iPhone用のLTEがないからとEMOBILEに頼ったときとはかなり状況が変わってしまったなと。(合併があったからこそできたことも多いが)

本当に初期はAXGPが唯一のLTE網だったのに、気づけばFDD-LTEもかなり増えたな。


ところでなんでSoftBankは当初、LTE方式としてAXGP(TD-LTE)を採用したんでしょうね?

そもそもTD-LTEというのは上り・下りを時分割で使い分ける方式である。

上り・下りを周波数帯で使い分ける方式がFDD-LTEで、こっちが先行していた。

TD-LTEの方が周波数の利用効率がよいということで、そこがメリットになると考えていたのかな。

一方でAXGPはWILLCOMの開発していたXGPの技術が使われていて、そこで重要だったのがマイクロセル化である。

サービス紹介 (Wireless City Planning)

32kbpsのPHSがスタート地点に書かれているが、下の方にクラウド基地局という話が書かれている。これが特徴だと。

そういう性格から、混雑している地域での通信改善に有利で、SoftBankが宣伝する通信品質を作る上で重要な役割を担っているとのこと。

ただし、現在はAXGPもFDD-LTEも自動的に切り替えて使うから、AXGPを感じるのはPocket WiFiぐらいでしょうかね。(AXGPは通信量規制が緩和されることがある)


Author : hidemaro
Date : 2017/01/07(Sat) 14:31
Linux・Net・Web | Comment | trackback (0)

うるう秒で1秒ズレてる!

みなさま明けましておめでとうございます。

正月の朝起きて、雑煮を作って、あらかじめ作っておいた料理を出して、とやるのはいいけど、餅を買いすぎたことに気づく。

雑煮にぜんざいと食べた程度ではまだまだたくさん残ってる。3日を過ぎてもしばらく正月は続きそうだ。


今日の9時を迎える前にうるう秒が挿入されたということで、この地域では少し話題になった。

というのも日本標準時を作っている情報通信研究機構(NICT)が小金井市にあるから。

以前、武蔵小金井駅で降りたときに標準時を作っていることをアピールする時計が置かれていたから、そうかと気づいたんだけど。

NICT本部や小金井駅でうるう秒の挿入を見守る人たちがいたそうである。

なお、NICTの最寄り駅は小金井駅のお隣、国分寺駅である。

小金井市・小平市・国分寺市の市境が交錯しているところにあるのでこうなる。


うるう秒のことはこのBlogでも8年前の正月に取り上げているな。

お正月だというので時計を見てみた

地球の自転が厳密に24時間ではないので、それを調整するために1秒挿入するのがうるう秒だと。

ゆえに今日は1秒だけ長い1日ということになる。


あまりうるう秒挿入の実感がないかもしれないが、PCの時計を調べてみると気づくかも。

JST Clock

厳密な時間合わせができるわけではないが、1秒ぐらいの精度は十分出そう。

確かに昨日見たときには0.1秒進んでいるとの表示だったが、今見ると1.2秒進んでいるとなる。

1秒進んでいるというのは、標準時は8時59分60秒を数えているけど、PCの時計はこれを数える9時00分00秒になったという意味。

電波時計の腕時計の秒針を見てみると、これもちょうど1秒ズレている。

一方で、電波時計の置き時計、これは普段は窓から離れたところに置いてるから、標準電波を拾うことはないのだけど

今、窓際において手動で合わせに行ったら、PCの時計や腕時計より1秒遅い時間にセットされた。

こちらはうるう秒反映後の標準時を拾ったから、こちらは正確にセットされたわけである。


普通の時計はうるう秒に対応していないので、このようなズレが発生する。

とはいえ、普通の時計はそんなに精度が出ないから、定期的に時刻合わせをするので、そこで吸収すれば実用上の問題はないと考えられる。

腕時計は今晩、電波を拾えれば時刻合わせができるし、PCも1週間以内にNICTのNTPサーバーに時刻合わせに行くから大丈夫と。

でも世の中にはうるう秒に対応したシステムってのもある。

例えばLinuxのntpd、NTPサーバーからうるう秒情報を取得して、それに応じて時刻を調整している。

logを見てみるとこんなのが残ってた。

Jan  1 08:59:59 gmo kernel: Clock: inserting leap second 23:59:60 UTC
Jan  1 09:00:00 gmo ntpd[1482]: 0.0.0.0 061b 0b leap_event
Jan  1 09:06:54 gmo ntpd[1482]: kernel reports leap second has occurred

8時59分59秒にleap second挿入ということで、59秒を2回数え、9時00分00秒を迎えていると。

あら、あまり考えてなかったけど、この方式だったのか。

一応、うるう秒には対応しているが、8時59分60秒の存在は認められないので、59秒を2回数えるという方法で対応している。


よく使われるのは1秒の長さを伸ばして少しずつ吸収する方式だと聞いてたのだが、

標準設定ではドカンと1秒戻して対応するという方式になってたんだな。

時計合わせにおいて、ドカンと指定した時間に合わせる方式をstepモード、少しずつ調整する方式はslewモードと言うそう。

slewモードであれば時間が飛んだり重複したりしないので、他への影響は小さく抑えられるが、少しずつ合わせるから時間がかかる。

というわけで、調整する時間の長短で使い分けているのだが、この閾値は標準では128msなので、うるう秒ではこれを超えてしまうわけである。

だからstepモードで調整されちゃったわけだけど、うるう秒ぐらいはslewモードで対処してよというのが一般的な考え方。

というわけでこれはntpdの起動オプションまたはntpd.confで設定すればよい。

ntpd.confで設定する場合だと、例えばこう。

tinker step 1200

これで1200msまでの時刻合わせはslewモードで、それ以上はstepモードでって意味になる。

0にしておくと必ずslewモードで合わせるという意味になる。

なお、slewモードは1秒あたり0.5ms延長・短縮することで調整する方式で、1秒のズレを吸収するには33分かかる。

このケースにおいては9時00分00秒に1秒進んだと認識して、そこから33分間かけて1秒のズレを吸収すると。こっちの方がいいよね。


まさかうるう秒にこんなことが起きてたとは気づかず。とはいえ、特に問題はなかったけど。

1月のうるう秒は正月休み中だからトラブルが起きないように回避できるかどうかが全てを決めることになる。

まぁ1回設定してしまえばなんとでもなるんですけどね。

うるう秒がゆえに平穏な元日が訪れなかった技術者も世の中にはいるのだろう。残念な事だ。


Author : hidemaro
Date : 2017/01/01(Sun) 18:28
Linux・Net・Web | Comment | trackback (0)

Googleが言う安全性の高い方法

ちょっと前にThunderbirdからGmailにログインできなくなるという問題が発生した。

理由はGoogleに言われるがままに「安全性の低いアプリの許可」を無効化したからだった。

けっこうGoogleの要求は厳しいのだ。


Googleはなにをもって安全性を低いと判断しているのかというと、

共通のユーザー名・パスワードを使って認証する方式か否かというところだそうだ。

これまでThunderbirdでGmailにログインするときは、IMAPSでユーザー名・パスワードそのものを暗号化した上で送っていた。

暗号化しているので経路中で盗まれる可能性は低いが、その一方でThunderbirdにはユーザー名とパスワードそのものを記録している。

なのでここからユーザー名・パスワードが漏れるという心配がある。

さらにこのユーザー名・パスワードでGoogleカレンダーもGoogle PlayもYouTubeにもアクセス出来てしまう。

これがGoogleが安全性を低いと考える理由である。


この点について、Googleはいくつかの選択肢を用意しているが、

もっとも推奨されているのはOAuth 2.0で認証するという方法である。

ThunderbirdはOAuthでの認証に対応しているので、この方法で対応することにした。

アカウント設定で認証方式を「通常のパスワード認証」から「OAuth2」に切り替えると、

初回アクセス時にGoogleの認証画面がポップアップで出てきて、ここにユーザー名・パスワードを打ち込んで、

Thunderbirdに与える権限(Gmail)を確認した上で、承認とすれば、あとは普通に使える。


OAuthはWebアプリケーション間の認証手段として作られた仕組みで、Twitterとかでもおなじみの方式である。

OAuthで使うTwitter API

Twitterとそれを利用するアプリを例に取ると、このような流れで認証が行われる。

  1. アプリからTwitterにリクエストトークンを要求する
  2. アプリはユーザーをTwitterの認証画面に飛ばす(このときリクエストトークンを添える)
  3. 認証が完了するとアプリにアクセストークンが返される
  4. アプリはリクエストトークン・アクセストークンの組み合わせでTwitter APIを叩く

この仕組みではユーザーはユーザー名・パスワードをTwitterの認証画面に直接入力し、アプリ自体には入力しない。

アプリはリクエストトークン・アクセストークンを保持するが、これはこのアプリ限りのものであり、権限は限定される。

もし問題があると考えれば、ユーザーはアプリごとに許可を取り消すことができるようになっている。

OAuth 2.0ではメールプロトコルに取り込むことができるようになった。

これを受けて、GoogleはIMAPでのアクセス時にもOAuth認証を使って欲しいと言っているのだ。


ただし、当初の目的を達成する方法は他にも考えられる。

アプリごとに違うパスワードを使っておけばよいのだ。というわけでアプリパスワードという方式を用意している。

利用できる条件は2段階認証プロセスを有効にしてあること。

2段階認証プロセスはパスワードを使った認証をするたびにSMS等でワンタイムパスワードを使って認証も要求する方式である。

2段階認証プロセスの対象になるのはOAuthの認証を含めたWeb上での認証に限られるので、OAuth非対応のメーラーでは使えない。

その補完としてアプリパスワードという仕組みを用意しているという理屈らしい。

このパスワードは後から取り消せることと、パスワード変更など重要な認証には使えないという特徴がある。

これで安全性が保たれるという理屈だ。


そもそもOAuthが生まれたのは、ユーザーに代わってAPIを叩くWebアプリにパスワードを預けるのは危険だという考えがあったように思う。

だから自分のPCにあるメーラーからパスワードが漏れることを恐れるというのは新しい考え方に思える。

ただ、確かにその危険って昔からあったんだよね。

その答えは全知全能のパスワードを持たせないということなんだろう。

OAuthは権限を限定したアプリ専用のアクセストークンを与えるという方法で解決しており、

アプリパスワードは目的別のパスワードで、後から無効化できて、なおかつパスワード変更など重要な認証には使えないという制約がある。

2段階認証プロセスは本来のパスワードが全知全能にならないようにするための手段で、本当のパスワード+ワンタイムパスワードを要求すると。


Gmailのパスワードを起点に芋づる式にパスワードが漏れるような例も世の中にはあるそうだ。

それだけにGoogleも対策を取らざるを得なかったのだろう。(とはいえ既存ユーザーはあえて変更しない限り変わらないのだが)

とりあえず、OAuthはお手軽なので使える環境の人はぜひどうぞ。


Author : hidemaro
Date : 2016/12/21(Wed) 21:45
Linux・Net・Web | Comment | trackback (0)

クライアント証明書で通す

らじる★らじる を録音する仕組みを作って自分だけで使うのはともかく、

秘密のURLってだけで、これといったアクセス制御はしてなかったことを思い出した。

パスワード認証という方法もあるが、いちいちパスワード打つのもめんどくさいし。

そこでクライアント証明書認証を導入することにした。


クライアント証明書認証はStartSSLのコントロールパネルへのログイン時に使ってるのを見たぐらい。

StartSSLが発行したE-mail証明書を、StartSSLのログインに使うと。そういう仕組みなんだね。

これを自分でやるならこういう形でやればよい。

  1. 認証局を作ってオレオレ証明書を作る (cf. SSLの鍵を打ち出す単純な方法)
  2. Apacheに作成した認証局証明書をSSLCACertificateFileに登録する
  3. アクセス制限したいところに SSLVerifyClient require を設定する

自分で認証局を作るのは本当は必須ではないのだが(既存の認証局の作った証明書を使うこともできそう)、

自分で認証局を作ると、自分の認証局が認めた人は全てOKという簡単なアクセス制御が使える。

これについてはオレオレ証明書でなんの問題もないわけだから、自分で認証局を作っちゃうのが得策でしょう。


認証局の立ち上げ方の詳しいところは、以前の記事に書いてあるが、基本的にこれでOK。

# /etc/pki/tls/misc/CA –newca
# openssl ca –gencrl –out /etc/pki/CA/crl.pem

作った認証局証明書は配る必要はないので、とりあえず置いておけばOK。

めんどくさければopenssl.cnfの設定で有効期間36500日とかにしておけばいいだろう。

ただし、認証局証明書とセットでCRLは作っておいた方がいいかもしれない。後に作った証明書を強制失効させるときに使う。

ここまでできたらクライアント証明書を作るのだが、まぁこんな具合。

$ openssl genrsa -out client.key 2048
$ openssl req -new -key client.key -out newreq.pem
# /etc/pki/tls/misc/CA -sign
$ openssl pkcs12 -export -inkey client.key -in newcert.pem -out client.p12 -name "foobar"

最終的にPKCS12形式にしておけば、FirefoxなりWindowsなりAndroidにインポートできる。


Apacheの設定はこんな具合。

SSLCACertificateFile /etc/pki/CA/cacert.pem
SSLCARevocationFile /etc/pki/CA/crl.pem
<Location /SECRET>
  SSLRequireSSL
  SSLVerifyClient require
</Location>

作った認証局証明書とCRLをセットする。

そしてアクセス制限したいところにSSLVerifyClient requireを設定する。

ただし、これだけだとHTTPSを使わずアクセスすると普通に通ってしまうので、SSLRequireSSLを付けてHTTPS必須にする。

これでHTTPSでアクセスすると、クライアント証明書を選択するダイアログが出てくるので、選んでOKとすると、正しくアクセス出来る。

一方、証明書を持たない人がアクセスしても、403エラーということでアクセス拒否される。


とりあえずこれで証明書を持っているか持っていないかのアクセス制御が実現できた。

さらに踏み込んで、証明書でユーザーの識別と認証を行う方法を考えてみる。

そこでBlogの管理画面のログインにクライアント証明書を使う仕組みを作ってみた。

まずはクライアント証明書の呈示を求めるための設定をApacheで行う。

<Location /d/admin.php>
  SSLRequireSSL
  SSLVerifyClient optional
</Location>

さっきの設定にそっくりだが、SSLVerifyClient optional と証明書の呈示を任意にしていること。

必ず証明書で認証を行うなら require にすればよいのだが、今回はID・パスワードでの認証か選択するようにしたので任意にしている。


ここまでしておけば、環境変数にクライアント証明書の情報が格納されるので、これを使えばよい。

PHPだと認証の成否は $_SERVER["SSL_CLIENT_VERIFY"] に格納され、SUCCESS だと成功を意味する。(認証なしだとNONEになる)

その上で、証明書の情報も格納されているので、例えば $_SERVER["SSL_CLIENT_S_DN_CN"] に格納されたCNでユーザーを識別できる。

証明書のCNというと、サーバー証明書だとドメイン名(ex. hdmr.org)を格納されることに決まっている。

会社内で使うクライアント証明書だとCNに従業員番号を格納したりするのかな? そういう使い方をしてもいいはず。

僕はCNにE-mailアドレスを格納しといたけど。


最後に、もし証明書を失効させなければならなくなったときの作業を書いておく。

/etc/pki/CA/index.txtに過去に作成した証明書のリスト、newcert 以下に発行した証明書が格納されているので、

失効させたい証明書ファイルを選択して失効させて、それからCRLを更新すればよい。

# openssl ca –revoke /etc/pki/CA/newcerts/xxxxxx.pem
# openssl ca –gencrl –out /etc/pki/CA/crl.pem

PC用の証明書とAndroid用の証明書を作り分けて、Android用の証明書を失ったと仮定して失効させてみた。

ここまでして、Apacheにreloadさせたら、これでAndroidからはアクセスできなくなった。

同じCNを持つ証明書でもPC用の証明書は今まで通り使えるので、特定の証明書を狙い撃ちで失効できたことがわかる。


タブレットの画面でパスワードを打ち込んでというのは、以前より煩わしいと思っていたので、その手間が省けるのは楽だ。

PCはまだましだが、それでも打たなくていいのはそれはそれで楽だと。

なおかつ、クライアント証明書認証に一本化した部分はたいへん攻撃に強いはずである。

証明書さえ失わなければけっこう有用なんじゃないのかなぁ。

HTTPS以外でも、Thunderbirdとdovecotの設定を見る限りではIMAPSの認証手段にもクライアント証明書は使えるみたいだ。

ただ、かなり情報が不足しているので、やろうとすると苦労しそうだが。


Author : hidemaro
Date : 2016/12/19(Mon) 23:35
Linux・Net・Web | Comment | trackback (0)

さながら らじる★らじるタイムフリー

民放ラジオではradikoタイムフリーという機能が最近始まっている。

放送区域内の放送局ならば無料で1週間以内の過去の番組をオンデマンドで聴けるという機能だ。

それ無料なんだ、と驚いたんだけど、無料で提供しても割が合うんでしょうね。

といっても民放で聞く番組はリアルタイムか、radiko以外でWebにアップロードされるのを聞くか(もともと放送区域外の場合を含む)だからね。


民放だとあまりメリットは感じないのだが、もしNHKがタイムフリーで聞ければ、それはメリットがありそう。

いろいろ番組があるのは知ってるんだが、聞こうと思うタイミングと合わないことは多いですから。

ニュース聞きたいなぁと思っても、その時間にニュースをやってなきゃ聞けないとかね。

そこで、らじる★らじる でNHK-FMとNHKラジオ第1の番組を録音し続けるシステムをサーバー上に作り込んだ。


もともと似たようなことを超A&G+でやっていた。

録音・録画して楽しむ

1年ちょっと前の話なんだな。あらかじめ指定した番組を録画・録音するシステムを組んでいた。

土曜日深夜の番組を日曜午前に聞くのと、夕方の番組を夜に聞くのに使っている。

使う道具は crond, RTMPDump, ffmpegで、このときに準備してあるからそのまま使える。

ただし、らじる★らじる の録音は番組を指定しなくても、深夜帯の一部を除いて、ひたすら録音し続ける仕組みにした。

radikoタイムフリーのように後からオンデマンドで聞けるようにするというのが目的である。


しかし、24時間ずっと録音し続けたとして、どれぐらいの容量を使うのだろう?

調べたところ、らじる★らじる の音声はAAC 48kbpsで配信されているので、1時間あたり22MB、24時間で518MBとなる。

サーバーの空き容量を考えても、1チャンネルで1GB程度なら問題ないだろうということで、48時間残すことにした。

実際には深夜帯など録音しない時間帯を作ることもできるので、もうちょっと抑えたが、ずっとやってもこんなもんと。


というわけで、こういう仕組みを作ることにした。

crondで毎時0分に呼び出し→RTMPDumpで1時間1分録音→ffmpegでFLVからMP4に変換→FLV削除→48時間前のMP4削除

RTMPDumpを使った らじる★らじる の録音方法については、ここが参考になる。

Linux でらじる★らじるも録音しちゃう (コはコンピューターのコ)

ここではShell Scriptで組んでるけど、僕はRubyで書いた。まぁ順番にコマンドを実行するだけなので、大差ないけど。

お好きな放送局のアドレスを持ってくればいいが、後発の福岡・札幌・広島・松山のアドレスは掲載されてないな。解析が必要か。

ここにRTMPDumpの非公式ビルドがあるが、こっちの方が安定するみたいね。


あとは、Web上で見れるように、録音したファイルのインデックスを付ければOKだが、

MP3だとリンクを踏めばFirefox自身が持つ再生画面に行ったのだが、MP4だと一旦ダウンロードしてとなるのが煩わしいので、

なんとかブラウザ上で再生できんもんかと思ったら、HTML5のvideo属性・audio属性を使えばMP4は再生できるみたい。

<video controls width="500" height="35" src="./19-20.m4a" type="audio/mp4"></video>

こういうHTMLを生成するページを作っておけば、MP4のままでもブラウザ上で簡単に再生できる。

AACのまま格納できるMP4なら、再エンコードを挟まないので劣化がなく、容量を節約できるのでオススメだ。

なお、FLVからMP4への変換は、ffmpegを使うなら、こうやってできる。

ffmpeg –y –i 19-20.flv –vn –acodec copy 19-20.m4a

このように自動的にストリーミングを拾うのは、本来想定されない方法ということで、規約上問題はありそうだが、

自分で拾ってきて自分で聞く分には権利上の問題は無いでしょうと。

将来にわたってこの方法が使える保障は全く無いけれど、それぐらいの問題なのでは?


用途としては、こういうことを考えている。

  • 夕方のニュース、朝のニュースを時差で聞く
  • 好みの音楽番組を選んで聞く
  • ラジオドラマのリアルタイムで聞けない分を補完する

朝以外にテレビを見る習慣がなく、なおかつテレビとPCの画面を共用しているので、夕方にテレビを見る機運も起きにくかった。

ラジオならばPCで作業しながら聞くこともできるので、好都合である。

リアルタイムだけだとニュースをたっぷり聞くのは時間が合うとも限らず難しい面もあるが、録音されていれば調整しやすい。

休日では朝のニュースも時間をずらして聞けるのはメリットがあり、今日さっそく使ったんだけど、

ニュースを聞いて、ついでにラジオ体操もできるのだ。休日の午前に最適である。

NHK-FMの音楽番組やラジオドラマにも使い道があるのでは? と思っているが、

まだなにをやってるかよくわかってない部分もあり、まずは環境を整えていろいろ聞いて探してみるというのがよいかなと。

少なくとも土曜のアニソンアカデミーをリアルタイムで聞けなくても翌日曜日に聞くことができるというメリットはあろうと思う。

土曜の午後とか出かけてることも多いですから。聞けなくて惜しいなと思ってたんだ。


Author : hidemaro
Date : 2016/12/18(Sun) 22:37
Linux・Net・Web | Comment | trackback (0)

怪しいと思ったら本当に怪しかった

6連休明けともなれば、E-mailがたくさん届いてるので、それを確認するところから始まるわけだが、

だいたいは直接関係ないか、予想してた連絡ばかりなので、さほど問題もなしと。


それからあれこれと仕事をしていたわけだけど、

一見、情報システム部門からの連絡に見えるようなE-mailが届いた。

まぁ一瞬で怪しいと気づいたんだけどね。

文面がこの会社っぽくはないし、何より差出人のE-mailアドレスが社外だから。

というわけでゴミ箱にポイと。


この時点では、これはきっと標的型攻撃の訓練メールだろうと思った。

過去にそういう訓練があったし、内容的にはまさにそういう内容だったから。

ただ、どうもそうではなかったようだ。

というのも数分後にさっき届いたのはウイルス入りのE-mailだという通知が届いたからだ。

どうもそういう監視システムがあったらしい。

ちなみにこっちはE-mailアドレスからして社内からと考えて問題ないだろう。


システムで検出したと言うことは、届いたということはあえて報告せずとも認識しているということだろう。

というわけで深追いはしていないが、実際にあるんだなぁとは。

怪しいE-mailを見抜くことが重要で、これは差出人を確認することと、社内の経験則に合うかだな。

情報システム部門はだいたいここのWebページを見ろと連絡してくるから、添付ファイルを見ろというのは多分正しくない。

そういう経験則だけでリスクを全て回避出来るわけではないが、そういう感覚も無視できないとは思う。


今まで数多の迷惑メールを受け取ってきたから、そういう感覚は研ぎ澄まされてると思っているのだが、

一方で、こういう条件が揃うとちょっと難しいかもなぁというのも気づいている。

自分のメールサーバーの対策内容は熟知してるけど、会社のメールサーバーはどうなんだろうかね。

それ次第だよね。


Author : hidemaro
Date : 2016/11/08(Tue) 22:25
Linux・Net・Web | Comment | trackback (0)

Internet Explorerの難点

定期的に会社のニュースがE-mailで配信されていて、仕事中に読むわけだ。

いろいろ書かれているけど、けっこう話題として多いのが新製品発表の話。

自分が関わってた製品とか話題になってる製品の話なら、「やっと発表されたのか」という感想だけど、

そういう流れを知らない製品ならば「これの新製品出るのか」とこの段階で知ることもある。


いずれにしてもどういう形で対外的に発表されているのかというのは興味があるので、

貼られているURLをクリックして、会社のWebサイトのプレスリリースを開いて見ようとするのだが……

コンピュータが固まってしまった。しばらくしたら復活したけど。原因はInternet Explorerが一瞬固まってしまったから。

この会社のWebサイト、とりわけプレスリリースのページを開くと高確率でWindowsごと固まる。

IEが固まるのはよくあることだけど、Windows全体が固まってしまうほどはあまりない気がする。


会社のコンピュータではWindows 7標準のInternet ExplorerをWebブラウザとして使うことになっている。

標準だからってのが大きな理由だろうけど、一見そんなに悪い選択肢ではない。

かつてのIEがWeb標準への対応が不十分だったが、IE8以降であれば特に問題にならないと考えている。

ところがどういうわけか知らんが、Webサイトを開いたときにフリーズすることの多いこと多いこと。

JavaScriptだとかの実行速度が遅いのか、HTMLやCSSの解釈に時間がかかるのか、特定のWebサイトで必ず固まるというのがある。

パフォーマンス面ではIEは難があるようだ。


それで仕事の能率が著しく落ちるということもないので、そんなもんかーと思って放ったらかしにしてるけど、

なんというか、なんでこのWebサイトが重いんだ? と思ってしまうよね。

Webブラウザは意外とリソースを食う存在だということも実感はあるのだが、

今まで経験してきた、Firefoxが重くなるシチュエーション、Chromeが重くなるシチュエーションとはまた違う挙動なんでね。

今まで多少は使えども、常に使い込むことのなかったIEを使い込むとこういうことが見えてくるのだ。


Author : hidemaro
Date : 2016/05/27(Fri) 23:29
Linux・Net・Web | Comment | trackback (0)

Tools