ダイソー USB扇風機(メタルフレームタイプ)

昨年購入したダイソーの300円USB扇風機が特に不具合なく使えた(現在も故障なく使えている)のでもう一つ購入しようと思ったら似た形でメタルフレームタイプ(300円)というのがあったのでそれを選んでみた。

ところが、使い始めて6時間も経たないうちに停まって動かなくなった。耐久性がゼロでガッカリ。
とりあえず、捨てる前に分解してみた。

ダイソー USB扇風機(メタルフレームタイプ) 1
ファンのガード部分とスタンド、要するに外側は全てメタル、スタンド用の黒いゴム(樹脂?)のクッションが3つ。このクッションは付属のものを購入後に自分で取り付ける。

ダイソー USB扇風機(メタルフレームタイプ) 2
ウラ面もメタル、電源スイッチと給電用のUSBケーブルがある。

ダイソー USB扇風機(メタルフレームタイプ) 3
USBケーブルからUSB扇風機のスイッチとモーターにつながってるだけ。清々しいまでに何も無い。まぁ、それで何か問題あるというものでもないが。

ダイソー USB扇風機(メタルフレームタイプ) 4
こちらがモーター。右下側がプラスチックのファンが付く側の軸。この軸があまりに短いのでファンの取り付けがちょっと怪しく回転させるとファンが僅かにブレてガタついていた。ガタつくと安物のモーターは軸受がメタルなので長持ちしないだろうなとは思ったが、まさか6時間持たずに壊れるとは・・・。

ファンがガタついていたのはあったがただちに壊れるとは思わなかったが、動かなくなってからファンを手で回すと明らかに異常があるという感じもなく軸受が悪くなった様子もなく普通に回る。その状態でスイッチを入れると僅かに回ろうとしている様子はあるが、やはり止まってしまう。異常なまでにトルクが無いっぽい。

モーターを分解してみた

ダイソー USB扇風機(メタルフレームタイプ) 5
左側がケース、内側がマグネット。
右側がローター。手前が整流子(ブラシが当たる側)になる。
なんか水没させたんじゃないかってほど錆てキチャナイ。ただし、軸受は正常でコアも巻線も問題なさそう。これを見る限りトルクが全然ない理由がわからない。

ダイソー USB扇風機(メタルフレームタイプ) 6
ブラケット側。
キッタナイ内側してるだろ。ウソみたいだろ。ほぼ新品なんだぜ。これで。
左右から中央に1本ずづ伸びてるのがブラシ。先端が三叉のフォークのようになっている。これが整流子に触れてコアに電気が流れる。 見ると解るが右から中央に伸びてる側のブラシの三叉の一つが曲がっている。本来なら3又は曲がっていてはダメで左から中央に伸びているブラシと同様に揃っていないとダメな筈。これが1本だけ上側に曲がっているということは想像するにこの1本だけがモーター組立時に整流子を挟んで反対側に行ってしまったのかも。当然ショートの危険もあるし、そうでなくても回転してトルクを発生させるタイミングに合わないところで電気が流れることになった筈。最初はなんとか回ることができる位置に当たっていたのが回っている内に最悪の位置にズレたということかな?でないと、最初は回ったのにその後に全くトルクがなくなった理由が思いつかない。

この曲がったブラシを真っ直ぐにすれば正常に回るモーターになるかと思われるが、分解時にブラケットが変形したのでもうこのモーターは使えない。というか、ブラケット固定部を破壊しないと分解するのが難しかったの。

値段が値段なので軸受けにベアリングを使えとまでは言わないが、ブラシはもう少しマシなのにして欲しいところ。今回は運悪く正しく組み立てられなかったモーターを組み込んだ個体に当たったらしいということが解ったが、このブラシでは正常な製品に当たったとしても耐久性は期待できないかな。

クレジットカード会社のウェブサイト SSL/TLS対応状況

6月中に日本の銀行のSSL/TLS対応状況を調べてみたけど、いよいよ7月に入ったのでクレジットカードの会社がどうなってるか調べてみた。なんで7月かというと前回も書いたけど、セキュリティ基準であるPCI DSSのv3.2では2018年6月30日、で脆弱性のあるSSL3.0とTLSv1.0の実装(使用)を無効化しなければならないとなっているから。 そのPCI DSSはクレジット会社用のセキュリティ基準。

会社名・カード名などSSL
3.0
TLS
v1.0
TLS
v1.1
TLS
v1.2
URLその他
アメリカン・エキスプレス・インターナショナル表示
ジェーシービー表示チェーン設定
三菱UFJニコス表示たいへんよくできました
株式会社クレディセゾン表示ROBOT
SBIカード検査不能表示ユーザー用サイト7月末で終了予定
りそなカード表示
SAISON表示ROBOT
静銀セゾンカード表示
三井住友トラストクラブ表示
イオンクレジットサービス株式会社表示カード申し込みページ
スルガ銀行表示チェーン設定, POODLE, RC4,
弱いのしかない
ゆうちょ銀行 JP BANK カード表示チェーン設定 ROBOT
三井住友VISA表示チェーン設定 ROBOT
セディナ OMC Plus表示弱いの優先
セディナ CF表示何故か上よりマシ
オリエントコーポレーション表示
ジャックス表示弱い順
アプラス表示弱いのしかない, ROBOT
楽天カード表示弱いの優先
ワイジェイカード表示
ライフカード表示
アコム表示優先順が変で結局弱い, ROBOT
全日信販株式会社表示弱いのしかない, POODLE, ROBOT
株式会社オーシー表示
株式会社エポスカード表示RC4
株式会社ビューカード表示弱いのしかない
東急カード株式会社表示
株式会社NTTドコモ (DCMX)表示POODLE
VISA表示たいへんよくできました
個人用ログインは無いのでトップページで
Mastercard表示個人用ログインは無いのでトップページで

リスト幅の制限でホスト名の「表示」にマウスカーソルを合わせるとホスト名を表示するようにした。クリックしちゃダメ。

クレジット会社はたくさんあってよくわからないので名前を聞いたことがあるような有名処っぽいところだけ。有名処でも抜けてるかも。

意外にもTLS1.2だけにしているところが結構多いという印象(いいね)。
PCI DSSが求めている「TLS1.0の無効化」をしていない場合は黄色を付けた。今回調べた中でドコモだけがSSL3.0を有効にしてた。滅びろ。
利用可能な暗号スイートはいくつか変な会社があったけど前回の銀行を調べたときと比べるとずいぶんとマシな印象。
「チェーン設定」を指摘しているところは例のシマンテック Secure Siteかシマンテック Secure Site Proあたりの糞ルート証明書。ただちに危険というわけではないし、ある意味直しようもないけど。
PCI DSSではTLS1.1を無効にすることは求めていないけど有効は望ましくないので、TLS1.2だけ有効にしていて暗号スイートの指定が適切で特に問題の無さそうな三菱UFJニコスとVISAに「たいへんよくできました」印を付けた。

見方(見るところ)が違うと異論もあるかもしれないけど「がとらぼ」での評価はこんな感じ。

ウェブサーバのTLS ChaCha20-Poly1305で通信させたい

以前にECDSAな証明書を作成したときにP-256を使ったけど、P-256は根拠は無いがなんか信用できないという人がいるのも確か。そこで来たるべくTLSv1.3時代を見据えてChaCha20-Poly1305やX25119にも対応させてみたい。速いらしいし。

サーバーOSは例によってFreeBSD、ウェブサーバはNginx、TLSに使うのはLibreSSLではなくOpenSSLとする。

OpenSSLの置き換え

X25519を使用するにはOpenSSL 1.1.0以上が必要だがFreeBSDのportsでOpenSSL(security/openssl)をインストールしている場合は1.0.xの筈なので非対応。security/openssl-devに変えなければならない。つい2ヶ月ほど前まではsecurity/openssl-devをインストールしようとすると多くの関連portsがビルドエラーになっていたが、急速に対応状況が改善していて2018年6月11日時点ではOpenSSLに依存しているportsの殆どがsecurity/openssl-dev対応になっている。一部非対応portsも残っているので油断はできないが。

/etc/make.conf(1行変更)
(変更前)
DEFAULT_VERSIONS+=ssl=openssl

(変更後)
DEFAULT_VERSIONS+=ssl=openssl-devel

OpenSSL ports置き換え手順 (portsツリー更新は省略)
### OpenSSLのオリジン替え
# portupgrade -o security/openssl-devel security/openssl
### 上のコマンドで反応しない場合はこちら、上で更新されたら↓の1コマンドは不要
# portupgrade -f -o security/openssl-devel security/openssl

### OpenSSLに依存しているportsを全て更新 (時間かかる)
# portupgrade -fr security/openssl-devel

Nginxの設定

server {
    listen 443 ssl http2;
    listen [::]:443  ssl http2;
    server_name hoge.example.com;

中略

    #RSAの証明書
    ssl_certificate      /path/rsa.pem;
    ssl_certificate_key  /path/rsa-key.pem;

    #ECDSAの証明書
    ssl_certificate      /path/ecdsa.pem;
    ssl_certificate_key  /path/ecdsa.key;

    #DHパラメータファイル (この記事の設定的には不要な筈だが、無いとNginxがエラーになる筈)
    ssl_dhparam          /path/dhparam4096.pem;
    
    ssl_protocols        TLSv1.2;
    ssl_prefer_server_ciphers  on;
    ssl_ciphers          ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;
    ssl_ecdh_curve       X25519:prime256v1;

中略

}

ECDSAの証明書が 無い or 使わない ならECDSA証明書の項目は削除でssl_cipherでECDSAを含む暗号スイートを削る。(半分になる)
今回は趣味でChaCha20-Poly1305を先頭に置いたが、サーバー側のCPUがIntelやAMDでAES-NIを効かせた処理速度を考えるとAESを優先させたいところ。逆にスマートフォンの閲覧者が多いサイトであれば(サーバー側が多少ツラくても) 非AES-NI環境で高速なChaCha20-Poly1305を優先してやると良いかも。
P-256が嫌いならssl_ecdh_curveから :prime256v1 を削るか別のに変える。

Nginxの再起動

###設定が致命的に間違っていないことを確認する
# service nginx configtest

###エラーが出ないならNginxを再起動する。
# service nginx restart

ブラウザで接続してみる

RSAの証明書のサイトでChaCha20-Poly1305 X25519 1
証明書がRSAなサイトでChaCha20-Poly1305 X25519な接続になるとブラウザではこのような表示。
(Chromeではページを表示して[F12]でデベロッパツールを開き[Security]タブを選択する)
ちなみに上の画像は「がとらぼ」をPC版のChromeで表示したもの。(2018年6月11日現在)

RSAの証明書のサイトでChaCha20-Poly1305 X25519 1
証明書がECDSAなサイトでChaCha20-Poly1305 X25519な接続になるとブラウザではこのような表示。
これは「がとらぼ」ではない別なサイトをECDHE-ECDSA-CHACHA20-POLY1305を最優先にして試したもの。

RSAの証明書のサイトでChaCha20-Poly1305 X25519 1
証明書がRSAなサイト(ここのこと)をQualysSSL LabsのSSL Server Testで見たもの。暗号スイートの優先順位も上の設定例で意図したとおりになっている。

ChaCha20って速いのかしら

###AES-NL有効化状態で計測
% openssl speed -elapsed -evp chacha20
% openssl speed -elapsed -evp aes-128-gcm
% openssl speed -elapsed -evp aes-256-gcm
% openssl speed -elapsed -evp aes-128-cbc

###AES-NL無効化状態で計測
% setenv OPENSSL_ia32cap "~0x200000200000000"      ←(tcsh用環境変数セット)
% openssl speed -elapsed -evp chacha20
% openssl speed -elapsed -evp aes-128-gcm
% openssl speed -elapsed -evp aes-256-gcm
% openssl speed -elapsed -evp aes-128-cbc

上のコマンドをIntel Pentium G630T 2.3GHzという非常に非力なPCで実行してで比較してみた。aes-128-cbcはAES-NLが効きやすいので有効化・無効化の差をはっきりと示す為の参考程度で。
逆に言うといまどきのセキュリティ重視な設定のウェブサーバ用途ではAES-NLは以前と違いあまり恩恵がない?ハードウエアの性能によるかしら。

速度比較AES-NLオン 1
AES-NLを有効化した計測結果。3秒で何回計算したかというもの。緑が参考値のaes-128-cbcだが、AES-NL有効でChaCha20とほぼ同じくらいを出せたのは16バイトのブロックの場合だけ。もっとaes-128-cbcが高い値になると思っていたので意外。
他のサイズではChaCha20が圧倒。ざっくり見てaes-128-gcmの3倍の値を出している。

速度比較AES-NLオン 2
AES-NLを有効化した計測結果。上のグラフの結果から計算回数とブロックの大きさを掛けて速度にしたもの。(実際にはコマンド実行で両方の数値が表示される)
効率からみると8192バイトのブロックが最も良い数値になるのかしら。こちらもaes-128-cbcがChaCha20と対等だったのは16バイトのブロックのときだけ。他はChaCha20が圧倒。そして、256バイト以上のサイズのブロックではaes128-gcm, aes-256-gcm, aes-128-cbcで大して変わらないことに。

速度比較AES-NLオフ 1
AES-NLを無効化した計測結果。3秒で何回計算したかというもの。AES-NLが効いてないので緑のaes128-cbcが1/3ほどに低下している。他のaes128-gcmやaes128-gcmも激減というほど酷くはないものの数値の低下はある。

速度比較AES-NLオフ 2
AES-NLを無効化した計測結果。上のグラフの結果から計算回数とブロックの大きさを掛けて速度にしたもの。(実際にはコマンド実行で両方の数値が表示される)
圧倒的な差を見せつけてChaCha20が勝利。

今回はCPUがショボイというのもあってか「がとらぼ」の中の人の思惑通りというか都合良くもChaCha20以外の選択肢はないだろというような圧倒的な結果になったが、サーバのマシンの性能によっては必ずこうなるとは限らない筈なのでウェブサーバで実際に試してみて安全で効率の良さそうな暗号スイートの優先度を上げるというのもアリかも。もちろん閲覧者の皆がメジャーブラウザの新しいバージョンを使っているとは限らないのでどうしても接続互換性重視ということであればChaCha20-Poly1305が最優先ということにはならないだろうけど。