はてなブックマーク

DNS 例えば「www.example.com」という文字列全体をFQDNと呼びますが、これに対して、ピリオドで区切られた「www」「example」「com」一つ一つの部分をラベルと呼びます。 字数は、ラベルの長さは1字以上63字以内（ラベル長0バイトはroot domainを表す）、__FQDNの長さは253字以内__です。255字ではなく253字なのには理由があり、これはJPNICの「ドメイン名のしくみ」というページの※1のところに解説があります。 ラベルに使える字種は、英字(A～Z)、数字(0～9)、ハイフン(-)です。ただし、ラベルの先頭文字と末尾文字は英字か数字でなければなりません。英字は大文字小文字を区別しませんので、abcとABCは同じと見なされます。 RFC的な話としては、RFC1034, RFC1035では先頭文字数字は不可でした。しかし、RFC1123 Section

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? システム障害など重大事故が発生したとき、特に製造業系の文化的色彩が濃い現場では、事後の振り返り、再発防止策の立案として「なぜなぜ分析」というのを実施しているケースがあるかと思います。いわゆる、なぜを5回繰り返すというアレです。 やっているよ、という方にお尋ねします。ぶっちゃけ、形骸化した様式美でなく実質的な意味のあるものとしてなぜなぜ分析を実施できていますか？ 私が個人的に見聞きした限りでは、トヨタを起源とすると言われる一連のなぜなぜ分析の系譜は、全部とは言わないまでも、形骸化していることが多いようです。役に立ちません。しかしそれでは困

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Redmineのインストールは、Bitnami Redmine Installer等のオールインワン型インストーラーを使うならあまり迷わなくて済みますが、そういうのを使わずに自分でやろうとすると、選択肢がいろいろあって自分で選ばなくてはならず、けっこう迷います。 本稿では、ネット上に膨大な数が公開されているRedmineインストール手順の一部を紹介していきます。 公式Redmineインストール手順 Installing Redmine http://www.redmine.org/projects/redmine/wiki/redmin

最初に算出する共通値 (g, p) はグループパラメータと呼ばれます。秘密である必要はなく、無暗号でそのまま送ります。 このグループパラメータ、従来のTLSではサーバ側でランダムに生成するものとされてきました。これが第一の流派です。 第二の流派は、 (g, p) の一覧表をあらかじめ仕様書に書いておき、使うときはその中から選んで使うというものです。この流派の代表的な存在はIPSecです。例えばIKEv1の場合、IANAの番号表に載っているうち、1, 2, 5, 14, 15, 16, 17, 18, 22, 23, 24の11種類がMODP DHのグループパラメータです。 sshの場合、IANAの番号表に載っているうち、MODP DH対応なのはdiffie-hellman-group-exchange-sha1, diffie-hellman-group-exchange-sha256,

御社におかれてはTLSスタックのテストは十分に実施しておられますか。拙稿改造する人のためのJSSEをお読みになった御社はもちろんばっちりだと思いますが、世の中では相変わらず不十分なテストと脆弱なコードが溢れかえっている今日この頃です。そんなわけで本稿のお題は証明書の検証！ 基本的な仕組みを復習する 証明書の検証というのは具体的に何をするのかを復習します。以下の説明では、TLSサーバ証明書をクライアントで検証するケースで説明します。これ以外のケース（TLSクライアント証明書をサーバ側で検証するとか、コードサイニング証明書を検証するとか）は、適宜読み替えてください。 証明書チェーン（候補）の構築 TLSのServerCertificateメッセージで、サーバ証明書がダウンロードされて来るわけですが、まずは証明書のSubjectフィールドとIssuerフィールドに注目し、下位証明書のIssuer

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? RFC229 (Google翻訳) Standard host names （標準ホスト名） RFC236 (Google翻訳) Standard host names （標準ホスト名） RFC237 (Google翻訳) NIC view of standard host names （標準ホスト名のNICビュー） RFC247 (Google翻訳) Proffered set of standard host names （標準ホスト名のセットの提供） RFC273 (Google翻訳) More on standard host

Linuxが起動すると、デーモンプロセスが順次立ち上がるわけですが、これを実際に処理する機能は、init (sysvinit) からUpstartを経てSystemdへと迷走発展してきました。そのため、Systemdへの移行を果たしたはずのUbuntu 16でも、過去のsysvinitの残骸互換性維持のためのファイルが一部残っており、ときどき混乱をもたらします。というわけで、何を今さらという感じではありますが、Systemdを取り上げたいと思います。対象LinuxディストリはUbuntu 16.04LTS！ではレッツゴー。 用語の定義 本稿では、以下の用語を使います。 一時的 何かを一時的に変更するとは、その変更は直ちに反映されるが、システムを再起動すると元に戻ってしまうということです。 恒久的 恒久的な変更とは、システムを再起動しても、変更された状態が続くということです。 現在 特に断ら

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 御社のルート証明書リスト管理は適切ですか。 ルート証明書リストはSSL/TLSのクライアントに必要なもので、ブラウザはもちろんですが、他にもIEEE802.1xでEAP-TLSとかその手のヤツを使う場合、サプリカント側で必要になります。また、メールサーバ (MTA) 同士の通信でTLSを使う場合は、送信側に必要です。また、コードサイニングやS/MIME署名の検証にも必要になります。 信頼__しない__証明書リスト（ブラックリスト）も重要で、重大な情報漏洩や不正な証明書の発行などを行った認証局は、このリストに収録することになります。 あな

SSL3.0～TLS1.2は、暗号通信が始まるまでのハンドシェイク手順がとても遅いので（それでもsshよりはだいぶマシだと思いますが）、これを多少なりとも高速化すべく、１回目のハンドシェイクは通常通りの手順（フルハンドシェイク）で行い、そこで得られるmaster_secret値をキャッシュして２回目以降は使い回すという方法があります。この２回目以降のハンドシェイク手順を「セッション再開」 (session resumption) と呼びます。 今のところ、Session IDを使う古典的な方法と、TLS Session Ticket拡張 (RFC5077, Google翻訳) を使う先進的な方法の２種類があります。 用語説明 セッションとコネクション TLSでは、セッションとコネクションは明確に別物です。 セッションの一生はmaster_secretとともにあります。フルハンドシェイクでm

以下順を追って説明します。 HelloRequest 相手にClientHelloを送信するよう促すメッセージです。送信しなくても構いません。 ClientHello ServerHello ClientHelloとServerHelloは、TLSのひとつめの肝です。後ほど説明します。 ServerCertificate サーバ証明書を送信します。中間CA証明書なども、ここで送ります。 ServerKeyExchange 鍵交換メッセージその１です。鍵交換はTLSのふたつめの肝で、これも後ほど説明します。 CertificateRequest クライアント証明書を送信するように促すメッセージです。クライアント証明書が必要な場合に送信します。何そのクライアント証明書って？と思った方は読み飛ばして構いません。 ServerHelloDone サーバからの送信終了を示すエンドマークです。 Cli

そんなわけで、「SSL3.0の拡張」は__書類上__は存在しないのです。しかしSSL3.0にもTLS1.0と同様に「後付けで拡張を追加できる余地」がありますので、TLS1.0と同じ方式の拡張をSSL3.0に後付けすることは可能で、一部では実際に行われているというわけです。 TLS1.2のcipher suiteは1.1以前と何が変わったのか。 PRFアルゴルズムとFinishedハッシュ長をcipher suiteで指定できるようになった、とRFCには書いてあるのです。しかし、これを書いている2016年5月時点で、IANAのcipher suite一覧のどこを見ても、「PRFアルゴリズム欄」や「Finishedハッシュ長さ欄」のあるcipher suiteなんて一つもありません。どうも企画倒れなんじゃないかという気がします。 ちなみに無指定の場合、PRFはP_SHA256, Finishe