Internet Infrastructure Review（IIR）Vol.33
2016年12月15日発行

Mirai Botnetとは

Mirai Botnet（以下、Mirai）は、ネットワーク接続可能なカメラやデジタルビデオレコーダーなどのIoT機器に感染し、ボットネットを構築するマルウェアです。IoT機器は単体では大きな処理能力は有していませんが、大量の機器が攻撃に利用された場合、非常に強力な攻撃を起こすことができます。多くのIoT機器は適切にセキュリティ管理がされておらず巨大なボットネットが形成されやすいと言えます。

2016年9月下旬に、アメリカのセキュリティ情報サイト「Krebs on Security」やフランスのインターネットサービスプロバイダであるOVHに対して大規模なDDoS攻撃が発生しました（※60）（※61）が、この攻撃にMiraiが使用されたと言われています。Krebs on Securityでは最大665Gbps、OVHでは最大1Tbpsという、かつて発生したことがない規模のDDoS 攻撃を受けました。その後、10月上旬にAnna-senpaiと名乗るMiraiの作者が突如ソースコードを公開しました。現在、Anna-senpaiが公開したソースコードにはアクセスすることはできませんが、ソースコードは各所にミラーリングされ、誰でもアクセスすることができる状態にあります。

本稿では、公開されたソースコードを基にMiraiの動作を解説した上で、Miraiの検知や感染有無の判断方法と対策を解説します（※62）。

Miraiのシステム構成と動作

Miraiの最小のシステム構成は図-14のようになっています。IoT機器はx86以外のCPUを使用していることも多いため、MiraiではARMやMIPSのバイナリをクロスコンパイルするためのシェルスクリプトも付属しています。このシェルスクリプトにはいくつかのビルドオプションを指定することができますが、「ssh」オプションは実装されていないため「telnet」オプションのみが意味を持ちます。また、Miraiに関連する通信はすべて平文で行われています。

拡大する

図-14 Mirai Botnetシステム構成

IoT（Bot）

Miraiに感染し、ボットとなったIoT機器です。MiraiがIoT機器に感染すると、watchdog timerを無効にし、自動的にリブートしないようにします。また、ローカルホストの48101/tcp への接続可否で他のMiraiボットのインスタンスが動作しているか判断します。動作している場合、該当するプロセスを終了させます。次に自身のプロセス名をランダムな文字列に変更します。ここまでの処理が成功すると、起動成功の目印として標準出力に「listening tun0」を出力します。後述する通信⑤の処理でも、この文字列をチェックすることでダウンロードしたボットの起動が成功したことを確認します。その後、22/tcp、23/tcp、80/tcpをバインドしているプロセスを終了させ（※63）、Miraiがこれらのポートをバインドすることで管理インタフェースにアクセスできないようにします。他にも、実行パスに「.anime」を含むプロセス、実行ファイルが削除されているプロセス、Qbot/Zollard/Remaitenのプロセスなどを終了させます。このように管理系のプロセスやマルウェアなどを終了させることで、Miraiに感染したIoT機器が復旧させられたり、他のマルウェアに乗っ取られることを防ぎます。また、C＆CサーバやScan Receiverのドメイン名やポート番号、他のIoT機器へのログイン試行で使用する認証情報などは、難読化のため、キーである0xdeadbeefを1バイトごとに分割した値を用いて、1バイトずつXORされています。

• 通信①：ボットにハードコーディングされたC＆Cサーバのドメイン名とポート番号に接続します（デフォルト： cnc.changeme.com, 23/tcp）。TCPセッションが確立した後に、表-1のフォーマットのデータをC＆Cサーバに送信すると、ボットがC＆Cサーバに登録されます。また、60秒ごとに表-2のデータフォーマットでハートビートがボットから送信されます。一方、C＆Cサーバからボットに対しては、必要に応じて表-3のデータフォーマットで攻撃命令が送信されます。このTCPセッションは永続的で切断されても自動的に再接続されます。

• 通信②：ランダムなIPv4アドレスの23/tcpに対してSYN スキャンを行います。ただし、10回に1回の割合で2323/tcpに対するSYNスキャンを行います。これは感染対象機器の一部がTelnetを23/tcpではなく、2323/tcpで提供しているためであると考えられます。なお、IPアドレスが表-4のものと合致した場合、再度ランダムなIPアドレスを選択します。SYNスキャンに反応があったIPアドレスに接続後、ボットにハードコーディングされた認証情報を使って、ログインできるか確認します。認証情報は表-5の61種類ありますが、それぞれに重みづけがされているため、すべての認証情報が均等に使われるわけではありません。この通信は、Miraiに感染している間、発生し続けます。

• 通信③：②でログイン試行に成功すると、ボットにハードコーディングされたScan Receiverに接続します（デフォルト：report.changeme.com, 48101/tcp）。TCPセッション確立後、表-6のデータフォーマットで認証情報を送信します。

拡大する

表-6 Scan Receiverに送信する認証情報のデータフォーマット

• 通信⑦：C＆Cサーバから攻撃命令を受け取ると、指定された攻撃対象に攻撃を行います。攻撃方法の詳細については、表-7を参照してください。なお、HTTP floodに関しては、DOSarrestとCloudFlareを認識するコードが実装されています。DOSarrestについてはDDoS対策サービスに対抗するためと思われるコードが実装されていますが、CloudFlare については認識をするのみで特に対抗するためのコードは実装されていません。更にソースコードには、「Proxy knockback connection」という実装予定と思われる攻撃の名前や、実装はされているものの呼び出しが行われない攻撃も存在します。

拡大する

表-7 DDoS攻撃一覧

拡大する

表-8 HTTP floodに使用されるUser-Agent

Scan Receiver

48101/tcpでボットのスキャン結果を受け取るサーバです。受け取った情報をパースして標準出力に出力するだけの簡易な機能を持っています。この出力結果を後述するLoaderに読み込ませます。

• 処理④：ボットから受け取ったログイン可能なIoT機器の情報をファイルコピーするなどして、Loaderの標準入力に入力します。公開されたソースコードでは情報の転送を自動的に行う仕組みは用意されていません。

Loader

入力されたログイン可能なIoT機器の情報を基に、実際の感染活動を行うサーバです。起動後、大量のスレッドを作成し、複数のIoT機器を同時に感染させることができます。

• 通信⑤：Scan Receiverから受け取った情報を基にIoT機器にログインします。ログイン後、busyboxのwget コマンドまたはtftpコマンドを使用して、ボットのバイナリをダウンロードして実行します。この時、IoT機器のCPUアーキテクチャに対応したボットのバイナリをダウンロードする必要がありますが、LoaderはIoT機器内の「/bin/echo」バイナリのELFヘッダを解析することでCPUアーキテクチャを判別します。wgetやtftpが使えない場合、IoT機器内の/bin/echoコマンドを使用して、ボットダウンローダを送りこんで実行します。感染に成功すると、「IoT（Bot）」と同様の動作を開始します。
• 通信⑥：Loaderにハードコーディングされた情報にしたがって、busyboxのwgetコマンドやtftpコマンドでボットのバイナリをダウンロードします（wgetデフォルト：100.200.100.100, 80/tcp, ファイルパス：/bins/mirai.[arch]（※64）（tftpデフォルト： 100.200.100.100, ファイル名：mirai.[arch]）。⑤で送り込まれたボットダウンローダも同様に、ハードコーディングされた接続先のHTTPサーバからボットをダウンロードします（デフォルト：127.0.0.1, 80/tcp, ファイルパス：/bins/mirai.[arch]）。

C＆C

Miraiボットネットを利用するために、管理者やユーザがログインするサーバです。ユーザのアカウントや攻撃実行履歴、攻撃先のホワイトリストがデータベースを使って管理されています。ユーザごとに利用可能なボットの数、最大攻撃継続時間、クールダウンタイムが設定されており、攻撃が終了してもクールダウンタイムで設定した時間が経過しないと次の攻撃を行うことができません。なお、攻撃の停止やボットの活動停止などのコマンドは用意されていません。

• 通信⑧：管理者またはユーザはC＆CサーバにTelnetで接続してボットネットを利用します。認証はユーザ名とパスワードで行われます。ボットもC＆Cサーバに23/tcpで接続しますが、23/tcpに接続直後のTelnet IACによって識別を行っています。使用できるコマンドは表-9を参照してください。攻撃コマンド例は図-15を参照してください。また、C＆Cへのログイン時の一部のメッセージはロシア語になっており、作者またその関係者がロシア語圏の人物であることを窺わせます（図-17 ）。

感染試行と感染有無の判断

ファイアウォールログ

ファイアウォール外部から内部に対して、23/tcpと2323/tcpへのアクセス数がおおよそ9対1になっているようであれば、Miraiの感染活動に晒されていると考えられます。送信先IPアドレスはランダムに選択されるため、一部を除きほとんどの組織が攻撃対象となります。逆にファイアウォール内部から外部に対して、23/tcpと2323/tcpへのアクセス数がおおよそ9対1になっているようであれば、内部の機器がMiraiに感染しているのはほぼ間違いないと考えられます。スキャン時の送信元IPアドレスは詐称されないため、感染している機器は簡単に判別することが可能です。

IDS/IPS

Miraiのシステム間の通信はすべて平文で行われているため、IDS/IPSで監視することができます。図-18に、Miraiの通信を検知するSnortシグネチャの一例を示します。公開されているソースコードを基にしているため、新バージョンのMiraiや亜種の通信は検知できない可能性があります。

拡大する

図-18 Snort用シグネチャ

対策

IoT機器メーカ

IoT機器のセキュリティを考える上で、メーカの役割は非常に重要です。Miraiに関する一連の事件を通して、多くのニュースやレポートでは対策として、IoT機器のパスワードを変更するように伝えています。確かに、非常に大量のIoT機器が感染していることの直接的な原因の多くはユーザがパスワードをデフォルトから変更していないことですが、一部の機種においてはパスワードがハードコーディングされており、変更はもちろん、アカウントの無効化などもできない状態であったことが伝えられています。このような状況では、ユーザ側で対応を行うことができないため、メーカ側に責任があると考えるべきではないでしょうか。メーカは以下のような観点でセキュリティ設計の見直しを行うべきでしょう。

• バックドアアカウントを作成しない。
• パスワードをハードコーディングしない。
• パスワードに使用できる文字種を極端に制限しない。
• すべての管理インタフェースをマニュアルに明記する（バックドアを実装しない）。
• TelnetやHTTPなど平文での通信は避ける。
• ユーザが最初にログインしたときにパスワードを変更させ、デフォルトパスワードは使えないようにする。

ユーザ

Miraiはファイルを残さず、メモリ上のみで動作するため、IoT 機器を再起動すれば感染から復旧させることができます。しかし、デフォルトパスワードのままではすぐに再感染してしまうため、パスワードを変更する必要があります。

IoT機器に限りませんが、パスワードはデフォルトから必ず変更しなければなりません。デフォルトの認証情報はマニュアルなどに記載されているため、攻撃者には既知の情報になっていると考えるべきです。そのため、デフォルトパスワードのままでは認証がない状態と同等であると言っても過言ではありません。パスワードを変更する場合、よく言われるように、可能な限り複雑で長いパスワードを設定することが望ましいでしょう。また、必要がないのであればIoT機器を直接インターネットに接続してはいけません。インターネットからアクセスする必要がある場合、IoT機器自身やファイアウォールなどで適切にアクセス制限を行ってください。

SSL/TLS バージョン推移の経緯

Netscape Communicationsから1995年に公開されたSSL2.0 はいくつかの拡張と問題点が修正され、SSL3.0（※65）として翌年公開されています。SSL2.0はHandshakeメッセージ部分に改ざん防止機能を有しない（データ完全性を保証していない）ため中間者攻撃が可能であり、プロトコルそのものが脆弱であると認識されています（※66）。またSSL3.0は2014年10 月に発覚したPOODLE攻撃（※67）によりメッセージの暗号化にCBC暗号モードを利用した場合にPadding Oracle攻撃が可能になることが分かり、現在は利用しないことが推奨されています（※68）。

SSLの後継であるTLSは現在3つのバージョン：TLS1.0（1999 年策定）、TLS1.1（2006年策定）、TLS1.2（2008年策定）があり、いずれも未だに広く利用されているプロトコルです。TLS1.0がSSL3.0をベースにIETFで策定された後、TLS1.1にてCBC暗号モード利用時に露呈するBEAST攻撃やその亜種への対策などを予め仕様に組み入れるなどの安全性強化を図っています。更にTLS1.2は認証暗号（AEAD：Authenticated Encryption with Associated Data）（※69）の利用が可能となりました。しかしこれらのプロトコルに対しここ数年で多くの攻撃がなされてきました。2015年2月に発行されたRFC7457（※70）は2014年頃までに公知となったTLSに対する攻撃の歴史がまとめられています。次に紹介するRC4ストリーム暗号に関する脆弱性が取り上げられているほか、利用者の想定よりも低いTLSバージョンを使用させるダウングレード攻撃や、圧縮機能を有効にしている場合に起こるタイミング攻撃など多岐にわたる既知の攻撃が取り上げられています。また、それ以降についてのSSL/TLSの主な脆弱性のポータルサイトとしてはCELLOS（※71）などで参照できますが、それぞれの攻撃に対して知識を積み上げ、その都度対処していくことは大変難しい状況になりました。

一例として暗号アルゴリズムのRC4とTripleDESに起こった事例を見ていくことにしましょう。RC4はSSL/TLSにおいてCipherSuitesが定義され、これまで多く利用されてきたストリーム暗号の代表格です。暗号アルゴリズムへの攻撃としては様々な攻撃モデルが考えられますが、SSL/TLSのような暗号プロトコルにおいて現実的な状況としてBroadcast setting と呼ばれる条件があります。これは同じ平文（暗号化される前のデータ）に対して複数の異なる鍵で暗号化された大量の暗号文が入手できる、という仮定でありSSL/TLSの利用形態を考えると十分に想定可能な条件です。この攻撃モデルのもと2001年から多くの暗号解読研究がなされており（※72）、RC4が生成するストリーム鍵の僅かな不均衡（バイアス）から平文を復元する攻撃が公開されています。具体的にはブラウザ上で不正なJavaScriptを動かせることによって大量の暗号文を生成するという手法が述べられており、USENIX Security 2015で発表された論文によると9×227の暗号文を入手することで94％の確率でcookieを搾取可能と報告されています（※73）。IETF としてもアカデミアによる複数の研究結果を鑑み、現実的な脅威として捉え2015年2月にRC4を排除する旨のRFCが発行されています（※74）。

一方でTripleDESが脆弱であると再認識されたSWEET32攻撃（※75）は、暗号アルゴリズムそのものに対する攻撃手法ではなく、SSL/TLSにてCBC暗号モードを利用する際に起こり得る潜在的な攻撃であり、完全に防ぐことはできないものとなっており、各ベンダーの対策もTripleDESの利用を制限もしくは格下げするというものでした。その一方で注意したいのはその攻撃が成功に至るまでに必要なリソースです。ACM CCS'16で発表された論文によると、2ブロック分のCookieを復元するためには785ギガバイトの暗号文をおよそ38時間もの間キャプチャし続ける必要があると報告されています（※76）。RC4バイアス攻撃はストリーム暗号RC4そのものに対する攻撃ですが、SWEET32攻撃は64ビットブロック暗号への攻撃ではあるもののCBC暗号モードの利用が必須であり、暗号アルゴリズムそのものの攻撃とは言い難い一面もあります。SWEET32攻撃が登場した際に、RC4を排除するRFC7465と同様にTripleDES の排除に関するインターネットドラフト（※77）が掘り起こされ、これを策定すべきかどうかについてCFRG（Crypto Forum Research Group）にて議論がありましたが、RFC化するには至りませんでした。

更に興味深いことをSWEET32攻撃は示唆しています。TripleDESもCBC暗号モードも未だにCRYPTREC暗号リストのうち電子政府推奨暗号リスト（※78）に掲載されながらも、この「安全な」2つのプリミティブを同時に利用したために脆弱になるという状況を引き起こしてしまいました。この事例は暗号アルゴリズムのミスユースとまでは言い切れませんが、このようなミスユースを想定した暗号アルゴリズムも想定されておりAEADのコンペティションであるCAESAR（※79）では、毎回異なるノンスを利用することが想定されているケースにおいて、誤って同じノンスを利用したとしても安全であることをメリットとするNonce Misuse-Resistantと呼ばれる性質を持つアルゴリズムも提案されています。そのほかのミスユース事例としてはDSA署名において同じパラメータを使って署名を行った場合に秘密鍵が漏えいすることが知られています（※80）。

以上のような暗号アルゴリズムのレイヤでの直接的な復元攻撃とは異なり、タイミング攻撃・サイドチャネル攻撃などにカテゴライズされる手法も進展があり、結果としてTLS1.0 及びTLS1.1では使用できないAEADに対応するためTLS1.2 への移行が望まれています。これはCBC暗号モードを利用していたとしてもTLS1.1以上のバージョンを利用することでBEAST攻撃やその亜種への対策が可能と考えられてきた一方で、TLS1.2に対してもタイミング攻撃が可能なLucky13（※81） 攻撃が登場したこともAEAD利用に拍車をかけることとなりました。更に、前述したようにRC4も使えないことからAEADへの移行が必要と認識されるようになりました。しかし各バージョンには実装必須のCipherSuitesがあることも考慮する必要があります。TLS1.0においては、TLS_DHE_ DSS_WITH_3DES_EDE_CBC_SHA、TLS1.1ではTLS_RSA_ WITH_3DES_EDE_CBC_SHAが実装必須（Mandatory）のCipherSuitesとして挙げられています。共に共通鍵暗号としてTripleDESをCBC暗号モードで利用するアルゴリズムが選択されています。またTLS1.2ではTLS_RSA_WITH_AES_128_ CBC_SHAが実装必須であり、AES利用となり、より安全なアルゴリズムにシフトしているものの、すべてのTLSバージョンにおいてCBC暗号モードの利用が必須となっています。これはRFC策定当時、CBC暗号モード利用時のパディングオラクル攻撃を想定していなかったと考えることができます。そのため、クライアント・サーバ共にCipherSuitesとしてCBC暗号モード利用のCipherSuitesを選択しない状況に置くことが必要です。特にサーバ側においては、選択されるべきCipherSuites の優先度を正しく設定することが必要となります。また、CipherSuitesの選択としては公開鍵暗号アルゴリズムとしてForward Secrecy（※82）対応のアルゴリズムを選ぶことが望まれている点も考慮すべきです。更にExport-grade暗号の設定についても注意が必要です。サーバ側のCipherSuites選択時により強い暗号アルゴリズムが選ばれることが通常の動作であるため、かつて使われていた弱いCipherSuitesを設定上残しておいたとしてもそれらは使われることはないだろうと考えられてきました。しかし2015年1月のFREAK攻撃や同年5 月のLogjam攻撃の発表（※83）によりExport-gradeな暗号アルゴリズムを設定しているがために起こってしまう攻撃が発覚しました。更に2016年3月にはDROWN攻撃（※84）が公開され、Export-gradeな暗号アルゴリズムを利用しない環境においてもSSL2.0を有効にしてしまっている状況下で暗号文の復元攻撃が可能であることが分かりました。

サーバが満たすべき設定基準の例

前パートにてすべてのSSL/TLSへの攻撃を加味してその都度対処していくことは大変難しい状況であることを述べました。本パートではWebサーバ管理者がどのような判断基準をを持ってWeb設定すべきか記載されたいくつかのドキュメントを紹介したいと思います。その1つとして、2015年5月にCRYPTRECから発行されたSSL/TLSサイトの暗号技術に関わる設定ガイドライン（※85）があります。プロトコルバージョン・サーバ証明書・CipherSuitesについて具体的にSSL/TLSサーバに要求される設定基準が示されています。このガイドラインは政府システムだけに特化して記載されているものではないため、民間で利用する一般的なWebサーバにおける設定改善のための参考書としても参照することができます。しかし公開後2年弱たったこともあり、現状とはそぐわない箇所も散見されるため、改訂や補遺が望まれます。更に各種アプライアンス製品の初期設定において、または手動で設定した場合にこのガイドラインの要件を満たすことができるかなどの詳細なレポートも発行され（※86）、より現実的な対策方法を入手できるようになってきました。そのほか日本語でも参照できる暗号プロトコルの安全性評価に関しては、例えば非営利団体であるCELLOS （暗号プロトコル評価技術コンソーシアム）からも公開されてきましたが、CRYPTRECの重点課題検討タスクフォースで2015年度検討されました。その結果、2016年度から暗号プロトコル課題検討WG（※87）が設置され、議論が行われています。

SSL/TLSブラウザベンダーからもWebサーバの設定に関する情報が集約されています（※88）（※89）。各論についてはここでは触れませんが、CipherSuitesの対応だけでなく、常時SSL/TLS化の要となるHSTS（HTTP Strict Transport Security）などについても記載されています。また、SSL/TLSサーバのテストサイトを提供しているQualys SSL Labでも設定のベストプラクティスに関する文書（※90）が提供されており、詳しい評価基準（※91）についても記載されているため、レイティングの理由だけでなくサーバ設定の改善点を知ることができます。一般ユーザでも当該FQDNを入力するだけで評価結果を参照することができるため、SSL/TLSサーバの設定不備が公知となってしまいます。そのため、レイティング結果が芳しくない場合には、ただ単に設定ミスなのか、一部のリスクを許容して設定しているのか区別がつかないという課題もありますが、弱い暗号アルゴリズムの移行を促進している点を考えると大変よい活動であると考えられています。

ブラウザベンダーの対応状況の変化

Webサイトのレイティングという観点では、ブラウザからも容易にサーバの状況を知ることができるようになりました。その1つがURLを記載するエリアにあるsecurity indicator であり、例えばEV SSL証明書利用サーバにアクセスすると緑のバーで表記されるエリアになります。Chromeではこのsecurity indicatorに関してバージョン52（Macintoshデスクトップのみ。それ以外はバージョン53）から表記方法に変化がありました。これは2016年6月に開催されたユーザビリティセキュリティを扱う国際会議で発表が行われ（※92）、この結果に基いて改善されたインタフェースが導入されています。この論文ではSSL/TLS接続状況をsecurity indicatorを通じて表示するアイコンについていくつかのバリエーションを被験者に提示した上で、よりよいものを選択するというアプローチを取っており、実際にChromeに実装されています。アイコン表示にはコネクションやサーバの信頼性に関する意味を持たせており、EV SSL証明書を持つ正しいHTTPS通信だけでなく、軽微なエラーを含むHTTPS通信、重大なエラーを含むHTTPS通信、などに応じて異なるアイコンが利用されています。このうち「軽微なエラーを含むHTTPS通信」については、HTMLコンテンツ内にHTTPで指し示されたコンテンツを有するMixed contents（HTTPコンテンツとHTTPSコンテンツの混在）という状況で表示されています。ブラウザベンダーはMixed contentsを起こしているサイトに改善を求めており（※93）（※94）、アップデート前のアイコンはニュートラルな印象を与えるアイコンでしたが、先の論文においてとても重大ではないがネガティブな印象を与えるアイコンを選択してユーザに注意を意識させています。このブラウザベンダーの変更にWeb管理者が対応できていないために、Mixed contentsエラーの出るHTTPSコンテンツを意図せず発信してしまっているSSL/TLSサーバが多く散見されており、今一度確認されることをお薦めします。

OSやアプリケーションが保有・管理し、信頼すべきルート証明書や中間CA証明書のリストを証明書ストア（Certificate store）と表現します。ブラウザなどのSSL/TLSクライアントはこの証明書ストアを参照し、当該Webサーバが信頼できるかどうかを判断してアプリケーション側でその状態を表示することが通例です。証明書ストアに格納されている証明書の削除・追加は可能なことが多いですが、通常利用時にはユーザは証明書を意識することはありません。そのため、SSL/TLSサーバはベンダーの証明書ストアの状況を把握して証明書を入手をする必要があります。これは各OSやアプリケーションで証明書ストアに含まれている証明書群が微妙に異なっており、同じ証明書でもある証明書ストアにおいては安全と判断される一方、他の証明書ストアではルートが辿れず証明書検証に失敗する事例が存在します。証明書を発行する認証機関においては、ベンダーの基準を満たすことができなかったために廃業に追い込まれた業者も存在しています。このようにトラストアンカーを創り上げる組織体に強く依存したモデルになっており、特にブラウザベンダーの動向が注目される事態を招いています。

証明書検証という観点ではもう1つ大きな問題があります。Andoroidにおいては証明書ストアにまつわる処理を正しく行わず、証明書検証時に検証処理を端折るアプリケーションの脆弱性がここ数年、大変多く報告されています。この例のように、利用ユーザはPKIを意識することなくアプリケーションのユーザインタフェースのみを閲覧するだけで当該通信の状況を把握することになっています。実際、先に見たように主要ブラウザベンダーの努力により利用ユーザはsecurity indicatorを通して通信状況を把握することができるようになっており、その他のチャネルで調査を行うことなく、ブラウザの表記を完全に信頼することが多くなっていると考えられます。SSL/TLSクライアントの1つであるWebブラウザは、通常のPCで閲覧するだけでなくタブレットやスマートフォンなど、より小さい表示領域しか持たないデバイスにおいて危険な通信であるかどうかをすぐに判断できるインタフェースを持つ必要があります。特に今後、表示能力が非力なIoT製品におけるsecurity indicatorについても考慮が必要です。

TLS1.3

TLS1.2の次期バージョンTLS1.3（※95）については2016年11月のIETF meeting 97（※96）にてTLS1.3ドラフトのTLS WGラストコールがアナウンスされ2017年2月のRFC発行に向けて佳境を迎えています。TLS1.3では特に実装必須のCipherSuites は指定されてはいませんが、従来利用されていたCBCモードの利用は想定されておらず暗号化とMAC（データ改ざんがなされていないことを示すデータ）を同時に付与するAEADのみがCipherSuitesとして列挙されています。AEADとしてはAEAD_AES_128_GCM、AEAD_AES_256_GCM（※97）、AEAD_ AES_128_CCM（※98）、AEAD_CHACHA20_POLY1305（※99）、AEAD_AES_128_CCM_8の5つがそれに該当し、CBC暗号モード利用のブロック暗号やストリーム暗号の代替アルゴリズムとして利用されます。TLS1.3は、それ以前のバージョンで生成されていたMAC（メッセージ認証用データ）用の鍵データを導出するインタフェースがないため、実質的にはAEADの利用だけに制限されることになります。

IETF meeting 97にて相互接続性結果が報告されたようにTLS1.3実装がブラウザ・サーバ共に進められており、一部の製品においてはユーザが手にとって確認することができるようになりました（※100）（※101）。TLS1.2とは互換性がないことからもバージョンのメジャーアップデート（TLS2.0、TLS2、TLS4）も提案されていましたが、会合ではTLS1.3支持派が多かったため、このままTLS1.3として普及されるでしょう。更に来年RFC 化されることで、多くの実装がTLS1.3に対応すると考えられます。一方で可搬性のあるデータ形式でブラウザ間を持ち歩くような利用状況も想定されていることから、この機能を突いた攻撃が発表されるかもしれません。そのほか、TLSへの耐量子暗号（※102）の適用も話題となりました（※103）。今後もレガシーデバイスにおけるバージョン移行の問題と新機能追加という正反対の動きで混沌とした状況が続いていくものと考えられます。