HOME HELP 新規作成 新着記事 ツリー表示 スレッド表示 トピック表示 ファイル一覧 検索 過去ログ

[ 最新記事及び返信フォームをトピックトップへ ]

■1404 / inTopicNo.21) 　Re[16]: ISBNでゲットだぜ！
  ▼■
□投稿者/ hidetake -(2020/12/14(Mon) 21:12:23)
http://https
    2020/12/14(Mon) 22:04:42 編集(投稿者)
    2020/12/14(Mon) 21:46:18 編集(投稿者)
    2020/12/14(Mon) 21:20:44 編集(投稿者)

    > それにしても、わっかり難いメッセージですね。

    それは、それとして
    そのサイトは、このエラーからして SSL を使用していた
    すなわち、証明書を使用していたと思われるが、その
    証明書自体は正しいものであったのか。期限とか証明書
    自体に問題があったのか。
    それとも、その証明書が失効しているのか、どうか、それ
    を確認するための失効証明書が取得できなかったのか。

    すなわち、そのサイトのデータを信頼すべきデータとして
    取り扱って良いのか、どうか。それが気にかかります。

    ※追加※
    詐欺サイトとか、セキュリティのことを無視しても良いと
    言うのであれば別ですが。

    ※さらに追加※
    もちろん、正しい証明書で署名されたサイトだから言って
    そのサイトにあるデータに問題が無いとは言い切れるもの
    ではありません。

    それは、送られてくるメールのデータであれ、インター
    ネットの上のデータであれ、そのデータを扱うものは
    自分自身でデータの信頼と安全を確保しなければなりま
    せん。

    メールのデータを扱う場合も、桐自身がその安全性を
    確保はしてはくれません。自分自身で、そのデータの
    安全化(セキュア化)を図らねばなりません。

    桐のヘルプにある
    [メール解析]コマンドを使用する際の注意点
    のように、いろんな仕組みを使って、ネットの世界では
    穴を狙ってきます。
    なので、ネットの世界で取ってきたデータは、自分自身
    でセキュリティを担保しなければなりません。

    ※メールデータのセキュリティの問題も Kthree 自体で
    　対応されることはなく、ユーザ自身の手にゆだねられ
    　ました。

    ※さらにさらに追加※
    先に書いた「メールの問題」を Kthree に指摘したとき、
    Kthree は、当初は「\」の処理だけをして対応を考えて
    (提出して)きました。Windows は「\」だけじゃく「/」
    も、同様に扱うんだよと教えてあげて、それも加えた
    対策を出して来ました。管理工学研究所だって、そんな
    程度です。世の中には、いろんな攻撃方法があります。
    気をつけねば!!
引用返信 [メール受信/OFF] 削除キー/
■1405 / inTopicNo.22) 　Re[17]: ISBNでゲットだぜ！
□投稿者/ ONnoji -(2020/12/14(Mon) 22:08:25)
    2020/12/14(Mon) 22:11:32 編集(投稿者)

    > それは、それとして
    > そのサイトは、このエラーからして SSL を使用していた
    > すなわち、証明書を使用していたと思われるが、その
    > 証明書自体は正しいものであったのか。期限とか証明書
    > 自体に問題があったのか。
    > それとも、その証明書が失効しているのか、どうか、それ
    > を確認するための失効証明書が取得できなかったのか。

    貴殿のご懸念はよく理解できます。当方もまったく同感です。

    世の中にはいろいろなｗｅｂサイトがありますが、

    > 今回の記事では、curlコマンドで、TLS証明書(SSL証明書)のエラーが出ても無視して、アクセスする必要があったので、メモを残しておきます。
    > 本来は、証明書のエラーを無視すべきではありません。証明書のエラーを無視しないでよい方法を調べて、修正するのが正しい対処方法でしょう。
    > これは、お勧めできる話ではありません。証明書/TLSは、セキュリティの目的で利用されています。
    > そのセキュリティのために利用される証明書でエラーがおきるということは、問題があるということです。
    curlコマンドでTLS/SSLのエラーを無視する方法
    https://kaworu.jpn.org/kaworu/2011-02-11-1.php

    ↑のように正当な意見を述べているものもありますよ。


引用返信 [メール受信/OFF] 削除キー/
■1406 / inTopicNo.23) 　Re[18]: ISBNでゲットだぜ！
□投稿者/ hidetake -(2020/12/14(Mon) 22:25:07)
http://https
    私が気づいた桐のセキュリティ問題は、
    「ディレクトリトラバーサル」に関する
    脆弱性、
    「SQLコマンドインジェクション」に
    関する脆弱性です。

    「SQLコマンドインジェクション」に
    関しては、うまく利用すれば、桐の
    多様な可能性もあり、利用もしている
    ので、使えなくなっては困るのですが、

    ネットのデータを扱うとなれば、いろ
    な攻撃方法が考えられると思います。

    もちろん、Khree は、そんなデータを
    扱うことは想定していません。
    自分の身は自分で守らなければなりま
    せん。
    面白い世界ではあるけど、やっかいな
    世界でもあります。
引用返信 [メール受信/OFF] 削除キー/
■1407 / inTopicNo.24) 　Re[15]: ISBNでゲットだぜ！
□投稿者/ ONnoji -(2020/12/15(Tue) 12:57:05)
    2020/12/15(Tue) 15:15:08 編集(投稿者)

    くおんたむさんへの投稿です。

    > curlコマンドでの取得が出来ない原因が以下の理由でした。
    >
    > 「curlコマンド　windouws10 失効の関数は証明書の失効を確認できませんでした」

    私はネット関係の知識は多くないですが、エラーの原因のひとつは以下の内容かもしれませんよ。

    もちろん、タラレバですけどね。アハハha。(^^ゞ

    こちら
    　↓
    プロキシサーバとHTTPS通信の関係
    https://kaworu.jpn.org/security/%E3%83%97%E3%83%AD%E3%82%AD%E3%82%B7%E3%82%B5%E3%83%BC%E3%83%90%E3%81%A8HTTPS%E9%80%9A%E4%BF%A1%E3%81%AE%E9%96%A2%E4%BF%82

    > HTTPのプロキシサーバは、HTTPSの暗号化通信(SSL)をきちんと扱えるのでしょうか？
    > HTTPSの通信を行う場合は、ユーザエージェントはCONNECTメソッドで接続したい相手をプロキシに伝え、
    > 暗号通信に必要なSSLサーバ証明書と公開鍵を取得してもらい、その後、暗号化通信を行います。



引用返信 [メール受信/OFF] 削除キー/
■1408 / inTopicNo.25) 　Re[16]: ISBNでゲットだぜ！
□投稿者/ hidetake -(2020/12/15(Tue) 22:03:59)
http://https
    > プロキシサーバとHTTPS通信の関係
    > https://kaworu.jpn.org/security/%E3%83%97%E3%83%AD%E3%82%AD%E3%82%B7%E3%82%B5%E3%83%BC%E3%83%90%E3%81%A8HTTPS%E9%80%9A%E4%BF%A1%E3%81%AE%E9%96%A2%E4%BF%82

    Squid は、遠い昔は ISDN のころ、無駄なトラフィックを
    さけ、狭い帯域でも快適なインターネット環境が使えるよう
    キャッシュサーバとして使っていました。
    つい１年ほど前までは、VPNの環境のせいで、直接はインター
    ネットに出られない環境だったのでプロキシサーバを使って
    いました。と、言うか、本来は Blue Coat がプロキシサーバ
    として使われていたのですが、それが壊れてしまったので
    急遽 Squid で代替えプロキシを立て直したのですが、特に
    問題はなく、HTTPS 通信もできていたけど。

    もう、プロキシなしでも通信できるようにしたので使って
    いないけど、次のような設定で、問題無く通っていました。


squid.conf.txt/1KB
引用返信 [メール受信/OFF] 削除キー/
■1409 / inTopicNo.26) 　Re[17]: ISBNでゲットだぜ！
□投稿者/ hidetake -(2020/12/16(Wed) 07:45:52)
    折角だから書いておくと

    SSL通信での問題はプロキシよりも

    SSL通信で問題が出やすいのは、もちろん
    ターゲット(サーバ)側の証明書の問題も
    ありますが、

    また、クライアント側(Windowsだったり、
    ブラウザソフト)の持っている、どの
    証明書を信頼して良いかという
    ルート証明書との整合性もありますが、

    最近は、多くの通信が SSL化して通信が
    行われるので、UTM、ファイヤウォール、
    そして、アンチウィルスソフトなどが
    暗号化された通信のため、データを傍受
    できず、流れるデータの安全性を確保
    できないと言う状態になり、逆に
    セキュリティを担保できないという状態
    になります。

    そのため SSLインスペクションという方法
    で、いっったん、UTM、ファイヤウォール、
    そして、アンチウィルスソフトなどが
    ターゲットとの間で SSL通信を行い流れる
    データをチェックしたうえで、
    クライアントとの間の通信は、自分が持ち
    合わせている証明書で、再暗号化して
    データ通信を行うと言う仕組みがあります。

    この場合、クライアント側にとっては、
    相手先のドメインと実際に暗号化で使われ
    ている証明書との不整合で、警告を出し
    たり、通信ができなくなると言うトラブル
    が発生する場合があります。

引用返信 [メール受信/OFF] 削除キー/
＜前の20件

トピック内ページ移動 / << 0 | 1 >>

このトピックに書きこむ
Mode/　 Pass/

HOME HELP 新規作成 新着記事 ツリー表示 スレッド表示 トピック表示 ファイル一覧 検索 過去ログ

- Child Tree -
- Antispam Version -