FTPS

FTPS ( FTP-SSLおよびFTP Secureとも呼ばれる) は、一般的に使用されているファイル転送プロトコル(FTP)の拡張機能であり、トランスポート層セキュリティ(TLS) と、以前はセキュア ソケット レイヤー(SSL、現在は RFC7568 で禁止されています) の暗号化プロトコルのサポートが追加されています。

FTPS は、SSH ( Secure Shell ) プロトコル用の安全なファイル転送サブシステムであるSSH ファイル転送プロトコル(SFTP)と混同しないでください。SFTP とは互換性がありません。また、FTP を SSH 接続経由でトンネリングする FTP over SSHとも異なります。

ファイル転送プロトコルは、科学研究ネットワークであるARPANETで使用するために1971年に起草されました。^[1] 当時のARPANETへのアクセスは、少数の軍事施設と大学、およびプロトコル内でデータセキュリティとプライバシーの要件なしで操作できる狭いユーザーコミュニティに限定されていました。

ARPANET がNSFNETに取って代わられ、その後インターネットが登場するにつれて、クライアントからサーバーまでの経路がますます長くなり、より多くの人がデータにアクセスできる可能性が高まりました。権限のない第三者がデータ送信を盗聴する機会も比例して増加しました。

1994年、インターネットブラウザ企業のNetscape社は、アプリケーション層ラッパーであるSecure Sockets Layerを開発し、リリースしました。^{[2]このプロトコルにより、アプリケーションはネットワークを介してプライベートかつ安全に通信できるようになり、盗聴、改ざん、メッセージの偽造を防ぐことができました。TCPなどの信頼性の高い接続を使用するプロトコルに}セキュリティ を追加できますが、最も一般的にはNetscapeがHTTPと組み合わせてHTTPSを形成するために使用されました。

SSLプロトコルは最終的にFTPに適用され、1996年後半にRFC（ Request for Comments）の草案が公開されました。 ^{[3]その後すぐに}IANAの 公式ポートが登録されました。しかし、RFCは2005年まで最終決定されませんでした。^[4]

FTP クライアントで使用するクライアント セキュリティを呼び出すために、暗黙的と明示的という2 つの異なる方法が開発されました。暗黙的な方法では、接続の最初からトランスポート層セキュリティを確立する必要があり、その結果、FTPS 非対応のクライアントおよびサーバーとの互換性が失われますが、明示的な方法では、標準の FTP プロトコル コマンドと応答を使用してプレーン テキスト接続を暗号化された接続にアップグレードし、単一の制御ポートを使用して FTPS 対応クライアントと FTPS 非対応クライアントの両方に対応できるようになります。

暗黙的な FTPS 構成ではネゴシエーションはサポートされません。クライアントは、TLS ClientHelloメッセージを使用して FTPS サーバーにすぐにチャレンジする必要があります。FTPS サーバーがこのようなメッセージを受信しない場合は、サーバーは接続を切断する必要があります。

既存のFTPS非対応クライアントとの互換性を維持するために、暗黙的なFTPSは、FTPS制御チャネルについてはIANAの既知のポート990/TCP、FTPSデータチャネルについてはポート989/TCPをリッスンすることが期待されていました。^[5]これにより、管理者は元の21/TCP FTP制御チャネルでレガシー互換サービスを維持できました。

暗黙的なネゴシエーションはRFC 4217では定義されていないことに注意してください。そのため、これはFTPのTLS/SSLをネゴシエートする以前の非推奨の方法であると考えられています。^[6]

明示的モード (FTPES とも呼ばれる) では、FTPS クライアントは FTPS サーバーにセキュリティを「明示的に要求」し、相互に合意した暗号化方式に移行する必要があります。クライアントがセキュリティを要求しない場合、FTPS サーバーはクライアントが安全でないモードで継続することを許可するか、接続を拒否することができます。

FTP で認証とセキュリティをネゴシエートするためのメカニズムは、新しい FTP コマンド AUTH を含む RFC 2228 で追加されました。この RFC では、SSL や TLS などの必要なセキュリティ メカニズムは明示的に定義されていませんが、FTPS クライアントが FTPS サーバーに相互に既知のメカニズムでチャレンジすることを要求しています。FTPS クライアントが FTPS サーバーに不明なセキュリティ メカニズムでチャレンジすると、FTPS サーバーは AUTH コマンドにエラー コード504 (サポートされていません)で応答します。クライアントは、FEAT コマンドを使用して FTPS サーバーにクエリを実行することで、サポートされているメカニズムを判断できますが、サーバーはサポートしているセキュリティ レベルを正直に開示する必要はありません。FTPS セキュリティを呼び出す一般的な方法には、AUTH TLS と AUTH SSL があります。

明示的な方法は、RFC 4217 で定義されています。このドキュメントの後のバージョンでは、FTPS 準拠のために、クライアントは常に AUTH TLS 方法を使用してネゴシエートする必要がありました。

FTPS には、サーバー側の公開鍵認証証明書とクライアント側の承認証明書の使用を含む、TLS および SSL 暗号化プロトコルの完全なサポートが含まれています。また、 AES、RC4、RC2、Triple DES、およびDESなどの互換性のある暗号もサポートしています。さらに、ハッシュ関数SHA、MD5、MD4、およびMD2 もサポートしています。

暗黙モードでは、FTPS セッション全体が暗号化されます。明示モードでは、クライアントが接続のどの領域を暗号化するかを完全に制御できる点が異なります。FTPS 制御チャネルと FTPS データ チャネルの暗号化の有効化と無効化はいつでも実行できます。唯一の制限は、サーバーの暗号化ポリシーに基づいてコマンドを拒否する機能を持つ FTPS サーバーから発生します。

AUTH TLS または AUTH SSL コマンドを発行することで、セキュア コマンド チャネル モードに入ることができます。この後、FTPS クライアントとサーバー間のすべてのコマンド制御は暗号化されているとみなされます。第三者によるユーザー名とパスワード データの盗聴を防ぐために、ユーザー認証と承認の前にこのような状態に入ることが一般的に推奨されます。

セキュア データ チャネルには、PROT コマンドを発行することで入ることができます。AUTH TLS コマンドが発行されると、デフォルトでは有効になりません。その後は、FTPS クライアントとサーバー間のすべてのデータ チャネル通信は暗号化されていると見なされます。

FTPS クライアントは、CDC (データ チャネルのクリア) コマンドを発行することにより、いつでもセキュア データ チャネル モードを終了できます。

次のシナリオで転送を実行する場合、データ チャネル暗号化を使用することは有利ではない可能性があります。

• 転送されるファイルは機密性のないものであり、暗号化は不要である。
• 転送されるファイルはファイルレベルですでに暗号化されているか、暗号化されたVPNを経由しているため、暗号化は不要です。
• 利用可能な TLS または SSL 暗号化モードは、必要な暗号化レベルを満たしていません。これは、以前の米国の高度暗号化輸出法により40 ビット SSL に制限されている可能性のある古い FTPS クライアントまたはサーバーでよく発生します。

次のシナリオでは、制御チャネルの暗号化を使用することは有利ではない可能性があります。

• クライアントまたはサーバーがネットワーク ファイアウォールまたはネットワーク アドレス変換(NAT) デバイスの背後にある場合の FTPS の使用。(以下のファイアウォールの非互換性を参照してください。)
• 同じセッション内で匿名 FTP クライアントが AUTH コマンドと CCC/CDC コマンドを繰り返し使用する。このような動作は、サーバーのプロセッサ時間を使用して TLS/SSL セッションを毎回再生成する必要があるため、リソースベースのサービス拒否攻撃として使用される可能性があります。

HTTPSと同様に、 FTPS サーバーは公開鍵証明書を提供する必要があります。これらの証明書は、 OpenSSLなどのツールを使用して要求および作成できます。

これらの証明書が信頼できる証明機関によって署名されている場合、クライアントが要求されたサーバーに接続されていることが保証され、中間者攻撃を回避できます。証明書が信頼できる CA によって署名されていない場合 (自己署名証明書)、FTPS クライアントは証明書が有効ではないことを示す警告を生成することがあります。クライアントは、証明書を受け入れるか、接続を拒否するかを選択できます。

これは、署名された証明書を提示せず、代わりに公開キーの帯域外認証に依存するSSH ファイル転送プロトコル(SFTP)とは対照的です。

FTP は動的なセカンダリ ポート (データ チャネル用) を使用するため、多くのファイアウォールは、どのセカンダリ データ接続を許可する必要があるかを判断するために、FTP プロトコル制御メッセージをスヌープするように設計されています。ただし、FTP 制御接続が TLS/SSL を使用して暗号化されている場合、ファイアウォールはクライアントと FTP サーバーの間でネゴシエートされたデータ接続の TCP ポート番号を判断できません。そのため、多くのファイアウォール ネットワークでは、暗号化されていない FTP 展開が機能する場合、FTPS 展開は失敗します。この問題は、データ用に限られた範囲のポートを使用し、ファイアウォールがこれらのポートを開くように構成することで解決できます。

• FTPSの概要とクライアント、サーバーのリスト
• Curl-loader - オープンソースの FTPS 読み込み/テスト ツール