apache や nginx の設定をしたことがあれば以下の様な行を見たことがある人も多いのではないでしょうか。(※ 下記は nginx の設定。apache の場合は SSLCipherSuite です。) ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; これが暗号スイートを指定している箇所です。そしてこの部分、わけのわからない文字列の羅列なのですごく取っつきにくくて何を指定したらいいかわからないので、コピペしてしまう人も多いんじゃないでしょうか。かくいう私も数年前に趣味で TLS 対応の Web サービスを作った時はコピペで済ませていました。この暗号スイートは、以下のような OpenSSL のコマンドを使って対応している一覧を見ることができます。 $ openssl ciphers -v AES128-SH
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
単純ではない、最新「クロスサイトスクリプティング」事情：HTML5時代の「新しいセキュリティ・エチケット」（2）（1/3 ページ） 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。第1回目は、Webアプリケーションセキュリティの境界条件であるオリジンという概念について説明しました。 現在のWebブラウザーでは、同一オリジンのリソースは同じ保護範囲にあるものとし、オリジンを超えたアクセスについてはリソースの提供元が明示的に許可しない限りはアクセスできないという、「同一オリジンポリシー（Same-Origin Policy）」に従ってリソースを保護しています。 その保護範囲であるオリジンを超え、リソースにアクセスする攻撃の代表事例であるクロスサイトスクリプティング（XSS）について、今回、および次回の2回に分け、HTML5においてより高度化された攻撃と、その対策を説明しま
当協会では、インターネット上の個人情報保護を目的とした調査研究を行っております。インターネットにおける個人情報保護技術としては、ウェブ技術標準化団体であるW3Cが策定したP3P(Platform for Privacy Preferences)があります。 このページではこのような個人情報保護に関連する情報やサービスの提供を行っております。 お知らせ [2005年11月] トップページをXHTML対応でリニューアルしました。 [2004年3月] 「関連情報」にパンフレット「安心して個人情報を取り扱うためには」のリンクを追加しました。 [2003年10月] 「関連情報」に「個人情報保護に関する法律」のリンクを追加しました。 [2002年10月] 「関連情報」、「その他のリンク」にレポート等の情報を追加・更新しました。 [2002年10月] P3Pポリシー検証サーバ「サイトビューロ」を実験終了
IE8 で導入される予定の Click Jacking 対策デモ さくっと作ってみた（DENY の例）。詳細は IEBlog の記事を参照[1]。要するに HTTP レスポンスヘッダか meta 要素を使って X-FRAME-OPTIONS を送出し、その値として DENY ないし SAMEORIGIN を指定する。 重要なのは、X-FRAME-OPTIONS を指定するのが frame/iframe 要素によって呼び出される側のコンテンツである、ということだ。つまり、この X-FRAME-OPTIONS が指定するのは、「自身が frame/iframe 要素によって他のコンテンツから参照されている場合、frame/iframe 要素へのロードを許可するか否か」なのだ。 次に IEBlog に書かれた仕様をまとめてみた（私が英語の解釈をミスっている可能性があるので注意）。 DENY fr
■ オレオレ証明書の区分 改訂版 はてなキーワードに「オレオレ証明書」の項目ができていた。 ここにある冒頭の「(特にPKI上不適切な場面で使われる)自己署名証明書。」 という定義は私の定義とは異なる。自己署名とは限らないし、 不適切な場面とも限らないからだ。 そのためその下にある第一種〜第五種の区分の記述と矛盾が生じている。 私の定義では、クライアント側で認証パスを辿れない（検証できない）証明書 のすべてをオレオレ証明書としている。それは、サーバ側の設定ミスかもしれ ないし、設定が正しくても今まさに通信路上で攻撃を受けているのかもしれな い。証明書の発行の意図に関係なく、クライアントから見れば等しく「オレオ レ」と言っているようにしか見えない。 攻撃を受けている場合を除いて、クライアント側でオレオレ証明書となる場合 の、その原因別の区分を9月3日の注釈で書 いていた。他に第六種もあったので
【追記】 たくさんのブクマコメントありがとうございました。たしかに悪用される可能性の方が高いかもしれませんね・・・。こちらもあわせてご覧ください。 » はてなブックマーク – 「現在セキュアな通信をしています」と明示的に表示するインターフェース SSL通信をしているかどうかはわかりにくいですよね。お買い物をしているときにURL（https）やブラウザの鍵マークを確認する人も多いのでは。 しかし、詳しくない人にはよくわからないかもしれないので次のようなインターフェースも悪くないかもです。 ↑ 画面上部に「セキュアなページです」と表示。 悪意のある使い方は論外ですが、こうしたちょっとした工夫でお買い物がすすむ、ということもあるかもしれないですね。 Akohaのショッピングサイトで実装されていましたよ。 » Welcome ~ Akoha Store
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
