SSL/TLSの基礎知識
- 前回の勉強内容
- 勉強のきっかけになった問題
- インターネット上でのデータの通信を暗号化したプロトコルをSSLといいます。
- SSLが進化してTLSができました。
- SSL/TLSでのクライアントとサーバでのやり取りではディジタル証明書が使われます。
- SSL/TLSは新しいバージョンを使用しないと攻撃を受ける可能性が高まります。
- 次回の勉強内容
前回の勉強内容
勉強のきっかけになった問題
- 暗号化通信中にクライアントPCからサーバに送信するデータを操作して,強制的にサーバのディジタル証明書を失効させる。
- 暗号化通信中にサーバからクライアントPCに送信するデータを操作して,クライアントPCのWebブラウザを古いバージョンのものにする。
- 暗号化通信を確立するとき,弱い暗号スイートの使用を強制することによって,解読しやすい暗号化通信を行わせる。
- 暗号化通信を盗聴する攻撃者が,暗号鍵候補を総当たりで試すことによって解読する。
インターネット上でのデータの通信を暗号化したプロトコルをSSLといいます。
- 正式名称 : Secure(安全な) Sockets(受け口) Layer
通常インターネット上での通信は「http(HyperText Transfer Protocol)」で行われますが、送受信されるデータは暗号化することができず、盗聴や改ざんを防げません。
しかし、SSLプロトコルを使用することで通信データは暗号化され、第三者が盗み見しようとしても解読することができません。
https://jp.globalsign.com/service/ssl/knowledge/
SSLで暗号化されたサイトのURLは「https」になります。
- 正式名称 : HyperText Transfer Protocol Secure
- 別名: HTTP over TLS
上記のサイトも暗号化されていてURLの先頭は「https」になります。
攻撃者が社内ネットワークに仕掛けたマルウェアによってHTTPSが使われると、通信内容がチェックできないので、秘密情報が社外に送信されてしまいます。
HTTPSではクライアント-サーバ間の通信が暗号化されます。このため、もし通信経路上にプロキシサーバ等が介在したとしても内容のチェックはできません。
応用情報技術者平成29年春期 午前問44
SSLを利用するWebサーバでは、そのFQDNをディジタル証明書に組み込みます。
ディジタル証明書のコモンネームにFQDNを設定します。
ディジタル証明書のコモンネームとサーバに設定されているFQDNを比較して、一致していたらSSL通信を開始することができます。
Google ChromeではFQDNのコモンネームへの設定は非推奨なのでSubject Alternative Nameに設定します。
SSLが進化してTLSができました。
インターネットなどのTCP/IPネットワークでデータを暗号化して送受信するプロトコル(通信手順)の一つです。
データを送受信する一対の機器間で通信を暗号化し、中継装置などネットワーク上の他の機器による成りすましやデータの盗み見、改竄などを防ぐことができます。
インターネットに接続された利用者のPCから,DMZ上の公開Webサイトにアクセスし,利用者の個人情報を入力すると,その個人情報が内部ネットワークのデータベース(DB)サーバに蓄積されるシステムがある。このシステムにおいて,利用者個人のディジタル証明書を用いたTLS通信を行うことによって期待できるセキュリティ上の効果はどれか。
- PCとDBサーバ間の通信データを暗号化するとともに,正当なDBサーバであるかを検証することができるようになる。
- PCとDBサーバ間の通信データを暗号化するとともに,利用者を認証することができるようになる。
- PCとWebサーバ間の通信データを暗号化するとともに,正当なDBサーバであるかを検証することができるようになる。
- (答え)PCとWebサーバ間の通信データを暗号化するとともに,利用者を認証することができるようになる。
出典 : 平成30年 秋期 応用情報技術者試験 午前問40
TSLの特徴
TSLの生い立ち
- 1990年代 : SSLをNetscape Communications社が開発
- 1999年
- 2006年 : TLS 1.0で発見された新たな攻撃手法への対処など改良を加えたバージョンとして、TLS 1.1がRFC 4346として公開される
- 2008年 : より安全性の高いハッシュを利用できるようにするなど改良を加えたTLS 1.2がにRFC 5246として公開される
- 2014年 : SSL 3.0に一定の条件の下で通信の一部が第三者に漏えいする可能性があるPOODLEが報告される
- 2018年 : TLS 1.3がRFC 8446として公開される
SSL/TLSでのクライアントとサーバでのやり取りではディジタル証明書が使われます。
- クライアントからのSSL/TLSによる接続要求に対し,Webサーバは証明書をクライアントに送付する。
- クライアントは,保持している認証局の公開鍵によってこのサーバ証明書の正当性を確認する。
- クライアントは,共通鍵生成用のデータを作成し,サーバ証明書に添付されたWebサーバの公開鍵によってこの共通鍵生成用データを暗号化し,Webサーバに送付する。
- 受け取ったWebサーバは,自らの秘密鍵によって暗号化された共通鍵生成用データを復号する。
- クライアントとWebサーバの両者は,同一の共通鍵生成用データによって共通鍵を作成し,これ以降の両者間の通信は,この共通鍵による暗号化通信を行う。
利用者個人のディジタル証明書を用いたTLS通信を行うことによって、PCとWebサーバ間の通信データを暗号化するとともに利用者を認証することができるようになります。
TLS通信では、必須のサーバ認証とは別にオプションでクライアント認証を行うこともできます。利用者PCと通信を行うWebサーバは、利用者個人のディジタル証明書に付された認証局の署名を検証することで、ディジタル証明書の正当性を確認します。ディジタル証明書が正当なものならば、利用者(クライアント)の真正性が証明されます。
平成30年秋期問40 TLS通信で期待できるセキュリティ効果|応用情報技術者試験.com
SSL/TLSは新しいバージョンを使用しないと攻撃を受ける可能性が高まります。
ダウングレード攻撃は、暗号化通信を確立するとき弱い暗号スイートの使用を強制することによって解読しやすい暗号化通信を行わせる攻撃です。
Logjamは、DH鍵交換で使用するアルゴリズムの強さを輸出グレードの暗号で使用する 512ビット以下に格下げします。
TLS プロトコルは、DHE_EXPORT 暗号スイートがサーバで有効になっており、クライアントではなっていない場合に、DHE_EXPORT が選択されたことをクライアントに適切に通知しないため、暗号アルゴリズムのダウングレード攻撃を実行される脆弱性が存在します。
本脆弱性は、"Logjam" と呼ばれています。
JVNDB-2015-002764 - JVN iPedia - 脆弱性対策情報データベース