DigiLoog

巷を騒がせていた「うるう秒」も、とりあえずは過ぎ去り、
インフラエンジニアが一息ついていると思われる今日昨今――

という事で、本日"8:59:59～9:00:00"の間に挿入された"8:59:60"の1秒ですが、
一体、世の中のシステムにはどれ程の影響があったのだろうか。
自分? 朝からPC前で「(teratermを)全力全開! STB～!!」な攻防があったとか、無かったとか。

ちなみに、"ns-lab BB"のサーバは2台のNTPサーバがあり、
他サーバやクライアントは上の2台をDNSラウンドロビンで参照させる構成を取っている。
で、本職の事もあり自鯖前には入れなかったので、
"6月30日 00:00:00"から2日ほどNTPを停止させる事で乗りきりました。
だって、わざと古いkernel使っている検証環境とかあるんだもん(´・ω:;.:…

………

そもそも、うるう秒は原子時計と地球の自転差分が出てしまう事の影響。
詳細はNICTで公開している資料を見て貰うとして、
概ね3年毎に1月1日か7月1日に挿入される事が多い。

今回は7月1日だったから良いが、これが1月1日実施とかになると、
また面倒臭い事になるんだろうな～(´；ω；｀)

………

で、今回のうるう秒については、世間一般の大きなシステム障害は起きなかったようで。
前回(2012年)はmixiとかForsquareがやらかした事も影響したのかね?
まぁ、こんな前例もあったから今年のうるう秒は世のサーバとNW管理者が
コンソール前で全裸待機する犠牲により、システムは今日も動き続けているのかも知れない。

"ns-lab BB"の内側では、各サーバの認証用にプライベート認証局をたてておき、
それのCA証明書をPCにインストールする事で認証時のエラーを無くしていたり。

んな事やらなくても、webブラウザ側で例外指定すればOKなのだが、
証明する為に使用している証明書を例外指定するのもどうかと思うので、
面倒臭いのだが、↑のような運用をしている。

で、先日サーバ側の証明書が期限切れになったのと、
巷で細やかに騒がれているSHA2証明書への完全移行が頭に過ぎったのであった。
色々と調べてみた所、今後は"RSA-SHA2"が主力となる見通しなのだが、
次世代暗号方法として楕円曲線暗号(EllipticCurveCryptography)も使われ出している事がわかった。

という事で「自宅鯖なんだから最新技術を追っ掛けてナンボじゃい!!」という事もあり、
プライベート認証局を"RSA SHA-256"と"ECC prime256v1"に対応させてみた。

"ns-lab BB"のとあるサーバ転送量グラフ。自作スクリプトなので適当仕様なのはご愛敬(´・ω・｀)
当たり前だが、プライベート認証局の証明書を使う事で、例外指定をせずにhttps通信が出来ている。

楕円曲線暗号(ECC)については、Syamtecのサイトに詳細が載っているので、そちらを参照。
要は「RSA暗号よりも、低負荷でより強固な暗号化」を行えると思って頂ければ(詳細は違うが…)

RSAにはsha256やsha512、ECCにはprime256v1やsecp521r1等があるのだが、
今回採用したのは"RSA SHA-256"と"ECC prime256v1"の二つ。
「題目がECCなのに、なんでRSAも…?」と突っ込まれそうだが、
自宅で使っているMTAや自作ソフトがECCに対応していなかったので、RSAも残す事に(´・ω:;.:…

ちなみに、sha256とprime256v1は32bit処理に特化したハッシュ関数。
64bit処理に特化させる場合はsha512やsecp521r1の方を使う必要がある。
が、自宅レベルでは二つの違いがわからないのと、
デファクトスタンダードは256bitの方なので、そちらに準拠してみた。

………

そして、実際に"RSA SHA-256"と"ECC prime256v1"を使って認証局を構築してみた。

	RSA SHA-256	ECC prime256v1
Cirtificate Signature Algorithm	PKCS #1 SHA-256 With RSA Encryption	Object Identifier (1 2 840 10045 4 3 2)
ページ情報
証明書情報
証明書の階層

※RSAとECCでの負荷比較については、@ITで紹介されているので割愛。

………

使用感についてだが、昨今のWebブラウザは標準でECCに対応しているので、
違いを気にせずに利用する事が可能だった。
また、証明書をインストールする時の操作性とかも全く問題無し。というよりも違いが無い

という事で、ガラケーが対象のシステム(ガラケーはECC非対応)や、
もの凄く古いOS(こちらはOS次第)を使っていない限りは
ECCタイプの証明書を導入しても問題無さそうという結論になった。

しかし、企業レベルでの導入事例がまだ少ないのと、
2030年まではRSA-SHA2で大丈夫と言われているので、
暫くの間は、今まで通りRSAが主流になりそうな気がする。

しかし、超大規模なECサイトとか、サイト全体をhttps化するような場合には
ECC証明書の導入を検討する余地はありそう。何せ、処理が凄く軽いので

証明書業界としても、ECC証明書の導入を推奨しているらしいので、
SHA2切り替え時に、一足先にECC対応させるのも一つの流れになるだろう。

« 続きを隠す

お題の通り。
2日程前、ns-labのメインサーバが全部落ちるという阿鼻叫喚が23時頃に発生していた(´；ω；｀)
原因はns-labを構成している仮想ゲストサーバを支えている、
ホスト側のNICで論理エラーが多発し、ネットワーク越しのアクセスが出来なくなった為。

言いたい事は色々あるのだが、その中でも声を大にしたいのが、
『本番環境で仮想はリスクを伴う事を肝に銘じておけ』
の一言。自鯖と言ってもインターネットに公開している以上、それなりの本番環境な訳で…

以前、自鯖屋で鯖をポンポン構築するなら仮想がよろしいという事を書いたのだが、
ホストが落ちるとゲストは全滅するリスクを伴う事を再認識した(´・ω・｀)
その為に仮想サーバ使うならハードウェアを二重化したり、
全く別系統に待機中のコピー鯖を用意させたり、いざという時の為の備えをやるわけで。

一応、www鯖を二重化してはいたのだが、ホストが落ちた時の備えは疎かにしていたし、
そろそろ自鯖と言えども本気で耐障害性を考える時なのかもと思った午後10時でした。
「そこまで可用性求めるならクラウド使え!」というご尤もな意見は(∩ﾟдﾟ)アーアーきこえなーい