mieki256's diary

そもそも、FFFTP等から正常にFTPSで接続できた際、どういうログが表示されるのだろう。そこからして分からなかったので、LAN内でFTPS (Explicit) 接続できるFTPサーバを立てて動作確認してみようと思い立った。

とりあえず、足元に置いてあるサブPC、Ubuntu Linux 22.04 LTS (Core i3-6100T機)に、FTPサーバ、vsftpd 3.0.5-0ubuntu1 がインストール済みだったので、設定(/etc/vsftpd.conf)を変更して、FTPS(Explicit)接続ができるようにしてみる。

• 接続先はLAN内の Ubuntu Linux 22.04 LTS + vsftpd 3.0.5。ぷららのFTPサーバじゃなくて、LAN内の実験用サーバ。
• FTPクライアントを動かしたOSは、Windows10 x64 22H2。

動作確認に使ったFTPクライアントは以下。 LAN内 の Ubuntu Linux + vsftpd にFTPS接続できたかどうかの結果も書いておく。勘違いされるとマズいので再度書く。ぷららのFTPサーバじゃないよ。LAN内の、だよ。

FTPクライアント	接続成功/失敗
FileZilla 3.65.0	Success
WinSCP 6.1.1	Success
Cyberduck 8.6.2	Success
FFFTP 1.98g	Success
FFFTP 2.00 x86	Success
FFFTP 4.5 x86	Failure
FFFTP 5.8 x86	Failure
FFFTP 5.8 x64	Failure

自分の手元の環境では、FFFTP 3.x以降のバージョンは、ことごとくFTPS接続に失敗している。

FFFTP は、2.00までと、3.x以降で、SSL/TLS関係の処理がごっそり変わっているそうで。2.00までは自前でSSL/TLS関連ファイルを持って処理をしていたけれど、3.x以降はWindowsが持ってる機能を使って処理するようになって、そのせいか環境によってFTPS接続ができたりできなかったりするらしい。

ネット上では「FTPS接続したいならFFFTPで」的に紹介されていることが多いけれど、今現在、一般的に入手しやすい FFFTP は 3.x以降なので、この状況はマズい気がする…。FTPサーバの種類、サーバ側設定との相性がかなりあるのではないか…。安易にFFFTPを推奨するのは危ない…。そのあたり、ぷららは分かっているのだろうか？ もちろん、フツーのFTP接続なら悪い選択肢では無いだろうけど。自分も普段使っているし。

ちなみに、「FFFTP の 32bit(x86) と 64bit(x64) で動作が変わるのではないか？」「OSが64bit版なら FFFTP も64bit版を選ばないとダメなのではないか？」と思ったけれど。試したところ、そのあたりは関係なさそう。動作に違いは無かった。

念のため、FFFTP 5.8 x64 から、 Ubuntu Linux 22.04 LTS + vsftpd にアクセスしてみた際のログ(?)も書いておく。ぷららのFTPサーバじゃないよ。

 ## DEBUG MESSAGE ON ! ##
 FFFTP Ver.5.8 64bit Copyright(C) 1997-2010 Sota & cooperators.
 ...
 ----------------------------
 FTP over Explicit SSL/TLS (FTPES)を使用します.
 ホスト i36100t (192.168.1.11:21) に接続しています.
 接続しました.
 220 Welcome to blah FTP service.
 >AUTH TLS
 234 Proceed with negotiation.
 ## InitializeSecurityContextW() failed(0x80090326): 予期されない、または形式が間違ったメッセージを受信しました。
 ログインできません.
 ## Skt=2208 : Socket closed.

FTPクライアント側(FFFTP)が、AUTH TLS を送信した直後にエラーが出て失敗している。

逆に考えると、FTPサーバ側がそこそこ真っ当に設定できていれば、FTPクライアントから AUTH TLS を送信するところまでは少なくとも進むはず、と言えそう。

しかし、ぷららのサーバはそこまで進まず、上記で言えば 220 すら返ってこない状態なので、やはりぷらら側で何かを間違えてしまっているとしか思えないわけで…。

各FTPクライアントは以下から入手できる。

_FFFTPの詳細情報 : Vector ソフトを探す！ (FFFTP 2.00が入手可能)
_Releases - ffftp/ffftp - GitHub (FFFTP 3.x以降が入手可能)
_FileZilla - The free FTP solution
_Cyberduck
_「WinSCP」SCP/SFTP/FTPS対応のFTPクライアント - 窓の杜

本来、FFFTP 2.00以前は OSDN から入手できるはずなのだけど、OSDNがずっと 504。つい最近、OSDNが中国企業に売られてしまったことが関係しているのだろうか…？

_接続不調が続く「OSDN」、米「SourceForge」がプロジェクトの勧誘に乗り出す - やじうまの杜 - 窓の杜

ググっていたら、Vector から FFFTP 2.00 を入手できることが分かった。下のほうにスクロールしていくと 2.00 (ffftp-2.00.zip) がある。助かった。

_FFFTPの詳細情報 : Vector ソフトを探す！

以下を参考にしながら vsftpd の設定をしていった。

_Ubuntu 22.04 LTS : Vsftpd Over SSL/TLS 設定 : Server World
_Ubuntu 20.04 で SSL/TLS を使用して FTP サーバー (vsftpd) をインストールおよび構成する方法
_vsftpd over TLS/SSL@cbreeze
_CentOS vsftpdでSSL/TLS暗号化接続が出来ないまたは途中で止まる - POCH-7003 BEATout!
_vsftpd - Over SSL/TLS 設定すると FileZilla でエラー！ - mk-mode BLOG

vsftpd に、FTPS接続の設定をしていく。

FTPS接続を可能にするためには、証明書なるものが必要らしい。外部に公開するサーバならちゃんとした証明書が必要らしいけど、今回はあくまでLAN内で実験するだけなので、自己署名の証明書なるものを作成して作業を進める。

以下を実行して、/etc/ssl/private/vsftpd.pem として証明書を作成。途中で国コードやら何やらを尋ねてくるので入力する。

sudo openssl req -x509 -nodes -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem -days 3650

$ sudo openssl req -x509 -nodes -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem -days 3650

...+.......+..+...
...
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:JP                                # 国コード
State or Province Name (full name) [Some-State]:Fukushima           # 地域(都道府県名)
Locality Name (eg, city) []:Sukagawa                                # 都市
Organization Name (eg, company) [Internet Widgits Pty Ltd]:RAD11    # 組織名
Organizational Unit Name (eg, section) []:                          # 組織の部門名 
Common Name (e.g. server FQDN or YOUR name) []:i36100t              # サーバのFQDN
Email Address []:yourname@example.com                               # 管理者のメールアドレス

サーバのFQDNとやらは、そのPCの hostname をそのまま入力したほうが良さそう。

念のためにアクセス権を変更。Ubuntu Linux 22.04 LTSの場合、最初から600になってた。

sudo chmod 600 /etc/ssl/private/vsftpd.pem

sudo vi /etc/vsftpd.conf

# 149行以降

rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
ssl_enable=YES
allow_anon_ssl=NO

ssl_ciphers=HIGH

# ssl_ciphers=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

# ssl_ciphers=kEECDH+AESGCM+AES128:kEECDH+AESGCM:kEECDH+AES128:kEECDH+AES:!aNULL:!eNULL:!LOW:!EXP

force_local_data_ssl=YES
force_local_logins_ssl=YES

ssl_tlsv1=YES
# ssl_tlsv1_1=YES
# ssl_tlsv1_2=YES
ssl_sslv2=NO
ssl_sslv3=NO

require_ssl_reuse=NO

strict_ssl_read_eof=NO

# Passive mode
pasv_enable=YES
# pasv_min_port=40000
# pasv_max_port=40030
pasv_min_port=60000
pasv_max_port=60010

vsftpdを再起動。

sudo systemctl restart vsftpd.service

これでFTPS接続ができるようになった。

FFFTP 1.98g でFTPSサーバ(vsftpd)にアクセス後、ファイルを転送してみたら以下のエラーが出た。

426 Failure reading network stream.

以下で解説されていた。

_vsftpdにアップロードしたら"426 Failure reading network stream."エラーが出るときの解決法 - Qiita

マニュアルのstrict_ssl_read_eofの項目にはDefault: NOと書いてあるがマニュアルの誤記で実際にはデフォルトYESである。

設定ファイルを変更して、strict_ssl_read_eof=NO を追記したところ、エラーは出なくなった。

sudo vi /etc/vsftpd.conf

strict_ssl_read_eof=NO

/etc/vsftpd.conf 内に記述する内容について、以下のような記述も見かけたが、実際に /etc/vsftpd.conf に記述してしまうと、Windows10 x64 22H2 + FFFTP 1.98g、FFFTP 2.00 x86、FileZilla 3.65.0 でFTPS接続できなくなってしまった。

ssl_sslv2=NO
ssl_sslv3=NO
ssl_tlsv1=YES
ssl_tlsv1_1=YES
ssl_tlsv1_2=YES

 ## DEBUG MESSAGE ON ! ##
 FFFTP Ver.2.00 Copyright(C) 1997-2010 Sota & cooperators.
 ...
 OpenSSLが読み込まれました.
 ----------------------------
 FTP over Explicit SSL/TLS (FTPES)を使用します.
 ホスト i36100t を探しています. (TCP/IPv4)
 ホスト i36100t (192.168.1.11 (21)) に接続しています. (TCP/IPv4)
 ## #### Connect: Error=10061
 接続できません. (TCP/IPv4)
 ## Skt=2236 : Socket closed.

以下の記述なら、FTPS接続ができた。何故。

ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO

巷の解説記事では、以下のように、TLS 1.2 のみを有効にしている指定が多いのだけど…。

ssl_sslv2=NO
ssl_sslv3=NO
ssl_tlsv1=NO
ssl_tlsv1_1=NO
ssl_tlsv1_2=YES

皆、一体どのOS/FTPクライアントを使って動作確認してるのだろう…？

また、以下のような記述も見かけた。

ssl_ciphers=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

これを設定しても、FFFTP 1.98g、FileZilla 3.65.0 から接続できた。でもまあ、今回は以下の指定にしておく。

ssl_ciphers=HIGH

FFFTP 1.98g で、vsftpd にFTPS接続できた時の結果は以下。

FFFTP Ver.1.98g Copyright(C) 1997-2010 Sota & cooperators.
...
OpenSSLが読み込まれました.
----------------------------
FTP over Explicit SSL/TLS (FTPES)を使用します.
ホスト i36100t を探しています. (TCP/IPv4)
ホスト i36100t (192.168.1.11 (21)) に接続しています. (TCP/IPv4)
接続しました. (TCP/IPv4)
220 Welcome to blah FTP service.
>AUTH TLS
234 Proceed with negotiation.
>PBSZ 0
200 PBSZ set to 0.
>PROT P
200 PROT now Private.
>USER hogeuser
331 Please specify the password.
>PASS [xxxxxx]
230 Login successful.
>FEAT
211-Features:
 EPRT
 EPSV
 MDTM
 PASV
 PBSZ
 PROT
 REST STREAM
 SIZE
 TVFS
211 End
>TYPE A
200 Switching to ASCII mode.
>PASV
227 Entering Passive Mode (192,168,1,11,225,252).
ダウンロードのためにホスト 192.168.1.11 (57852) に接続しています. (TCP/IPv4)
接続しました. (TCP/IPv4)
>LIST
150 Here comes the directory listing.
226 Directory send OK.
...

この結果から、いくつかのことが分かる。

1. まず、FFFTP が「接続しました. (TCP/IPv4)」と言ってきた直後、FTPサーバから送られてきたウェルカムメッセージ、「220 Welcome to blah FTP service.」が表示される。
2. その直後、FTPクライアントは、「AUTH TLS」を送信する。暗号化通信関係のコマンドだろうか。サーバ側は「234 Proceed with negotiation.」を返してきて…。
3. その後、何度かやり取りして、暗号化通信が有効になるのだろう。そこでようやくFTPクライアントは、ユーザ名を「USER hogeuser」で送信する。
4. サーバから「331 Please specify the password.」が返ってきたら、FTPクライアントはパスワードを「PASS [xxxxxx]」で送信してやる。
5. パスワードが間違ってなければ、サーバは「230 Login successful.」を返してくる。
6. そこから、PASVモードを有効にしたり、ファイルの一覧を取得したり、といったやり取りになっていく。

つまり、正常にFTPS接続できているなら…。

• まずサーバは、ウェルカムメッセージを 220 で返してくる。
• そこでようやくFTPクライアントは「おい磯野、暗号化通信しようぜ！」的に「AUTH TLS」を送信する。
• ユーザ名やパスワードのやり取りをするのは、「AUTH TLS」が通った後の話。

まずはFFFTPのログに「AUTH TLS」が出てこないと話にならない。

「AUTH TLS」が出てきていないのに「ユーザ名やパスワードが間違ってませんか？」「パスワードが短すぎるのでは？」などと言い出すのは頓珍漢な話、ということになるのだろう。たぶん。

FileZilla 3.65.0 でアクセスした時の結果は以下。

状態:           i36100t のアドレスを解決中
状態:           [2405:6583:3200:b100:cdd6:8f8c:4b36:a61f]:21 に接続中...
状態:           接続を確立しました。ウェルカム メッセージを待っています...
レスポンス:     220 Welcome to blah FTP service.
コマンド:       AUTH TLS
レスポンス:     234 Proceed with negotiation.
状態:           TLS を初期化しています...
トレース:       TLS Handshake successful
トレース:       Protocol: TLS1.3, Key exchange: ECDHE-SECP256R1-RSA-PSS-RSAE-SHA384, Cipher: AES-256-GCM, MAC: AEAD, ALPN: ftp
状態:           TLS 接続が確立されました。
コマンド:       USER hogeuser
レスポンス:     331 Please specify the password.
コマンド:       PASS ********
レスポンス:     230 Login successful.
状態:           サーバーは non-ASCII の文字をサポートしていません。
コマンド:       PBSZ 0
レスポンス:     200 PBSZ set to 0.
コマンド:       PROT P
レスポンス:     200 PROT now Private.
状態:           ログインしました
トレース:       Measured latency of 4 ms
状態:           "/public_html/plala" のディレクトリ リストを取得中...
コマンド:       CWD /public_html/plala
レスポンス:     250 Directory successfully changed.
コマンド:       TYPE I
レスポンス:     200 Switching to Binary mode.
コマンド:       EPSV
レスポンス:     229 Entering Extended Passive Mode (|||60004|)
トレース:       Binding data connection source IP to control connection source IP 2405:6583:3200:b100:bc64:5065:7fdf:7cb5
トレース:       Trying to resume existing TLS session.
コマンド:       LIST
レスポンス:     150 Here comes the directory listing.
トレース:       TLS Handshake successful
トレース:       TLS Session resumed
トレース:       Protocol: TLS1.3, Key exchange: , Cipher: AES-256-GCM, MAC: AEAD, ALPN: 
レスポンス:     226 Directory send OK.
状態:           "/public_html/plala" のディレクトリ リストの表示成功

やはり、サーバから220が返ってきてから AUTH TLS を送ってる。FFFTPと違って、AUTH TLS を送って 234 が返ってきたら、すぐにユーザ名やパスワードを送って、その後、PBSZ 等を送ってるようだなと…。

ところで、今朝、再度ぷららのサイトのフォームから問い合わせをしてみたわけで…。以下のFFFTPのログも一緒につけて、「FTPS接続できません。何かこちらで試せることはありますか？」と尋ねてみたわけで…。

 FFFTP Ver.1.98g Copyright(C) 1997-2010 Sota & cooperators.
 ...
 OpenSSLが読み込まれました.
 ----------------------------
 FTP over Explicit SSL/TLS (FTPES)を使用します.
 ホスト 60.43.63.107 (21) に接続しています. (TCP/IPv4)
 接続しました. (TCP/IPv4)

 接続できません.

夕方頃、ぷららサポートセンターからメールで返事が来たわけで…。「パスワードが短すぎるのかもしれない。7文字以上にしてみてくれ」とのこと。

あのさあ。こちらから送ったFFFTPのログを眺めれば、そこじゃないと分かるだろうよ…。

もちろん、サポートさんの仰る通り、一応、念のため、パスワード変更も試してみたけれど、やはり状況は変わらず。当たり前だけど。

だって、パスワードを送るどころか、ユーザ名すらFTPクライアントから送ることができてないし、そもそも「おい磯野、暗号化通信しようぜ！ (AUTH TLS)」すらあちらに送れてないわけで…。「おい、いそ」と言い出す前にカツオ(www7.plala.or.jp)が電話ガチャン、みたいな。カツオのスマホの電話番号(IPアドレス)に電話してるから、おそらくカツオが電話を取ったんじゃねえかな、ぐらいは想像できるけど、取り付く島もないというか。

ログを見ればそういうことが分かるはずなんだけど、最初から見る気ゼロで答えてるんだろうな…。 *1

これはもう只の邪推と愚痴だけど。ぷららでは、サポート担当の人と、サーバの設定をしてる人の間で、連絡を取り合う手段が一切何もなくて、もう返事のしようもないのかもしれない。だから「パスワードを」とか言ってお茶を濁そう(?)としてるのかも。

あるいは、メールを返してきているのは、AIなのかもしれない…。どうも話が通じていない感があるし…。AIが相手では、そりゃFFFTPのログを見せても理解できるわけがないよな…。

しかし、だとしたら、よくないなあ。せっかくユーザがサービスの障害報告をしてくれても、対応をAIに任せてたら、しかるべき部署に連絡が一切行かなくなる。サービスが正常動作してないのに、そのことすら把握できなくなる。どう考えてもマズい。もっとも、AIに置き換えてしまえば人件費が、なんて上の人が安易に考える時点で、当の昔にサポート担当は他部署から完全に分離・断絶されているのだろうから、人間がやってもAIがやっても結局状況は変わらないのかもしれないけど…。

どうすりゃいいんだ、コレ。サポートに連絡してもこんな状態ではなあ…。このサービス、詰んでないか。

そもそも本来、「FTPS接続しか受け付けません」ではなくて…。

• Webブラウザ経由で更新できる仕組みも用意しておくとか (昔、Yahoo! GeoCities がそういう仕組みも提供してた)、
• 申請があったユーザだけはFTP接続を許可するとか、

他のアクセス方法も何かしら用意しておかないといかんだろう…。だって、ユーザがファイルを一切更新できない状況に追い込まれかねないわけで。何かしらの救済手段を用意してから切り替えないと。

動作確認が取れているFTPクライアントの種類とバージョンをサポートページに列挙してないのもなんだかなあ。いやまあ、どうせほとんど動作確認してないから書きようもないんだろうけど。今では入手できない上に暗号化通信機能を持ってないFFFTPのバージョンを平気でサイトに書いちゃってるぐらいだし。

それにしても、どうして急にこんな余計なことを…。セキュリティ強化以前に、ユーザがサーバにアクセスできなくなったら、それはもうサービスとして成立しないだろう…。 *2