MySQLへの接続の暗号化

基本
MySQLでSSLクライアント証明書を使う - Qiita

※MySQL側のCommon Nameはサーバのホスト名にする


暗号化されていることを確認するSQL

show status like'Ssl_cipher';
MySQL5.6での注意点
MySQL 5.6でSSL接続が有効にならない・クライアントからSSL接続できない。 - ah-2


WindowsのMySQL Query Browserでは、caだけでなく、下記の全てを指定しないと接続できないようだ。

USE_SSL => "Yes"
SSL_CA => ca.crtのファイルパス
SSL_CERT => client.crtのファイルパス
SSL_KEY => client.keyのファイルパス
ファイルパスのバックスラッシュ（￥）はバックスラッシュのままでも、スラッシュにしてもどちらでもOK。
ファイルパスのスペースが含まれていてもOK。
ca.crtは、server.crtとclient.crtの中身を合わせる必要はないようだ。

参考：MySQL :: MySQL Administrator :: 21.4.1 SSL Connections


REQUIRE SSLなユーザーだと、MySQL Query Browserの上部メニューからのMySQL Administratorの起動や、逆にMySQL AdministratorからMySQL Query Browserの起動ができない。（直接起動すれば起動できる。）

愛称？の付けられた脆弱性

（2015/6/29 VENOMとLogjamを追加）

愛称というか、通称というか、ニックネームというか。


2011年 9月 BEAST (CBC)

2012年 9月 CRIME (TLS)


2013年 2月 Lucky Thirteen (TLS)
2013年 8月 BREACH (SSL/TLS)

2014年 4月 Heartbleed (OpenSSL)
2014年 6月 CCS Injection (OpenSSL)

2014年 9月 Shellshock (bash)
2014年10月 POODLE (CBC)
2014年11月 WinShock (Windows)

2015年 1月 GHOST (glibc)

2015年 3月 FREAK (OpenSSL他)

2015年 5月 VENOM（QEMU）

2015年 5月 Logjam（SSL/TLS）

2014年はWindows XPサポート期限終了（4月）もあって当たり年と言われたが、今年はそれを上回る勢い...
ところでSSL/TLSはPOODLE対応を境にTLS/SSLと呼び替えられ始めてるみたい。いまだにサーバ証明書はSSL証明書と書かれることが多いけど...


参考

Transport Layer Security - Wikipedia
華麗なる因数分解:FREAK攻撃の仕組み - ぼちぼち日記

自己証明書の作り方 2015年版

Apache用（他でも使えると思うけど）の、自己署名のサーバ証明書（SSL証明書、改め、TLS証明書？）の作り方のメモ。

条件

• 秘密鍵はパスフレーズ無し＝暗号化しない
• 2048ビット
• SHA-2

コマンド
# 秘密鍵作成（2048ビットを指定、暗号化指定は無し）
openssl genrsa -out server.key 2048
# CSR作成
openssl req -new -key server.key -out server.csr
# 証明書作成（SHA-256を指定、期間は適当に）
openssl x509 -req -in server.csr -signkey server.key -days 3650 -out server.crt -sha256
↓
手元のブラウザで、"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"になった（最強？）

参考：CentOS OpenSSLを使用したSSL用の秘密鍵と証明書の作成 | kakiro-web カキローウェブ

PHPの crypt()で SHA2のハッシュを生成する

PHPのcrypt()を使うと、パスワードで使うのに便利な文字列を生成できる。（説明のために3色に色付けした。）

$str = crypt('test'); => $1$X0zFikbH$z9QaylK29Eu4VQajK6PKw0

生成された文字列は$記号で区切られた3つの部分から構成されている。

• $1$ → MD5でハッシュを生成したことを表す
• X0zFikbH → ハッシュ生成に使ったsalt。crypt()の第2引数でsaltを指定した場合は指定したsaltが使われるが、指定しないと自動生成されたsaltが使われる
• z9QaylK29Eu4VQajK6PKw0 → 生成されたハッシュ
  

この文字列を使ってパスワードが正しいか確認したい場合、下記のようにcrypt()だけで確認できる。

if (crypt($input_password, $str) === $str) {
    echo 'OK';
} else {
    echo 'NG';
}

crypt()の第2引数としてcrypt()で生成した文字列を渡すと、saltの部分だけを取り出してsaltとして使ってくれる（後ろのハッシュ値は無視される）ので、わざわざsaltだけを取り出す必要はない。（便利だが一見しただけでは分かり辛い．．．）


crypt()の第2引数でsaltを指定しなかった場合のハッシュアルゴリズムは、手元の環境ではMD5が使われた。
第2引数でsaltを指定する場合は、saltの前に付ける文字列によって下記のようにハッシュアルゴリズムを指定することができる。

• 何も付けない → DES（拡張DESではなく標準DES？）
  
• $1$ → MD5
• $2a$ → Blowfish
• $5$ → SHA-256 （PHP 5.3.2以降）
  
• $6$ → SHA-512 （PHP 5.3.2以降）
  

上記のように、PHP 5.3.2以降ではcrypt()でSHA2（SHA-256/512）が使えるようになった。
（既に脆弱性が発見されているSHA-1はスキップされたようだ。）

BlowfishやSHA-256/512を使う場合は自動生成のsaltが使えないので、文字列生成時にはsaltを渡してあげないといけない。
saltは推測可能な値でも構わない（元の文字列が同じでもハッシュが異なるようにすることに意味がある）ので、uniqid()あたりでいいんじゃないかな。

$str = crypt('test', '$6$' . uniqid());

参考：PHP: crypt - Manual


関連記事

• floatingdays: HMAC方式で認証用のハッシュを生成するメモ
• floatingdays: PHPで AES方式 （Rijndael-128）で暗号化するメモ