2018-08-18

いまさらSSL/TLS証明書

今までSSL証明書をなんとなく雰囲気で使っていた感が否めないため、自信を持って解説ができるよう具体的な仕組みを調べたメモ。

X.509証明書

X.509証明書はISO/IECによって定められている証明書に関する仕様。

公開鍵証明書、属性証明書、特定証明書の三つがあり、主に公開鍵証明書が一般に「証明書」と呼ばれる。

公開鍵証明書は、CA証明書とエンドエンティティ(またはリーフ)証明書に別れる。

CA証明書はルートCA証明書と、中間CA証明書に別れ、ブラウザやOSはルートCA証明書の一覧をあらかじめ持ち検証に使う。ルートCA証明書は中間CA証明書を発行することができ、その中間CAも新しい中間CA証明書を作成することができるため、チェーンする。

CA証明書かどうかは、拡張領域のbasicConstraints(基本制約)フィールドに設定されるフラグにより判断され、CAであれば上位のCAをたどり、ルートCAまで遡れれば検証が完了する。

例えば、以下はGoogleにopensslを用いてアクセスをした例:

depth=1 /C=US/O=Google Trust Services/CN=Google Internet Authority G3
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
   i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign

sがSubject(証明の対象)、iがIssuer(発行者)。 www.google.comに対する証明書から、Google Trust ServicesのCA、GlobalSignのルートCAと辿れていることがわかる。 (GlobalSignはGMOグループのルート認証局。GoogleがGMOに依存してるの意外。)

apacheだと中間証明書を指定するディレクティブがあるため意識しないが、nginxなどでは公開鍵に中間証明書を結合して設定する必要がある。 (PEMファイルの仕様 https://tools.ietf.org/html/rfc7468#page-5。サーバ証明書、中間CA証明書の順で結合する。https://tools.ietf.org/html/rfc4346#page-41)

証明書の失効

証明書に記載されている有効期間(notBefore, notAfter)以外の理由で失効する場合、証明書の失効はCRLまたは、OSCPというプロトコルによってクライアントに伝えられる。CRLは証明書に付与されるシリアルナンバーのリストをWeb上でホストする方式で、古いTLSクライアントで用いられている。このリストは肥大化するため、デルタCRLという差分のみを提供する方式がある。

OSCPは認証局に証明書の状態を問い合わせるプロトコル。クライアントが直接叩くか、OSCP staplingを用いてサーバが代わりに認証局へ問い合わせる方式がある。

2018-08-04

GoでSpannerを扱う際のポイント

そもそもSpannerって？

SpannerはGCPが提供する高可用性のあるリレーショナルデータベース。SQL文が使え、スキーマ定義・スキーマの変更・SELECT系のクエリを実行できる。(INSERT, UPDATE, DELETEは無い) プライマリーキーを適切に設定すれば、負荷に応じて自動でシャーディングを行ってくれる。トランザクションも使える。この辺がよくまとまっている。超実践 Cloud Spanner 設計講座

GoでSpannerを利用した開発を行う中で、何点かわかったことがあったのでそのまとめ。

CreateSessionは遅い

Spannerに対してリクエストを行うとき、まずCreateSessionというgRPCが走るのだが、これが500msぐらいかかるため、Spannerに対して初めてリクエストを送る際など遅延が発生する。これを防ぐために、SessionPoolConfigを適切に設定する必要がある。 spanner - GoDoc SessionPoolConfigの値は、 https://cloud.google.com/spanner/docs/sessions この記事を見ながら設定すると良い。(Spannerはこの辺のドキュメントが全て日本語で読めるためありがたい…)

クエリの遅延が発生した場合、この辺の設定を見直すことをおすすめする。

DeleteでAllKeyは(基本的に)使えない

テーブル内の全データを削除したいと思ったとき、愚直に考えれば「DeleteにAllKeys渡せばいいんだろ」となるのだが、データ数が増えた場合にこの戦略は使えなくなる。 CloudSpannerは、変更系のクエリの影響範囲が20000件以内、という制限を持つ。これは、UPDATEやINSERTに関しては「影響を受ける列数が20000件以内」で、DELETEに関しては「影響を受ける行数が20000件以内」となる。あくまで「影響を受ける」件数であるため、20000件以上のデータを持つテーブルの初期化は、「一度消して作り直す」しか方法が無いらしい。

ALTERで追加するカラムにはNOT NULL制約が付けられない

SpannerのALTER文の文法にはしっかりと「NOT NULL」という規則が載っているのだが、 https://cloud.google.com/spanner/docs/data-definition-language#alter_table 実際には使うことができない。Spannerは標準で新しく作ったカラムにはNULLを入れるのだが、NOT NULL制約を指定すると矛盾が発生するため、指定することができない。

セカンダリインデックスの場合も、スプリットを意識したキーを選ぶ必要がある

SpannerのPKを選ぶ際、スプリットが入ることを意識してキーを選ぶ必要があるのはご承知の通りだと思うが、セカンダリインデックスについても、スプリットが入ることを意識し、ホットスポットが入らないようなキーを選ぶ必要がある。
ドキュメントにも明記されているのだが、セカンダリインデックスもテーブルとして実装される。よって、セカンダリインデックスに指定したキーは、そのテーブルの主キーとして使用され、スプリットもそのキーによって決められる。
よって、アクセスが集中しやすいテーブルでセカンダリインデックスの先頭にCommit Timestampなどの単調に増加・減少する値を設定した場合、ホットスポットが発生し、スケールしなくなる。

今後、また気づきが増えたタイミングで更新します。

2018-07-22

golangとbazelで作るいい感じなビルド環境

※Makefileに一部間違いがあったため、修正しました

bazelはビルドシステムの一つで、Googleが開発し社内でも使用している。makeなどの従来のビルドシステムと比べると、簡潔な設定で幅広い言語・ビルド対象に対応していて、ビルドが必要なものはほとんどbazelで解決できる。

Bazel - a fast, scalable, multi-language and extensible build system" - Bazel

例えば、Goのビルドと同時にdockerイメージもビルドしたい、protoもビルドしたいといった場合、通常であれば個別にビルドコマンドを打つ必要があるのだが、この作業をbazelに一本化でき、とても便利。

必要な物

以下のものを使用する:

1. bazel

2. rules_go

3. gazelle

4. rules_docker

rules_goはGo言語向けbazelルール。go_libraries、go_test、go_binaryなどを提供し、Go言語に関するビルド、テスト処理を記述できるようになる。

gazelleはrules_goを用いたビルド設定を自動生成するツール。importなどを見て、自動で依存を解決し、ビルド設定を吐き出してくれる。

rules_dockerは、bazelを用いてdockerイメージをビルドしたり、プッシュすることができるルール。今回はgoのバイナリを含めたイメージをビルドし、実行する。

オススメの構成

以下にサンプルのレポジトリを作成した。

GitHub - mjhd-devlion/bazel-gazelle-sample

ディレクトリ構造としては以下のようになっており、cmd以下のsampleが、今回動かす対象のプログラム。pkg/sampleパッケージを読み込み、Hello, Worldを出力する。depによるvendoringも行いたかったため、いつもよりキレイめにHello, Worldを表示している。

./
├── BUILD.bazel
├── Gopkg.lock
├── Gopkg.toml
├── Makefile
├── WORKSPACE
├── cmd
│   └── sample
│       ├── BUILD.bazel
│       └── main.go
├── pkg
│   └── sample
│       ├── BUILD.bazel
│       ├── sample.go
│       └── sample_test.go
└── vendor

また、以下のようなMakefileを用意している。make gazelleコマンドを実行することでプロジェクト全体のBUILD.bazelファイルを更新し、その後make runすることによってプログラムを実行することができる。

.PHONY: run
run:
	bazel run //cmd/sample:go_image

.PHONY: build
build:
	bazel build //cmd/sample:go_image

.PHONY: test
test:
	bazel test //...

.PHONY: gazelle
gazelle:
	bazel run //:gazelle
	bazel run //:gazelle -- update-repos -from_file ./Gopkg.lock

ここで一つ注意点があり、Makefileのgazelleの項に、update-reposという記述をしている。

gazelleとvendoringは相性が悪く、特にprotoをビルドする際など、バージョンの違いによる問題が発生したりする。

ここ(go_proto_library dependency overhaul · Issue #1548 · bazelbuild/rules_go · GitHub)に詳しく載っているのだが、protoをビルドする際にrules_goが提供する依存のバージョンがvendoringしているものと衝突した場合、ビルド時、または実行時のエラーが発生する。

これを解決するためには、WORKSPACEにgo_repositoryルールを用いて依存するライブラリのバージョン指定をする必要があるのだが、手作業でやるのは流石に辛い。

ということで、実はgazelleはupdate-reposという「Gopkg.lockとgo_repositoryを同期する」プログラムを用意してくれている。(つい先日知った)

サンプルでは、このプログラムを用いてdepの解決した依存に、bazelの依存を同期し、安全にビルドが行えるよう、update-reposをgazelle実行時に呼ぶような設定を行っている。

微妙な点

実はvendorディレクトリを削除しても動く。依存はbazelがビルド時にダウンロードし、その後も管理をしてくれるため、vendorディレクトリの中身はビルド時に使用されていない。二重管理になってしまうため、vendorディレクトリを削除したいのだが、vendorディレクトリが無いとエディタが真っ赤になる…。

何かもっと良い方法をご存じの方、是非コメントいただけると嬉しいです。

2017-07-11

ノートパソコンをタッチ対応に…Neonode AirBarを購入してみた

www.air.bar

AirBarは、タッチ未対応のノートパソコンの画面を、タッチ対応にするデバイス。(現在はWindows10のみの対応。今後Mac対応の製品が発売されるらしい)

お値段も$69.00で買え、13.3inchから15inchまでのサイズをそろえている。

最近、秋葉原で5000円ほどのタッチパネルを購入し、タッチ機能のすばらしさに気づいたため、どうせなら本体のディスプレイもタッチ対応にしてしまおうということで購入した。

Amazon.com(co.jpじゃない)だと安い

日本の並行輸入品だと1万超えてきてしまうし、海外で購入しても1週間ほどで届くため、注文時に多少英語を読む必要はあるけどAmazon.comで購入した方がお得。

Amazon.comでは、$69.00+Shipping($11.31)で購入できた。(Shippingはいくつかのオプションから選べたため、最も安いものを選択すれば$5ぐらい安くなる)

開封の儀

f:id:wait0000:20170711105004j:plain

f:id:wait0000:20170711105324j:plain

内容物は、予備のマグネット4個、スクリーンクリーナー、ケース、AirBar本体、説明書。

マグネット自体は本体にあらかじめ付いているため、予備は本当に予備。

AirBar本体が思ったよりも細長く、洗練された印象。

取付

f:id:wait0000:20170711105838j:plain

AirBar本体の背面に、マグネットが付いているため、このマグネットのシールをはがす。

粘着面が現れるため、AirBar本体のガイドラインをよく見ながら位置を合わせる。

位置は、ガイドラインと画面のはじを合わせ、画面した3mmほどのところに、水平に設置すると良いらしい。

位置を決めたら、AirBarを画面に押し付け、そっとはがすと、マグネットが画面に張り付く。

これで設定完了。

あとは、AirBarを画面に取り付け、USBを接続すれば画面がタッチ対応になる。

設定が完了したら、

Updating the firmware on your AirBar for Windows 10 device – AirBar by Neonode

からファームウェアをアップデートすると良い。

(例えば、初期の状態では変なブザー音が鳴っていたのだが、解消された。)

感想

タッチパネルとしての感想だが、精度は中の下ぐらい。同じ光学式のタッチパネルと比べても、少し感度が悪いため、文字の手書きなどの用途には使えない。

また、設置の具合かもしれないが、画面右上の反応が悪いため、ウィンドウを全画面にした際にバッテンが押せないなどのもどかしさがある。

また、持ち運ぶにもへし折れそうなほど細長いので怖く、あまり持ち歩く気にならない…。

有線接続なのももったいない…かといって無線にすると電源が確保できないか…。

…ただ、ディスプレイを交換することなくタッチ機能を追加できるのは、メリット。

また、マルチタッチにも対応しているので、ちょっとズームをしたい際など、AirBarがあると便利。

結論

ノートPCってそもそも程よい位置にトラックパッドがあり、画面まで手をもっていかなくても操作をできるようになっているため、あえて追加のデバイスを使って、ノートPCを畳めなくしてまで、画面をタッチ対応にする必要もないなと思った。

ノートPCをすぐに畳めない、持ち運びに不安があるという懸念点があるため、ノートPCをデスクトップ化して使っている人など、持ち運ばない用途であれば十分価値があると思う。

余談

Windowsってタッチパネル２つあると、カーソルがどっちかのタッチパネルにしか表示されないっぽい。

惜しい…。

2017-03-03

macOS SierraでJIS配列キーボードを US配列として使う方法

mjhd.hatenablog.com

この記事でも書いたのだが、macOS SierraからはKarabinerが使えない。

そこで、前回はカスタムキーボードレイアウトを作成することで対処をしたのだが、この方法の難点は、「日本語入力中の配列が JISのまま」というところ。

不完全な方法だった。

今回は、完璧にキーボード配列を書き換えられるSierra対応ソフトを見つけたため、その設定ファイルを公開したいと思う。

Locaille

Lacaille - 親指シフト for macOS

このソフトは、もともと親指シフトを Macで実現するために作成されたものなのだが、かなり細かくキーボードレイアウトをカスタマイズすることができるのが特徴。

今回は、親指シフトを無効にして、 KarabinerのUS配列を移植した。

Locailleをダウンロードし、「設定ファイルを読み込む...」ボタンを押し、以下のファイルを読み込むことによって、完全に US配列に置き換えることができる。

drive.google.com

このUS配列の特徴は、単純にキーボードレイアウトをUS配列にした時に入力できない「`」「~」などの文字を「¥」キーの位置に割り当てていること。

完璧なUS配列ライフがおくれそう。

2017-02-06

WSLをXenialにアップデートしてみた

mjhd.hatenablog.com 過去記事で紹介したBashOnWindows(WSL)環境において、UbuntuのバージョンをTrustyからXenialへアップデートしたメモ。

アップデート方法

以下のコマンドを実行するだけ。

sudo do-release-upgrade

その後、いくつかのアプリケーションに問題が起こった。

dbusがらみのエラーが起こる

DBusを使用するアプリケーションが、「Exhausted Authentication Mechanisms」的なエラーを吐いて起動しない。
“/etc/dbus-1/session.conf"を以下のように編集することで対応可能。

<auth>EXTERNAL</auth>

を

<!--<auth>EXTERNAL</auth>-->

とする。

GnomeTerminalがすぐ終了する

なんでか知らんけど、GnomeTerminalが子プロセス作って自分は勝手に終了しちゃう。
以下のように–disable-factoryを追加することで対応可能。

gnome-terminal --disable-factory

そんなぐらい。

2017-01-28

オブジェクト指向とは

メモ

新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiitaなどを参考にまとめたメモ。

オブジェクト指向プログラミングとは，オブジェクト同士の相互作用として，システムの振る舞いを捉える考え方である．所謂手続き型の言語しかなかった時代，コンピュータの性能向上につれて，データ構造，処理の複雑化し，正しく動く可読性の高いプログラムの記述が困難になった．1960年代にはこうした状況に「ソフトウェア危機」[1]という名前が付けられ，新たなプログラミングの手法が模索された．こうして考案されたのが「構造化プログラミング」[2]などのデザインパターンである．構造化プログラミングでは，言語特有のステートメントを直接使うのではなく，抽象化したステートメントを持つ仮想機械を想定し，その仮想機械上でプログラミングを行う．こうすることで，プログラムの正当性や可読性を向上することができるようになる．またこれとともに，「モジュラプログラミング」[3]と呼ばれる，同じ機能を持つ処理同士をモジュールという単位でまとめ，分割する手法が広まっていき，また良い分割を行うために，「状態」と「副作用」[4]を如何に扱うかが問題になっていった．その一つの解決策として現れたのが，オブジェクト指向プログラミングと，関数型プログラミングである．関数型プログラミングでは，基本的に副作用を持たず引数と返り値のみでプログラムを構成することで，参照透過性を保っているが，オブジェクト指向プログラミングでは，状態と副作用を「オブジェクト」に閉じ込めることで，抽象化を行った．このオブジェクト指向言語として初めて現れたのが，Simula[5]である．Simulaには，オブジェクト，クラス，動的ディスパッチ，継承，ガベージコレクションなどの現在のオブジェクト指向言語が持つ機能が実装されていて，後にC言語にこの機能が取り入れられ，C++言語ができた．また， Smalltalk[6]もSimulaに影響を受けた言語として制作され，C言語にSmalltalkの機能を取り入れた言語として，Objective-C[7]言語などが作られた．オブジェクト指向プログラミングでは，プログラムはオブジェクトの集合として定義され，特徴として「カプセル化」[8]や「ポリモーフィズム」[9]，「継承」[10]などの概念が挙げられる．初めに，カプセル化とは，Simulaで考案されたもので，データと処理を1つのオブジェクトとしてまとめることで，オブジェクト外部への副作用を減らすことができ，プログラムの正当性を高めることができるものである．例えば，グローバル変数を使い状態を共有しているモジュールがあった場合，片方の仕様を変更したとき，もう一方も修正しなくてはならなくなる．このような時，カプセル化を行うことでこのモジュール間の結合をなくすことができる．次に，ポリモーフィズムとは，現在の言語ではオーバーロードや仮想関数，インターフェースと呼ばれる機能などで実現されていて，異なるクラスであっても同一のコードで扱えるよう，クラスが複数のクラスに属すことのできる性質のことを言う．例えば，以下のリスト7の様な処理があった時，printNumber, printDate関数は，以下のリスト8の様に一つの関数としてまとめることができるようになる．最後に，継承とは，あるクラスを基に，機能を追加したり変更したりした別のクラスを定義することのできる機能である．これにより，副作用を基のクラスに隠蔽したまま，新たな機能を追加することができるため，プログラムの正当性，可読性に役立つ．

リスト7. ポリモーフィズムの例1 (疑似コード)


1:  class Number {
2:      public string ToString() {
3:          retutn 文字列へ変換する処理;
4:      }
5:  }
6:  
7:  class Date {
8:      public string ToString() {
9:          return 文字列へ変換する処理;
10:     }
11: }
12: 
13: public void printNumber(Number value) {
14:     print(value.ToString());
15: }
16: public void printDate(Date value) {
17:     print(value.ToString());
18: }
19: // プログラムの開始地点
20: public void main() {
21:     var number = new Number();
22:     var date   = new Date();
23: 
24:     // それぞれ別の関数に渡さなければいけない
25:     printNumber(number);
26:     printDate(date);
27: }

リスト8. ポリモーフィズムの例2 (疑似コード)


1:  interface IConvertible {
2:      public string ToString();
3:  }
4:  
5:  class Number : IConvertible {
6:      public string ToString() {
7:          retutn 文字列へ変換する処理;
8:      }
9:  }
10: 
11: class Date   : IConvertible {
12:     public string ToString() {
13:         return 文字列へ変換する処理;
14:     }
15: }
16: 
17: public void print(IConvertible value) {
18:     print(value.ToString());
19: }
20: // プログラムの開始地点
21: public void main() {
22:     var number = new Number();
23:     var date   = new Date();
24: 
25:     // 同じ関数に異なる型を渡すことができる
26:     print(number);
27:     print(date);
28: }

参考:

MJHD

エモさ駆動開発