今回は、SSLインスペクションがどうやって暗号化通信を解析しているかをイラストを用いて解説していきたいと思います。
前提条件
本解説では、以下の前提知識を必要とします。
- Webサーバとクライアントの動作理解
- Web Proxyの動作理解
なお、本解説ではSSLインスペクションの動作原理について解説しています。
SSLインスペクション内で行われているパケットの処理については解説しておりません。
基本情報技術者試験以下のレベルで解説を行っております。
暗号化通信の登場人物
初めに、本解説で主になる暗号化通信で必要となる鍵について解説します。
暗号化通信を行うために必要なものは主に3つあります。
1つ目は、共通鍵です。
共通鍵は1つの鍵で暗号化と復号化の両方ができるという特性があります。
そのため、基本的にはこの共通鍵を使用して暗号化通信を実現しています。
いうなれば、暗号化するためのパスワードという感じでしょうか。
暗号化するためのパスワード(共通鍵)はアクセス元(クライアント側)で生成してWebサーバに送る必要があります。
2つ目は公開鍵です。
公開鍵は、暗号化専用の鍵で、後述の秘密鍵とセットで使用されます。
一般的に公開鍵はインターネット上に公開されてます。
なぜ、インターネット上に公開されていても問題ないかというと、この鍵は暗号化専用で復号ができないからです。一般的に公開鍵で暗号化されたデータは対応する秘密鍵が無いと復号化ができず、暗号化されたデータを収集しても内容が読めないため価値が無いからです。
近年流行のランサムウェアなどはこの法則を悪用し、公開鍵のような暗号化専用の鍵を使用し、企業のデータ等を暗号化して復号してほしければ身代金をよこせと要求してくる感じになります。
3つ目は秘密鍵です。
秘密鍵は、公開鍵と逆の性質を持っており、復号化専用の鍵になります。
また、復号できるのは、秘密鍵から生成した公開鍵のみとなります。
そのため、この秘密鍵が流出すると、公開鍵で暗号化したデータが流出した秘密鍵によって復号化されてしまい、暗号化通信の意味が無くなります。
秘密鍵の流出については、たびたび大きなニュースとなっていますが、大きなサービスで使用している秘密鍵が流出した場合、データが筒抜けになるため、損失が大きくなる傾向があります。
秘密鍵の取り扱いについては、慎重になりましょう。
暗号化通信の基本
本章では、暗号化通信(HTTPS)の基本を解説します。
暗号化通信の基本①として、HTTPSで通信をしたいクライアント側で共通鍵を生成します。
ここでは共通鍵が2本用意されていますが、同一の共通鍵となります。
2本生成した共通鍵のうち、1本はWebサーバ側に転送する用の共通鍵となります。
暗号化通信の基本②として、クライアント側で生成した共通鍵をインターネット上に公開されている暗号化専用の公開鍵で暗号化します。
公開鍵は対応する秘密鍵を持っていないと復号化できないため、公開鍵で共通鍵を暗号化した時点でインターネット上に公開しても問題ない状態となりました。
暗号化通信の基本③として、公開鍵で暗号化された共通鍵をWebサーバへ送付します。
暗号化通信の基本④として、Webサーバに送付された暗号化された共通鍵は、Webサーバの内部に保存された秘密鍵を使用して復号化します。
暗号化通信の基本⑤として、クライアント側とWebサーバ側で安全に共通鍵の受け渡しが完了しました。
最後に、安全に共通鍵の受け渡しができたので、暗号化と復号化の両方ができる共通鍵を使用してWebサーバ側からクライアントへの通信はWebサーバ側が共通鍵を使用して暗号化し、クライアント側の共通鍵で復号化することで、安全な通信が可能になります。その逆もしかりで、クライアント側からWebサーバへの通信も共通鍵で暗号化して、Webサーバ側で共通鍵を使用して復号化ができるようになります。
ここまでがSSLインスペクションを理解するための前提になる解説となります。
次項ではこの仕組みを使用したSSLインスペクションの動作を解説していきます。
SSLインスペクションの動作
前項では、公開鍵、秘密鍵、共通鍵を使用して、通信の経路上を暗号化して通信できる仕組みを解説しました。
SSLインスペクションは、その名の通り、「SSLを検査したり監査したりする」動作となります。
しかし、前項で解説した通り、クライアントとWebサーバの間では、End to Endで暗号化されているため、通信の途中にあるUTMなどはクライアントとWebサーバ間で使用している共通鍵が無いと、暗号化通信を解析できません。2023年4月現在では、暗号化された通信を傍受し、共通鍵無しでデータを復号化する製品は一般的に出てきておりません。
しかし、暗号化通信の方式を工夫すれば、UTMなどで暗号化されたデータを復号化することができるようになります。
それが、通信セッションの分割です。
図のように、UTMで通信のセッションを中継させることにより、クライアントからUTMの通信とUTMからWebサーバの通信を分割させることができるようになります。
セッションの中継をしない場合、クライアントとWebサーバが直接やり取りを行いますが、UTMをWeb Proxyとして動作させることで、クライアント→UTM→Webサーバのように中継させることができます。そこで、前項で解説した暗号化通信の基本を利用します。
やることは、前項で解説した共通鍵の生成ですが、ここではセッションを分割するため、クライアント側で共通鍵1を、UTM側で共通鍵2を生成します。
共通鍵1は、クライアントとUTM間で暗号化通信をする用の共通鍵で、共通鍵2は、UTMとWebサーバ間で暗号化通信をする用の共通鍵となります。
暗号化通信の基本として、生成した共通鍵は、それぞれの公開鍵を使って暗号化します。
クライアント側の共通鍵1は、UTMが生成した公開鍵1を使用して暗号化します。
共通鍵2は、Webサーバが生成した公開鍵2を使用して暗号化します。
それぞれのセッションで暗号化した共通鍵をUTM・Webサーバに送付します。
こうすることで、クライアントで生成した共通鍵1はUTMに、UTMで生成した共通鍵2はWebサーバに転送されます。
暗号化された共通鍵1は、UTMの秘密鍵1で復号化され、暗号化された共通鍵2はWebサーバの秘密鍵2で復号化されます。
ここまで来たらあとは簡単で、クライアント-UTM間では共通鍵1を使用して、UTM-Webサーバ間では、共通鍵2を使用して暗号化通信を行います。
こうすることで、各セッション毎にデータのやり取りができるようになりました。
前置きが長くなりましたが、ここがSSLインスペクションの動作ポイントです。
UTMとWebサーバ間では、共通鍵を使用して暗号化通信をしています。
共通鍵は暗号化と復号化をすることができると解説しました。
つまり、UTMを介さない通信の場合は、クライアントとWebサーバの間は完全に暗号化され、傍受することが事実上不可能でしたが、UTMとWebサーバ間では、Webサーバから受け取ったデータをUTM側で復号化ができるのです。
復号化してしまえば、あとは中身の解析ができてしまいます。
復号化されたデータについては、UTMがデータの解析をし、SSLインスペクションの解析ルールに基づきデータの処理が行われます。
データの解析が完了し、安全だと思われるデータのみをクライアント側に転送します。
こうすることで、SSLインスペクションが成立しています。
まとめ
今回は、SSLインスペクションを解説してみました。
SSLインスペクションの仕組みについては、セッション間で暗号化通信の技術を応用し、通信を中継することでSSLの通信を解析しているように見せているだけです。
暗号化通信を直接解析してチェックする製品については、現時点で販売されていない(技術的にコスパが悪い)ため、このようなことをしてより負荷がかからない方法で解析を行っています。
昨今、インターネットを流れる通信の80%ほどがSSLの暗号化された通信になってきており、暗号化通信の敷居が下がってきています。
一昔前は、SSLの通信が一般的ではなかったので暗号化されていないHTTPの通信をそのまま解析すればよくない通信を遮断すれば問題なかったのですが、SSL通信が大部分を占める今は、このようにSSLインスペクション等を使用してSSLの通信を復号化しないと通信内容が見えずに、良くない通信の遮断が難しくなりました。
このような時代背景から、SSLインスペクションを取り入れる企業が増えてきたものと思われます。
(SSLインスペクションすると通信速度が遅くなるから入れたくない・・・)
おまけ
本ブログではVMwareやWindows、Linuxのインストール手順等も公開しております。
インフラエンジニアとして有益な記事や無益なコンテンツも作成しておりますので、通勤時間や休憩時間、休日のスキマ時間等に合わせて読んでいただけると幸いです。
また、Youtubeで解説動画も鋭意作成中です。本ブログで記事にしているものも動画にしようと思っておりますので、よろしくお願いいたします。
willserverのnoteも開設したのでフォローお願いします。
コメント