検索条件
全26件
(2/3ページ)
2016/07/27(水)FreeBSD 10.3R 環境で dovecot 2.2.25 はそのままでは動作しない
2017/10/12 19:34
弊社でも採用していますが、どうやら FreeBSD固有のバグがあるようです。
具体的には、
Last died with error (see error log for more information): kevent(EV_ADD, READ, 56) failed: Bad file descriptor（実際は改行しません）
といったメッセージが起動時に発生し、サービスを全く提供出来なくなるという重篤な問題。
これは、日本語の情報がほぼ皆無ですが、以下のパッチで凌げます。（弊社でも確認済。）
＃Ports でインストールする場合は、既にパッチが当たった状態でインストールされるので問題ありません。
画像をクリックすると見やすい大きさで表示されると思います。
〔参考ＵＲＬ〕 https://github.com/dovecot/core/commit/ffd8dc932516bc55bf01d91355540daab365e5e9
余りお勧めしませんが、次のバージョン 2.2.26 が出るのを待つ手もあります。
2016/07/17(日)プライベートＣＡの構築[FreeBSD] (2)
2017/10/12 19:33
今度は、構築したプライベートＣＡを用いて、実際にサーバ証明書を発行するところまでメモしておきます。実際に発行する環境を整えるために、最初の一度だけ幾つか準備が必要です。
○ 準備その１－ /etc/ssl/openssl.cnf の変更
以下のセクションを修正します。
[ usr_cert ]
basicConstraints=CA:false(CA:true を CA:false に)
[ v3_ca ]
basicConstraints=CA:false(CA:true を CA:false に)
これやらないと、証明書は発行できるものの、発行した証明書は不正証明書扱いになってしまいます。
○ 準備その２ － CA の公開証明書を pem 形式から der形式へ変換
# cd /root/BasekernelCA # openssl x509 -in cacet.pem -inform PEM -out cacert.der -outform DERここで作成した der 形式の証明書ファイルを Ｗｅｂサイト公開ディレクトリ等に設置し、Ｗｅｂページからダウンロード出来るようにしておきます。
● いよいよサーバ証明書の発行
ここから先は、本物の認証局にサーバ証明書発行手続きをする際にもほぼ同じ手順が使用できます。但し、Unix系/Linux系のコマンドラインインタフェースが基本です。
○ 秘密鍵の生成
# openssl genrsa -out private.key 2048この後生成する公開鍵とペアで使用されます。
ここでは 2048bit(256バイト) 長の秘密鍵を生成します。
一般的に「鍵長」とはこの秘密鍵の鍵長で、現在では 2048 bit 以上でないと、サーバ証明書発行を受け付けません。
また、-des3 や -aes128 などのパラメータを付加すると、パスフレーズ（パスワードと同じようなものだが、似て非なるもの）を付けることが出来ますが、サーバ用途においては却ってパスフレーズが邪魔になる（自動起動が できなくなる）ため、特に理由が無い限りは付けないほうがよいです。
○ ＣＳＲ（署名申請書/Certificate Signing Request）の生成
# openssl req -new -sha512 -key private.key -out server.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:JP State or Province Name (full name) [Some-State]:Hokkaido Locality Name (eg, city) []:Sapporo Organization Name (eg, company) [Internet Widgits Pty Ltd]:Base Kernel Co,.Ltd. Organizational Unit Name (eg, section) []:labo Common Name (e.g. server FQDN or YOUR name) []:clione.basekernel.ne.jp Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:この手順で、当該の例では暗号化された CSR が server.csr ファイルに作成されます。
ここで・・・
Country Name － ここは日本なので、ISO3166 で規定され、日本を示す２レターコード JP を指定します。
State or Province Name － 日本では都道府県に該当し、米国では州、中共では省です。筆者の組織は北海道にありますので、そのまま Hokkaido とします。
Locality Name － 市区町村名。筆者の組織は札幌市にありますので、そのまま Sapporo とします。 Sapporo-shi や Sapporo City でも大丈夫なようですが、個人的には好みではありません。
Organization Name － 組織名。英語表記の正式名称を記述します。
本物の認証局に対し CSR を発行する際は、ドメイン登録情報と比較したときに、ここを一字一句間違えただけでも発行を拒絶されることがあります。
Organizational Unit Name － 組織内部署名。省略可能ですが、同一組織が複数のサーバ証明書を必要とする場合、ここに何等かの情報を記述し、区別する必要があります。
Common Name － サーバの場合は、サーバのFQDN 名、電子メール認証の場合は、証明対象の電子メールアドレスを記述します。
Email Address 以降は通常、省略します。
本物の認証局に証明書発行依頼をする際は、殆どの場合、この server.csr の中身（テキストファイルです）をコピー＆ペーストする仕組みになっていると思います。
○ ＣＡ局による証明書（公開鍵）の発行
# openssl ca -out server.pem -infiles server.csrこの操作により、
Enter pass phrase for /root/BaseKernelCA/private/cakey.pem:と、プライベートＣＡを生成するときに設定したパスワードを入力後、
下記のように確認が促され、
Sign the certificate? [y/n] の問いに y で署名処理、
1 out 1 certificate requests certified, commit?[y/n] の問いに y で登録処理
がなされ、証明書ファイル server.pem が作成されます。
このファイルの中身（暗号化されたテキストファイル）が証明書本体です。
2016/07/16(土)サトーパーツの端子台 ML-1800-S1-Pxx
2017/10/12 19:31
左側が32端子あるタイプの ML-1800-S1-P32 という型番の部品、
右側が 6端子あるタイプの ML-1800-S1-P6 という型番の部品。
この端子台は、横にいくつでもレゴブロックのように連結することができます。
話には聞いていたし、どこかでそういう説明も見かけた記憶があるのですが、実際に見たことが無いし、メーカーのカタログ等に説明が無い。
と、いうことで、将来同じ疑問を持つかもしれない方々のために検証出来たので記録しておきます。
先ず、左端は簡単にカバーを外すことができます。
カバーを外すと金属端子がむき出しになります。それを覆うためのカバーですね。
ここからが重要なのですが、この端子台は最小２端子単位で簡単に分解できます。
なので、品番としては 32端子ものの ML-1800-S1-P32 が入手可能な端子数としては最大ですが、連結してあたかもひとつの大きな端子台として実装することができます。
これは 32端子ものと 6端子ものを合体させて、38端子を構成した様子です。
連結の際は、連結する側の左端のカバーを外します。
ちなみに右端は常にこんな感じになります。
連結のための凹部があります。
2016/07/15(金)プライベートＣＡの構築[FreeBSD] (1)
2017/10/12 19:30
７年半前に構築したきりですので、構築手順を忘れています・・・orz
ということで、２回の記事に分けて投稿します。いつものメモです。
具体的には、弊社のＶＰＮ接続と電子メール送受信(TLS 又は SSL を使用している場合のみ)に影響があります。新しい証明書に入れ替えて頂く必要があります。
きちんとした正式認証局のものを使うべきだろう、、という声も聞こえてきそうですが、弊社暗号化通信サービスに閉じた用途ですし、逆に汎用的に使われては困るので、弊社プライベートＣＡでの運用としています。
● 先ずは、スクリプトの修正
Google先生の検索では、Linux ベースの CentOS の事例ばかりで、FreeBSD の事例はほぼ皆無。
ですが、ファイルの置き場所以外に大差ありません。
FreeBSD の場合は、 /usr/src/crypto/openssl/apps/CA.sh を編集します：
（63行目付近）
if [ -z "$DAYS" ] ; then DAYS="-days 395" ; fi # 13 month CADAYS="-days 14610" # 40 years REQ="$OPENSSL req $SSLEAY_CONFIG"（71行目付近）
if [ -z "$CATOP" ] ; then CATOP=/root/BaseKernelCA ; fiCADAYS はＣＡの有効日数。
CATOP はＣＡにて発行する証明書の管理トップディレクトリです。
共に適宜の値を指定します。
変更したら、
# chmod +x /usr/src/crypto/openssl/apps/CA.shとして、スプリプトを実行可能状態にしておきます。
●次に /etc/ssl/openssl.cnf の修正
FreeBSD においては、opensslの設定ファイルは、/etc/ssl/openssl.cnf にあります。
このファイルは、セクション単位に設定項目がまとまっています。
セクション内の該当パラメータを以下のように修正します。
[ CA_default ] dir = /root/BaseKernelCA default_days = 7305 default_crl_days= 30 default_md = sha512 policy = policy_match [ policy_match ] countryName = match stateOrProvinceName = supplied organizationName = supplied organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] default_bits = 2048 default_md = sha512 [ req_distinguished_name ] countryName_default = JP stateOrProvinceName_default = Hokkaido 0.organizationName_default = Base Kernel Co., Ltd [ usr_cert ] basicConstraints=CA:true nsCertType = server [ v3_ca ] basicConstraints = CA:true nsCertType = sslCA, emailCAこの修正で、鍵長デフォルト 2,048bit、暗号化ハッシュ SHA-2(SHA512) に対応します。
修正したら、プライベートＣＡの構築です。（以下、一部テキスト伏字処理あり）
# /usr/src/crypto/openssl/apps/CA.sh -newca
CA certificate filename (or enter to create) Making CA certificate ... Generating a 2048 bit RSA private key ...............................................................+++ .......................................+++ writing new private key to '/root/BaseKernelCA/private/./cakey.pem' Enter PEM pass phrase: （ＣＡパスフレーズ入力） Verifying - Enter PEM pass phrase: （もう一度同じＣＡパスフレーズ入力） ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [JP]: （JP でよいのでこのままリターン） State or Province Name (full name) [Hokkaido]:（Hokkaido でよいのでこのままリターン） Locality Name (eg, city) []:Sapporo Organization Name (eg, company) [Base Kernel Co., Ltd]: Organizational Unit Name (eg, section) []:Base Net Common Name (eg, YOUR name) []:Base Kernel CA Email Address []:hoge@example.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: （このままリターン） An optional company name []: （このままリターン） Using configuration from /etc/ssl/openssl.cnf Enter pass phrase for /root/BaseKernelCA/private/./cakey.pem: Check that the request matches the signature Signature ok （以下省略）実際には続いてこんな感じで詳細が出力されます：
この例では、/root/BasekernelCA/cacert.pem にＣＡの証明書が生成されます。
この証明書は、後でサーバ証明書を発行する際に、一緒にＣＡ証明書として通知を行います。
また、この例では証明書の有効期間を 40年としていますが、こういうアホな証明書も発行できるということでご参考にどーぞ。
次の記事は、このプライベートＣＡを用いたサーバ証明書の発行方法です。
＃以前は出来なかったんです。はい。確か、2036年くらいが限界でした。
2016/06/10(金)FreeBSD自身をコンパイルしてセルフ更新してみる
2017/10/12 19:27
FreeBSD 9.3R , Athron64x2 3800+ Dual Core , DDR2 1024MByte , ATA100 80GB HDD
中古購入のため M/B 型番不明
（その２）
FreeBSD 10.1R , Athron64 3000+ , DDR 2048MByte , ATA100 80GB HDD
Asus A8V
（その２）のほうは、時間かかりすぎのような気がするのだが、、、
ＯＳのバージョンも違うし、（その２）のほうは、役割上ＬＡＮを４系統接続している状態だし、ハードウェアスペックも低いから単純な比較は出来ないけれど。。
それを差し引いてもねぇ。。です。どんなものでしょうか。
2016/06/02(木)ソフトウェア的なデバッグでは判らない不具合・・・
2017/10/12 19:26
何度チェックしてもコンピュータプログラム的には間違いがない。
だが、意図した動作にならない。
今回はディジタル信号で計測温度を取得する温度センサで、温度センサとやりとりする信号線の波形を観ないと原因が判らない。
こんなときはオシロスコープを使うのですが、どんなに安価なものでも２０万円程度はする高価な測定機器で、業務上必要なのにもかかわらず、筆者の手元には未だに無いのです。
ほんと、腹立だしいのと情けないのと交錯する心境です。
ですが、使い古しのデジタルオシロスコープセットを貸してくれた同業者が居られたので、折角ですから、問題は既にハードウェア設計変更で解決してしまったのですが、原因を追ってみました。
具体的な機種名は一応伏せておきますが、15年くらい前にノート型パソコンとセットで発売された機種のようで、帯域10MHz、サンプリング周波数 100MHz のようです。
波形が取れたら、原因はすぐわかりました。
「この温度センサーとこのハードウェアは直結できない」です。
具体的な話は専門分野な方々にしかわからない話になるので、コメントで質問していただければ、回答致します(^^)
やっぱり欲しいねぇ。。オシロスコープ。。。
今、手元にあるオシロスコープは返却しないといけませんからね。
今般の案件では問題ないけれど、無線周波数帯には使えないし、、
2016/05/09(月)今更ながら dovecot-SASL による CRAM-MD5,DIGEST-MD5,SCRAM-SHA-1 SMTP認証のサポート
2017/10/12 19:25
実はこれらの動作検証をするには、メールサーバが欠かせません。
実際に顧客に提供しているサーバはサービス停止を引き起こす障害が起きると、その対応となりますので、非公開のメールサーバをいじることになります。
ところが、手元のメールサーバ(dovecot + OpenLDAP + postfix) の構成にて、どのようにサポートしているのか（特にパスワード自体の管理方法）の情報が断片的かつごく少数しかありません。
弊社では、SMTP認証を dovecot-SASL に担当させ、電子メールアカウントやパスワードを OpenLDAP にて管理しています。
試行錯誤したところ、OpenLDAP には今まで通り平文管理(実際の格納形式は Base64)で、全種類いけることが判明しました。
こうなると簡単です。
dovecot.conf に
のような設定を行い、postfix 側は CRAM-MD5 や DIGEST-MD5 のための特別な設定は要りません。（厳密には、postfix側にセキュリティ的設定オプションがあるが、LOGIN 認証と PLAIN 認証をサポートするのであれば、デフォルトでいけるはず）
dovecot.conf に上記の設定を行ったあと再起動し、他ホストから SMTP を喋ってみると、サポートできていることが下記のように確認できます。
これで作業を進めることが出来ました。
昨今では、通信経路そのものを暗号化しようかという方向で、SMTP認証の CRAM-MD5や DIGEST-MD5 といった暗号化ハッシュ認証対応はどちらかというと消極的なＩＳＰが多いのですが、簡単にできるのが判っててサポートしな いのは手抜きですので、近日中に全ての弊社メールサーバにて対応予定としたいと考えてます。
〔2016/05/16 追記〕上記は、2016/05/11 付でサポート開始しています。
SCRAM 認証は 2010年７月に RFC5802 として規定されましたが、現在どこまでサポートされているのかはよく知りません。
SHA-1 は MD5 と並んで広く使われている暗号化ハッシュ関数の名称ですが、脆弱性が指摘されていて、SSL サーバ証明書なんかがこの影響をもろに受け、SHA-2 へ移行しています。
2016/05/08(日)今更ながら DIGEST-MD5 SMTP認証[RFC2831,RFC1321]/postfix 3.0.3 + dovecot 2.2.21
2017/10/12 19:24
DIGEST-MD5 は、実装難易度などからサーバ側でのサポート割合が低いのですが、昨年からの POP before SMTP のサポート淘汰に伴い、この状況は変化しているようです。
DIGEST認証は、RFC2831 にて、従前から先行して使われていた HTTP における DIGEST認証と互換を持たせる形で規定されています。
日本語でのまともな資料がなく、仕様そのものも少し中途半端な感があります。
よって、CRAM-MD5 と異なり、サーバ側の動作環境で挙動が異なる場合が考えられるので、ここでは当方の環境である Postfix 3.0.3 + dovecot 2.2.21 における環境であることを明示しておきます。
〔2016/05/09 追記〕 Postfix 3.1.0 + dovecot 2.2.24 でも大丈夫でした。
DIGEST-MD5 によるＳＭＴＰ認証は、以下のようなシーケンスを取ります。
[Client -> Server] AUTH DIGEST-MD5 [Server -> Client] 334 cmVhbG09ImV4YW1wbG...《以降省略》 [Client -> Server] dXNlcm5hbWU9ImluZm8uZXhhbXBsZS5jb20i...《以降省略》 [Server -> Client] 334 cnNwYXV0aD1mOTE2MGE0NzQ4MjE3MmNlMmMxNDk2NGFjZTUyN2VjOA== [Client -> Server] ZjkxNjBhNDc0ODIxNzJjZTJjMTQ5NjRhY2U1MjdlYzg= [Server -> Client] 235 Authentication successful.認証途上でサーバとやりとりするデータは、必ず Base64エンコードして送受信します。
クライアント側では、Base64 デコードして処理しなければなりません。
DIGEST-MD5 における処理の要（かなめ）は、後述するレスポンス MD5 ハッシュの生成になります。
この部分はちょっと複雑です。
（対応した案件でもＣ言語のソースコードレベルで 150行前後の規模になってしまった）
順に処理を追ってみます。
１）サーバに対し、AUTH DIGEST-MD5 コマンドを発行すると、状態コード 334 で、Base64エンコードされた文字列が返される。先ずはこれをデコードする。
・図中のBase64文字列をデコードすると、下記の文字列が得られます。これを「チャレンジ」と言います。
realm="example.com",nonce="JQMKtdgbEhMra4GdAYmAjQ==",qop="auth",charset="utf-8", algorithm="md5-sess"・これらは、パラメータとその値です。
表示都合上、改行入れていますが、実際には改行しません。
・ダブルクォーテーションで括ってある文字列については、ダブルクォーテーションを除去します。
・DIGEST-MD5 SMTP 認証の場合、qop="auth" と algorithm="md5-sess" になるので、ここではこの事例のみを扱います。
・認証フェーズで使用する文字コードは、通常 utf-8 です。
このパラメータが無い場合は、iso-8859-1 と見なさなければなりません。
しかし、通常の 7bit ASCII を使う限り、utf-8 と 7bit ASCII は同じで、文字コードとして 0x20 ～ 0x7e の間しか出てこないので全く意識していません。
２）レスポンス MD5ハッシュの生成
2-1) RFC2831 で規定する A1 データ列を生成。
RFC2831 では A1 データ列は以下のように規定されています。
A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
":", nonce-value, ":", cnonce-value, ":", authzid-value }
ここで、
username-value = info.example.com （ユーザ名を平文で）
realm-value = サーバから与えられた realm の値を複写 (example.com)
passwd = userpassword （パスワードを平文で）
nonce-value = サーバから与えられた nonce の値を複写（JQMKtdgbEhMra4GdAYmAjQ==)
cnonce-value = lWF{[QuiRj}_L[PW （クライアント側でランダム文字列を生成する）
authzid-value = サーバから与えられた authzid の値を複写
としますが、通常、authzid パラメータは与えられませんので、この場合はこうしろと規定されています。
A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
":", nonce-value, ":", cnonce-value }
具体的には、まず username-value,realm-value,passwd を ':' で連結した文字列info.example.com:example.com:userpasswordに対して、MD5ハッシュを算出し、
(ハッシュ値は以下の16バイトデータになります）
この 16バイトデータと、nonce-value と cnonce-value を ':' で連結し、連結した文字列の MD5 ハッシュを算出しておきます。
算出値は
となります。
2-2) A2 データ列の生成
RFC2831 では A2 データ列は以下のように規定されています。
A2 = { "AUTHENTICATE:", digest-uri-value }
ここで、digest-uri-value は、サーバタイプ、ホスト名、サーバ名を '/' で連結した文字列で、サーバタイプは 'smtp'、ホスト名は DNS MXレコードで検索できるFQDN、サーバ名は通常省略します。ここで、ホスト名を 'mx.example.com' とすると A2 データ列は以下のようになります。
AUTHENTICATE:smtp/mx.example.comA2 データ列に関しても MD5ハッシュ値を算出しておきます。
算出値は
となります。
2-3) response ハッシュ値の算出
RFC2831 では以下のように規定されています。
HEX( KD ( HEX(H(A1)),
{ nonce-value, ":" nc-value, ":", cnonce-value, ":",
qop-value, ":", HEX(H(A2)) }))
KD は２つの文字列を':'で連結の意、HEX はバイトデータ列を 16進文字列表記に変換、
H は、ハッシュ関数の意味で、ここでは MD5 になります。
ここで示している具体例だと、先ず
46a5d6ccc156d8ca8da970723d455d17:JQMKtdgbEhMra4GdAYmAjQ==:00000001:
lWF{[QuiRj}_L[PW:auth:e7280b0554e7e6636bd6a32ec6d5d2cf
※ 表示上、改行しているが、実際は絶対に改行を入れないこと。のような連結文字列を生成し、この連結文字列に対して MD5ハッシュ値を16進数表記したものを得ます。
算出文字列は、
729303fe19230ab4d3733dd28ab2b0b2となります。
2-4) サーバに返すレスポンスデータ列の生成
具体的には以下のような文字列を生成します。
username="info.example.com",realm="example.com",nonce="JQMKtdgbEhMra4GdAYmAjQ==",
cnonce="lWF{[QuiRj}_L[PW",nc=00000001,qop=auth,digest-uri="smtp/mx.example.com",
response=729303fe19230ab4d3733dd28ab2b0b2,charset="utf-8"
※ 表示上、改行しているが、実際は絶対に改行を入れないこと。・qop パラメータにはダブルクォーテーションを付けないことに注意してください。
・realm パラメータ、nonce パラメータ、qop パラメータは、サーバから与えられた値をそのまま返します。
・realm 値は空文字列のことがあります。この場合もそのまま空文字列を返します。
ただ、RFC2831 では「サーバのホスト名が入る」とされています。
・時折、digest-uri パラメータのホスト名に realm の値を設定するような事例を見かけますが、これは正しくありません。DNS のMX レコードに指定されるホスト名を使用すべきと観ています。RFC2831 に説明はあるのですが 、今一つ明確ではありません。。
・nc 値は、事実上 00000001 固定です。サーバ側はこれをチェックしているため、00000001 以外の値だと認証エラーになります。
上記文字列を Base64 エンコードすると、シーケンス図の中に書いてある文字列になります。この Base64エンコード文字列をサーバに返信します。これを「レスポンス」と言います。
３）認証確認
DIGEST-MD5 はこれでユーザ認証処理完了ではなく、もう一度状態コード 334 で Base64 エンコードした文字列が送られてきます。
cnNwYXV0aD1mOTE2MGE0NzQ4MjE3MmNlMmMxNDk2NGFjZTUyN2VjOA==を Base64デコードすると、
rspauth=f9160a47482172ce2c14964ace527ec8が得られます。
この32バイト長の16進数文字列は、２）レスポンス MD5ハッシュの生成 で A2 データ列を
A2 = { ":", digest-uri-value }
に変えて処理したものになります。クライアント側は、肯定応答をするために同じように A2 データ列を上記のものに変更したレスポンスハッシュ値を算出し、サーバ側に送り返します。
このあたりは、RFC2831 に明確な記載がなく、当方の環境で確認した挙動です。
このレスポンスがあって、サーバは初めて状態コード 235 を返して認証フェーズを完了します。
2016/05/07(土)今更ながら CRAM-MD5 SMTP認証[RFC2195,RFC2104,RFC1321]
2017/10/12 19:21
電子メール送信の不正利用を減らす目的の一環として、送受信時に「認証」という手続きを踏むのですが、昨今では、この部分にかつての主流であった「POP before SMTP」という方式は昨年あたりから淘汰されつつあり、各種 の「SMTP 認証」という方式になってきています。
電子メールを送受信するだけの殆どの一般ユーザなら、電子メール送受信ソフト(MUA)の設定時以外は全く意識することは無いのですが、今般は電子メール送受信の機能そのものを実装するため、仕組みを理解しないことには話 になりません。
CRAM-MD5 方式による認証手順仕様は、POP3/IMAP4向けに策定された RFC2195 で規定されており、そこで使用される HMAC-MD5 方式による暗号化ハッシュでパスワードを検証する仕組みになっています。
考え方としては、クライアント側で提示した HMAC-MD5 ハッシュ値と、サーバ側でクライアント側と同じ手順で算出した HMAC-MD5 ハッシュ値が一致することで「パスワード一致」と見做すわけです。
ここでの暗号化ハッシュの要（かなめ）は MD5 と呼ばれる方式で、任意長のデータ列から「暗号化理論に基づくハッシュ関数」により１６バイト(128bit長)のハッシュ値を作りだすもので、RFC1321 にて規定されています。
CRAM-MD5 によるＳＭＴＰ認証は、以下のようなシーケンスを取ります。
[Client -> Server] AUTH CRAM-MD5 [Server -> Client] 334 PDIwMTYwNTA4MDE1NzMyLjQ2QTRFNENGRjUyMUBteDIuYmFzZWtlcm5lbC5uZS5qcD4= [Client -> Server] aW5mby5leGFtcGxlLmNvbSAxODBjYmQwNTdjNDQxOTFhYjRkOTU2NWQ3MzA2ZmVmZg== [Server -> Client] 235 Authentication successful.ここで、
PDIwMTYwNTA4MDE1NzMyLjQ2QTRFNENGRjUyMUBteDIuYmFzZWtlcm5lbC5uZS5qcD4=
という文字列は、
<20160508015732.46A4E4CFF521@mx2.basekernel.ne.jp>という文字列を Base64エンコードしたもので、クライアント側でデコードして使用します。
この文字列は 「チャレンジ」と言います。認証毎にランダムな文字列です。
クライアント側では、SMTPサーバを利用するユーザ名と当該ユーザパスワードを暗号化したものを Base64エンコードにて送り返します。これを「レスポンス」と言います。
ここで「ユーザパスワードの暗号化」を行うのですが、この部分が CRAM-MD5 方式の核となるところです。以下に生成手順を示します：
・CRAM-MD5 は「鍵付きハッシング」と呼ばれる暗号化を使用します。
これは、HMAC と言い、RFC2104 にて規定されています。
ハッシュ関数にMD5 を使うので、HMAC-MD5 と称します。
・RFC2104 によれば、HMAC の算出は、
H(K XOR opad, H(K XOR ipad, text))となっています。
H は、ハッシュ関数を意味し、ここでは MD5 です。他に SHA1 などあります。
K は、ここでは平文で示されたパスワードです。例示として userpassword を示します。
opad は、0x5c を64バイト並べた文字列、
ipad は、0x36 を64バイト並べた文字列、
text は、サーバから送られてきた「Base64エンコードされたチャレンジ文字列」をデコードしたものです。
・Phase0 もし、パスワード文字列が 64バイトを超える場合、その文字列の MD5ハッシュ値を算出し、そのハッシュ値16バイトデータ列を以降の処理でパスワード文字列として扱う。
・Phase1 パスワード文字列 'userpassword' と ipad のバイト単位 XOR 演算
[K XOR ipad]
以下のようになります。
・Phase2 パスワード文字列 'userpassword' と opad のバイト単位 XOR 演算
[K XOR opad]
以下のようになります。
・Phase3 Phase1 で算出した 64バイトデータ列と、サーバから得たチャレンジ文字列を連結し、16バイトの MD5 ハッシュ値を得る。
・Phase4 Phase2 で算出した 64バイトデータ列と、Phase3 で得た16バイトデータ列を連結し、16バイトのハッシュ値を得る。
・Phase5 Phase4 で得たハッシュ値を１６進数文字列化する。
結果は、
180cbd057c44191ab4d9565d7306feffとなります。
・Phase6 認証対象のユーザ名と、Phase5 で得た32バイト長文字列を半角スペースで連結し、Base64 でエンコード。これをサーバへレスポンスとして送り返す。
Base64エンコード後の文字列は
aW5mby5leGFtcGxlLmNvbSAxODBjYmQwNTdjNDQxOTFhYjRkOTU2NWQ3MzA2ZmVmZg==となります。これは、
info.example.com 180cbd057c44191ab4d9565d7306feffを、そのまま Base64 エンコードしたものです。
パスワードを解析・解読可能な状態でインターネット上に送らないので、セキュリティ的には安全とされていましたが、昨今ではMD5ハッシュの脆弱性が指摘されているのと、CRAM-MD5 認証そのもので電子メール本文そのものが暗号化されるわけでは無いので、この点での脆弱性を指摘する意見があるようです。
ですが後者に関しては言及のレベルや話題の論点が全く異なる話であり、
「認証と通信そのものを混同してるよね」という印象しか個人的には持てません。
2016/03/09(水)今般の FreeBSD 9.3 のセキュリティアップデートは見送ったほうが無難
2017/10/12 19:19
今のところ、
・SSH 接続ができない（接続がクラッシュする）
・SMTP接続にて TLS 接続やるとクラッシュする
・IMAP接続にて TLS 接続やるとクラッシュする
といった情報が上がっています。
公式サイトにも FreeBSD 9.3R-p37 のアナウンスは無いようです。
運用環境的にどうしても OpenSSL 周りのパッチが必要な場合は、ports/pakkages の OpenSSL で凌ぐしかないと思います。（こちらは大丈夫という報告があがっています）
個人的には、メンテナンス工数との絡みがあり、数日様子見したほうがいいかなと考えています。
〔2016/03/10 追記〕
本日、FreeBSD 9.3R-p38 が提供されたようです。
公式サイトにも掲載されています。