IPsec vs SSL/TLS
IPsec も SSL/TLS も共に『通信相手が正しいこと、パケットの中身 (ヘッダは除く) が改ざんされていないこと、パケットの中身 (ヘッダは除く) が盗聴されないこと』を実現するセキュリティプロトコルです。
この 2 つがどのように違うかをまとめてみました。
エンドポイント間で暗号化するときは SSL/TLS が便利です。これについては次の章で詳細を説明します。
一方、IPsec は『サイト間 VPN』があるのが大きなポイントです。これは SSL/TLS では実現できません。
リモートアクセス VPN についてはどちらも利用可能です。利便性ではやはり https のみを許可すれば使える SSL-VPN が有利ですが、パフォーマンスでは一般に IPsec-VPN が有利です。
また、セキュリティ強度は正直そこまで大きく変わりません。
IPsec は相互認証が必須であり、事前共有キー (Pre-Shared Key) による相互認証後に 1対1での P2P 通信をすることが多いですが、証明書による認証もサポートされています。
一方、SSL/TLS は基本的には証明書によりサーバのみを認証する片方向認証で使われることが多いです。それゆえ、サーバは不特定多数を相手にする 1 対多の通信に対応しやすいです。クライアント証明書による相互認証はオプションとなっており、銀行の法人口座などの特殊環境下などで使われます。
また、事前共有キーによる相互認証も規格としてはサポートしています。
片方向認証をサポートしている、ということは『クライアント側で特別な設定が要らない』ということであり、このあたりが SSL/TLS 普及の成功のポイントだったと言えます。
IPsec (トランスポートモード) と SSL/TLSの比較
IPsec は大きく 2 つのモードがありますが、ホスト間通信においては、トランスポートモードが (SSL-VPNではない純粋な) TLS に近いですので、IPsec トランスポートモードと TLS を比較します。
暗号化 (＋改ざん検知) 範囲の違い、オーバーヘッドの違い
IPsec はレイヤー 3 を保護するため、TCP や UDP ヘッダから暗号化・改竄検知を行います。IPsec 利用時の最大オーバーヘッドサイズは 52 Bytes です。
一方、TLS はレイヤー 4 を保護するため、TCP や UDP のヘッダは暗号化・改竄検知せず、TCP や UDP のペイロードを暗号化・改竄検知します。TLS 利用時の最大オーバーヘッドサイズは 40 Bytes です。
IPsecの欠点とは？
暗号化範囲は IPsec の方が広いので、IPsec の方がすごい！と思ったかもしれません。が、TCP や UDP のヘッダって、盗聴されて何か困りますか？(改竄された場合は通信ができなくなるので困ると言えば困りますが、改竄されるならペイロードのほうが致命的。)
特に最近のネットワークセキュリティではファイアウォールによる防御が当たり前になっており、ファイアウォールを柔軟に適用するためには、トランスポート層の TCP や UDP のヘッダは見えていないといけません。
IPsec のように TCP や UDP ヘッダを暗号化してしまうと、IPsec の通信を全て通すか、全て通さないかの 2 択になります。ところが、TLS を使えば、https (http+TLS = TCP:443) は通す、IMAP4s (IMAP4+TLS = TCP:993) は通さない、等と TCP レイヤーでの柔軟なアクセス制御が可能となり、IPsec と比べての大きなメリットです。
このことは、プロキシサーバにおいても同様です。プロキシサーバは https には対応できますが、IPsec でトランスポート層を暗号化してしまうと、機能しません。
プロキシサーバの https アクセスについては以下を参照下さい。
また、前述の通り、IPsec は相互認証が必須となるため、サーバもクライアント側を認証する必要がありますが、SSL/TLS では必須ではなく、むしろ片方向認証でサーバのみを認証するケースがほとんどです。
SSL/TLS の欠点は？
SSL/TLS ではサイト間 VPN が使えません。また、一般に IPsec と比べると性能が劣る傾向にあります。
また、SSL/TLS は TCP のみに適用可能で、UDP 向けには DTLS という規格があります。TLS ではパケットの復号に前のパケットが必要だったりリプレイ攻撃対策などでシーケンスを見ていますが、UDP に適応するとそのあたりが逆に邪魔になってくるため、DTLS ではそのあたりを緩和した仕様になっています。
ですが DTLS はあまり実装がされておらず、普及が進んでいません。
SSL/TLS の今後の展望
最近では HTTP/3 (HTTP over QUIC) が話題になっており、Google が開発した QUIC と呼ばれるプロトコルが、UDP で TLS v1.3 を使うようになります。
まだ仕様策定フェーズですが、HTTP 以外への応用も大いに期待できるでしょう。
IPsec と SSL/TLS の暗号化するタイミング
IPsec はルータの設定完了時から SA トンネルが確立し、常に暗号化・復号化出来る状態になっています。つまり通信の最初から最後まで必ず暗号化/復号化が伴います。暗号化/復号化には CPU 処理による CPU 負荷、もしくは高価なオフロードカードが必要になります。
一方、TLS は対象通信 (https や smtps 等) がトリガーとなり、TCP 3way handshake 以降にネゴシエーションを開始します。3way handshake 直後にネゴシエーションを開始するケースが多いですが、STARTTLS (すたーとてぃーえるえす) と呼ばれるコマンドがあり、暗号化が不要なときは通常の通信を行い、暗号化が必要なタイミングで STARTTLS による暗号化を開始することができるので、負荷をある程度抑えることができます。
一般的な例なのが SMTP で、EHLO 等の開始処理コマンドでは暗号化せず、実際に送信するメールデータの通信を始めるタイミング等で STARTTLS による暗号化を行います。
(SMTPs というものもありますが、これは通信の最初から最後まで SMTP 通信を暗号化する方式ですので異なります。)
以下に、IPsec 利用時と TLS 利用時の SMTP 通信の比較を示します。
リモートアクセス VPN (IPsec-VPN と SSL-VPN) の比較
前述の通り、IPsec VPN にはルータや FW 同士を論理的に直結する『サイト間 VPN』というものがありますが、SSL-VPN にはそのような機能はありません。
一方、クライアント (WindowsやLinux、Android、iPhone等) からルータや FW 等を論理的に直結する『リモートアクセス VPN』というものは、IPsec VPN にも SSL-VPN にも存在します。(VPN として使うときは、TLS を使っているのに、何故か TLS-VPN と呼ばず SSL-VPN と呼びます。)
ここではこの『リモートアクセス VPN』の比較をします。
| 比較 | IPsec VPN | SSL VPN |
|---|---|---|
| クライアント | ・クライアントソフトの 事前インストールが必須 ・全てのIP通信を利用可能 | ・リバースプロキシ方式であれば ブラウザのみでOK。ただし 対応アプリケーションが 限定される。 ・それ以外は大抵、Agent やクライ アントソフトをインストールする ことで、全てのIP通信を利用可能 |
| セキュリティ強度 | ・同程度 | ・同程度 |
| サーバ認証方式 | ・Preshare Keyが一般的 ・デジタル証明書も利用可 | ・デジタル証明書が一般的 ・Preshare Keyも利用可 |
| クライアント 認証方式 | ・IDパスワードが一般的。 ADやLDAP連携も多い。 ・クライアント証明書や OTP 等の様々な方式を 利用できるタイプも多い | ・IDパスワードが一般的。 AD や LDAP 連携も多い。 ・クライアント証明書やOTP等の 様々な方式を利用できるタイプ も多い |
| パフォーマンス | ・一般に高い | ・一般に低い |
コメント
こんにちは。
IPsec トランスポートモードは「利便性が低くあまり利用されていない」
とのことですが、GRE over IPsecやL2TP over IPsecで用いられるため、
個人的にはまあまあ利用されている（NW素人である私の）認識でした。
nesukeさんは、上記2つの方式自体があまり利用されていない、という認識なのでしょうか。
よろしくお願いいたします。
あああああさん
コメントありがとうございます。
ご指摘ありがとうございます。私自身が今まで仕事で GRE over IPsec や L2TP over IPsec を使うことがほぼ無かったので、この2つについては考慮していませんでした。純粋な IPsec を利用したパターンとお考え下さい。
私の思い込みがあったので、とても参考になりました。
他の記事でも気になった点がありましたら、ぜひまたご指摘下さい。
IPsecがFWの制御で不利になるように書かれていますが、エンドポイント間のIPsecでなければ、あまり不利にならないのはないでしょうか。
場数を踏んでいないので怪しいですが、IPsecを利用する場面はエンドポイント間で使うのではなく、ネットワーク間を接続、またはエンドポイントとネットワークを接続することが多いと思います。
つまり、ネットワークの入り口はVPN装置になりますから、そのあとにFWを噛ませば良く、しかもそれが一般的ではないでしょうか。世間ではVPN装置単体では売っていなく、ルータ、SW、FWなども含まれています。FWの制御で不利になることは実際には起きにくいと思います。
イントラネット—-FW—-VPN装置—-（外）—-VPN装置—-FW—-イントラネット
また、SSL VPNはエンドポイント間で暗号化通信をすることに長けていますが、IDS/IPSなどを噛ませている場合は暗号化されているためにパケットのウイスルチェックができなくる欠点があります。
エンドポイント—-IDS/IPS—-（外）—-IDS/IPS—-エンドポイント
（図は適当です）
たぶん将来のセキュリティエンジニアさん、コメントありがとうございます。
> IPsecがFWの制御で不利になるように書かれていますが、エンドポイント間のIPsecでなければ、あまり不利にならないのはないでしょうか。
その点は仰る通りです。本記事では敢えて前提として「IPsecトランスポートモード」と断りを入れていますが、実態としてはトンネルモードが多いです。
トンネルモードはさらにサイト間VPNとリモートアクセスVPNに分かれますが、SSLにはサイト間VPNは無く、リモートアクセスVPNについては大きなメリットデメリットの差異が無いので、比較が難しくなるため、比較という切り口でこのような書き方をしていますが、繰り返しますが、実態については貴殿の仰るとおりです。
ちなみに、IPsecのこのあたりの詳細は以下に記載しています。
https://milestone-of-se.nesuke.com/nw-basic/ipsec/ipsec-summary/
> また、SSL VPNはエンドポイント間で暗号化通信をすることに長けていますが、IDS/IPSなどを噛ませている場合は暗号化されているためにパケットのウイスルチェックができなくる欠点があります。
これはSSLに限らずIPsecの欠点とも言えますね。これに関しても本サイトの色々なところで言及しています。こちらもご参考までに。
https://milestone-of-se.nesuke.com/nw-basic/tls/decrypt-intercept/
https://milestone-of-se.nesuke.com/nw-basic/fw/utm/