あるAnonymous Coward曰く、米国防総省がセキュリティ向上を目指し、メールシステムでSTARTTLSの利用をデフォルトとするという（CNN.co.jp、NEOWIN）。STARTTLSはメールサーバーとのやり取りを暗号化された経路で行う技術。これによって、メールサーバーとのやり取りの傍受によってその内容やアカウント情報が漏洩することを防ぐことができる。とはいえ、同様の暗号化技術は広く普及しており、逆に今まで暗号化を使っていなかったことのほうがo泥機ではある。また、STARTTLSを使ってもそれだけではメールの内容は十分には保護できないという点については触れられていない。
o泥機 (スコア:2)
え？
Re:o泥機 (スコア:5, 参考になる)
"O" バージョンのandroid機ってことだろ。
Re: (スコア:0)
関係ないけど東西線がhylom感
https://twitter.com/shigets0312/status/885300420452564993/photo/1 [twitter.com]
Re:o泥機 (スコア:1)
そこは触れないでおくのが優しさ
Re: (スコア:0)
ギャル文字の方が遥かにマシに見えるんだが
Re:o泥機 (スコア:1)
m9(^Д^) hylomにつられてやんの！
釣られるのもネタ？
ごめんなさい、野暮なコメかいちまった・・・・
Re:o泥機 (スコア:1)
さっき見た時は、(スコア:-1)荒らしだったのに、今は(スコア:2)になってる。
今回はモデ合戦が早い。
Re: (スコア:0)
こんなツッコミ待ちの謎ワードに触れたらマイナスモデだなんて
Re:o泥機 (スコア:1)
ほんとだ、hylom様の罠だったのか・・・
Re: (スコア:0)
「ぐんぐつ（なぜか変換できない）」とかと同じで、突っ込んだら負けってことでしょう。
2ch文化ですよ。
Re: (スコア:0)
こんなミス驚きーなんてねハハハ
Re: (スコア:0)
これはわざとじゃないのか流石に。
まぁ、意味があるかどうかはさておき
Re: (スコア:0)
スラドの仕事はタダなのかもしれないけど、hylomさんは文章書くのが本業でしょ。誤字多すぎない？他のサイトや本とかでもやってないか不安だわ。
スラド外部にもニュース提供してるじゃん。いいのか？ (スコア:0)
さすがにどんなIMEでもこんな変換するわけないから、また造語だろと思って一応検索してみましたよ。そしたら外の人も見てるじゃないですか、この記事。外部の人に見てもらうならこういう遊びはやめたほうがいいんじゃないですか。
http://www.zaikei.co.jp/article/20170713/385091.html [zaikei.co.jp]
http://www.excite.co.jp/News/it_g/20170713/Slashdot_17_07_12_0720254.html [excite.co.jp]
Re:スラド外部にもニュース提供してるじゃん。いいのか？ (スコア:1)
それは提供してるんじゃなくて、あっちが勝手に読んで引用記事仕立て上げてるんじゃないすかね。
ちゃんとしたニュースサイトで責任あるアンカーなら内容真贋裏取って誤字脱字くらいは修正しそう。
と思ったら「o泥機」そのまんま載せてやんの、おもったより仕事してないね。
記事を書いてる(コピペ？)途中で疑問に思わないんだろうか。
もしこのまま拡散していったら、どこかで新しいバズワードになったりして。
#コピペするだけのお仕事羨ましい。
Re: (スコア:0)
それらのサイトに「記事提供元スラド」って書いてあるので、「提供されたものの内容を改変せずにそのまま使う」っていう契約の元に記事にしてるんじゃないですかね？
どのストーリーを選ぶかは、それらのサイト側が選んでるんでしょうけど。
Re:スラド外部にもニュース提供してるじゃん。いいのか？ (スコア:1)
そうなんだ、ということはそれらのサイトから記事使用料とか出てるのかな。
あれで金取るのもなんだかねぇ。
一部ちょっとした間違い(Typo)があるだけだと言えばそうなんだけど。
Re:スラド外部にもニュース提供してるじゃん。いいのか？ (スコア:1)
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)
無料メールのデファクトスタンダードの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)
業務で「暗号化したファイルとそのパスワードは別のメールで送ってください」と支持されています．
さっさとS/MIMEを導入した方がいい．
メールとか電話とかFAXみたいなレガシーなツール使うのやめよう (スコア:1)
全部数十年前に設計されたモノで今のネットワークの時代にはあってないよね？
Re: (スコア:0)
今のネットワークは数十年前に設計されたものを継承しているという事実から目を背けたい？
Re:メールとか電話とかFAXみたいなレガシーなツール使うのやめよう (スコア:1)
TCP/IP なんて時代に合ってないぜ、俺が新時代のプロトコルを作る！
っていって墓場に埋葬されたプロトコルってどれぐらいあるんだろう・・・
Re: (スコア:0)
「(さすがに国防総省で)メールとか電話とかFAXみたいなレガシーなツール使うのやめよう」
って言いたかったんじゃないかな？
そうでないなら世間を知らなすぎるもの。
TLSなんか簡単に破れるので (スコア:1)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
はやくPGP使えばいいのに。
Javascriptのライブラリとか探せばあるよ？
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJZZu3aAAoJENGApoDZrL8Ss/IH/1aDSHrOTbinIES8I5jmGgr1
IRJD/yrGg2ZzV+0GhJc6CRaUA8VlNkMGTfkurRfTD3ERa3T8nv+CNJvEMGylv3ln
CpK3R1HQ23wqjss0+0AKsbtmY4SODuEIrhJ4dqBYsFq8umBGSwO9YQOtmd7ll+TZ
rvgGOgVZoNRm3Vgzaa6uOtvl+jXzURQb6b8xAR5k8zAuef3HiSCTny+lTxVsEFSD
VjzKu3M+L8ei3WCTpuMVBPV4j7EsQ+V89U6F/WSnOrfuaCqAUbDi723pKbV61HAF
C2SI/xd906OHqdelr/MCpQyMYA6cPPK3BpOnGCYeWEa3LeMNA1OcpnH8AcjfV0g=
=Fvek
-----END PGP SIGNATURE-----
Re: (スコア:0)
JSのPGPライブラリってあまりなくない？
「OpenPGP [openpgpjs.org]」有名、むしろほとんどがこれ使ってる。暗号・復号・検証。やや難関。
「EasyPGP [danwin1210.me]」 最近知った。暗号化のみ(作者のコンタクトフォームに使われてる)。1ライブラリ、サンプル付。
Re: (スコア:0)
ACなのに署名とか面白おかしいｗ（モデ権ないからできないッ）
いっそのこと全部Gmail(G Suite)政府版とかにしちゃった方が予算減るんじゃない (スコア:0)
これ以上強力なの作れるの？
Re: (スコア:0)
逆に政府がgmailを使っていない(使わない)ことでお察し
Re: (スコア:0)
ここだけの話、AWS GovCloudも政府には一切使われてないって話だぞ(適当
Re: (スコア:0)
これ以上強力なの作れるの？
Gmailの運用に雇用された他国人がいるのが問題なのでは？
Re: (スコア:0)
Gmailはひょっとするとセキュアかもしれないが、Gmailに届くまでの経路があるから、経路か文面のE2Eの暗号化が必要なんですよ。
その意味ではHTTPSだったり中継点が無いという意味で、Twitter DMとかSNSのメッセージのがはるかにセキュア。
と20年くらい前からずっと言われてるが変わらないのよなぁ。。。
Re: (スコア:0)
今時、メールゲートウェイはTLS対応してるのが当たり前
そうじゃないのは日本の企業と大学とISPくらい
#日本でも業種によってはTLS対応されてるのが普通、というところもある
Re: (スコア:0)
そんなあなたにこちらをどうぞ
Google 透明性レポート
https://www.google.com/transparencyreport/saferemail/?hl=ja [google.com]
アジアを見てもらえばわかるが、日本のメールサービスがクソなのは明らか。