加えて、LINEでは、仮に通信ネットワークの傍受が行われたとしてもメッセージを覗くことができないように、公開鍵暗号(public key encryption)方式を使っています。ユーザーに対してLINE アプリを提供する際、暗号化ができる公開鍵のみをアプリに入れて提供し、ユーザー端末とサーバが接続されたときだけLINE サーバでのみ解析できる暗号化された安全なチャネルを作ります。こうすることで、SSL(Secure Socket Layer)より軽く、LINEの全バージョンで使用できる安全な暗号化を実現できます。

SSL はすでに時代遅れの代物で、 2015年秋現在は皆さん TLS を利用されていることでしょう。 Web ブラウザで SSL 2.0 や SSL 3.0 を有効にしているそこのあなた、今すぐ無効にしましょう。

TLS では、公開鍵暗号方式や共通鍵暗号方式、電子証明書、暗号学的ハッシュ関数といった複数の暗号技術要素を組み合わせて安全な通信路を確保しています。

RSA に代表される公開鍵暗号方式は一般的に AES に代表される共通鍵暗号方式と比べて計算量が大きい、つまり重たい処理となります。

このため TLS では、通信路を流れるデータの暗号化に共通鍵暗号を用いて、共通鍵の共有や相手の認証のために公開鍵暗号方式を用いるのが一般的です。

仮にメッセージの暗号化に RSA を用いているとしたら、 SSL より軽いという点をどのように実装しているのか気になります。

http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年 10月14日 22時40分に閲覧：

ユーザー側のLINE アプリ(クライアント)には、サーバが発行したRSA鍵を使用してデータの暗号化に使う暗号化鍵値を共有します。この鍵を利用してデータを暗号化すると、第三者はメッセージを見ることができなくなります。

これは上で説明したとおり SSL や TLS でも行っていることです。

RSA を用いているので安全であるという主張をしていますが、メッセージの暗号化に用いられている暗号スイート（アルゴリズムの種類、鍵の長さ、ブロック暗号の場合は暗号利用モード、そしてハッシュアルゴリズムの種類）は、その通信路が安全であると判断できるか否かを決める大切な情報です。

http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年 10月14日 22時40分に閲覧：

既存のRSA 方式も秘密データの共有に使う安全な方式ではありますが、鍵管理の面から見ると、ユーザー側の端末でそれぞれのRSA鍵をすべて管理しなければならないという問題があり、その代替手段としてDHを使用するようになりました。

DH および ECDH による共通鍵暗号に用いる鍵の交換は SSL や TLS でも実装されており近年では広く使われています。 SSL より軽いと主張し、 SSL や TLS が公開鍵暗号方式以外の要素によって担保している安全性をどのように確保しているか不明な実装に比べると、大きな改善です。

なお SSL や TLS においては通信相手の公開鍵を全て管理する必要がないように、上で説明した電子証明書による公開鍵基盤 (PKI) の仕組みを利用しています。

つまり共通鍵暗号に用いる鍵の交換にどのような手段を用いるかは、鍵管理とは（ほぼ）独立です。

共通鍵暗号と暗号利用モード

http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年 10月14日 22時40分に閲覧：

ここでメッセージの暗号化に使用している暗号化アルゴリズムはAES-CBC-256という方式で、現在一般に使われている暗号化アルゴリズムの中で最も強度が高いと評価されています。

メッセージ認証と組み合わせない CBC はビット反転攻撃に弱いことが知られています。 GCM ではデータの暗号化と認証を同時に行うためビット反転攻撃に耐性があります。 AESを GCM で利用するのは、最近の TLS の実装では広く用いられており、 Google や twitter も利用しています。

CBC も CBC-MAC のようにメッセージ認証と組み合わせることでビット反転攻撃に強くなります。

解決されない鍵管理 問題

図6 のとおり、 ECDH で共通鍵暗号に用いる鍵の交換を行うにしても通信相手の公開鍵は必要です。上で説明したとおり鍵管理という問題への解決策になりません。また公開鍵が本当に通信相手のものであることをどのように検証するのかについても不明です。通信相手の検証は、送信側では秘密の話を他の人に知られないように、受信側では他の人になりすまされないように、双方にて必要です。

ここからは安易なパターンの想像ですが、通信相手の公開鍵情報は LINE ユーザー情報の一部として LINE サーバーで管理されており、必要に応じて安全な通信路を用いて LINE サーバーから取得するようなものではないかと思います。公開鍵情報のやりとりに用いられる通信路に正しく実装された TLS が用いられていて、サーバーとクライアントの両方が認証されていて、現在の水準から見て妥当なレベルの暗号スイートが用いられていることを願うばかりです。

公開鍵と秘密鍵がどこでどのように保管されているのか気になります。各端末で保管するのが安全ですが、サービスの要求として端末を乗り換えてもメッセージが読めるという条件を安易に満たすために秘密鍵を LINE サーバーに預託していないことを祈るばかりです。

ECDH 鍵の生成は計算量が大きい処理であり質の良い乱数を必要とします。 PC に比べると非力なスマートフォンで生成した鍵の質をどのように担保しているのか気になります。

2015年 10月17日 10時16分追記

先ほど閲覧したところ、上記引用箇所の多くは削除されていました。公開鍵が本当に通信相手のものであることをどのように検証するのかについては明らかではないようです。 LINE サーバーが介在する形であれば、鍵をすり替えることで別のユーザーになりすますことが可能でしょう。または、 LINE アプリに何か細工をする方がより簡単でしょう。

ECDH 鍵はその場限り (ephemeral) という説明がないので Perfect Forward Secrecy ではないと考えられ、望ましくないという意見もあるようです。 LINE サーバーとの間に安全な通信路を確立する目的で ECDH 鍵を用いる場合、 LINE サーバーが用いる秘密鍵の漏洩は全てのユーザーに影響を与えうるため PFS は非常に重要です (TLS を用いた Web サーバーでも同様です) 。一方ユーザー間でメッセージを暗号化する場合、ユーザー所有の ECDH 鍵についてはそのユーザーに影響が限定されます。通信相手ごとに必要なその場限りの鍵生成とユーザー所有の ECDH 鍵を利用した鍵交換にかかる計算量と ECDH 鍵漏洩のリスクを天秤にかけて PFS を採用しないという判断かもしれません。

通信の秘密という観点ではメッセージの内容だけではなく誰と通信したか (または、していないか) という情報も守りたくなります。宛先を LINE サーバーで確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます。

Permalink | 記事への反応(0) | 00:27

2015-08-07

■一体なんだよこの記事

http://webbingstudio.com/weblog/cms/entry-773.html

知ってか知らずかちょっとこの記事ひどいので、突っ込む。

共用SSL証明書が当たり前？

小規模の商用サイトでは、フォームを暗号化する際には、共有SSLを利用するのが当たり前となっています。独自ドメインのSSL証明書を取得すると、フォームを通して得られる収益よりも、維持費の方がはるかに高くなってしまうからです。

とこの記事では書かれていますが、一体どこで「当たり前」なんでしょうか？

SSL証明書の取得費用は、サーバーホスティングによって額がまちまちなのは確かですけれども、

安く独自 SSL証明書を取得して利用できるサーバーホスティングは山ほどあります。

WEB制作者として「自分が良く知っているだけ」のサーバーのレンタルをクライアントに押し付けてはいませんか？

また、小規模商用サイトにしても、仮に年額35,000円のSSL証明書をつけ、かつ、月額3,000円のサーバーを借りていたとすると

月額でいえば6,000円くらいの負担ですが、

いくら小規模とはいえ、広報活動の中核をなすWEBサイトであるならば、

月額6,000円をペイできないとすると、

ちょっと商用サイトとしては破綻しているように感じます。

（というか、効果測定をしていないだけ？）

改ざんの認識

共用SSLのリスクに関して言えば、この記事が引用している、高木浩光氏の書かれている通りではあります。

cookieを取得できてしまうという点においては。ですね。

で、その部分の帰結が、完全におかしい。

cookieが取得できてしまう結果として、一番最初に狙われるのは、管理画面へのログイン。

いわゆるセッションハイジャックです。

ログイン状態を乗っ取られた時点で、どんなCMSでも、WEBサイトの改ざんは可能です。

なぜか。

CMSは「コンテンツをマネージメント」する仕組みで、

そのコンテンツは多くの場合 MySQLに代表されるDBに保存してあります。

したがって、ファイルの改ざんなどを行わずとも、WEBサイトの内容は書き換えることが可能なのです。

WEB アプリケーションの仕組みに明るくない方が読むと

「なるほど」と思ってしまうかもしれないので、

早々に訂正していただきたい。

また、この記事にある a-blog cmsというCMSについてはよく知りませんが、

多くのモダンなCMSでは、ほとんどの管理画面ログインにおいて、

セッションハイジャックに対する防衛は行われていますので、

cookieの取得が、即WEBページの改ざんに繋がるような書き方も、

CMS 利用者に対して、誤解を広げる結果になりそうですので、

ここも早々に訂正していただきたい。

CMSを過信していないか？

この筆者さんは、a-blog cmsというCMSを利用されているようだ。

このCMSはどうやら、PHP製ながらPHPのソースを暗号化しているようだ。

なるほど、それならばファイルの改ざんは確かに起きにくい。

が、それはあくまで起きにくいだけの問題。

こう言ってはなんですが、攻撃者にしてみれば、a-blog cmsを攻略するくらいならMovable TypeやWordPressを攻めた方が楽というものです。

この記述はむちゃくちゃである。攻撃者にしてみれば、誰でも手に入れられるCMSであれば、

ファイル構造の解析はそんなに難しい話ではない。

a-blog cmsの公式サイトを拝見すると、MySQLを利用しているようで、

ともすれば、インストールさえしてしまえば、

ファイルの暗号化はなされていようとも、DBの中身の仕様は丸見えだ。

前提条件として「知っている」「知らない」の差はあれど、攻撃に関して「ラク」というのは

どう考えても楽観的に過ぎる考えだ。

「安全」の認識

最後に突っ込んでおきたい。というか質問というか。

どうも「SSLで確保される安全の領域」について、かなり認識が甘いようだ。

SSLはあくまで、TCP/IP ネットワークにおいて通信経路を暗号化するための技術だ。

通信する際に、通信先のサーバーが正しく認証されているかどうか？に必要なのは SSL証明書。

で、ここに書いたとおり、SSLはあくまでサーバーと利用者の通信においての暗号化だ。

この記事に書かれていることは「メールフォームについて」のことのようだが、

サーバーに到達したあとのメールについては安全性をかんがえていますか？

メールは全く暗号化されず平文で送信されるとても脆弱な通信手段だ。

いくらSSLで通信を暗号化しようとも、問い合わせフォームの送信がメールだったとすると…

外部から傍受される危険性が高くなります。

とこの記事ではかかれていますが、そもそもHTTPやHTTPSの通信を傍受するより遥かに

メールを傍受したほうがラクとも考えられるはず。

CMSを使っている方を非難するわけではないが、

CMSの機能に甘んじて、こういったベーシックな問題に考えが及んでいないとすると、

WEB制作者としては、ちょっと配慮が足らなくはないですか？

とおもう。

P.S SSLということばはもうないよ。

記事に対するつっこみではないですが、

SSLということばは、とても古い言葉です。

便宜上みんな「SSL」といっているだけで、

正しくは「TLS」でっせ。

Permalink | 記事への反応(0) | 19:02

2014-07-02

■[まとめ]有名どころネット サービスの通信セキュリティ 比較

各社サービスの通信暗号化をまとめてみた。

判定基準は Transport Layer Security - Wikipedia

会社	サービス	プロトコル	暗号化方式	判定
ゆうちょ銀行	ゆうちょダイレクト	TLS 1.0	AES_128_CBC	実装による
みずほ銀行	みずほダイレクト	TLS 1.0	RC4_128	安全ではない
三菱東京UFJ銀行	三菱東京UFJダイレクト	TLS 1.0	AES_256_CBC	実装による
三井住友銀行	SMBCダイレクト	TLS 1.0	RC4_128	安全ではない
りそな銀行	りそなマイゲート	TLS 1.2	AES_128_GCM	安全
シティバンク・ジャパン	オンライン	TLS 1.0	3DES_EDE_CBC	強度不足、実装による
ジャパンネット銀行	ログイン	TLS 1.2	AES_256_CBC	安全
住信SBIネット銀行	ログイン	TLS 1.2	RC4_128	安全ではない
Amazon	アカウントサービス	TLS 1.0	AES_128_CBC	実装による
楽天	お買い物かご	TLS 1.2	AES_256_CBC	安全
Yahoo! JAPAN	Yahoo!ショッピングカート	TLS 1.2	AES_128_GCM	安全
Google	Gmail	TLS 1.2	AES_128_GCM	安全
Microsoft	Outlook(旧ホットメール)	TLS 1.2	AES_256_CBC	安全
Yahoo! JAPAN	ヤフーメール	TLS 1.0	AES_128_CBC	実装による

みずほ、三井住友は銀行のくせにRC4でいいの？

メガバンはどこも安心なところはなかったのが何とも…

Permalink | 記事への反応(2) | 01:06

2014-04-14

■２歳児に例える意味はなし

ユーザーがheartbleedに対応する順序

https://www.ssllabs.com/ssltest/index.htmlでサイトをチェックする。

Protocols　で、TLS 1.2とTLS 1.1の項目で「Yes」だったら、パッチ済みであっても、一定期間で洩れた可能性がある。

（だからパスワードを変えろという話）

ここがNoで、脆弱性チェックでも白なら無視して、他のサイトをチェック。

Permalink | 記事への反応(0) | 13:45

2014-02-27

■Apple's SSL/TLS bug (22 Feb 2014)の意訳

例のAppleのSSL/TLSのバグの件、日本語情報がなかったので意訳しました。

Adam Langleyさんによって書かれた原文はこちら。要所要所に親切なリンクがついているので、ぜひ原文も見てみてください。

Apple's SSL/TLS bug (22 Feb 2014)
https://www.imperialviolet.org/2014/02/22/applebug.html
(Hi Adam Langley, Than you for your blog! We really appreciate you.)

-----

昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。
それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。

その答えは既にハッカーニュースのトップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。
そして現在、俺たちはその誤った情報を正すステージに来ているんだ。

ほらここに、Appleのbugがあるんだ。：

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
 OSStatus        err;
 ...

 if ((err = SSLHashSHA1.update(&amp;amp;hashCtx, &amp;amp;serverRandom)) != 0)
  goto fail;
 if ((err = SSLHashSHA1.update(&amp;amp;hashCtx, &amp;amp;signedParams)) != 0)
  goto fail;
  goto fail;
 if ((err = SSLHashSHA1.final(&amp;amp;hashCtx, &amp;amp;hashOut)) != 0)
  goto fail;
 ...

fail:
 SSLFreeBuffer(&amp;amp;signedHashes);
 SSLFreeBuffer(&amp;amp;hashCtx);
 return err;
}(Quoted from Apple's published source code.)

(訳者注：(Quoted from Apple's published source code)→sslKeyExchange.c)

2行のgotoがあるだろ。
2行目のgotoは、見て分かる通り常に発動する。
変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。
それって成功したのと同じなんだよね！

この署名検証処理は(訳者注：SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージの署名を検証するものだ。
このServerKeyExchangeでは、"the ephemeral key"（通信のための一時的な鍵）を交換するためのDHE や ECDHE という暗号スイートが使われる。
そのサーバーは言うんだ。
「ここに"the ephemeral key"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね！」

今、もし"the ephemeral key"と証明書の関係が破たんしているならば、すべては無意味なんだ。
これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った（つまり適当にその辺で作った）鍵を使ったり、そもそもハンドシェイクに署名しなかったりってことができるってことなんだよ！

そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵の秘密鍵を持っているってことの証明が、何もないんだ。

これはSecureTransport(というライブラリ)に入っていて、以下に影響する。
・iOS 7.0.6より前(俺は7.0.4で確認した)
・OS X 10.9.2より前(10.9.1で確認した)
(訳者注：つまりiOS 7.0.6、OS X 10.9.2で解決した)

これはSecureTransportを使っているすべてに影響するけど、ChromeとFirefoxはそうじゃない。
ChromeとFirefoxはSSL/TLSのためにNSSを使っている。
でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね)


超特急でテストサイトを作ってみたよ。https://www.imperialviolet.org:1266
ポート番号に気を付けてね。(テストサイトはCVE番号になってるよ)
443は通常通りに動いているからね。

ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキーで署名しているんだ。
君がもしポート1266のHTTPSサイトにアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:)


それってつまり、証明書チェーンは正しいってことで、そしてハンドシェイクと証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。

またこれは、DHE または ECDHE 暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。
攻撃者は、この暗号スイートを使うサーバーを自分で建てるようになるだろう。

また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。
でも攻撃者は使うプロトコルをある程度選ぶことができるから、安心できないよ。
(訳者注：サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。)
でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。
同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。
(2つのうち、1つ目のほうがだいぶ好ましい。)

俺のテストサイトでは、iOS 7.0.6 と OS X 10.9.2で問題は解決していた。
(更新：このバグはOS X 10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。)

こんなような微妙なバグって、悪夢だ。
俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。


ここに、今回の問題を明らかにするコードがある。：

extern int f();

int g() {
 int ret = 1;

 goto out;
 ret = f();

out:
 return ret;
}

もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeのGCC 4.8.2 や Clang 3.3は死んでるコード(the dead code)について警告をしないんだ。
本当にビックリだよ！！！

ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。
(ピーター・ネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない！)

if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。
でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。

テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。
TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。
俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも)

コードレビューはこの種類のバグについて効果的でありえる。
ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。
Appleのコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。
でも、誰もがそんなにいい仲間を持てるわけじゃないよね。


最後に。昨日、Appleが証明書のホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、
それは OS X のコマンドラインでcurlを使うと、IPじゃない証明書でもIPでHTTPSにつながっちゃうってだけだったよ。変だけど。
Safariはこの問題には関係なかったよ。

Permalink | 記事への反応(0) | 01:12

2010-01-31

■

http://hyper-text.org/archives/2010/01/ftp_security.shtml

よって、サーバとの通信時に暗号化が行われる SFTP （SSH File Transfer Protocol）や FTPS （File Transfer Protocol over SSL/TLS）を使用するようにしましょう。SFTP に対応したクライアントとしては WinSCP、FTPS 対応クライアントとしては NextFTP （シェアウェア）がそれぞれ個人的なオススメです。

はあ？？？

キーロガー仕掛けられてたら通信暗号化しててもパスワードは盗まれるし既にウィルスに感染しているってことはAPIフックでもなんでもし放題でAPIフック使えば平文取得出来るんだけど？？？何を言っているのこいつは？？？

Permalink | 記事への反応(0) | 12:54

「TLS」を含む日記

■情報処理安全確保支援士_20170416午後解答メモ

■LINE Engineers' Blog に掲載された記事を読み解こうとして力尽きた

長すぎ；読まない

暗号化通信の流れ

SSLと公開鍵暗号

共通鍵暗号と暗号利用モード

解決されない鍵管理問題

2015年10月17日 10時16分追記

■一体なんだよこの記事

共用SSL証明書が当たり前？

改ざんの認識

CMSを過信していないか？

「安全」の認識

P.S SSLということばはもうないよ。

■[まとめ]有名どころネットサービスの通信セキュリティ比較

■２歳児に例える意味はなし

■Apple's SSL/TLS bug (22 Feb 2014)の意訳

2015年 10月17日 10時16分追記