【図解】IPsecとSSL/TLSの違い ~セキュリティ強度や用途、メリット・デメリットの比較~

IPsec vs TLS(旧SSL)

IPsec も TLS(旧SSL)も共に『通信相手が正しいこと、パケットの中身(ヘッダは除く)が改ざんされていないこと、パケットの中身(ヘッダは除く)が盗聴されないこと』を実現するセキュリティプロトコルです。

この2つがどのように違うかをまとめてみました。

まず、先に書いておくと、セキュリティ強度は正直そこまで大きく変わりません。強いて言えば、相手を認証する方式において、TLSのほうがデジタル証明書を使う習慣が根強く、Pre-shared Key(事前共有キー)で対応しがちな IPsec よりもセキュリティが高い気がします(個人の感想です)。

ホスト間通信としての IPsec (ESP/トランスポートモード) と SSL/TLSの比較

まず、IPsec は大きく4つのモードがありますが、ホスト間通信においては、ESPのトランスポートモードが(SSL-VPNではない純粋な)TLSに近いですので、IPsec(ESP/トランスポートモード)とTLSを比較します。

暗号化(+改ざん検知)範囲の違い、オーバーヘッドの違い

IPsec はレイヤー3を保護するため、TCP や UDPヘッダから暗号化・改竄検知を行います。IPsec 利用時の最大オーバーヘッドサイズは 52 Byteです。

一方、TLS はレイヤー4を保護するため、TCPやUDPのヘッダは暗号化・改竄検知せず、TCPやUDPのペイロードを暗号化・改竄検知します。TLS 利用時の最大オーバーヘッドサイズは 40 Byteです。

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 アクセスについては以下を参照下さい。

【図解】httpプロキシサーバの仕組み(http GET/https CONNECTメソッド)や必要性・役割・メリットデメリット・DNSの名前解決の順序
【図解】httpプロキシサーバの仕組み(http GET/https CONNECTメソッド)や必要性・役割・メリットデメリット・DNSの名前解決の順序
プロキシサーバとは、クライアントからサーバへhttp通信する際、直接やり取りする...

SSL/TLSの欠点は?

あれ、UDP は?と思ったかもしれません。そうです、そこだけが TLS のデメリットです。今のところTLSはUDPへの応用ができません

ただし、最近では HTTP/3 (HTTP over QUIC) が話題になっており、Google が開発した QUIC と呼ばれるプロトコルが、UDP で TLS v1.3 を使うようになるようです。

まだ仕様策定フェーズですが、HTTP以外への応用も大いに期待できるでしょう。

参考:TLS v1.3 について

【図解】TLSv1.3の仕組みとシーケンス ~QUICに向けた0-RTT, key_shareやHelloRetryRequest, NewSessionTicketとPSKの関係, コネクションとセッションの違い~
【図解】TLSv1.3の仕組みとシーケンス ~QUICに向けた0-RTT, key_shareやHelloRetryRequest, NewSessionTicketとPSKの関係, コネクションとセッションの違い~
TLS バージョン 1.3 の概要、1.2 との違い 2018年8月に TLS ...

暗号化するタイミング

IPsec はルータの設定完了時からSAトンネルが確立し、常に暗号化・復号化出来る状態になっています。つまり通信の最初から最後まで必ず暗号化/復号化が伴います。暗号化/復号化には CPU 処理による CPU 負荷、もしくは高価なオフロードカードが必要になります。

一方、TLS は対象通信 (https や smtps等) がトリガーとなり、TCP 3way handshake 以降にネゴシエーションを開始します。3way handshake 直後にネゴシエーションを開始するケースが多いですが、STARTTLS(すたーとてぃーえるえす)と呼ばれるコマンドがあり、暗号化が不要なときは通常の通信を行い、暗号化が必要なタイミングで STARTTLS による暗号化を開始することができるので、負荷をある程度抑えることができます。

一般的な例なのが SMTP で、EHLO 等の開始処理コマンドでは暗号化せず、実際に送信するメールデータの通信を始めるタイミング等で STARTTLS による暗号化を行います(SMTPs というものもありますが、これは通信の最初から最後まで SMTP 通信を暗号化する方式ですので異なります)。

以下に、IPsec 利用時と TLS 利用時の SMTP 通信の比較を示します。

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 VPNSSL VPN
クライアント・クライアントソフトの
事前インストールが必須
・全てのIP通信を利用可能
・リバースプロキシ方式であれば
ブラウザのみでOK。ただし対応アプリ
ケーションが限定される。
・それ以外は大抵、Agentやクライアント
ソフトをインストールすることで、
全てのIP通信を利用可能
セキュリティ強度・同程度・同程度
サーバ認証方式・Preshare Keyが一般的
・デジタル証明書も利用可
・デジタル証明書が一般的
・Preshare Keyも利用可
クライアント認証方式・IDパスワードが一般的。
ADやLDAP連携も多い。
・クライアント証明書やOTP等の
様々な方式を利用できるタイプ
も多い
・IDパスワードが一般的。
ADやLDAP連携も多い。
・クライアント証明書やOTP等の
様々な方式を利用できるタイプ
も多い

シェアする

  • このエントリーをはてなブックマークに追加

フォローする