• ベストアンサー
  • 困ってます

SSLについて デメリット

SSLについて デメリット WebシステムのSSLはサーバーからクライアントのパソコン間の通信でデータを暗号化復号化して通信時のデータの安全性を図るものだと理解しています。 httpsで始まるURLの場合、全てのデータが暗号化復号化されていると理解しています。 これで正しいでしょうか。 では、安全性からしたら全てSSLにしたほうがよいと思います。そうなるとhttpで始まるURLはなくなるはずです。現実には多くのサイトがhttpで始っています。httpsにするメリットは安全性と思いますが、デメリットがあるのでしょうか。あればデメリットをお教えください。 また、「SSLサーバ証明書」はそのサイトが本物のサイトですという証明書であって、証明書がなくてもSSLにすることはできるという理解でよろしいでしょうか。

共感・応援の気持ちを伝えよう!

  • 回答数6
  • 閲覧数5769
  • ありがとう数10

質問者が選んだベストアンサー

  • ベストアンサー
  • 回答No.5

>httpsで始まるURLの場合、全てのデータが暗号化復号化されていると理解しています。 概ね合っています。(正確にはすべてのデータではなく、キー交換後のSSLセッション後 からなんですけど) >安全性からしたら全てSSLにしたほうがよいと思います。 SSLは ”安全性を高めるには費用が必要” ”SSLに対応していない端末もある” ”通信量が多くなる” 等々、暗号化しなくてよいものに関してはデメリットしかないのです。 また、安全性云々も、いくら高めてても、オペレーションミスによって いとも簡単に無駄になってしまうのです。 (例:架空のURL) https://hoge.tsuri.yaho.co.jp http://hoge.yahoo.co.jp どちらかに個人情報を入力するとしたらどっちですか? SSLだからって、無条件に信用しますか? さて、どうでしょうか。 >、「SSLサーバ証明書」はそのサイトが本物のサイトですという証明書 には必ずしもなりません。 >証明書がなくてもSSLにすることはできる. できます。 →ほら、安全性と相反するでしょ? ベリサインやセコムトラストやサイバートラストなど、聞いたことがあるかとおもいます。 そのサイトが本物である証明は、登記簿等々、申請が面倒かつ、結構高額(3年で20万程度~)なんですよ。 誰でもなんでもできるのは、本物である証明が出来ないですよね。 後、SSLに対応していない携帯電話も多々ありますし、 携帯でSSLにアクセスすると、[2048bit]暗号化の場合、1通信につき、2パケット分追加になるんですよ。パケ放題に入ってないとパケ死(笑)になりますよ・・・。

共感・感謝の気持ちを伝えよう!

質問者からのお礼

ありがとうございます。

関連するQ&A

  • 無効なSSLサーバ証明書

    有効期限が切れたなどの理由で無効になってしまっているSSLサーバ証明書のサイトにhttpsで接続しようとすると、「このサーバ証明書は無効です」というような警告がでます。 これにOKしてhttpsで接続する場合、サーバの正当性が証明されないだけで通信の暗号化はされているのでしょうか? よろしくお願いします。

  • 無料のSSLと無料のサーバ…

    wkey.meでサーバを借りました。 ドメインは、「wkeya.com」でサイトのアドレスは「http://○○○.wkeya.com」となります。 それで、Wordpressを使うことにしたのですが、SSLサーバ証明書を自分で用意しないといけないとわかり、いろいろ調べた末にStartSSLにたどり着きました。 StartSSLの設定も終わり、いざ証明書を発行しようとした所… ドメイン認証で「wkeya.com」が使えないと判明!証明書が発行せず今に至ります。このままでは、Wordpressに平文ログイン、フォームを用意したとしても平文やりとり。これでは危ないですよね? そこで、トップレベルドメインを取ろうと思い無料のものを探した結果、「.tk」に行き着きました。 しかし、StartSSLを見ると「.tk」も未対応と来たもんです。 もうどうすればいいのか八方塞がりになってしまいました。 無料でWordpressが使え、無料でSSL暗号化通信を導入できるにはどうすればいいのでしょうか? レンタルサーバから暗号化通信まで、びた一文払わずにやるというのは不可能なのでしょうか? 「.free」というトップレベルドメインが開始されるとかされないとからしいのですが、StartSSLで使えるかも不透明でしょうし^^; 貧乏人はサイト作るべからずですかね?w

  • PKIの仕組みのSSLへの適用は理解できるのですが、S/MIMEへの適

    PKIの仕組みのSSLへの適用は理解できるのですが、S/MIMEへの適用が理解できません。 具体的には、証明書により確認する相手は誰なのか(メール送信者?メールサーバー?)、内容の暗号化は誰が行って、誰が復号するか等です。

その他の回答 (5)

  • 回答No.6

#5です。 すみません、読み違えていました・・・。 >証明書がなくてもSSLにすることはできる 自己証明書でも何でもいいので(笑)証明書は必要です。

共感・感謝の気持ちを伝えよう!

質問者からのお礼

ありがとうございます。 ちゃんとした証明書でなくても出来るということですね。

  • 回答No.4
  • jjon-com
  • ベストアンサー率61% (1597/2589)

>httpsで始まるURLの場合、全てのデータが暗号化復号化されている >と理解しています。これで正しいでしょうか。 正しいです。(ちなみに暗号化の反対語は復号です。復号化じゃないです) >httpsにするメリットは安全性と思いますが、デメリットが >あるのでしょうか。あればデメリットをお教えください。 ANo.1, ANo.2 は,第一に挙げるべきもっとも基本的な点を指摘していません。 SSL/TLSによる暗号化処理は遅いのです。 暗号化なしの場合と比べて,CPU負荷は100倍近くにもなるんじゃないですか。 だから暗号化の必要がないのなら SSL/TLSで暗号化しない方が効率よく多数のWebアクセスを捌けます。 SSLアクセラレータというCPUとは別の装置を解説したページを紹介しておきます。 http://fenics.fujitsu.com/products/ipcom/catalog/data/ssl/ >証明書がなくてもSSLにすることはできるという理解でよろしいでしょうか。 http://okwave.jp/qa/q3396499.html の私の過去の回答 ANo.3

共感・感謝の気持ちを伝えよう!

質問者からのお礼

ありがとうございます。 CPU負荷は100倍近くということは厳しいですね。

  • 回答No.3
  • yidong
  • ベストアンサー率37% (25/67)

全部暗号化のデメリット サーバ視点 CPUを浪費する。 クライアント視点 企業などで導入されているGWタイプのウイルスチェックなどが効かなくなる などでしょうか

共感・感謝の気持ちを伝えよう!

質問者からのお礼

ありがとうございます。 ウイルスチェックの点があるのですね。

  • 回答No.2

>これで正しいでしょうか。 概ね正しい。 しかし、ざっくり言えばSSLはURIスキームの一つでしかない。 >httpsにするメリットは安全性と思いますが、デメリットがあるのでしょうか。あればデメリットをお教えください。 安全性という認識がちょっと違う。 公開されたWebサイトを暗号化して通信する意味があるとお思いでしょうか? >、「SSLサーバ証明書」はそのサイトが本物のサイトですという証明書であって ここもセキュリティにおいては意味が違う。 「SSLサーバ証明書」はあくまでサーバーで作成された証明書に過ぎず、サイトの安全性やセキュリティを保証するものではありません。 金庫と鍵が頑丈でも、初めから中身が本物でないかもしれません。

共感・感謝の気持ちを伝えよう!

質問者からのお礼

ありがとうございます。 例えばMSのように公開されたWebサイトであっても、本物か偽物かはいつも気になります。 このようなQAサイトでしたらほとんど気にしませんが、MSが言ってることとかNTTが言ってることでしたら、そこの責任で言うでしょうからそのサイトが本物かどうかが気になります。

  • 回答No.1
  • mtaka2
  • ベストアンサー率73% (867/1179)

> また、「SSLサーバ証明書」はそのサイトが本物のサイトですという証明書であって、証明書がなくてもSSLにすることはできるという理解でよろしいでしょうか。 これは間違いです。SSLでは、サーバ側に必ず「サーバ証明書」が必要です。 その証明書に基づいて暗号化が行われるので、証明書の持ち主以外には復号できない、 ということで、通信の安全性を確保します。 で、そのサーバ証明書が、「本物のサイトです」と証明できるものであるかどうかはまた別の話。 そういう証明力のない「自己署名証明書」(いわゆるオレオレ証明書)でSSLサーバを運用することもできます。 ですが、自己署名証明書を使った場合、中間者攻撃に遭っていないことを確認できませんので、 暗号通信が成り立っている保証がまったくありません。 中間者攻撃では、盗聴者はサーバからはクライアントのふりを、クライアントにはサーバのふりをして、 サーバとクライアントの間に盗聴者が通信を仲立ちしつつ盗聴や改竄をおこないます。 このとき、クライアントから見ると「自己署名証明書を使った正しいサーバと暗号通信を行っている」のか、「自己署名証明書を使った盗聴者と暗号通信を行っている」のかを区別はできないのです。 > httpsにするメリットは安全性と思いますが、デメリットがあるのでしょうか。あればデメリットをお教えください。 SSLでサーバ運用するためには、、正しい証明書が必要になりますので、その分コストがかかるというのがデメリットの一つです。 もう一つは、httpsの暗号化通信の特性から、「ネームベースバーチャルホスト」が使えない、という欠点があります。 一つのWWWサーバで、複数のドメインを運用することができないのです。

共感・感謝の気持ちを伝えよう!

質問者からのお礼

ありがとうございます。 自己署名証明書ではかなりいい加減になるのですね。 コストとネームベースバーチャルホストですか。 調べてみます。 ありがとうございます。

関連するQ&A

  • SSL(暗号化通信)設定について

    教えて下さい。 FEDORA CORE4で自宅サーバを構築しているものですが、 Apache+mod_sslで暗号化通信をしたいのですが、設定の仕方が よくわかりません。 それからベリサインなどに証明書を申請するお金もないため、 証明書まで自分で作成して、暗号化通信を可能にしたいのです。 設定方法のコマンドラインでの設定例やおすすめサイトなど 教えてください。 よろしくお願いします。

  • CentOS5.4で「自作SSLサーバ証明書」作成途中の「Webサーバ

    CentOS5.4で「自作SSLサーバ証明書」作成途中の「WebサーバのFQDN」 (「プライベートCA(認証局)」による「自作SSLサーバ証明書」を   作成時に手入力する項目の1つ) について教えてください。 お世話になります。 おそらく通常ですと、「WebサーバのFQDN」へは、 「www.~」から始まるURL値を手入力すると思います。 そこで質問内容ですが、WWWとあわせて、 他にFileZillaなどでFTPも利用しているサーバに対しましては、 上記致しました「www.~」から始まるURL値で、1つ「自作SSLサーバ証明書」を作成後に、 更に、 もう1つ別に、 今度は「ftp~」から始まるURL値で、別の「自作SSLサーバ証明書」を2つ目の証明書として 作成する必要があるのでしょうか? それとも、 上記致しました「www.~」から始まるURL値で、1つ「自作SSLサーバ証明書」を 作成しておけば、 それが、FTPを利用する際にも、 SSL通信であわせて、SSLとして利用可能な状態になるのでしょうか? 今回初めて1年更新の時期がきて、「自作SSLサーバ証明書」作成・更新を、 近日中に実施予定の為、 上記のご質問をさせていただきました。 宜しくお願い致します。

  • SSLの信頼性について

    ネット販売の代金決済にSSLによる暗号化通信があります。以前に知人がクレジットカードによるSSL決済でURLのプロトコルhttpsの確認、右下タスクトレイ上に鍵マーク確認、カギマークから発行元証明書の確認もしたようです。しかし結果して悪用されたそうです。その話を聞いて私はネット上のSSLを信頼していません。下記についてご助言を頂きたいと思います。 (1)ブラウザで公開鍵で暗号化し、送信したデータが    通信経路上で秘密鍵が盗取されてデータが復元さ   れ、情報盗取されることは可能でしょうか。 (2)証明書の発行元の偽装は簡単に行えるのでしょう    か。 (3)発行元が本人(法人)であることは何で確認すれば    安全でしょうか。以上お願いいたします。

  • httpとhttpsとSSLの違い

    http は通信内容が平文でネットワークを流れる。 https は通信内容がWEBサーバとPCのブラウザ間で暗号化される。ブラウザのキャッシュが効かない。 SSL は通信内容がWEBサーバとPCのブラウザ間でSSL証明書をもって暗号化できる。httpsに追加して使える(2重に暗号化?)。httpには使えない。通信を要求するサーバが信頼できることを証明する。 と理解していますが、たぶんどれか間違っていると思います。 上記3個の違いを簡潔に教えてください。 よろしくお願いします。

  • SSLについて

    会社のホームページ制作担当をしていますが、昨今個人情報保護法などのからみから、CGIフォームでのデータの送信にSSLでの暗号化をして欲しいという意見がでました。 現在使用しているホスティングサーバーはSSLに対応していないらしく、サーバーの乗換えを考えています。 いろいろ調べているのですが、共有SSLという安い方式と、5~6万円くらい金額がかかる、日本ベリサインなどのSSLサーバ証明書を取得する場合とがあるのですが、どう違うのでしょうか。 できれば安く上げたいのですが共有SSLだと何か問題が発生したりするのでしょうか。

  • SSL通信と認証局について

    すいません。トピック違いかもしれませんが、ご質問させて頂きます。 初歩的な質問なのかもしれませんが、(すいません・・それすら分からず)よく、SSL通信を行うにはどこかの認証局で証明書を発行しないといけないと伺っております。 例えば、ある画面にて値を埋め込み、POSTメソッドにて特定のURLに送信します。これを、Aの画面からBの画面へ遷移すると考えてください。 Bの画面(POSTメソッドの値を受け取る方)には既に、ある認証局からの証明書があり、SSL通信しております。(Bの画面のURLは、https:// になります) その際に、もしAの画面にも証明書を発行しSSL通信の画面にした場合(画面AのURLも、https//: )にした場合、認証局が違えば、通信できなくなったりするのでしょうか。 素人的な考えで、bit数は合わせないといけないのかなと思うのですが・・・。 また、日本でどれくらいの数の認証局があるのかが分かるページなんてご存知の方いらっしゃいませんでしょうか。 質問ばかりですいません。 どなたか、よろしくお願いします。

  • 「SSLプロトコルの検査機能」の安全性について

    Q1.「ESET Smart Security8」の設定で「SSLプロトコルを常に検査する」をONにするとブラウザのURL欄の鍵印をクリックしてサーバ証明書を確認すると、発行者が「ESET SSL Filter CA」となっていますが、これは、Superfishの様に、勝手にサーバ証明書を発行していると云う事ですか? ESET社が正規の認証局であっても、アプリで都度、サーバ証明書を発行するのは、Superfishi行為と云えるのでは? 一方、「SSLプロトコルを検査しない」をONにすると、オルジナルの正規の「VeriSign社のサーバ証明書」が表示されます。 Q2.「ESET Smart Security8」の仕様では、「SSLプロトコルを常に検査する」場合は、検査対象の「サーバ証明書」は使用出来ないので、代替としてESET社の「サーバ証明書」を使用すると云う事ですか? この仕様が非常に判り難く、納得がいかないのですが? 検査対象の「サーバ証明書」が検査OKであれば、何故、オリジナル原本の「サーバ証明書」が使用出来ないのですか? そもそも、ESET社の「サーバ証明書」は、当該サーバの安全性を保証・認証するものではないですよね? あたかも、Superfishの様に、勝手にアプリ用の「サーバ証明書」を都度、発行して、オリジナル原本の「サーバ証明書」に上書きしている様にしか見えませんが? Q3.Superfishの様に、「ESET Smart Security8」のESET社製「サーバ証明書」が、クラッカー犯罪者に抜き取られて、SSL通信が傍受・漏洩していると云う危険性はないのでしょうか? 本件の安全性を立証するバックデータで説明頂けると助かります。 Q4.「SSLプロトコルを常に検査する」機能は、クラッカー犯罪者がSSLプロトコルでマルウェアをダウンロードさせる様な行為を防御する為ですよね? この機能をOFFにすると「SSL通信では、一切、防御機能は働かずに、マルウェア等の被害を受けるリスクがある」と云う事ですか? それとも、この機能は、「サーバ証明書」の真偽だけをチェックしているだけですか? ※OKWaveより補足:「ESETセキュリティ ソフトウェア シリーズ」についての質問です。

  • SSLの証明書・秘密鍵について

    こんにちは。tatu456です。 LAN環境で RedHat Linux7.1JにてApache-SSLを導入し、セキュアなサーバを構築しようと思っているのですが、CA証明書・サーバ証明書・サーバ秘密鍵の作成方法、または入手方法がわかりません。 CA証明書については下記のURLを参考に作成してみたのですが、他の2点がよくわからないのです。 ご存じの方教えてください。 参考にしたURL:http://www.ipa.go.jp/security/fy12/contents/crack/soho/soho/chap3/ssl/apachessl.html

  • 自己署名証明書によるSSL通信について教えてください!

    SSL通信により、データを暗号化してWeb上でやりとりするシステムの構築を考えています。 そこで自己署名というのを考えているのですが、署名の流れがいまいち分かりません。 認証局利用の場合、私の理解では、 【サーバ側】 1.サーバ側でRSA秘密鍵を生成 2.RSA秘密鍵を元にCSRを作成 3.CSRファイルを認証局に送信 【認証局】 4.CA秘密鍵により暗号化し、サーバ証明書を作成 5.サーバ側にサーバ証明書を送信 【サーバ側】 6.クライアント側にサーバ証明書を送信 【クライアント側】 7.サーバ側よりサーバ証明書を受信する 8.認証局より公開鍵を取得する 9.認証局の公開鍵でサーバ証明書の暗号化された鍵(認証局の秘密鍵で暗号化されたもの)を復号する 10.復号した鍵により、サーバ証明書の暗号文を復号する となります。(間違いがある場合はご指摘下さい) では、自己署名を行う場合はどうなるのでしょうか? 単純にサーバ証明書を自分で作成すると考えてよろしいのでしょうか? CSRファイルの作成などもやはり行うのでしょうか? クライアント側の流れは変わらないのでしょうか? また、この操作は接続毎に毎回行うことになるのでしょうか? (秘密鍵、サーバ証明書は毎回変わるのでしょうか?) 初歩的な質問とは思いますが、よろしくお願いいたします。

  • SSLを導入したい

    すみません。SSLを個人のPCに導入したいのです。しかし、SSLを導入するのに必要なものや仕方が分からないのです。有料の電子証明書を発行する認証局のサイトを見て、SSLの仕組みなどを見ても、頭から?が飛び出ます。 ローカルネットワーク内で、試験的に、SSLによる暗号化が行われているかテストしたいので、証明書を個人で作成するつもりです。 環境: OS : Windows XP Professional Webサーバ : Apache 2 この環境で(OSがWindowsでいいのかはわかりませんが、「Apacheを使う」環境という意味で)、SSL暗号化処理を1から構築するために、しなくてはいけないこと、用意することや、その手順について、詳しく教えていただけたら幸いです。