アカウント名:
パスワード:
FTPの最大の欠点は何かというと、ファイルのハッシュ値が変わることです。FTPにはアスキーモードとバイナリモードというものがありまして、バイナリデータでないアスキーデータは自動的にアスキーモードとして扱われて、JS(ジャバスクリプト)やHTMLやTXTなどのアスキーデータは改行コードがクライアントOSに合わせて自動的に書き換わる仕組みが採用されています。これによりファイルのハッシュ値が変わってしまうので、セキュリティを重視する現在では実用に耐えないといってもいいでしょう。
FTPはHTTPSと違って改竄される恐れがあるので、FTPでダウンロードするときにはHTTPSのページなどに書かれたファイルのハッシュ値と比較します。(昔からダウンロードサイトにはハッシュ値を書く文化がありました。)
JavaScriptなどのプログラムもアスキーデータですからハッシュ値が一致しないと安全性の検証ができないわけですね。
だからこそ、もうFTPは滅びるしかないと思います。HTTPやHTTPSならば改行コードはそのまま転送されるので、サーバとクライアントでOSが違っても改行コード変換でハッシュ値が変化することはありません。
バイナリモード使えば解決では?
今日のほんこれ
改ざんよりはダウンロード未完了等の破損の検知だな。改ざん検知ならハッシュは信頼している場所からとらないといけないからな。
FTPがそれならHTTPもHTMLの頭のほうの文字が乳かどうかで解釈変えるような時代のクライアントは使えなかったな。
FTPSとかなら残ってても良いのでは?とおもったけど、転送モード煩わしいから良いや…そもそもこれ要求するトコ、モードもデータ仕様もオレサマ常識ばかりだし。
FTPSはTLSでラップされていてアプリケーションプロトコル中のIPアドレスをブロードバンドルーターという中間者が改ざんできないから、NAT全盛のIPv4アドレス枯渇時代にあってはPASSIVEモードじゃないと使い物にならんのだよ
そもそもの話として、IPv6対応できてるの?という疑問すら。# 具体的には、RFC2428 [ietf.org]とか
その理屈であればsmtpも滅ぶことになりそうですね。
メールクライアントでのSMTPは、TLSに対応したSMTPSがよく使われる。ブラウザでTLSに対応したFTPSは使われない。
元コメは多分暗号化の話はしてませんよ。
ftpとかsmtpとかの古代のプロトコルは「テキストをなるべく便利にやりとりしよう」というのが設計思想にちらっと含まれていたので、「見た感じが同じになるよう、内容のエンコード方法を送信時に調整する」という機能が付いていて、送ったものがそのまま届かない可能性があるんです。設定が不十分なメールサーバを介すると、メール全文が文字化けする、なんてこともザラです。
ネットワークの授業でよく出てくる(けど今時は使い道が無くて説明が難しい)「プレゼンテーション層」というのがその名残です。
通信経路での機密性(暗号化)の話ではなく、通信経路での真正性(改竄の検知、署名の検証、ハッシュ値確認)の話。
斯くして、EUC でコードされた、改行コードが/crのファイルが出来上がるですね。キメラなファイルを欲しがるとは変態ですね。他人からもらうデータは生のままで、自分のところにあるツールで使いやすいように変えなさいと教わらなかったのでしょうか。
まっとうなosを使ってるならsedもnhkもあるんだから、RETRした後、自分で好きなように変えればいいのに。
#あ、俺様が使いやすいようにテキストファイルをms word形式でよこしなさい、という類の手合いか。
nhk違う。nkfですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
FTPの最大の欠点はファイルのハッシュ値が変わること (スコア:0)
FTPの最大の欠点は何かというと、ファイルのハッシュ値が変わることです。
FTPにはアスキーモードとバイナリモードというものがありまして、バイナリデータでないアスキーデータは自動的にアスキーモードとして扱われて、JS(ジャバスクリプト)やHTMLやTXTなどのアスキーデータは改行コードがクライアントOSに合わせて自動的に書き換わる仕組みが採用されています。
これによりファイルのハッシュ値が変わってしまうので、セキュリティを重視する現在では実用に耐えないといってもいいでしょう。
FTPはHTTPSと違って改竄される恐れがあるので、FTPでダウンロードするときにはHTTPSのページなどに書かれたファイルのハッシュ値と比較します。(昔からダウンロードサイトにはハッシュ値を書く文化がありました。)
JavaScriptなどのプログラムもアスキーデータですからハッシュ値が一致しないと安全性の検証ができないわけですね。
だからこそ、もうFTPは滅びるしかないと思います。
HTTPやHTTPSならば改行コードはそのまま転送されるので、サーバとクライアントでOSが違っても改行コード変換でハッシュ値が変化することはありません。
Re:FTPの最大の欠点はファイルのハッシュ値が変わること (スコア:2, すばらしい洞察)
バイナリモード使えば解決では?
Re: (スコア:0)
今日のほんこれ
Re:FTPの最大の欠点はファイルのハッシュ値が変わること (スコア:1)
改ざんよりはダウンロード未完了等の破損の検知だな。改ざん検知ならハッシュは信頼している場所からとらないといけないからな。
FTPがそれならHTTPもHTMLの頭のほうの文字が乳かどうかで解釈変えるような時代のクライアントは使えなかったな。
Re: (スコア:0)
FTPSとかなら残ってても良いのでは?とおもったけど、転送モード煩わしいから良いや…
そもそもこれ要求するトコ、モードもデータ仕様もオレサマ常識ばかりだし。
Re: (スコア:0)
FTPSはTLSでラップされていてアプリケーションプロトコル中のIPアドレスをブロードバンドルーターという中間者が改ざんできないから、NAT全盛のIPv4アドレス枯渇時代にあってはPASSIVEモードじゃないと使い物にならんのだよ
Re: (スコア:0)
そもそもの話として、IPv6対応できてるの?という疑問すら。
# 具体的には、RFC2428 [ietf.org]とか
Re: (スコア:0)
その理屈であればsmtpも滅ぶことになりそうですね。
Re: (スコア:0)
メールクライアントでのSMTPは、TLSに対応したSMTPSがよく使われる。
ブラウザでTLSに対応したFTPSは使われない。
Re: (スコア:0)
元コメは多分暗号化の話はしてませんよ。
ftpとかsmtpとかの古代のプロトコルは「テキストをなるべく便利にやりとりしよう」というのが設計思想にちらっと含まれていたので、
「見た感じが同じになるよう、内容のエンコード方法を送信時に調整する」という機能が付いていて、
送ったものがそのまま届かない可能性があるんです。
設定が不十分なメールサーバを介すると、メール全文が文字化けする、なんてこともザラです。
ネットワークの授業でよく出てくる(けど今時は使い道が無くて説明が難しい)「プレゼンテーション層」というのがその名残です。
Re: (スコア:0)
通信経路での機密性(暗号化)の話ではなく、通信経路での真正性(改竄の検知、署名の検証、ハッシュ値確認)の話。
Re: (スコア:0)
バイナリモードでファイルが化けずに転送できればほとんどの場合は済むのだから、ASCIIモードが要らないからといってFTP自体を廃止することはない。
HTTPのPUTだのDELETだのはあまり使われないし、サーバ側の実装が悪いと脆弱性を生みがちだけど、だからと言ってHTTPを廃止しろとはならないでしょう。
Re: (スコア:0)
斯くして、EUC でコードされた、改行コードが/crのファイルが出来上がるですね。キメラなファイルを欲しがるとは変態ですね。
他人からもらうデータは生のままで、自分のところにあるツールで使いやすいように変えなさいと教わらなかったのでしょうか。
まっとうなosを使ってるならsedもnhkもあるんだから、RETRした後、自分で好きなように変えればいいのに。
#あ、俺様が使いやすいようにテキストファイルをms word形式でよこしなさい、という類の手合いか。
うわ、恥ずかしい (スコア:0)
nhk違う。
nkfですね。