- ホーム >
- 基礎知識 >
- インターネットの仕組み >
インターネットのセキュリティ（2） ～ SSL/TLSとは ～
インターネット上でやり取りされるデータは、何もしなければ誰にでも見える状態で通信されており、特に電子メールは盗聴や改ざんの危険にさらされています。
こうしたハガキのような状態のデータを「平文（ひらぶん）」と言います。
これまで、平文のデータを暗号化するために様々な方法が考えられてきました。しかし、インターネットの発展にともなって暗号解読の技術も進歩し、追いかけっこのように安全性に対する懸念は絶えることがありません。
いまやAmazonやGoogleをはじめとするオンラインサービスの利用は日常的になってきましたが、クレジットカード情報などをやり取りするには強固な暗号化技術が必須になるのです。
電子メールのセキュリティ 編で学習してきたとおり「公開鍵暗号方式」の誕生によって、暗号通信は大きく飛躍しました。公開鍵を配布する仕組みによって、誰もが暗号通信をすることができるようになったのです。
そして公開鍵暗号方式を利用した様々な通信の仕組みが開発されてきました。中には脆弱性が発見された技術もありますが、公開鍵暗号方式そのものの解読方法が確立されたわけではありません。
そのため、現代の暗号技術のベースになっているのは公開鍵暗号方式です。電子メールにおいてはSMTPSやSTARTTLS、S/MIMEなどの仕組みを学習してきました。これらも公開鍵暗号方式をベースとしています。
様々な仕組みがあって混乱しがちですが、電子メールの拡張規格 で学習したとおり、暗号通信には大きく2つの概念があります。重要な概念なのでよく理解しておきましょう。
それは、
経路の暗号化とデータの暗号化
です。
経路の暗号化とは、例えば電子メールであればメーラーからメールサーバまでの経路という意味です。ある地点からある地点までの一定の経路が暗号化され、一般的にそこを通過するデータがすべて暗号化されます。
ある地点からある地点までの「トンネルをつくる」イメージです。トンネルを通過するデータはすべて保護され、外部からは見ることができなくなります。
データの暗号化は、文字どおり特定のデータを暗号化します。どの経路を通過しようと問題ではなく、データ自体が送信元から送信先に到着するまで暗号化されたままです。
こちらは経路途中でデータを盗み見される可能性がありますが、中身が暗号文であるためリスクとみなしません。ただし、暗号化されるのは特定のデータだけになります。
電子メールの危険性 で学習したSMTPSやSTARTTLSは経路の暗号化、S/MIMEはデータの暗号化に分類されます。
多くの仕組みがあってややこしいですが、SMTPSはメーラーから送信サーバまでの経路、POP3Sは受信サーバからメーラーまでの経路にトンネルをつくって保護します。
ただし、トンネルをつくるということはトンネルから出てしまう可能性があるということです。
つまり、経路の暗号化は、
平文に戻る可能性がある
ことになります。
例えば、SMTPSで送信されたメールが受信者のメールサーバに到達し、そのサーバが仮にPOP3Sに対応していなかった場合、そのメールは平文で処理される可能性があります。
電子メールにおいては、送信サーバと受信サーバが異なることや7ビット制限などの要因があり、メールの送信から受信までのすべての経路にトンネルをつなぐことが困難になっています。
そのため、 データの暗号化技術であるS/MIMEを組み合せなければ完全にセキュリティが確保できませんでした。
しかし、学習のとおりS/MIMEでは一貫して暗号通信が行るものの、設定できるのは特定の相手との通信だけになります。送り手と受け手の双方がS/MIMEに対応している必要性があり、全員と暗号通信を行えるわけではありません。
このように、どちらもメリットとデメリットがあります。どちらの方法が優れているというわけではありませんが、一般的には経路の暗号化技術が広く利用されています。ある意味、電子メールの通信が特別と言っていいかもしれません。
本項では、インターネットの主役であるウェブサイトの利用における暗号通信、つまり、WWWサーバとブラウザ間の暗号通信について詳しく学習します。
まずは、代表的な技術の仕組みから理解していきましょう。
SSL（エスエスエル）
SSLは「Secure Socket Layer」の略で、暗号化通信を行うためのプロトコルです。
POP3SやSMTPSの「S」はSSLを意味しています。
WWWサーバ（ウェブサーバ）とブラウザの通信に用いられるHTTPプロトコルに、データを暗号化するセキュリティ機能、ユーザー認証機能を追加したプロトコルになります。
OSI参照モデルではトランスポート層のセキュリティ強化に使用され、TCP/IPプロトコルを利用するすべてのアプリケーション層、プレゼンテーション層（HTTP、FTP、POPなど）からも利用することができます。（OSI参照モデルについては、プロトコルとは を参照してください）
先述のとおり経路を暗号化する技術で、ウェブサーバやメールサーバとクライアント（ユーザー）のブラウザやメーラー間の通信を暗号化します。HTTP以外のプロトコルにも適用可能ですが、主にHTTPの暗号化に利用されています。
暗号化には、
ハイブリッド暗号方式
が採用されています。
データの暗号化と復号化には共通鍵暗号方式を使い、送信時には公開鍵暗号方式を使う方式です。（詳しくは、電子メールのセキュリティ 編を参照してください）
SSLが利用されているウェブページでは、URIが「http」ではなく、下図のように「https」に変化し、さらに「鍵」マークが表示されます。「https」は「HyperText Transfer Protocol over Secure Socket Layer」の略になります。
SSL通信の流れは、下図のようになります。
まず、SSLを利用するAmazonなどのウェブサイトの運営者は、自身のサーバを証明する電子証明書を作成します。
電子証明書は、認証局（CA）とPKI で学習のとおり、自分で作成する自己署名証明書（オレオレ証明書）を利用することも可能ですが、それではまったく信頼性がないので、信頼ある認証局に発行してもらいます。
この電子証明書を、
サーバ証明書（SSLサーバ証明書）
と言います。
サーバ証明書によって、サーバのドメインや運営者の正当性を証明し、証明書に含まれるかたちでサーバの「公開鍵」をクライアントに配布しています。（ドメインについて詳しくは、クラスとドメイン を参照してください）
次に、クライアント（ブラウザ）がHTTPSでウェブページにアクセスすることにより、サーバにSSLでの接続要求を行います。
そしてサーバは、サーバ証明書をクライアントに提供し、クライアントは証明書の改ざんとなりすましの検証を行います。
このときの検証は、サーバ証明書に付けられている認証局のデジタル署名を、ユーザーのパソコンに事前にインストールされている認証局のルート証明書（自己署名証明書）の公開鍵で検証します。
検証が正しければ、そのサーバ証明書は認証局から発行された正当な証明書であることが証明され、ひいてはそれが証明しているウェブサーバ（ウェブサイト）を信頼することができます。（検証のプロセスについては、電子証明書とPKI を参照してください）
ただし後述しますが、ここで証明できるのは、その電子証明書の取得申請をした人または組織が作成したウェブサイトに間違いないということだけです。例えば、そのウェブサイトが「トヨタ自動車のウェブサイトに間違いない」ことを証明するものではありません。
次に、クライアント側で「共通鍵」を作成します。これは、SSLに対応したブラウザの機能で自動的に作成されます。
そして、
サーバ証明書から取り出した公開鍵で共通鍵自体を暗号化してサーバへ送信する
のです。
サーバは暗号化された共通鍵を受け取り、自身の秘密鍵で復号化します。以降の通信は、双方が「共通鍵」を用いて通信します。これがSSLにおける公開鍵と共通鍵のハイブリッド暗号方式になります。
厳密には、共通鍵を送信するのではなく、共通鍵のもとである「乱数」を暗号化して送信し、WWWサーバ側でもそれをもとに共通鍵を作成して通信するのですが、要旨は同じであり共通鍵を送信するという解釈で問題ありません。
共通鍵を使うメリットは、公開鍵暗号化方式とは で学習のとおり処理速度が速いためです。公開鍵暗号方式で通信すると処理が複雑なため、処理に時間がかかり速度が遅くなります。
また、共通鍵暗号化方式を使うもうひとつの理由は、サーバ側がユーザーの公開鍵を持ち得ないためです。
ユーザーの公開鍵がなければデータを送り返すことができません。ユーザーの公開鍵を入手するには、ユーザーに電子証明書を購入してもらう等の処理が必要になってしまいます。
つまり、ハイブリッド通信を行うことで、ユーザーに負担をかけることなく安全で高速に暗号化通信が行えるようになります。
SSL通信を行うには、サーバとブラウザの双方がSSLに対応している必要がありますが、現在のモダンブラウザで対応していないものはありません。
また、サーバ証明書を発行しているほとんどの認証局のルート証明書も事前にパソコンにインストール（プリインストール）されています。詳しくは後述しますが、無料でサーバ証明書を発行している認証局もあります。
比較的新しい認証局のルート証明書がプリインストールされていない場合は、プリインストールされている他のルート認証局が証明する「クロス署名」などの方法が用いられます。
このように、SSLにおいても公開鍵暗号方式である以上、信頼性のある第三者証明としての「電子証明書」が重要になっています。
では、それを踏まえて、先述した経路の暗号化とデータの暗号化について考えてみましょう。
SSLの場合、通信経路はサーバとブラウザ間だけであり、トンネルをかける経路が複雑ではありません。そのため、基本的にすべての経路で安全に通信を行うことが可能です。
とは言え、インターネットは様々なネットワークや機器がつながっており、どの経路を通るかわかりません。100％すべての経路で暗号化が行われていると断定することは困難です。
そこで、SSLでは以下の方法で安全性を高めています。
通信経路（トンネル）が確立してから通信を行う
上の図で言うと、クライアントがサーバからサーバ証明書を取得して検証し、共通鍵を交換することで経路が確立します。
データの暗号化も行う
経路の暗号化だけでなく、データの暗号化も行います。
上の図で言うと、共通鍵を使ったデータのやり取りがデータの暗号化になります。データを暗号化することにより、経路途中でSSLに対応していないサーバや機器を経由した場合でも平文に戻ることはありません。
つまり、公開鍵暗号方式で経路の暗号化を行い、共通鍵暗号方式でデータの暗号化を行っているということです。
このように、SSLは経路の暗号化とデータの暗号化の両方を実現する技術です。そのため、非常に強固な暗号通信の仕組みと言えます。実際のところ、経路の暗号化はデータの暗号化も行うことが一般的になっています。
少し脱線すると、S/MIMEは公開鍵暗号方式でデータの暗号化を行う技術になり、事項で学習するVPNという経路の暗号通信技術の中には、データの暗号化を行わないものもあります。
様々な技術があって暗号通信の仕組みを理解することが難しくなっていますが、基本的な概念をしっかり理解しておきましょう。
では次に、SSLの種類を知っておきましょう。
種類といってもセキュリティのレベルが異なるというわけではありません。
サーバ証明書に種類がある
ということです。
サーバ証明書には公開鍵を配布して暗号通信を行うほかに、もう一つ重要な役割りがあります。
それは、
ドメイン（ウェブサイト）の正当性を証明する
という役割りです。
デジタル署名とは で学習した「デジタル署名」と同じです。サーバ証明書のデジタル署名を検証することによって、クライアントはそのサーバ（ウェブサイト）が正当なものであることを確認します。
電子証明書は、認証局が申請者本人で間違いないことを証明するものです。つまり、SSL化することによってウェブサイトが正当なものであることをアピールできるのです。
この認証局による証明の度合いによってサーバ証明書にランクがあるということです。ただ、どのような証明書であっても暗号方式は同じであり、セキュリティレベルの高低はありません。
DV証明書（ドメイン認証）
もっとも安価で認証レベルの低い証明書になります。
DVは「Domain Validation」の略で、ドメインの使用権までを認証（Validation）します。
具体的には、当サイトのサーバ証明書がこれに該当します。当サイトのドメイン「yamanjo.net」の使用権が正当なものかどうかだけを証明しています。
通常、ドメインを取得するには、ドメイン取得サイトなどから申請者の情報を提供してドメインの所有権を得ます。このときの情報は、Whois（フーイズ）というデータベースへの登録が義務付けられています。
Whoisは、ドメイン名に関連する登録情報などをインターネット上で検索して参照できるサービスで、ドメインの所有者情報は全世界に公開されているのです。
したがって、当サイト「yamanjo.net」でWhois検索すると申請者である管理人の情報が公開されています。
義務付けられているため、公開したくない個人情報であっても公開されることになります。（ドメインを取得したサイトの運営企業の情報を代理で公開するなどの方法があります）
下図は、日本のトップレベルドメイン「jp」を検索できるWhois検索ページです。気になるドメインがあれば、ここで検索すると登録者情報を確認することができます。
ただし、上記サイトは「com」や「net」など、gTLDのドメインは検索できない場合があります。（当サイトのドメイン「yamanjo.net」は検索できません）
簡単なDV認証では、このWhois情報に登録されているメールアドレスにメールを送信し、メールのリンクをクリックして認証する程度で証明書が発行されるものもあります。
つまり、
申請者（サイトの運営者）の身元まで証明しない
ということです。
証明書自体は正しい手順で発行されたもので信用して問題ないのですが、比較的容易に取得できることから、DV認証を受けた偽サイトを作ることが可能になるのです。
例えば、「東京第一銀行」という企業が「tokyodai1.jp」というドメインを取得して、オンラインサービスを展開していたとします。そこで、悪意のある人が「tokyodail.jp」というドメインを取得します。
両者の違いは数字の「1」と小文字のエル「l」です。明らかに疑わしいアドレスですが「tokyodail.jp」のドメインを取得して、DV証明書を取得することが可能です。
あとは、東京第一銀行とそっくりのサイト作成し「tokyodail.jp」へのリンクを貼り付けたメールを送り付ければ、フィッシングサイトの完成という具合です。
つまり、先述のとおり「申請者とサイトの運営者が同一である」という証明にすぎません。
仮に同じような偽サイトが存在するとして、
SSLの鍵マークだけではそのサイトが本物であるかどうかの証明にはならない
ということです。
実際に、多くのフィッシングサイトがDV証明書を取得しており、手口が非常に巧妙になっています。
近年ではウェブサイトのSSL化が標準仕様になっており、DV証明書も無料で取得できるケースが増えてきました。有名なものに「Let's Encrypt（レッツ エンクリプト）」という米国の認証局が無料で発行するDV証明書があります。
Let's Encryptは世界最大の認証局の1つで、認証局として疑わしいところはまったくありませんが、申請の受付から証明書の発行まですべて自動化されていて、有効期限は90日と短いものの、数分のうちにDV証明書を取得することができるようになっています。
そのため、非常に多くのサイトでLet's Encryptのサーバ証明書が利用されています。
まずは、いろいろなサイトでサーバ証明書を確認してみましょう。
証明書の中身は、多くのブラウザで同じような操作で確認することができます。Windows Edgeの場合は、アドレスバーに表示されている「鍵」アイコンをクリックし、「接続がセキュリティで保護されています」を選択し、「証明書」のアイコンをクリックします。
すると、「証明書ビューアー」画面が表示され、サーバ証明書の中身を確認することができます。
上図は、当サイトのサーバ証明書です。「発行先」がドメインの申請者情報になります。「共通名（CN）」に当サイトのドメイン名が記載されています。CNは「Common Name」の略で、詳しくは割愛しますが、通常ドメイン名と同じになります。
また「発行者」は認証局の情報になります。「GlobalSign」という認証局が発行した証明書であることがわかります。そのほか、有効期限やフィンガープリントが記載されています。
さらに「詳細」タブでは、より詳細な証明書の内容を確認することができます。（電子証明書の内容については、電子証明書とPKI を参照してください）
だだし、DV証明書であるので「発行先」の「組織（O）」や「組織単位（OU）」には「Not Part Of Certificate」の文字が記載されています。これは「証明書に記載がない」という意味で、この部分は証明していないという意味です。
つまり、申請者の「組織」情報（身元）は証明されていないことになります。
そのため、銀行などの信用を必要とする企業やインターネットサービスを展開する企業などは、DV証明書では不十分として、さらにグレードの高い証明書を取得する傾向があります。こうしたサイトで先述の「Let's Encrypt」の無料証明書が利用されている場合は、疑った方がいいかもしれません。
DV証明書は、もっとも安価で、主に個人や小規模な事業者が取得する証明書です。取得までの日数が短いため、クイック認証などと呼ばれる場合もあります。
OV証明書（企業認証）
OVは「Organization Validation」の略で、ドメインに加え、申請者である企業（組織）の正当性まで認証（Validation）します。
具体的には、認証局が実際に審査を行います。申請者の企業または組織が実在するかどうか公的なデータベース等で法的実在性を確認し、電話をかけるなどして申請者の所属と実在を確認します。
ドメインを運営する組織の正当性も認証するので、非常に信用度の高い証明書になります。そのため比較的高価です。
上図は、集英社のウェブサイトのOV証明書です。
DV証明書とほぼ同じですが、「発行先」の「組織（O）」に企業名（組織名）が記載されており、「SHUEISHA Inc.」という組織が認証されていることがわかります。Oは「Organization」の略で、組織を意味します。
「組織単位（OU）」が「<Not Part Of Certificate>」になっていますが、これは、2022年9月1日以降に発行するサーバ証明書で「OU（組織単位）」の項目利用が禁止されたためです。
OUは「Organizational UnitName」の略で、主に部署名などに利用されていましたが、Oとの関連があまりないことなどから廃止となりました。そのため、ここに記載がないのは問題ありません。
大手企業のサイトなどでは企業情報まで認証するケースが多いです。OV証明書の「O」に正しい組織名が記載されていれば、正当なサイトで間違いないと言えます。
仮に「O」の組織名に違和感があったとしても、少なくとも実在する組織であることは間違いありません。OV証明書を利用したフィッシングサイトを作成しようと思うと、実在する組織から作り込む必要があり、非常に困難になります。
クレジットカード情報などを登録するサイトでは、利用前にサーバ証明書を確認するようにしましょう。
ただし、なぜかAmazonのサーバ証明書はDV証明書が利用されています。（証明書の種類はユーザー行動に影響しないというデータもあるようです）
EV証明書（拡張認証）
EVは「Extended Validation」の略で、OV証明書よりも組織認証を強化したもっともグレードの高い証明書です。
より厳格に組織審査が行われるため、さらに信頼度が高まります。具体的には、登記簿を確認したり、経営者や担当者の身元に間違いがないか等を細かく審査します。
最上級に信用度の高い証明書で、非常に高価です。
上図は、楽天銀行のEV証明書です。
Windows Edgeの場合はOVと全く同じです。これでは、一般ユーザーは違いを判断することができません。
以前はアドレスバーが緑色になるなど、特徴的にアピールすることができていましたが、現在のEdgeでは下図のように、説明文に組織名「Rakuten Bank, Ltd. [JP]」が表示されるだけになっています。
ここに組織名が表示されるのはEV証明書だけです。
とは言え、EV証明書であることが一目で判断できないため、ユーザーへのアピール効果は以前よりも低くなってきています。高価なEV証明書を導入するメリットを見出すのはなかなか難しいですが、銀行のウェブサイトなどでは広く採用されています。
では最後に、SSLのバージョンについて知っておきましょう。
SSLは1.0から3.0までバージョンアップが行われてきました。たびたび脆弱性が発見されてきたからです。
これはSSLの技術的な脆弱性であり、先述のとおり公開鍵暗号方式そのものに脆弱性が発見されたというわけではありません。実を言うと、SSLはバージョン3.0までのすべてのバージョンにおいて脆弱性が発見されています。
つまり、
SSLの使用は非推奨（禁止）になっている
ということです。
それではこれまでの学習はなんだったのかとなってしまいますが、すでに1999年にはSSL3.0をバージョンアップするかたちで後継仕様が設計されています。
それが、
TLS（ティーエルエス）
というプロトコルです。
TLSは「Transport Layer Security」の略で、SSLの脆弱性を修正し、セキュリティ機能を向上させた次世代規格になります。
つまり、SSLという名称が広く普及してたため、
TLSも含めてSSLと呼ばれている
ということです。
ややこしいですが、現在では実質的にすべてTLSに変更になっています。しかし、TLSを指して今なおSSLと呼ばれているのです。さすがにわかりにくいので「SSL/TLS」と併記される場合もあります。
TLSも1999年のバージョン1.0から2006年にバージョン1.1、2008年にバージョン1.2、2018年にバージョン1.3がリリースされ、バージョンアップを続けています。
2024年現在では、TLS1.1以前のすべてのバージョンでモダンブラウザのサポートが停止になっています。
Windowsでは「コントロールパネル」→「インターネットオプション」→「詳細設定」タブで利用可能なTLSのバージョンを設定することができます。
原則として、脆弱性が発見された古いバージョンを無効にし、その時の最新バージョンを使用することが重要です。（ブラウザによってWindowsの設定を利用するものやブラウザ独自で設定が必要になるなものがあります）
しかし、Windows10ではTLS1.3が有効化されていません。Windows11では下図のとおりデフォルト（初期設定）で有効になっているので、Windows10を使用の方は有効にしておきましょう。
長くなりましたが、以上でSSL/TLSについての学習は修了です。
現在では、サーバ証明書を取得して自社や個人のウェブサイトをSSL/TLS化することがすでに一般的になっています。特に、Let's Encryptに代表される無料証明書の登場で一気に広がりました。
すでに、httpsで保護されていないhttpアドレスのページにアクセスすると警告が表示されるようになっています。
さらに、ブラウザがページを表示しなかったり、ファイルをダウンロードできなくなるなどの制限がかかるようになってきました。
問題のないサイトであることがわかっている場合には、Windows Edgeの場合「設定」→「Cookieとサイトのアクセス許可」→「セキュリティで保護されていないコンテンツ」より、サイトアドレスを追加してアクセスを許可することができます。
Let's Encryptは、すべてのサイトをSSL/TLS化することを目的としています。こうした動きから、ますますSSL/TLSの知識が重要になってきます。基礎からしっかり理解しておきましょう。
更新履歴
- 2009年8月14日
- ページを公開。
- 2009年8月14日
- ページをXHTML1.0とCSS2.1で、Web標準化。レイアウト変更。
- 2018年2月1日
- ページをSSL化によりHTTPSに対応。
- 2024年4月26日
- 内容修正。
参考文献・ウェブサイト
当ページの作成にあたり、以下の文献およびウェブサイトを参考にさせていただきました。
- 文献
- 図解入門 インターネットのしくみ
- SSLは無料と有料で何が違うの！？今さら聞けないSSLの仕組みと導入のメリット
- https://www.cpi.ad.jp/column/column08/
- 「このサイトは安全ではありません」の解決方法！IEとEdgeエラーメッセージ一覧
- https://security.data-site.info/882.html
- オレオレ証明書はもう古い！「Let's Encrypt」で無料SSL証明書を使おう！
- https://sakiot.com/use-lets-encrypt-for-ssl/
- 管理人のつぶやき
- Twitterのフォローお願いします！