アカウント名:
パスワード:
使っている人を見かけたことないんですが、今 S/MIME ってどうなってるんでしょうか？あるいは GPG や PGP とか……
自分は見られても、恥ずかしいレベルの見られても困らない程度の内容しかメールでやり取りしてないから必要性がないのですけど、見られたくない人たちはどうしてるのかなーと。STARTTLS だってサーバをのっとられたら結局一緒じゃないかと。
PGPは20年くらい前に試しでやってみましたが、PGP対応の相手が一人しか居なかったので、しばらくは宣伝も兼ねて署名だけに使っていました。しかし、PGP対応の相手がいつまで経っても広がらなかったので、結局はやめてしまいました。当時はPGPの設定も複雑で、人に勧めるにしても相当PCの扱いに慣れていないと無理そうでした。そのうち、秘密・公開キー生成から、メーラーの設定まで自動でやってくれるソフトがでるんじゃないかと思っていたのですが、そんなものが流行ることもなく、そのままになってしまいました。webページの方は暗号化に対応していったのに、なぜ、メールでは流行らなかったのかは不思議ですねぇ～～。
鍵ペアの生成・管理と Outlookのプラグインならばこちらに https://www.gpg4win.org/ [gpg4win.org]
これ入れた状態で Sylpheedとか起こすと、プラグインなしでもPGP関連のメニューが有効になったりもします。
皆さん、S/MIMEの標準対応, gpg4win, gpgtools等情報ありがとうございます。キーの発行がgpgの方が楽だけど、運用考えるとS/MIMEの方が楽で、悩ましいところですね。Let's Encryptの様な、気軽なS/MIMEの認証団体があれば良いのですが。
プラグイン入れないと使えないあたり、一般に普及するのは無理ってことかな。ちなみに、Macだとこちら。
https://gpgtools.org/ [gpgtools.org]
無料メールのデファクトスタンダードのGmailを運用するGoogleにとって，通信経路を暗号化することで顧客の情報を独占できるHTTPSは自己の利益になっても，PGP, GPG, S/MINEのような中抜きができない暗号化は利益にならないからではないかな．
S/MINEは、ユーザー側で特になにもしなくていいし(メールアプリが最初からサポートしてる)、最近では金融機関からのメールでは多用されるようになった。けど、やはり一般の企業では、メールのセキュリティはまだまだ無頓着。
PGP、GPGにデフォルトで対応してるメジャーどころのメールアプリがないので、こちらも普及が難しい。ましてや、最近はメッセンジャーアプリやチャットサービスが普及して、相対的にEmailは減っていってるだろうから、今後も難しそう。
STARTTLSと、S/MIMEなどは、レイヤーが異なります。STARTTLSは、httpに対するhttps のように「通信経路」を暗号化するものです。「通信経路での盗聴・改竄」を防ぐだけ。サーバの確認はしますが、送信者/受信者の確認しません。そのためにはS/MIMEなどの上位のプロトコルで暗号化したり署名したりする必要があります。
#STARTTLSとS/MIMEの混同は、極論的には「HTTPSで暗号化してるから、ユーザーID/パスワードによる認証は要らないよね」っていう暴論です。
でもって、「STARTTLS」は自体は特定のプロトコルを指すものではなく、汎用的な「暗号化通信の実現手法」にすぎません。その最大のポイントは、「一旦平文でコネクションを確立した後、双方のネゴシエーションに基づいて暗号化通信に移行する」点です。httpsとか、pop3s、smtps などでは、SSLによる暗号通信しかできませんから、平文通信を行う通常のwell-known ポートとは別にSSL暗号通信専用のポートを用意する必要があります。そのため、SMTPのような「不特定多数が相手で、暗号化をサポートしているかどうかも不明」な場合に非常に使いにくいです。SMTP+STARTTLSの場合、送信側受信側どちらかがSTARTTLS非対応の場合は今まで通り平文通信するだけ。双方が対応していれば暗号通信になるという透過的な処理になります。今までのSTARTTLS非対応なMTAには手を付けることなく、「可能ならば暗号化通信する」ことになります。
…ところで、これソースの記事だけ読んでも、どこにSTARTTLSするのかさっぱりわからないんですよね。
・どこをSTARTTLS対応させるのか? 「SMTP 外部からのメール受信」「SMTP 外部へのメール送信」「SMTP 内部での部署間のメール中継」「SMTP 内部利用者からのメール送信」 「POP3/IMAP4 内部利用者のメール受信」など
・STARTTLSを使わない平文通信は可能なのか? STARTTLSによる暗号通信必須なのか? (不特定多数相手の、外部からのメール受信・外部へのメール送信は、暗号通信必須にすると、メールが送受信できない相手が出てしまいます。内部的な通信なら暗号必須にしてもいいと思います。)
このあたり、どうなってるのかによって、大きく話が変わるのですが、ソースを辿った [vice.com]ところ、「mail.mil」という軍内部のメールシステムで、末端利用者からのメール送信がインターネットを通るので、STARTTLSによる暗号化必須にする、という話のようです。
mail.mil のシステムがどういうものかわからないのですが、送信(MUA→MTA)をSMTP+STARTTLS と、受信をPOP3+STARTTLS/IMAP4+STARTLSに対応させる、という2本立てかなぁ…
#今時、そんなことするより、webベースのMUAをサーバで動かして、クライアント-サーバはhttpsでやる方が楽そう…
でもって、「STARTTLS」は自体は特定のプロトコルを指すものではなく、汎用的な「暗号化通信の実現手法」にすぎません。その最大のポイントは、「一旦平文でコネクションを確立した後、双方のネゴシエーションに基づいて暗号化通信に移行する」点です。 httpsとか、pop3s、smtps などでは、SSLによる暗号通信しかできませんから、平文通信を行う通常のwell-known ポートとは別にSSL暗号通信専用のポートを用意する必要があります。
HTTPに関してはSTARTTLSとは別の方法 [ietf.org]が提案されているようですが、普及する様子はなさそうですね。
何か技術的な課題があって普及しないのか、それとも単にHTTPSが充分に普及してしまって他の方法が入り込む余地がないのか。
STARTTLS だってサーバをのっとられたら結局一緒じゃないかと。
というか、現状STARTTLSって「平文パスワードを保護するための仕組み」くらいにしか役立っていないような気が。 ユーザはsubmissionにTLS使うことを強制できてもサーバ間の配送にまでは強制できませんし、かといって配送にTLS使うのが一般的かというと…。
どちらも署名用では使われているのをぼちぼち見ますが、暗号化に使われてるのはあまり見ないですね。
Facebook が自分の PGP 公開鍵を登録しておくとメールを暗号化して送ってくれたりするぐらいでしょうか。
必要もないのに暗号化まではしないでしょうね。私も署名にしか使ったことがないなあ。暗号化が必要で、かつ、Mailでやりとりする状況は非常に限定的じゃないかな。
アカウント登録情報とか送られてきません？ あるいは購入履歴とか住所とか。個人個人ではまだしも個人対企業ではバンバン送られてる印象が。
最初は何のことかと理解できなかったが、暗号化が必要な部分はhttpsでMailは使ってないよね。
ユーザー側にアプリケーションのインストールと設定が必要なものをユーザーとのやりとりに使っている企業があるのかと思った。
S/MIMEだって端末をのっとられたら結局一緒じゃないかと、なんてことも言えますぜどこまでの脅威を対象にするかと、かけたコストに対する効果が割に合うかどうかでしょう
端末乗っ取りはその人に関係するメールだけだけど、サーバ乗っ取りは全メールなので影響は段違いかと。
サーバ上でウィルススキャンが効かなくなるので困ると思うサーバ管理者も多そうだな。あとメーリングリストの運用が難しいのでそれも大きい。
銀行からのメールはS/MIMEで署名してあるものも結構ありますね。
PGP/GPGはThunderbirdやGmailが対応していれば普及したでしょうね...
Gmailは基本Webサービスだし、GPGなどに対応するのは難しいと思う。ブラウザに実装するか、もしくは秘密鍵をGoogleに預けるしかない。Javascriptでローカルでやるにしても、秘密鍵はどこにあ保存しないといけない。WebStorageとかだろうか。下手すると脆弱性などでXSSにより秘密鍵抜かれるリスクあるしなぁ。
業務で「暗号化したファイルとそのパスワードは別のメールで送ってください」と支持されています．さっさとS/MIMEを導入した方がいい．
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
S/MIME はどこ行ったの？ (スコア:1)
使っている人を見かけたことないんですが、今 S/MIME ってどうなってるんでしょうか？あるいは GPG や PGP とか……
自分は見られても、恥ずかしいレベルの見られても困らない程度の内容しかメールでやり取りしてないから必要性がないのですけど、見られたくない人たちはどうしてるのかなーと。
STARTTLS だってサーバをのっとられたら結局一緒じゃないかと。
Re:S/MIME はどこ行ったの？ (スコア:2)
PGPは20年くらい前に試しでやってみましたが、PGP対応の相手が一人しか居なかったので、しばらくは宣伝も兼ねて署名だけに使っていました。しかし、PGP対応の相手がいつまで経っても広がらなかったので、結局はやめてしまいました。
当時はPGPの設定も複雑で、人に勧めるにしても相当PCの扱いに慣れていないと無理そうでした。
そのうち、秘密・公開キー生成から、メーラーの設定まで自動でやってくれるソフトがでるんじゃないかと思っていたのですが、そんなものが流行ることもなく、そのままになってしまいました。
webページの方は暗号化に対応していったのに、なぜ、メールでは流行らなかったのかは不思議ですねぇ～～。
Re:S/MIME はどこ行ったの？ (スコア:2)
鍵ペアの生成・管理と Outlookのプラグインならばこちらに https://www.gpg4win.org/ [gpg4win.org]
これ入れた状態で Sylpheedとか起こすと、プラグインなしでもPGP関連のメニューが有効になったりもします。
Re:S/MIME はどこ行ったの？ (スコア:2)
皆さん、S/MIMEの標準対応, gpg4win, gpgtools等情報ありがとうございます。
キーの発行がgpgの方が楽だけど、運用考えるとS/MIMEの方が楽で、悩ましいところですね。
Let's Encryptの様な、気軽なS/MIMEの認証団体があれば良いのですが。
Re: (スコア:0)
プラグイン入れないと使えないあたり、一般に普及するのは無理ってことかな。
ちなみに、Macだとこちら。
https://gpgtools.org/ [gpgtools.org]
Re: (スコア:0)
無料メールのデファクトスタンダードのGmailを運用するGoogleにとって，通信経路を暗号化することで顧客の情報を独占できるHTTPSは自己の利益になっても，PGP, GPG, S/MINEのような中抜きができない暗号化は利益にならないからではないかな．
Re: (スコア:0)
S/MINEは、ユーザー側で特になにもしなくていいし(メールアプリが最初からサポートしてる)、最近では金融機関からのメールでは多用されるようになった。
けど、やはり一般の企業では、メールのセキュリティはまだまだ無頓着。
PGP、GPGにデフォルトで対応してるメジャーどころのメールアプリがないので、こちらも普及が難しい。
ましてや、最近はメッセンジャーアプリやチャットサービスが普及して、相対的にEmailは減っていってるだろうから、今後も難しそう。
Re:S/MIME はどこ行ったの？ (スコア:2)
STARTTLSと、S/MIMEなどは、レイヤーが異なります。
STARTTLSは、httpに対するhttps のように「通信経路」を暗号化するものです。「通信経路での盗聴・改竄」を防ぐだけ。
サーバの確認はしますが、送信者/受信者の確認しません。そのためにはS/MIMEなどの上位のプロトコルで暗号化したり署名したりする必要があります。
#STARTTLSとS/MIMEの混同は、極論的には「HTTPSで暗号化してるから、ユーザーID/パスワードによる認証は要らないよね」っていう暴論です。
でもって、「STARTTLS」は自体は特定のプロトコルを指すものではなく、汎用的な「暗号化通信の実現手法」にすぎません。その最大のポイントは、「一旦平文でコネクションを確立した後、双方のネゴシエーションに基づいて暗号化通信に移行する」点です。
httpsとか、pop3s、smtps などでは、SSLによる暗号通信しかできませんから、平文通信を行う通常のwell-known ポートとは別にSSL暗号通信専用のポートを用意する必要があります。
そのため、SMTPのような「不特定多数が相手で、暗号化をサポートしているかどうかも不明」な場合に非常に使いにくいです。
SMTP+STARTTLSの場合、送信側受信側どちらかがSTARTTLS非対応の場合は今まで通り平文通信するだけ。双方が対応していれば暗号通信になるという透過的な処理になります。今までのSTARTTLS非対応なMTAには手を付けることなく、「可能ならば暗号化通信する」ことになります。
…ところで、これソースの記事だけ読んでも、どこにSTARTTLSするのかさっぱりわからないんですよね。
・どこをSTARTTLS対応させるのか?
「SMTP 外部からのメール受信」「SMTP 外部へのメール送信」「SMTP 内部での部署間のメール中継」「SMTP 内部利用者からのメール送信」 「POP3/IMAP4 内部利用者のメール受信」など
・STARTTLSを使わない平文通信は可能なのか? STARTTLSによる暗号通信必須なのか?
(不特定多数相手の、外部からのメール受信・外部へのメール送信は、暗号通信必須にすると、メールが送受信できない相手が出てしまいます。内部的な通信なら暗号必須にしてもいいと思います。)
このあたり、どうなってるのかによって、大きく話が変わるのですが、ソースを辿った [vice.com]ところ、「mail.mil」という軍内部のメールシステムで、末端利用者からのメール送信がインターネットを通るので、STARTTLSによる暗号化必須にする、という話のようです。
mail.mil のシステムがどういうものかわからないのですが、送信(MUA→MTA)をSMTP+STARTTLS と、受信をPOP3+STARTTLS/IMAP4+STARTLSに対応させる、という2本立てかなぁ…
#今時、そんなことするより、webベースのMUAをサーバで動かして、クライアント-サーバはhttpsでやる方が楽そう…
Re:S/MIME はどこ行ったの？ (スコア:1)
でもって、「STARTTLS」は自体は特定のプロトコルを指すものではなく、汎用的な「暗号化通信の実現手法」にすぎません。その最大のポイントは、「一旦平文でコネクションを確立した後、双方のネゴシエーションに基づいて暗号化通信に移行する」点です。
httpsとか、pop3s、smtps などでは、SSLによる暗号通信しかできませんから、平文通信を行う通常のwell-known ポートとは別にSSL暗号通信専用のポートを用意する必要があります。
HTTPに関してはSTARTTLSとは別の方法 [ietf.org]が提案されているようですが、普及する様子はなさそうですね。
何か技術的な課題があって普及しないのか、それとも単にHTTPSが充分に普及してしまって他の方法が入り込む余地がないのか。
Re:S/MIME はどこ行ったの？ (スコア:1)
STARTTLS だってサーバをのっとられたら結局一緒じゃないかと。
というか、現状STARTTLSって「平文パスワードを保護するための仕組み」くらいにしか役立っていないような気が。 ユーザはsubmissionにTLS使うことを強制できてもサーバ間の配送にまでは強制できませんし、かといって配送にTLS使うのが一般的かというと…。
Re: (スコア:0)
どちらも署名用では使われているのをぼちぼち見ますが、暗号化に使われてるのはあまり見ないですね。
Facebook が自分の PGP 公開鍵を登録しておくとメールを暗号化して送ってくれたりするぐらいでしょうか。
Re: (スコア:0)
必要もないのに暗号化まではしないでしょうね。私も署名にしか使ったことがないなあ。
暗号化が必要で、かつ、Mailでやりとりする状況は非常に限定的じゃないかな。
Re: (スコア:0)
アカウント登録情報とか送られてきません？ あるいは購入履歴とか住所とか。
個人個人ではまだしも個人対企業ではバンバン送られてる印象が。
Re: (スコア:0)
最初は何のことかと理解できなかったが、暗号化が必要な部分はhttpsでMailは使ってないよね。
ユーザー側にアプリケーションのインストールと設定が必要なものをユーザーとのやりとりに使っている企業があるのかと思った。
Re: (スコア:0)
S/MIMEだって端末をのっとられたら結局一緒じゃないかと、なんてことも言えますぜ
どこまでの脅威を対象にするかと、かけたコストに対する効果が割に合うかどうかでしょう
Re:S/MIME はどこ行ったの？ (スコア:2, すばらしい洞察)
端末乗っ取りはその人に関係するメールだけだけど、サーバ乗っ取りは全メールなので影響は段違いかと。
Re: (スコア:0)
サーバ上でウィルススキャンが効かなくなるので困ると思うサーバ管理者も多そうだな。
あとメーリングリストの運用が難しいのでそれも大きい。
Re: (スコア:0)
銀行からのメールはS/MIMEで署名してあるものも結構ありますね。
PGP/GPGはThunderbirdやGmailが対応していれば普及したでしょうね...
Re: (スコア:0)
Gmailは基本Webサービスだし、GPGなどに対応するのは難しいと思う。ブラウザに実装するか、もしくは秘密鍵をGoogleに預けるしかない。
Javascriptでローカルでやるにしても、秘密鍵はどこにあ保存しないといけない。WebStorageとかだろうか。
下手すると脆弱性などでXSSにより秘密鍵抜かれるリスクあるしなぁ。
Re: (スコア:0)
業務で「暗号化したファイルとそのパスワードは別のメールで送ってください」と支持されています．
さっさとS/MIMEを導入した方がいい．