最新 追記

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1762   昨日: 1295

2007年04月07日

JPCERTも糞、ベリサインも糞、マイクロソフトは糞、トレンドマイクロも糞、フィッシング対策解説は糞ばかり

一昨年7月のWASフォーラムのイベントで話した以下の件。

  • セキュアなWebアプリ実現のために本来やるべきことは? - 高木浩光氏, MYCOM PCWEB, 2005年7月12日

    誤った解説や必要以上に危機感を煽る報道に不満

    (略)アドレスバーがきちんと表示されていてURLが確認できる状態になった上で、SSLの鍵マークが表示され、ブラウザがSSL証明書に関する警告画面を出さなければ、いちいち証明書を開かなくても安全性は確認できるのに、未だに「安全性を確認するには証明書を開く必要がある」といった誤った解説が(それもセキュリティに詳しいとされている記者の記事の中で)なされている」と指摘。その上で「キーワードジャーナリズムは、よりユーザにとって手間のかからない対策手法を紹介すべきだし、Webサイトを運営する事業者側も「ここまでは我々の責任だが、これ以上はユーザ側の責任」という分界点を明確にすべき」と参加者に呼びかけた。

これは何のことを言っていたかというと、ズバリ以下の記事のことだ。

  • 「悪質サイトへ勝手にリダイレクト」――DNSキャッシュ・ポイズニング攻撃の現状と対策(下), 勝村幸博, 日経IT Pro記者の眼, 2005年4月13日

    現在大きな話題になっている「フィッシング」。フィッシングでは偽メールでユーザーを偽サイトへ誘導する。専門家たちが危惧するのは,この偽メールの代わりに,DNSキャッシュ・ポイズニング攻撃を使われることだ。これは,「ファーミング」とも呼ばれる(略)

    ユーザーができるDNSキャッシュ・ポイズニング対策はあるだろうか。SANSが公表した事例のように,全く異なるサイトへリダイレクトされればユーザーも異常に気付くだろう。だが,本物そっくりの偽サイトへリダイレクトされた場合には「気が付きにくいだろう」(JPCERT/CCの山賀氏)。「極論すれ ば,『HTTPのページは信用しない。HTTPS(SSL)のページでは,ページごとにデジタル証明書を開いて確認する』ということが,ユーザーの対策となる。だが,これらは理想論。ユーザーに実施させるのは不可能だ」(同氏)。「DNSキャッシュ・ポイズニング対策」という観点では,管理者に任せるほか ないようだ。

「証明書を開いて確認する」なんてことは無用な話だ。

DNS poisoning攻撃されている可能性のある状況であっても、https:// のページでオレオレ証明書警告が出ていないなら、それは本物サーバ(アドレスバーに表示されたURLのドメインの本物サーバ)である。だって、サーバ運営者しかそのドメイン用の証明書を持っていないことを認証局が保証しているんだから*1。「証明書を開いて確認する」って、いったいどこを確認するというの?

無用なことを必要と言い、「理想論で、不可能」などと言う。出鱈目言うな、という話だった。

同じ話はその後、一昨年12月にJNSAの「Network Security Forum 2005」でも話した。

  • シンプルな安全確認ルールとそれに則ったサイト作りを〜産総研高木氏講演, INTERNET Watch, 2005年12月2日

    不要な対策を利用者に要求してはいけない

    高木氏は、利用者に対して不要な対策を要求している例もあるとして、DNSキャッシュポイズニングに関して書かれた記事を取り上げた。「この記事では JPCERT/CCの山賀氏の発言として、HTTPSのページでは、ページごとにデジタル証明書を開いて確認することがユーザーの対策だと書かれているが、これは間違い」として、「デジタル証明書は、PKIの仕組みにより自動的に本物であるか偽者であるかを確認できるところにミソがあるのであって、目で確認するものではない。それよりも、(デジタル証明書の異常を示す)警告が出るか出ないだけで判断すればよいこと」と指摘した。

    また、マイクロソフトの個人向けセキュリティ解説ページについて、フィッシング詐欺に関する記述を取り上げ、「ここでは『Webサイトでも、アドレスバーに正しいアドレスが表示されているように偽装することも可能です』と書いてあるが、それは修正したのではないか」と指摘した。「確かに、アドレスバーの上に枠のないウィンドウをかぶせて別のアドレスを表示させるという手口が流行ったが、それはWindows XP SP2で修正されている。せっかくこうしたことをやっているのに、信用できませんと自分で言ってしまってどうするのか」と述べ、仕様と脆弱性はきちんと区別しなければ消費者に正しいことを伝えられないと主張した。

2つ目の話は、ズバリこれのことだ。今も当時のまま掲載されているようだ。

自分で「IEは糞だからどうしようもない」て言ってどうすんの? ちゃんと直したのに? なんでこんなに馬鹿なの? 言うべきことは、サポート期限切れのWindowsを使わないでくださいってことでしょ? あんたが言わなくてどうすんの?

とまあ、そういう話を講演でしたのだった。それから1年以上が経ったが、現状はどうか。

先月23日、JPCERT/CCが、「ひとくちメモ」と同時に「イラストでわかるセキュリティ」なるものを公開した。

その内容がひどい。

  • イラストでわかるセキュリティ ― 情報セキュリティの脅威に対する対策, JPCERT/CC

    7.安全であることが確認できないWebサイトにはアクセスしない

    安全であることが確認できないWebサイトにはアクセスしないようにしましょう。Webサイトで個人情報や機密情報などを入力する際には、以下の点を確かめるようにしてください。

    • SSL (https) による経路の暗号化が行なわれているか確認

      個人情報やクレジットカード番号などの機密情報を送信するページで、SSLサーバ証明書がない、また通信経路の暗号化が行なわれていないサイトは利用しないようにしましょう。SSLによる暗号化通信が行われているかどうかは、URLの文字列が https:// で始まっているか、Webブラウザの右下のバーに鍵マークが表示されているか、などで判断します。

    • SSLサーバ証明書の内容に問題がないか確認

      証明書自体が適切な認証局から発行されているか確認してください。自己署名証明書や身元のはっきりしない認証局によって発行された証明書が使用されているサイトを利用する際は注意してください。

SSLが正しく使われていることの確認だけして、何だって言うの? これはいったい何の解説なの?*2

イラストの画面には「激安ソフト ダウンロード」と描かれているが、その意味での「安全であること」の確認が、SSLの確認でいいわけがないじゃないか。

どうしてこうどいつもこいつも、こんな素人ばかりにセキュリティ解説を書かせるの? 解説が間違ってることの重大性、読む人への影響、あんたら何だと思ってるの? 金さえあればデザイン業者に投げてハイ完成、ですか?

フィッシング対策の解説もひどい。

  • イラストでわかるセキュリティ ― 情報セキュリティインシデントへの対応 ― オンライン詐欺の被害にあわないようにするには, JPCERT/CC

    フィッシング

    銀行などのサイトであると詐称して、Web のフォームなどから入力された口座番号やキャッシュカードの暗証番号といった個人情報を盗み取るものです。既に国内での被害も報告されており、注意が必要です。

    フィッシングの被害を受けないためには、ある特定の Web サイトにアクセスするように促してきたメールが本当に送信元とされる組織から送られてきたものなのかを、送信元とされる組織に直接確認することが必要です。その場合、連絡先の情報として、送られてきた電子メールや Web サイトに掲載された情報を用いてはいけません。契約時に取り交わした書類など、確実に対象となる組織から送付されたものであることが確認できる資料に掲載された情報を用いてください。

たったこれだけ。ごちゃごちゃ書いてあるが結局のところ何も対策を紹介していない。

続く部分は致命的に誤ったことが書かれている。

フィッシングと並べて書かれている流れからすると、これはフィッシング以外の偽ショッピングサイト、つまり、存在自体が架空の店舗の詐欺の話だろう。それなのに、SSLで詐欺が見抜けるっていうの?

先週の日記「銀行のフィッシング解説がなかなか正しくならない」で、全国銀行協会の解説「フィッシング詐欺の防止策」の内容が間違っていることを書いたが、これは誰のせいなんだろう?

検索して探してみたところ、日本ベリサインの解説が見つかった。

  • 電子証明書とPKI入門 ― 第11話:SSL暗号化通信が行われているかを確認するには?, 日本ベリサイン

    サーバ証明書を確認するには?

    「https://〜」となっているページで表示された「錠マーク」をダブルクリックすると、電子証明書を確認することができます。

    この画面が表示されたら、次の3点を確認してください。
    発行先 アクセスしたサイトのURLと、ドメイン名が一致していること。
    発行者 信頼できる認証局が記載されていること。
    有効期間 期限切れになっていないこと

なんで、そんなことを人間様が確認しなきゃなんないの? それはSSLクライアント(Webブラウザ)が自動的に機械的に検証するところだろうーが! だからこそのPKIなんじゃないの。

どうしてこんなことになっちゃってるわけ? PKIのプロ中のプロであるはずのベリサインでさえこの体たらく。*3

他にも通りすがりに見かけたトレンドマイクロの解説も糞だった。

  • これだけは知っておこう! フィッシング詐欺サイトを見分けるポイント, トレンドマイクロ

    2 ブラウザのアドレス欄を確認

    通常、前述のSSLによる情報の暗号化を行っているWebサイトのアドレスは、「https:// 〜」で始まります。フィッシング詐欺サイトの中には、アドレスが「http://xxx.xxx.xxx.xxx/〜」(xは0〜9までの数字=IPアドレス)と表示されるものがあります。IPアドレスが入っているWebサイトのすべてがフィッシング詐欺サイトというわけではありませんが、個人情報の入力には注意が必要です。(※2)

    ※2 パソコンをウイルス感染させ、正しいアドレスを表示して安心させる場合もあります(実際には表示と異なるニセのWebサイトに接続している)。

    3 Webサイトのプロパティ(情報) を確認 Internet Explorerの場合、ツールバーの「ファイル」から「プロパティ」を選んで、そのWebサイトの本当のアドレスを確認することができます。アドレス欄に表示されているものと「プロパティ」に掲載されているアドレスが同じであれば、本物のWebサイトだと判断できます。

出鱈目。もうむちゃくちゃ。数値IPアドレスじゃなきゃ本物なのか? アドレスバーとプロパティが同じなら本物なのか?

こんなのさっさと消せよ。害が広がる。

  • セキュリティ教室 ― フィッシング対策, トレンドマイクロ

    4 そのページの「ソース」を確認する

    個人情報を入力する際に、ブラウザのソースを見て、そのページが本物かどうかを確認する方法があります。

    Internet Explorerの場合、ツールバーの[表示]→[ソース]で、ブラウザのソースが表示できます。このソースの中から、フォームの送信先に指定されているURLを確認して、本物かどうかを判断することが可能です。

本気で言ってるのか?


とまあ、このくらい言えば読んでくれるかな……。

*1 こういうとき、ドメイン保有者でないところに証明書を発行してしまうタコ認証局が存在することを仮定して云々言う人がいるが、その場合は、どんなに証明書を目で調べても無駄だ。なぜなら、入力欄のある画面で証明書を調べて、まともな認証局発行であるのを確認しても、入力データの送信先である次のアクセスのSSL接続は、タコ認証局発行の証明書(攻撃者が不正に手に入れている)でつながってしまう可能性がある。画面が表示されてから調べても後の祭りだ(データは既に送信済み)。だから、認証局がどこかを調べても意味がない。そのような仮定をこの議論に持ち出すのが誤りである。(そのような認証局は排除する以外にない。)

*2 加えて言えば、「自己署名証明書」なんてここで書いても読者に意味がわかるわけがないし、「身元のはっきりしない認証局によって発行された証明書が使用されている」というのがどういう場合のことを言っているのか説明しなきゃ何の解説にもならないし、「利用する際は注意してください」ってどう注意するって話? まったくどうしようもない糞解説。

*3 これ書いた人は、「シール」の話と混同してるんじゃないか? 「ベリサインセキュアドシール」とか言っているが、こんなものはPKIでも何でもない、何ら技術的裏づけのないものだから、偽サイト上にいくらでも表示できる。だから、あれこれ一致しているか目で確認するように注意書きされている。そういうどうでもいい話と混同してるんじゃないの? そもそもこういう安全に使いこなせないシールなんて、やめてしまうのがPKIのプロたる会社の社会的責任だと思うが。

本日のリンク元 TrackBacks(100)

2007年04月08日

常陽銀行のリニューアルに期待したがその期待は裏切られた

2年以上前に「フィッシング防止のため地方銀行はこうするべき」という日記を書いていた。

常陽銀行のドメイン名は joyobank.co.jp だが、図1では www2.paweb.anser.or.jp/BS?CCT0080=0130 であることを確認せよと言っているし、千葉銀行のドメイン名は chibabank.co.jp だが、図2では www2.ib-center.gr.jp となっていることを確認せよと言っている。難儀な話だ。

これは、自前でインターネットバンキングシステムを構築できない地方銀行が、 NTTデータの「金融ANSERシステムサービス(anser.or.jp)」ないし、日立の「日立インターネットバンキングセンター(ib-center.gr.jp)」もしくは、日本IBMの「地銀サイバープロジェクト(cyber-biz.ne.jp)」のASPサービスを使っているためだ。

フィッシング詐欺に騙されないために、地銀の預金者たちは、これらのドメイン名を覚えていないといけない。いずれも、NTTデータ、日立、日本IBMといった、信頼ある企業名の含まれていない名前で、anser だの ib-center だの cyber-biz だのよくわからない名前で覚えにくいうえ、どれも怪しげな名前にさえ見えるし、gr.jp なんかは誰でも取れるドメイン名というところも危うい。

この問題は現実的な解決策がある。 Webバグ広告業者がやっていることを真似ればよいのだ。 (略)

つまり、ログイン画面のコンピュータはこれまでどおり、NTTデータ、日立、日本IBMに置いたまま、anser.joyobank.co.jp や ib-center.chibabank.co.jp というホスト名でアクセスできるようにすればよい。

サーバ証明書はどうするかというと、anser.joyobank.co.jp なので常陽銀行の名前で常陽銀行の社員が証明書を取得したうえ、NTTデータが運営する ANSERシステムのサーバに入れてもらう。

フィッシング防止のため地方銀行はこうするべき, 2005年2月20日の日記

地方銀行というと私は、つくば市に移り住んだ際に口座を作って以来、常陽銀行を利用している。その常陽銀行から去年、インターネットバンキングのシステムを大幅にリニューアルするという通知が来ていた。私は、今度こそ、joyobank.co.jp のドメイン名の上にログイン画面が構築されるのかもしれないと期待した。

しかしその期待は裏切られた。

新たに開始された常陽銀行のインターネットバンキングシステムは、「chance.co.jp」などという、ますます得体の知れない怪しげなドメイン名の上に作られていた(図1)。

常陽銀行の新システムのログイン画面
図1: 常陽銀行の新システムのログイン画面

SSLのサーバ証明書の内容を調べてみると、図2のように、「Regional Banks and Information Technology Solution Co. Ltd.」などと耳慣れない会社名が出てくる。

常陽銀行のログイン画面のサーバ証明書の内容
図2: 常陽銀行のログイン画面のサーバ証明書の内容

NTTとか日立とかIBMといった耳慣れた名称はどこにもない。そこで、whoisでこのドメインの登録者を調べてみたところ、次の通りだった。

[組織名]                     株式会社 地銀ITソリューション
[Organization]               Regional Banks and Information Technology Solution Co., Ltd.
[登録年月日]                 2006/04/27

「"地銀ITソリューション"」でGoogle検索してみると、どうやら、日本IBMが2004年に設立した子会社らしいということがどうにかわかる。

たしかにドメイン名の登録も 2006年4月と、つい最近のことだ。「chance.co.jp」などという、あまりにもありきたりな単語のドメイン名が2006年になってよく取れたもんだと思ったが、archive.orgで調べてみると、かつては別のところが使用していたドメイン名らしい。

それにしても、こんな、会社名とも無関係な名前で、周知もされていないありきたりな名前のドメイン名を、銀行のフロントエンドに使うなどというのは、センスを疑う。

どうして、joyobank.co.jp ドメインの上に作らないのか?

既存のシステムを修繕するのは大変とか、そういうことならまだわかる。だが、最近になって新しいシステムを作り上げたわけだから、これはできたはずのものだろう。

失望した。@ITの記事によると、今後、百十四銀行、十六銀行、南都銀行がこの巻き添えを食らうらしい。

  • 常陽銀行で「地銀共同化システム」の第一弾システムが稼働, @IT NewsFlash, 2007年1月6日

    同プロジェクトは、三菱東京UFJ銀行の現行システムをベースとしたシステムを常陽銀行、百十四銀行、十六銀行、南都銀行で共同化するもので、 2003年から検討・開発を進めてきた。今回の常陽銀行を皮切りに、今後、百十四銀行、十六銀行、南都銀行も順次、地銀共同化システムに移行する予定。(略)

    日本IBMは同システムの開発・保守・運用の委託を受け、コンピュータは同社センターに設置。開発・保守・運用の実務は、日本IBM子会社の地銀ITソリューションが行っている。

もしかして、何か実現できない技術的な理由があるのだろうか? 銀行側がDNSに登録するだけだと思うのだが。

そういえば、少し前に、地銀のいくつかが自社ドメインに移行しているようだとの話を小耳に挟んだことがあったが、本当かどうか調べてなかった。全国地方銀行協会のサイトに掲載されている地銀リストをたよりに、各銀行のログイン画面(個人向けインターネットバンキングサービス)のドメイン名がどうなっているいかざっと調べてみると、現時点で、自社ドメインを使用しているのは以下の9行のみのようだ。

これらが、anser.or.jp や ib-center.gr.jp や cyber-biz.ne.jp などから移行したものなのか、それとも元からこうだったのかはわからない。

これらの各行では、初めてサイトを訪れた場合(およびドメイン名がうろ覚えの場合)であっても、ログイン画面でサーバ証明書の内容を見ることで、銀行の会社名(ただし英文)を確認することができる。

参考: 安全なWebサイト利用の鉄則サイト運営者の鉄則 「サービス提供者が保有するドメイン名を使う」

本日のリンク元 TrackBacks(100)

2007年04月15日

IE 7の普及でサーバ証明書失効によるトラブルが表面化する

Internet Explorer 6まででは、「サーバー証明書の取り消しを確認する」の設定(「インターネットオプション」の「詳細設定」タブのところにある)が、デフォルトでオフになっていたが、IE 7で、これがデフォルトでオンになった。

  • Internet Explorer 7 における HTTPS セキュリティの強化点, Microsoft

    Windows Vista にパフォーマンス強化および OCSP プロトコルのサポートが追加されたことで、Windows Vista 上で実行される IE7 では既定で失効状態のチェックが有効になり、セキュリティが強化されます。

この影響が出始めているようだ。

  • QNo.2856522 証明書エラーがでてしまいます・・, 2007年3月22日

    ビスタに変えてから、XPの時に普通に入れていたサイトにログイン出来なくなりました。(略)

    このサイトの管理会社に問い合わせても、異常がないのでそちらのPCの問題だと思うと言われてしまいました。(略)

    下記のURLが問題のサイトなんですが、会員ログイン、会員登録、お問い合わせ、いずれも「この Web サイトのセキュリティ証明書には問題があります。この組織の証明書は失効しています。」等と表示されてしまいます・・
    http://www.gootencash.jp/top.html

当該サイトの当該ページにIE 7でアクセスしてみると、たしかに図1のようになる*1

サーバ証明書が失効しているときのIE 7の画面
図1: サーバ証明書が失効しているときのIE 7での表示の例

オレオレ証明書の場合の画面と異なり、「このサイトの閲覧を続行する」のリンクが用意されていない。

今後、サイト運営者が「失効確認の設定をオフにしてください」などと言い出すことが懸念される。

サーバ証明書が失効とされるのはどういう場合になのだろうか。また、どのくらい起きているのだろうか。

検索してみたところ、過去の事例が見つかった。

このときは、IE 6なので、この方は自力で「サーバー証明書の取り消しを確認する」の設定をオンにしていたのだろう。そういうユーザは少ないだろうから、従来はトラブルが表面化しにくかったと思われる。

ちなみに、IE 6で「サーバー証明書の取り消しを確認する」の設定をオンにしている場合に出る警告はこうだ(図2)。

サーバ証明書が失効しているときのIE 6での警告
図2: サーバ証明書が失効しているときのIE 6での警告

とても冷淡な警告だ。

オレオレ証明書の場合の警告では続行ができるのに、失効証明書の場合は続行を許さないというのには首をかしげる。詐欺師がこうなるとわかっていてわざわざ失効証明書を使うわけがないし、失効証明書の秘密鍵を入手するよりオレオレ証明書を自作するほうがはるかに容易なのに。

ちなみに、オレオレ証明書が使われているときにIE 7が出す警告については、セキュリティベンダーであるトレンドマイクロが解説してくれている。

  • 製品Q&A Internet Explorer 7の使用時におけるhttpsを用いたWebコンソールへのアクセスについて, トレンドマイクロ, 2007年1月22日
    トレンドマイクロの解説ページの画面

    製品のWebコンソールにアクセスすると「このWEBサイトのセキュリティ証明書には問題があります。」と証明書エラーのページが表示されます。

    「このサイトの閲覧を続行する(推奨されません)」をクリックすると、下図のようにWebコンソールのログイン画面が表示されます。

    Internet Explorer のアドレスバーの隣に「証明書のエラー」が表示されますが、以下の製品Q&Aにおいて対応している製品については問題なくご使用いただけます。

「問題なく」ねえ。やれやれ。

*1 インターネットオプションの詳細設定では「取り消し」という用語なのに、エラー画面では「失効」と、用語が食い違っている。IE 6では「取り消し」で統一されていた。詳細設定の方の用語を「失効」に変えるべきだろう。

本日のリンク元 TrackBacks(67)

2007年04月19日

APOP終焉で「POP over オレオレSSL」の撲滅運動が可能に

というわけで、POP over SSLの特需が見込まれるところだが、MUAのサポート状況はどうだろうか。

大きなシェアを占めるBecky! はというと、POP over SSLをサポートしているのだが、残念なことに図1の設定がある。

Becky!の設定「証明書を検証しない」
図1: Becky!の設定画面にある「証明書を検証しない」のチェックボックス

この「証明書を検証しない」は、失効確認のことではない。オレオレ証明書の警告を出さない、そのチェックさえしないという設定だ。 これを設定した場合、偽サーバに接続*1しても何の警告もなしに処理される。(パスワードは偽サーバによって復号ないし解読され得る。)

ここはデフォルトではオフ(証明書を検証する)なのだが、例によって例のごとく、このチェックを入れろと指示するサイトがたくさんある。

以下、インターネット接続プロバイダやレンタルサーバ屋が提供しているPOPサービスにおける、POP over SSL対応でのオレオレ証明書使用状況について、ざっと調べてみた。

  • さくらインターネット ― SSL/TLSを用いたメールの送受信について

    「さくらのレンタルサーバ」ではメールサーバ(SMTP,POP)への接続にSSL/TLSを用いることが可能となっておりますが、現在SSL証明を発行しておりません。

    このため使用するメールソフトにより暗号化通信に関するメッセージが送受信時に表示されますが、メール本文はSSLを使用し暗号化されたものとなっております。(略)

    「ツール」−「メールボックスの設定」−「詳細」タブにおいて、"SSL/TLS関連" の "証明書を検証しない"をチェックします

  • EditNet ― メールサーバ(SMTPS,SMTP認証など)の使い方について

    (3)「詳細」のタブを開き,次の設定を行う
    ●「SSL/TLS関連」の「送信用」は「デフォルト」,「証明書を検証しない」をチェックする   →弊社の証明書は自己署名のため,「証明書を検証しない」を選択します.それでも暗号化には問題ありません.(略)

    ●弊社では,当面「自己署名」の証明書で運用する予定です.そのため,「証明書を検証できない」という警告が出ることがありますが,暗号化はされていますのでご安心ください.(ご利用状況によって証明書を購入したいと思います.)

  • プレミアエクスビットレンタルサーバ ― Becky!の設定(SSLで暗号化してメールを送信したい場合)

    3.「証明書を検証しない」にチェックがついていることを確認

  • カモシカジェイピー ― よくある質問

    PopOverSSLへは対応していますか?

    はい、非公式ですが対応しております。非公式と申し上げるのは、証明書の名称が当www.kamosica.jpであり、ユーザ様のPopとドメインが異なってしまうため、「証明書が異なります」等の警告やエラーが出てしまうためで、ある程度の技術と理解をお持ちのユーザ様でないと、問い合わせが頻発する可能性があるため、明記は控えております。現状としましては、Becky! ver2.2.52において、「証明書を検証しない」という設定で、PopOverSSLが使用できることが確認済です。また、 OutlookExpress 6(Windows xp sp2 6.00.2900.2180)でも、一旦警告が出ますが、それ以後は使えるようです。

  • SPPDレンタルサーバー ― Becky! Ver2 設定方法 (ステップ2/2)

    「詳細」タブをクリックし、左上の「サーバーのポート番号」のPOP3の値を「995」と入力します。次に、その下「SSL/TSL関連」受信用を「デフォルト」に再選択すると「SSL/TSLを有効にしますか?」と表示されますので「はい」をクリックします。最後に「証明書を検証しない」にチェックマークを付けてPOP over SSL設定は完了です

  • PSインターネットサービス ― セキュリティの警告について

    POP3S もしくは SMTPS の暗号化通信を行う場合、下記のようなセキュリティの警告画面が表示されることがあります。これは、サーバの証明書を PSN が自分自身で署名して発行したためです。

    この警告が表示されても問題ありません。暗号化通信可能ですので操作を続行してください。尚、この警告を出さない設定も可能ですので information係までご連絡ください。(略)

    この警告が表示されたときは、「ツール」メニューの「メールボックスの設定」の「詳細」の「SSL/TSLの証明書を検証しない」のチェックマークを入れてください

  • 沖縄ケーブルネットワーク ― 高セキュリティメール受信設定

    SSL/TSL関連の「証明書を検証しない」にチェック

  • XREA.COM ― メンテナンス情報:サーバーソフトウェア

    クライアントPCとXREAサーバーとの間のメール通信をSSL経由で暗号化する機能(POP over SSL/IMAP over SSL/SMTP over SSL)、および、送信時にユーザー認証を行うSMTP-AUTH(CRAM-MD5/LOGIN/PLAIN)に正式対応いたしました。(略)

    ・SSL証明書のチェックを行わない設定にしてください。
    OUTLOOKの場合は、最初の認証時に表示されるエラーを無視して、OKを押してください
    Becky!の場合は、「メールボックスの設定」の「詳細」で「証明書を検証しない」にチェックを入れてください

この問題は以前から気になってはいたが、どうせ指摘しても「メールは元々盗聴可能ですから」という返事が来ると予想されるので言う気がしなかった。しかし、パスワードを守る目的でAPOPが必要とされていた環境において、今後、オレオレでないPOP over SSLの需要が高まるだろう。

それにしても、上のオレオレ事業者たちは、なぜ普通にサーバ証明書を買わないのだろうか?*2

*1 設定した本物サーバのホストのアドレスに接続したつもりが実際に接続されるコンピュータが偽という状況。(a)公衆無線LANで攻撃に遭っている状況、(b)ホテルのLANで攻撃に遭っている状況、(c)hubに不正に接続された装置により攻撃されている状況、(d)DNSが攻撃されている状況、(e)通信路上のルータが乗っ取られている状況などで起こり得る。

*2 そこで PAKEですよ。

本日のリンク元 TrackBacks(100)

2007年04月25日

北海道新聞の記者がWinnyを使って流出ファイルを入手したことを公言しているが自分のやっていることがわかっているのか

北海道新聞の記者のブログにこんな記述がある。

今回の流出資料を、インターネット掲示板「2ちゃんねる」の情報を元に入手してみました。 (略)

私はWinnyを使う際、ハードディスクの中身を完全に消し、クリーンインストールし直した古いPCで起動しました。もちろん、個人情報などは一切入っていません。会社のネットは使わず、自宅のネットを使ったほか、流出資料はその古いパソコンでウイルスファイルの除去を行い、Winnyが入っていない別のパソコンでさらにウィルスチェックを行い、安全を確認してから閲覧しました。仕事用のパソコンでは開いてません。これぐらいやらないと危なくて危なくて。

で、目的のファイルを入手した時点で、古いパソコンは再び、押し入れにしまいました。流出ファイル自体もパソコンからは既に消去しました。こんな危ない資料を持ち続ける勇気は私にはありません。

またWinnyで捜査資料流出…【ニュース斜め読み】, メディアの節穴, 2007年4月24日

Winnyを使って「ダウンロード」する行為は、単なるダウンロードではない。ダウンロードしたファイル(およびダウンロード中の断片データ)を、他人の求めに応じて自動送信する状態にする行為(送信可能化行為)だ。

つまり、そのファイルを他人と「共有」し合うということ。だから「ファイル共有ソフト」と呼ばれる。他の誰もがそれをしなかったなら、この記者も入手することはできなかっただろう。give and takeで成り立つシステムだ。事故流出したファイルのさらなる流通に加担し、被害を拡大させるキンタマコレクターの共有仲間になったという自覚はこの記者にあるのか。

道警発表によると、17日に警察庁から道警に連絡があったようですから、警察庁の調査能力たるや恐るべし、ということになるのでしょうか(苦笑)

またWinnyで捜査資料流出…【ニュース斜め読み】, メディアの節穴, 2007年4月24日

警察庁は、当該ファイルを入手して事実確認をしたのだろうが、当然ながら、Winnyを使わずにしているだろう。共有せず、ダウンロードだけしかしないプログラムを使って調査しているはずだ。*1

こういうことが新聞社サイトに堂々と書かれているのを見た人々が、適法行為だと勘違いして、真似するようなことにならなければいいが。

関連:

*1 知らないけど。そうに違いないよね。

本日のリンク元 TrackBacks(21)

最新 追記

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|
最新 追記