2017/12/28

ルート証明書を無効にされた「WoSign」その後

 恣意的かつデタラメな認証局運用で各ブラウザから無効にされた、例の WoSign(と StartCom)その後どうなったかなぁ…と思ってアクセスしたら、普通にアクセスできた。
 アレ? WoSign のルート証明書は「信頼されていない証明書」へ登録しているのに何で?…と証明書チェインを確認すると…DigCert の下位認証局になってた :-P


 しかし、この WoSign へ "助け舟" を出した「DigCert」だが、例の Symantec の認証局業務(Google からダメ出しされた)を買収したところでもあるんだよなぁ。
 なんだか認証局業界の廃物利用企業という感。

 話を WoSign へ戻すと、IE、Chrome、FireFox でルート証明書を無効にされて、ルート認証局から下位認証局へ落ちぶれたわけだけれども、何故か Opera だけはルート認証局として認めてくれているらしい。なんとも不思議な話ながら、その理由は以下の通り。

マイクロソフト、不正が指摘されていた中国CAの証明書を無効に - CNET Japan
----------引用ココから
 WoSignの証明書をおそらく今後も信頼するであろうウェブブラウザの1つが、Operaだ。Operaブラウザは2016年、Golden Brick Silk Roadを中心とする中国企業のコンソーシアムに買収されている。このコンソーシアムには、北京のモバイルゲームベンダーであるKunlun TechやQihoo 360が名を連ねており、WoSignとStartComはQihoo 360の傘下にある。
----------引用ココまで

 なんともかんとも胡散臭い話だ。

2017/12/19

「マイナンバー」に代わるもの

 名簿の名寄せ乃至それに類した作業をしていると、同姓同名の人に悩まされる。
 他の属性(生年月日や住所)があって判定の材料にできれば良いのだが、必ずしもそういう属性が(対象リストに)あるとは限らないし、そもそも変化してしまう属性も多くある。

 そこで時の政府は「マイナンバー」なるものを考案したわけだが、もっと良いことを思いついた。
 ズバリ、「姓名」で一意になるようにしてしまえば良いのだ。

 人名に使える漢字を 2,998字として。
 もっともオーソドックスな「姓2文字 + 名2文字」の構成で考えても、名前空間は「2998^4」(80兆余り)。「姓1文字 + 名3文字」や「姓3文字 + 名1文字」の構成を許すなら「2998^4*3」(242兆余り)。更に「姓名で 5文字」まで許容すれば「2998^5*4」(96京余り)。

 本邦の人口を 1.27億人として、この名前空間がどれだけの広さか考えると…
 「2998^4」であれば、全人口に 63万回余り名前を付与できる。「2998^4*3」であれば 190万回余り。「2998^5*4」に至っては 76億回余り。
 言い換えると、それだけの世代交代の間、この名前空間は持つということ(人口が増減しないという前提)。ちなみに、生命誕生は 45億年前とか。生命誕生から毎年世代交代していても「2998^5*4」であれば、まだ 31億くらい残ってるね。

 …これ、何気に素晴らしいアイディアじゃないか。
 今からでも遅くないので「マイナンバー」なんていう無粋なものは廃止して、「マイネーム」制度として進めてはどうか。

2017/01/31

ChatWork その認証(パスワード)関係の仕様について


 ビジネス向けチャットツールの雄である「ChatWork」。
 自分も好む好まざるに関わらずお世話になっているわけですが、その認証関係の仕様を確認して、今更ながらに愕然となった。

 ChatWork のパスワードは「半角英数記号8文字以上」となっている。
 でもこれ「半角英数記号から任意に使って8文字以上」という意味だったりする。半角英数記号を混在させる必要はない。入力チェックしているのは文字数だけなので、なんなら「11111111」("1" を 8文字)でも通ってしまう。
 何だよこれ。

 これで二段階認証があるのならまだしも、それも無い(2年くらい前から実装するする言っているけど、未だに…)。
 管理者がパスワード強度を引き上げる(強いパスワードをユーザに強制する)オプションがあるのかと思いきや、それも無い。
 せめて、ユーザのパスワード強度を一覧できる機能でもあれば個別に指導もできるのだが、それすら無い。

 このお粗末さは、ビジネスツールとして如何なものかと。
 「チャットツール」と聞けば軽いイメージがありますが、ビジネス向けともなれば重要な内容が飛び交うわけで、あまつさえファイル添付機能もある。

 ちょっと安心して使えるツールとは思えないなぁ。

2016/09/29

「WoSign」と「StartCom」を「信頼されていない証明書」ストアへ

中国最大の認証局「WoSign」が証明書発行日改竄などを行っていたとしてFirefoxがブロックの方針 - GIGAZINE

 こんなルート証明機関を「信頼」していたら、公開鍵基盤が成立しないでしょう。
 遅まきながらではありますが、「Certification Authority of WoSign」と「StartCom Certification Authority」のルート証明書を、「信頼されていない証明書」ストアへ登録しました。

 ルート証明機関というのは、公開鍵基盤の要です。
 いまや色々な社会基盤、例えば銀行(オンラインバンク)でさえも公開鍵基盤に依存しているわけです。その要であるルート証明機関には、極めて高度なモラルが要求されます。
 問題のあるルート証明機関が一つでもあれば、公開鍵基盤全体が危機に晒されるからです。

 それが瑕疵や怠慢ですらなく、故意にルールに反した運営をしていたわけで、話にならないとしか言い様がないです。

Firefox ready to block certificate authority that threatened Web security - Ars Technica
----------引用ココから
A Google spokesman declined to say whether Chrome planned to issue similar recommendations against WoSign/StartCom.
----------引用ココまで

 なお、Google は上記引用のように呑気に構えているようです。
 FireFox 嫌いの自分ではありますが、FireFox の迅速なブロック方針には賛辞を贈りたいです。

2015/09/04

「ー(長音)」。 いいえ、「―(ダッシュ)」です。

 一連のデータの中から、あるカタカナ名称を検索していてヒットしないので、おかしいなと思っていたら…「ー(長音)」であるべきところが「―(ダッシュ)」で記載されていた。
 もうね、ひたすら脱力。

 ややこしいデータで、ヒットしない(その名称が含まれない)可能性は色々考えられたので、あれやこれや調べていた。その後だっただけに尚更。

 で、その憂晴らし事後調査で見つけたのがこのページ。

日本語の横棒記号に絶望した - taichino.com
----------引用ココから
まず半角記号の’-'はハイフンマイナス(0x2d)と呼ばれていて、ハイフンとマイナスの意味を包含した記号になっています。ASCIIコードのビット数の制限があった事を考えても、センスの良さが光る決定だと思います。文脈でハイフンかマイナスかは容易に判断できる訳です。ハイフンとマイナスを別々にしていたら、今頃マイナスのつもりで書いたハイフンに対するコンパイルエラーで世界中のプログラマのイライラは100%水増しと言った状況なわけです。世界平和に繋がっているといっても過言ではありません。

一方でJIS記号由来でunicodeに採用されている一連のマルチバイトな横棒のセンスのなさと言ったらありません。色んな文脈で使われる横棒を全部別々に定義してしまっています。
----------引用ココまで

 一般論として、文字の意味を分けて定義しておくというのは、間違った選択ではないと思うんですよね。
 統合されたものを分離し直すより、分離されているものを統合し直すほうが遥かに楽なわけです。前者にはなにがしかの判断が(それが「容易」なものであれ)必ず必要ですが、後者は機械的におこなうことができますから。

 ただし、ここまで見た目が紛らわしい文字を、ここまで細かく分けて定義してしまっているというのは、間違いなく悪手でしょうね。
 ユーザの選択能力を過大評価したのか、単に何も考えていなかったのか…。

 慣れた人でも注意深く使い分けないといけないので、慣れていない人の場合は推して知るべし。
 さらに、PC上の文字はコードにより抽象化されているということを知らない人の場合、説明しても「見た目は同じなんだから、なんでダメなの?」となってしまうのです。んがくく…。

 ちなみに、自分の場合は「-(半角ハイフン マイナス)」、「-(全角ハイフン マイナス)」、「ー(長音)」、「一(漢数字の 1)」を "注意深く" 使い分けるので手一杯です。それ以外は意識的に無視して使わないようにしています。
 もっとも、それだけに今回は「―(ダッシュ)」に考えが及ぶのが遅れたんですが…はぁ…。

2015/08/19

ディスプレイ電源オフでウィンドウの配置やサイズが崩れる問題と、その回避方法

Windows7Home 省電力の設定でディスプレイの自動OFF後にマウスなどでディスプレイの電源ONになった際に開いていたいくつかのWindowが全て小さくなる - Microsoft コミュニティ

ディスプレイの電源を切って入れ直すとデスクトップの各ウィンドウサイズが変わる - Microsoft コミュニティ

 Windows 利用中にディスプレイの電源をオフにすると、何故かウィンドウの配置やサイズが崩れてしまう(画面左上方へ押し込められてしまう)現象。
 どうも画面解像度の変更処理(ないしはそれに類似した処理)が走ってしまっているようなのですが、この現象、自分も困ってるんですよね。

 翌日へ作業を持ち越すためにログオフしないでロックだけして帰る時、ディスプレイの電源をオフにできないのです。
 放置しておけば省電力モードへ移行するのですが、それまでの間に「マメな人」がディスプレイの電源を切ってくれたりするわけで、そんな時は翌朝悲惨なことになります。

 理屈で考えて「ディスプレイからの信号が無くなったからといって解像度を変える必要はなく、新たな信号がくるまで現状の解像度を維持すれば良いだけ」なのですから、この現象はディスプレイドライバの問題であると理解しています。
 しかし「仕様」と考えて(=諦めて)あまり深く突っ込んでいませんでしたが、そうか、VGA端子を使うという手もありましたか。

 試しに VGA端子で(わざわざ VGAケーブルを探して)接続して試してみると…おぉ、自分の環境では再現しません。
 この辺り、リンク先でも書いておられるように、VGA規格の旧さが奏功しているのでしょうね。

 ともあれ、これでメデタシメデタシ…なわけ無いだろ!
 CRTディスプレイが絶滅した今、何が悲しくて VGA なんぞ使わなくてはいけないのかと。

----------

 そこで、この問題を(とりあえず)回避する「手抜き Tips」を紹介します。
 要は、ディスプレイの電源をオフする際、予めディスプレイとログオン中ユーザとの "リンク" を切断しておけばよいのです。

 「ディスプレイとログオン中ユーザとの "リンク" を切断」と言ってもどうするか。
 ロック(Windowsキー + Lキー)だけでは不可です。前述のとおり再現してしまいます。ログオフすれば当然に切断できますが、それだと意味がありません(やれるならやってる)。

 現行のクライアント向け Windows(Windows Vista ~ 8.1、そして恐らく 10 も)であれば、「Ctrlキー + Altキー + Delキー」のメニューを表示して、「ユーザの切り替え」を選択(Altキー + Wキー)します。これで切断されます(正しくは「コンソール・セッションでなくなる」と表現すればいいのかな)。
 実際に別のユーザでログオンする必要はなく、この手順でログオン画面にするだけで可です。

 復帰する時は、普通にパスワードを入力すればログオンしていたユーザへ戻れます(普通にロックしていた時より、若干時間は要しますが)。
 仮にディスプレイの電源が切られていても、ウィンドウの配置やサイズは元のままです。

 これで「マメな人」にディスプレイ電源をオフにしてもらっても大丈夫です(…しかし、なんでここまでせにゃならんのだ…という気はする)。

 以上、「手抜き Tips」でした。
 まぁ「手抜き」とはいっても、「手を抜かず回避」(=解決)しようとすると、恐らくディスプレイドライバに対応してもらうしか無いんですけどね、この問題。

----------

Afterfollow 2016/10/03


 世の中、有徳の士というのはいらっしゃるもので、解決方法が公開されていました。

DisplayPort接続時のディスプレイのオンオフによるウィンドウの再配置について - 塵の雨日記

 以下のレジストリを変更すると、ディスプレイを切断してもウィンドウの配置やサイズが崩れないとのこと。
 物理ディスプレイ切断時に切り替わる仮想的なディスプレイがあって、その画面サイズがこのレジストリ値で指定できるのでしょう。

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration\SIMULATED_(数字アルファベットの羅列)\00]
PrimSurfSize.cx = 横ピクセル数
PrimSurfSize.cy = 縦ピクセル数

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration\SIMULATED_(数字アルファベットの羅列)\00\00]
ActiveSize.cx = 横ピクセル数
ActiveSize.cy = 縦ピクセル数

 この現象、Windows 10 では発生しませんが、やはりまだまだ Windows 7 や 8 の方もいらっしゃることですし、Afterfollow として追記しておきます。

2015/08/18

Heartbleed 脆弱性への対応と、技術への理解

 セキュリティ関連企業のホワイトペーパを読んでいたら、Heartbleed 脆弱性への対応で SSL証明書を入替えた際、秘密鍵を変更しないまま証明書を再発行している Webサーバーが多いらしい。
 馬鹿な、有り得ないだろ。

 事実だとすれば、大きく二重の不見識だと思う。
 一つは、Heartbleed 脆弱性の内容(プロセスのメモリ内容が漏洩 = 秘密鍵が漏洩)を理解しないまま、「SSL証明書を再発行しないといけない」という上っ面だけの対応をしてしまっていること。
 もう一つは、そもそも SSL証明書を再発行(更新)する際は、新しい秘密鍵を使わなければいけないという大原則に反していること。

 セキュリティ関連企業のホワイトペーパーである(多少なりと宣伝の色彩がある)ことを割引いて読まないといけないのだろうけれど、自身の経験でも、何も考えずに長い有効期限(複数年)の証明書を選択したり、あまつさえ CSR を使い廻したりするのを見てきているので、あながち誇張だとばかりも思えない。
 どちらも、複数年にわたって「同じ秘密鍵を使い続ける」という事なので。特に後者(CSR の使い廻し)は、公開鍵基盤公開鍵暗号の仕組を理解していたら絶対にしない選択だと思う。

 「技術」というのは IT関連に限らず、詳細はともかく概要だけでも理解していないと安全に使うことすら叶わないのだと、改めて思うのです。