Submit Search
Upload
SSLとは何か?:What's SSL?
•
1 like
•
1,155 views
C
CyberHacks
Follow
SSLについての説明です Lecture about SSL
Read less
Read more
Education
Report
Share
Report
Share
1 of 15
Recommended
ネットワークの暗号化
ネットワークの暗号化
Hiroki Kaneko
DNS RFC系統図
DNS RFC系統図
Takashi Takizawa
qpstudy08 lsyncdによる共有ファイルシステムっぽい何かの検証
qpstudy08 lsyncdによる共有ファイルシステムっぽい何かの検証
Takashi Takizawa
#dnstudy 01 ドメイン名の歴史
#dnstudy 01 ドメイン名の歴史
Takashi Takizawa
RFCについての復習
RFCについての復習
Takashi Takizawa
Unboundの最適化(OSC2011 Tokyo/Spring)
Unboundの最適化(OSC2011 Tokyo/Spring)
Takashi Takizawa
Unbound/NSD最新情報(OSC 2014 Tokyo/Spring)
Unbound/NSD最新情報(OSC 2014 Tokyo/Spring)
Takashi Takizawa
#qpstudy 2015.11 20分でわかるPKI
#qpstudy 2015.11 20分でわかるPKI
Masahiro NAKAYAMA
Recommended
ネットワークの暗号化
ネットワークの暗号化
Hiroki Kaneko
DNS RFC系統図
DNS RFC系統図
Takashi Takizawa
qpstudy08 lsyncdによる共有ファイルシステムっぽい何かの検証
qpstudy08 lsyncdによる共有ファイルシステムっぽい何かの検証
Takashi Takizawa
#dnstudy 01 ドメイン名の歴史
#dnstudy 01 ドメイン名の歴史
Takashi Takizawa
RFCについての復習
RFCについての復習
Takashi Takizawa
Unboundの最適化(OSC2011 Tokyo/Spring)
Unboundの最適化(OSC2011 Tokyo/Spring)
Takashi Takizawa
Unbound/NSD最新情報(OSC 2014 Tokyo/Spring)
Unbound/NSD最新情報(OSC 2014 Tokyo/Spring)
Takashi Takizawa
#qpstudy 2015.11 20分でわかるPKI
#qpstudy 2015.11 20分でわかるPKI
Masahiro NAKAYAMA
Unbound/NSD最新情報(OSC 2013 Tokyo/Spring)
Unbound/NSD最新情報(OSC 2013 Tokyo/Spring)
Takashi Takizawa
UnboundとDNSSEC(OSC2011 Tokyo/Spring)
UnboundとDNSSEC(OSC2011 Tokyo/Spring)
Takashi Takizawa
#mailerstudy 01 LT POP/IMAP入門
#mailerstudy 01 LT POP/IMAP入門
Takashi Takizawa
#mailerstudy 02 暗号入門 (2012-02-22更新)
#mailerstudy 02 暗号入門 (2012-02-22更新)
Takashi Takizawa
#logstudy 01 rsyslog入門
#logstudy 01 rsyslog入門
Takashi Takizawa
#mailerstudy 02 メールと暗号 - SSL/TLS -
#mailerstudy 02 メールと暗号 - SSL/TLS -
Takashi Takizawa
DNSのRFCの歩き方
DNSのRFCの歩き方
Takashi Takizawa
BIND of Summer (2017-04-13)
BIND of Summer (2017-04-13)
Takashi Takizawa
サバフェス! 2015 Spring LT資料
サバフェス! 2015 Spring LT資料
Takashi Takizawa
DNS RFCの歩き方(短縮版)
DNS RFCの歩き方(短縮版)
Takashi Takizawa
initとプロセス再起動
initとプロセス再起動
Takashi Takizawa
nginx入門
nginx入門
Takashi Takizawa
セキュリティ入門
セキュリティ入門
y-hattori
DNS再入門
DNS再入門
Takashi Takizawa
nginxの紹介
nginxの紹介
Takashi Takizawa
The_Five_Books_Overview_Presentation_2024
The_Five_Books_Overview_Presentation_2024
koheioishi1
TokyoTechGraduateExaminationPresentation
TokyoTechGraduateExaminationPresentation
YukiTerazawa
ゲーム理論 BASIC 演習105 -n人囚人のジレンマモデル- #ゲーム理論 #gametheory #数学
ゲーム理論 BASIC 演習105 -n人囚人のジレンマモデル- #ゲーム理論 #gametheory #数学
ssusere0a682
TEAMIN Service overview for customer_20240422.pdf
TEAMIN Service overview for customer_20240422.pdf
yukisuga3
UniProject Workshop Make a Discord Bot with JavaScript
UniProject Workshop Make a Discord Bot with JavaScript
yuitoakatsukijp
東京工業大学 環境・社会理工学院 建築学系 大学院入学入試・進学説明会2024_v2
東京工業大学 環境・社会理工学院 建築学系 大学院入学入試・進学説明会2024_v2
Tokyo Institute of Technology
More Related Content
Viewers also liked
Unbound/NSD最新情報(OSC 2013 Tokyo/Spring)
Unbound/NSD最新情報(OSC 2013 Tokyo/Spring)
Takashi Takizawa
UnboundとDNSSEC(OSC2011 Tokyo/Spring)
UnboundとDNSSEC(OSC2011 Tokyo/Spring)
Takashi Takizawa
#mailerstudy 01 LT POP/IMAP入門
#mailerstudy 01 LT POP/IMAP入門
Takashi Takizawa
#mailerstudy 02 暗号入門 (2012-02-22更新)
#mailerstudy 02 暗号入門 (2012-02-22更新)
Takashi Takizawa
#logstudy 01 rsyslog入門
#logstudy 01 rsyslog入門
Takashi Takizawa
#mailerstudy 02 メールと暗号 - SSL/TLS -
#mailerstudy 02 メールと暗号 - SSL/TLS -
Takashi Takizawa
DNSのRFCの歩き方
DNSのRFCの歩き方
Takashi Takizawa
BIND of Summer (2017-04-13)
BIND of Summer (2017-04-13)
Takashi Takizawa
サバフェス! 2015 Spring LT資料
サバフェス! 2015 Spring LT資料
Takashi Takizawa
DNS RFCの歩き方(短縮版)
DNS RFCの歩き方(短縮版)
Takashi Takizawa
initとプロセス再起動
initとプロセス再起動
Takashi Takizawa
nginx入門
nginx入門
Takashi Takizawa
セキュリティ入門
セキュリティ入門
y-hattori
DNS再入門
DNS再入門
Takashi Takizawa
nginxの紹介
nginxの紹介
Takashi Takizawa
Viewers also liked
(15)
Unbound/NSD最新情報(OSC 2013 Tokyo/Spring)
Unbound/NSD最新情報(OSC 2013 Tokyo/Spring)
UnboundとDNSSEC(OSC2011 Tokyo/Spring)
UnboundとDNSSEC(OSC2011 Tokyo/Spring)
#mailerstudy 01 LT POP/IMAP入門
#mailerstudy 01 LT POP/IMAP入門
#mailerstudy 02 暗号入門 (2012-02-22更新)
#mailerstudy 02 暗号入門 (2012-02-22更新)
#logstudy 01 rsyslog入門
#logstudy 01 rsyslog入門
#mailerstudy 02 メールと暗号 - SSL/TLS -
#mailerstudy 02 メールと暗号 - SSL/TLS -
DNSのRFCの歩き方
DNSのRFCの歩き方
BIND of Summer (2017-04-13)
BIND of Summer (2017-04-13)
サバフェス! 2015 Spring LT資料
サバフェス! 2015 Spring LT資料
DNS RFCの歩き方(短縮版)
DNS RFCの歩き方(短縮版)
initとプロセス再起動
initとプロセス再起動
nginx入門
nginx入門
セキュリティ入門
セキュリティ入門
DNS再入門
DNS再入門
nginxの紹介
nginxの紹介
Recently uploaded
The_Five_Books_Overview_Presentation_2024
The_Five_Books_Overview_Presentation_2024
koheioishi1
TokyoTechGraduateExaminationPresentation
TokyoTechGraduateExaminationPresentation
YukiTerazawa
ゲーム理論 BASIC 演習105 -n人囚人のジレンマモデル- #ゲーム理論 #gametheory #数学
ゲーム理論 BASIC 演習105 -n人囚人のジレンマモデル- #ゲーム理論 #gametheory #数学
ssusere0a682
TEAMIN Service overview for customer_20240422.pdf
TEAMIN Service overview for customer_20240422.pdf
yukisuga3
UniProject Workshop Make a Discord Bot with JavaScript
UniProject Workshop Make a Discord Bot with JavaScript
yuitoakatsukijp
東京工業大学 環境・社会理工学院 建築学系 大学院入学入試・進学説明会2024_v2
東京工業大学 環境・社会理工学院 建築学系 大学院入学入試・進学説明会2024_v2
Tokyo Institute of Technology
Recently uploaded
(6)
The_Five_Books_Overview_Presentation_2024
The_Five_Books_Overview_Presentation_2024
TokyoTechGraduateExaminationPresentation
TokyoTechGraduateExaminationPresentation
ゲーム理論 BASIC 演習105 -n人囚人のジレンマモデル- #ゲーム理論 #gametheory #数学
ゲーム理論 BASIC 演習105 -n人囚人のジレンマモデル- #ゲーム理論 #gametheory #数学
TEAMIN Service overview for customer_20240422.pdf
TEAMIN Service overview for customer_20240422.pdf
UniProject Workshop Make a Discord Bot with JavaScript
UniProject Workshop Make a Discord Bot with JavaScript
東京工業大学 環境・社会理工学院 建築学系 大学院入学入試・進学説明会2024_v2
東京工業大学 環境・社会理工学院 建築学系 大学院入学入試・進学説明会2024_v2
SSLとは何か?:What's SSL?
1.
SSLとは何か? SSLの概略について説明しています
2.
序章:鍵について 暗号には「鍵」と言われるものが使われる 鍵はソフトウェア的なものであり、物質的なものではない
鍵には、「共通鍵」と「公開鍵と秘密鍵」とに大別される
3.
共通鍵 共通鍵暗号方式とは、暗号化するための鍵とそれを復号化するための鍵に同じものを使用する方式のこと 両者が同じ鍵を持つ
共通鍵暗号方式の場合、暗号化した際に使用した鍵は、復号化する際にも必要になる。例えば、ある文書をインターネットを介してAさんがBさんに送付する場合、AさんはBさんに対して、暗号化の際に使用した鍵を他人に知られないような方法を使ってBさんに渡さなければならない。更にAさんがBさん以外に、Cさん・Dさんとも暗号文のやりとりをしようと思った場合には、Cさん用・Dさん用にも鍵を用意してそれぞれの相手と共有 しなければならない。 つまりAさんは暗号文のやりとりをする相手の数だけ鍵を保管し、しかも厳重に管理しなければならない。こういった問題点があってはインターネットというインフラを十分に活用することが難しくなってしまう。 但し、共通鍵は互いが同じ鍵を使うので暗号化も復号化(暗号化する前の状態に戻すこと)も処理に時間がかからないという利点がある。
4.
公開鍵暗号方式(公開鍵と秘密鍵) これに対して公開鍵暗号方式は暗号化と復号化でペアとなる2つの異なる鍵を使用する。片方の鍵を使って暗号化したものは、それとペアになっているもう一方の鍵を使用しなければ復号化出来ない仕様になって居る。この一対の鍵を「秘密鍵」と「公開鍵」と呼ぶ。 先ほどのAさんとBさんの例を公開鍵暗号方式で考えてみると、今度はBさんがAさんに暗号文を送付する場合、先ずBさんはAさんの公開鍵
を入手する。基本的に公開鍵は誰が手に入れても良いものなので、Aさんは公開鍵を電子メールで送っても良いし、自分のウェブサイト上に公開しても問題ない。 BさんはAさんの公開鍵を入手しその鍵を使ってAさんに送付したい文書を暗号化する。暗号化された文章を受け取ったAさんは、自分の秘密鍵を 使用して文章を復号化することで本来の内容を読むことが出来る。 Aさんの公開鍵で暗号化したものは、Aさんの秘密鍵でしか復号化出来ない為、仮に悪意の第三者がAさんの公開鍵を入手したとしても、暗号化された文書の 本来の内容が漏れてしまうことはありません(これを復号化するにはAさんの秘密鍵でないと無理だから)。 逆にAさんの公開鍵を持っていれば、誰もがAさんに暗号文を送ることが出来る。また、暗号文をやりとりする相手が 何人になろうと、Aさんが厳重に保管しなければならないのは、Aさんの秘密鍵だけである。 このように公開鍵暗号方式は共通鍵暗号方式に比べて、オープンなネットワークであるインターネットに非常に有効性が高い方法である。 但し、公開鍵暗号方式には共通鍵暗号方式に比べて、暗号化/復号化に時間がかかるという欠点がある。その為、実際の通信においては互いの欠点を補う形で2つの暗号方式を併用する。
5.
補足 公開鍵暗号方式では、鍵と呼ばれるデータを利用して暗号化と復号化を行う。鍵長とは、この鍵のデータ量のことを指す。 鍵長は一般的に、
1024bit、2048bitなどビット数で表されており、鍵長が長いほど暗号文は解読し難くなり安全になるが、計算手順は増える為に暗号化・復 号化に時間がかかる様になる。 また、極端に短い鍵長の鍵を使用することはセキュリティ上好ましくなく、第三者に解読されてしまう恐れもある。
6.
SSLとは?:総論 Secure Socket
Layerの略。 米Netscape社が開発したインターネット上で情報を暗号化し、送受信出来るプロトコル(=通信規約:ネット上で「プロトコル」と出る場合は「決まり事」と解釈すれば良い)。 サーバ⇔クライアントPC間でクレジットカード情報等の機密性の高い情報を安全にやり取り出来る。
7.
8.
SSLの仕組み 公開鍵暗号方式と共通鍵を使う。 秘密鍵で暗号化したものは公開鍵でしか復号化出来ず、公開鍵で暗号化したものは秘密鍵でしか復号化出来ない。
SSLもこの仕組みを利用。
9.
10.
その為には安全に共通鍵を互いが交換し合わなければならない。そこで公開鍵と秘密鍵を使用する。
11.
※1:公開鍵のキーペアを作成する際に、公開鍵暗号方式とその鍵長を設定。サーバ管理者は十分な強度の暗号方式、鍵長を設定する様に注意しなければならない。
12.
13.
SSLサーバ証明書には主に下記二つの役割がある。
14.
証明書に表示されたドメイン(サーバ)の所有者であることの証明
15.
ブラウザとウェブサーバ間でのSSL暗号化通信の実現
16.
17.
補足(認証局:その1) 認証局(CA:Certification Authority)の役割の一つ目は電子証明書を発行すること。例えばメールの暗号化等に使われるクライアント証明書の発行の場合、登記事項証明書や印鑑登録証明書を用いて申請元の企業が実在しているかを確認したりする。
二つ目の役割は、失効の依頼を受けた電子証明書や秘密鍵の危殆化の可能性のある証明書を失効させること。 電子証明書の所有者が自分の秘密鍵を紛失したり盗まれたりして、その秘密鍵が悪意のある者の手に渡ってしまった場合、本来の所有者になりすますこと が出来てしまう。その為、所有者は秘密鍵を盗まれてしまった場合等は、そのことを直ちに認証局に届け出て証明書の失効処理を行わなければならな らない。届け出を受けた認証局は失効した証明書のリストを公開する。証明書の失効情報の公開の仕方には現在大きく分けて2つ存在する。 CRL(Certificate Revocation List)の配布 OCSP(Online Certificate Status Protocol)による問い合わせへ応答 CRL(証明書失効リスト)とは、認証局が失効させた電子証明書の リストで認証局から発行される。利用者はCRLを確認することで、電子証明書が失効していないかを確認することが出来る。 OCSPとは電子証明書の失効問い合わせの為のプロトコルで、電子証明書の提示を受けたアプリケーションはその電子証明書の有効性をOCSPに問 い合わせる。 OCSPでは自分が管理している失効リストに問い合わせのあった電子証明書がないかどうかを確認し返答。 また、電子証明書を失効させるのは秘密鍵が失われた場合だけではない。 電子証明書の記載事項が変更された場合も失効の対象となる(電 子証明書を所有している企業の社名やURLが変更された時は所有者は認証局に連絡して電子証明書の失効を申し出る)。
18.
補足(認証局:その2) 認証局は、電子証明書の 申請者が提出した所有者情報を審査する機関である登録局(Registration
Authority)、登録局からの要求に基づいて実際に電子証明書の発行や失効を行う機関である発行局(Issuing Authority)、ならびに認証局に関する情報や電子証明書の有効性に関する情報を提供するリポジトリ(Repository)から構成されている。 リポジトリの公開を義務付けている認証局では、リポジトリからルート証明書や中間証明書、CRLをダウンロードすることが出来る。 認証局には、2種類の形がある。1つはVeriSign等のパブリック認証局。パブリック認証局が発行する電子証明書のルート証明書は一般的なブラウザやメールソフトに予め組み込まれており、ルート証明書の配布やインストールが不要な為、取引先など外部とのやり取りに電子証明書を利用す場合に煩雑な設定が必要なく便利。2つ目は、事業会社等が独自の運用基準を設けて設立したプライベート認証局。プライベート認証局はルート証明書の配布や設定等に手間が掛かるが、運用規程を自由に設定出来る為、社内だけなど限られたネットワークで電子証明書を利用する場合はプライベート認証局を設立し電子証明書を発行する方が便利。
19.
SSLサーバ証明書の種類 ドメイン認証:サーバ証明書の所有者が証明書に記載されるコモンネーム(URL)の所有者であることを認証するもの。証明書に記載されるコモンネーム(URL)は偽装が出来ない為、アクセスユーザは証明書を確認することで、自分のアクセス先を知ることが出来る。 企業実在認証:証明書に記載される組織が法的に存在すること、またその組織が証明書に記載されるドメインの所有者であることを認証するもの。
Extended Vlidation(EV SSL):証明書に記載される組織が、法的かつ物理的に実在し、またその組織が証明書に記載されるドメインの所有者であることを認証するもの。EV SSLは世界標準の認証ガイドラインがあり、サーバ証明書の中で最も厳格な審査が行われる。
20.
認証局の信頼性 電子証明書は階層構造になっており、下位の認証局は上位の認証局に証明書を発行してもらうことで、その信頼性を担保している。階層構造の最上位に位置する認証局をルート認証局と呼び、ルート認証局自身は自分自身に対して電子証明書を発行している。
では、ルート認証局自身は何故信頼出来ると言えるのか?多くの認証局では信頼されるルート認証局であり続ける為に、WebTrust for CAという厳正な監査基準に基づく審査を受ける。WebTrust for CAとはインターネット事業者が国際的な電子商取引保証規準に基づいた電子商取引を行なっているかを審査するサービスで、審査に合格したインターネット事業者には審査報告書とWebTrustシールが付与され、消費者はWebTrustシールをクリックすることで審査報告書 を確認することが出来る。 ルート証明書:ルート認証局が自分自身に対して発行した証明書のこと。電子証明書の 提示を受けた場合、本来であれば階層構造の根幹まで遡り、信頼出来る認証局から発行されている電子証明書であるかを判断しなければならないが、そ の都度確認するのは非常に手間がかかり現実的ではない。そこで代表的なブラウザやメールクライアントには、 WebTrust等の厳しい監査基準を満たした認証局の ルート証明書が予め搭載されており、ソフトウェアの利用を通して意識することなく電子証明書の信頼性を確認出来る様にしている。 つまりソフトウェアはWebTrust for CAの監査基準を満たした認証局を信頼し、ユーザはソフトウェアを信頼する。この信頼の繋がりによってユーザは個別に認証局を調べることなく、ブラウザ の利用を通して意識することなく証明書の信頼性を確認出来る。 証明書の信頼性:データの送信先を信頼するには、証明書自体が信頼出来るものでなければならない。電子証明書は知識さえあれば誰でも発行することが出来、例えばオ レオレ詐欺の様に自ら発行した証明書(自己署名の証明書)で他人になりすますことも出来る。そこで証明書に信頼性を持たせる為に、信頼の出来る第三者認証機関から発行された証明書を使用することが必要になる。 信頼性のない電子証明書を使用した場合:ブラウザからセキュリティ警告が発せられる。