X.509 - Wikipedia
暗号において、X.509とは、ITU-Tの公開鍵基盤 (PKI)の規格である。X.509は、公開鍵証明書の標準形式や証明書パス検証アルゴリズム（英語版）などを定めている。 歴史と用法[編集] X.509の第1版は、1988年7月3日にX.500標準と関連して公開された。証明書を発行するための認証局（証明機関、Certificate authority、CA）の厳密な階層構造を規定している。PGPのような、特別な認証局だけではなく誰でも署名や他人の公開鍵の真正の確認ができるweb of trustモデルと対照的である。第2版は1994年に公開され、証明書の形式はv2となったが、ほとんど使用されていない。1997年の第3版で、証明書の形式がv3となり、証明書失効リストの形式がv2となった。2000年に第4版が公開され、標準拡張フィールドが 1 つ追加されたが、証明書や証明書失効リストの形式は第
SSL・SSLサーバー証明書とは | SSL-SECURE.jp
SSL(Secure Socket Layer)とは、情報を暗号化して送る通信プロトコルのひとつです。インターネット上を流れる個人情報やクレジットカード情報などを、暗号化することによって盗聴の危険から守ることができます。WWWだけでなく、メールやFTPなどに対しても利用することができます。 SSLで使われる暗号は非常に強力です。理論上は解読可能なのですが、莫大な時間がかかり、まったく現実的ではありません。 しかし、暗号そのものを解読しなくても、実は、もっと簡単な方法で、通信内容を読み取ることが出来ます。 それは、「なりすまし」です。 あるオンラインショップに送られるカード情報を盗み読みたいとしましょう。 盗聴用のサーバを立ち上げる。このサーバは一種のプロクシーサーバで、ユーザと本物のSSLサイトとの通信をそっくり中継する仕組みになっている。したがって、ユーザには、本物と見分けがつか
SSL とは何か、証明書とは何か？
1.2. SSL とは何か、証明書とは何か？ Secure Socket Layer プロトコルは Netscape 社によって web サーバとブラウザの間の安全な通信を保証するために作り出されました。 このプロトコルは通信の一方の端、または両端の身元を保証するために、 認証局 (Certificate Authority, CA) と呼ばれる第三者を用います。 以下が簡単なその仕組みです。 ブラウザがセキュアなページ（通常 https:// ）を要求する。 その web サーバが、その証明書と一緒にその公開鍵を送る。 ブラウザはその証明書が信用が与えられた機関 （通常は信用が与えられたルート認証局(root CA)）によって発行されたものであること、 その証明書がまだ有効であって、そして、 その証明書が接続しようとしているそのサイトと関係づけられていることをチェックする。 そして、ブラ
ssh scp sftp の正しい自動実行方法
Landscape トップページ | < 前の日 2004-11-15 2004-11-17 次の日 2004-11-18 > Landscape - エンジニアのメモ 2004-11-17 ssh scp sftp の正しい自動実行方法 当サイト内を Google 検索できます * ssh scp sftp の正しい自動実行方法この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [ssh] [セキュリティ] scp と sftp について調べていると、正しい自動実行についての文書を見つけた。cron から scp や sftp を自動実行しようと考えている私には役に立つ文書だ。 - 「専用のパスフレーズなしの鍵を作って権限限定」がベスト正しいssh/scpの自動運転は ぴろ日記 http://www.banana-fish.com/~piro/20040609.
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
InfoQ: HTTPSコネクションの最初の数ミリ秒
ほとんどの人がHTTPSとSSL (Secure Sockets Layer) を結びつけて考えます。SSLは1990年代半ばにNetscape社が開発した仕組みですが、今ではこの事実はあまり正確でないかもしれません。Netscape社が市場のシェアを失うにしたがって、SSLのメンテナンスはインターネット技術タスクフォース(IETF)へ移管されました。Netscape社から移管されて以降の初めてバージョンはTransport Layer Security (TLS)1.0と名付けられ、1999年1月にリリースされました。TLSが使われだして10年も経っているので、純粋な"SSL"のトラフィックを見ることはほとんどありません。 Client Hello TLSはすべてのトラフィックを異なるタイプの"レコード"で包みます。ブラウザが出す先頭のバイト値は16進数表記で0x16 = 22。 これは
中国によるソースコード強制開示報道に踊らされるのはまだ早い - A Successful Failure
読売新聞が中国、ＩＴソースコード強制開示強行へ…国際問題化の懸念と報じたことから、「IT製品のソースコードの開示が強要される」「日本企業は中国から撤退すべきだ」といった極端な拒否反応があちこちで見られる（はてなブックマーク、痛いニュース）。 しかし、実際読売新聞の記事は少々拡大解釈をしている。スラッシュドットのエントリを参考に、もう少し詳しく見てみよう。元ソースは中国部分情報処理のセキュリティ製品に関する強制認証実施の公告であり、昨年12月に読売新聞により正確な解説記事が掲載されている。これを読むと、多くの人が誤解している点が浮かび上がってくる。 【注】本エントリのスコープは中国の強制認証制度に関する正確な情報を伝え、多くの人が誤解している点を正す点にある。中国が信用できるかできないか、ソースコードの流用がなされないか、という懸念に関する議論はスコープ外である*1。 まず第一に、審査対象と
クリックジャッキングってこうですか？ わかりません
↑ この透過されているiframeは、ブラウザの最前面に配置されています ※はてなにログインしていると、どのようにボタンが被っているのかわかりやすくなります
第7回■文字エンコーディングが生み出すぜい弱性を知る
文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。（1）文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と，（2）文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング（1）――冗長なUTF-8符号化問題 まず，（1）の不正な文字エンコーディングの代表として，冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン（表1に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー
PPDGen : 疑似個人情報ジェネレータ
PPDGen：疑似個人情報ジェネレータは、テストデータ生成・管理ツールです。 本物の個人情報にそっくりな架空の個人情報『疑似個人情報』を生成するだけでなく、 実際の個人情報（本番データ）を読み込んで、住所や氏名を置き換え、安全なデータに変換することもできます。 PPDGen：疑似個人情報ジェネレータはフリーソフトです。 無料・無制限でお使いいただけます。 疑似個人情報の例 疑似個人情報とは、本物そっくりながら架空の個人情報です。 姓名、住所、電話番号、生年月日、銀行口座番号、クレジットカード番号などの項目があります。 システム開発において、本物の個人情報をテストに使うと、個人情報が漏洩する危険性があります。 特に、Winnyなどのファイル共有ソフトによる漏洩は、システム開発を受託した開発会社の社員が テストデータを自宅に持ち帰ることで多く発生しています。 本物の個人情報の代わりに、疑似個人
「プロフ」の何が問題か
MIAUでネットリテラシー読本をリリースして、いろいろな方のご意見を伺っている（MIAUが“ネットの教科書”冒頭部公開 CCライセンスで）。ネットでは何をどうやっても必ず叩く人というのが出現するのが常だが、実際の教育現場の方々からは高い評価をいただいている。それもそのはずで、実はあの読本を作る前には、多くの先生方からかなり時間をかけてヒアリングを行なってきたのである。 リリース後もさらにヒアリングを続けているが、次のテーマとして取り上げて欲しいもののトップが、どうも「プロフ」のようだ。「学校裏サイト」も問題の1つであるが、そもそも「学校裏サイト」というサイトがあるわけではない。個人ブログのコメント欄や掲示板が、「裏化」するものである。プロフにも掲示板機能があるので、そこもまた「裏化」する可能性がある。裏サイトは、とらえどころのないもっと広汎な問題だ。 一方で「プロフ」を問題視する声は、比較
知っておきたいSSLサーバ証明書の取得まで - livedoor ディレクター Blog(ブログ)
こんにちわ。モバイルディレクターの飯田瞬です。 ウェブディレクターの中には、SSL サーバ証明書が必要なウェブサイトの構築を担当した人は少なくないと思います。 今回は SSL サーバ証明書を取得するにあたり、ディレクターが知っておいた方が幸せになれる必要最低限な事項を簡潔にまとめてみました。 割愛している部分もかなりありますが、詳細まで突っ込むと1エントリーでは収まりきらないため、何卒ご理解いただければと思います... 【01】SSLサーバ証明書って何だろう? SSL を一言でまとめると、住所やカード番号などを暗号化して第三者が傍受してもデータの改ざんや盗聴を防ぐといった技術が SSL です。 SSL サーバ証明書というのは、その SSL の暗号化技術を利用するサーバの身元を、第三者である認証局が保証することを示すものです。この証明書の中には SSL でクライアントとサーバ間の通信を暗号化
高木浩光＠自宅の日記 - 日本のインターネットが終了する日
■ 日本のインターネットが終了する日 （注記：この日記は、6月8日に書き始めたのをようやく書き上げたものである。そのため、考察は基本的に6月8日の時点でのものであり、その後明らかになったことについては脚注でいくつか補足した。） 終わりの始まり 今年3月31日、NTTドコモのiモードが、契約者固有ID（個体識別番号）を全てのWebサーバに確認なしに自動通知するようになった*1。このことは施行1か月前にNTTドコモから予告されていた。 重要なお知らせ:『iモードID』の提供開始について, NTTドコモ, 2008年2月28日 ドコモは、お客様の利便性・満足の向上と、「iモード(R)」対応サイトの機能拡充を図るため、iモード上で閲覧可能な全てのサイトへの提供を可能としたユーザID『iモードID』（以下、iモードID）機能を提供いたします。 （略） ■お客様ご利用上の注意 ・iモードID通知設定は
盗難されたキャッシュカードを引き出されにくくするための簡単な方法 - 空中の杜
今日、某銀行で「引き出し中の画面で、キャッシュローンの広告出すな！ しかも『ご案内しますか』で『いいえ』か『はい』を選択しないと先に進めないタイプの！ 鬱陶しいわ！」とか思いながらATMの操作をしていたわけですが、ふと前を見てみると、暗証番号の設定の注意みたいなことが書いてありました。それは、類推できる暗証番号だとカードを盗まれて引き出される恐れがあるから、わかりにくい番号にしておけというタイプのもの。 たしかに財布ごとキャッシュカードを盗まれ、その中の免許に書かれている暗証番号を入力され、金を引き出されるということがけっこうあるようです。もっとやっかいなのは身内や知り合いで、そういう人に盗難された場合、暗証番号（誕生日）などのデータが判明しているので、引き出しも安易にされてしまう場合もあります。それで「誕生日などとは関係ないものに」と銀行も呼びかけているのですが、くくりつけられる数字でな
Javascriptで数値文字参照の値を求める方法
具体的なJavascriptのコードは、このページのHTMLソースを見ていただいければ分かりますが、charCodeAtメソッドを用います。HTMLのヘッダー部分に、左のようにConvertという自作関数を定義しています。意外と簡単な仕組みになっています。 Javascriptの関数定義の部分は、左のテキストボックスの中に記したコードのようになります。参考にしてください。 もう一つの方法は、特定文字のUnicode（ユニコード）値（16進数）を10進数表記にすることです。Unicode値は、WindowsのIME 2002なら「ツール→IMEパッド→文字一覧」を選びます。そこで、左端の「シフト JIS」という文字の横の三角印をクリックして「unicode」を選択します。これで、Unicodeの文字一覧が表示されます。 上の例のように、「考」という漢字は、unicodeは「0x8003」（「
高木浩光＠自宅の日記 - 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと
■ 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと 「コンピュータセキュリティを基礎から」というと、暗号の解説、特に共通鍵暗号と公開鍵暗号の違いからなどといった解説をよく目にする。昔は専門の方によって注意深く書かれていたのに対し、ここ何年かはひどい状況になっている。先月、宮崎で開かれたSCIS 2008の席でも暗号研究者の方々との雑談でそういう話になった。私は暗号は専門でないのでその話題は迂闊に書けないできたが、このところの巷の誤り解説の氾濫ぶりは目に余るものがある。 最もひどく蔓延っていてしばらく消えそうにない間違い解説の典型例は次だ。 「公開鍵で暗号化したものを秘密鍵で復号するのと同様に、秘密鍵で暗号化したものを公開鍵で復号できるようになっている。」 事例1: 日本ベリサイン株式会社による公開鍵暗号方式の解説 このような共通鍵暗号方式の問題点を解決する暗号方式が、公開鍵暗号方式
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2to3を使ってコードをPython 3に移植する - Dive Into Python 3 日本語版
IDEA * IDEA
Reverse engineering Charange 2008 -イベント情報：NetAgent Co., Ltd.
必修講座100 ＜ ITpro SkillUP ： ITpro