影響範囲の一例として Hijacking user sessions with the Heartbleed vulnerability の実際にどういうデータが抜き取られてしまうのか、という例で JSESSIONID が見えているように Cookie が漏洩している可能性があります。
考えられる攻撃シナリオ
OpenSSL TLS Heartbeat Extension - Memory Disclosure を自分のサーバーに試した時に mod-spdy-beta が原因で脆弱性が残ったままになっていて、 Rails アプリの Cookie が見えていました。
そこで考えたのは上記のブログに書いてあるようにセッションハイジャックが可能だということでした。
悪い状況を考えると、 脆弱性の情報が公開されてから対策がされるまでの間に 全世界の Web サーバーに Heartbleed の攻撃を仕掛けておいて、 後でログを調べて、こういう Cookie のような情報があれば それを使って別途セッションハイジャックなどの別の攻撃をする、 という可能性があります。
Rails での対処方法案
config/initializers/secret_token.rb の secret_token を再生成して設定し直すという方法が考えられます。 その際、ログインしているユーザーのセッションが無効になったり、 Remember me で覚えさせていても忘れられたりするということが起きるので、 ユーザーへの影響を考えて実施する必要がありそうです。
また、データベースへ保存するデータの暗号化の鍵としても使っていたら、 読めなくなってしまうので、そういう用途にも使っていたら、 別の方法で既存の Cookie を無効にするしかなさそうです。
secure 属性を付けていても無関係
クライアントとの通信内容の残骸が漏洩してしまうので、 Cookie に secure 属性を付けていても防げません。
アプリケーションサーバーが別プロセスでも無関係
apache+passenger や nginx+php-fpm のようにアプリケーションサーバーとフロントエンドの Web サーバーが別プロセスにわかれていても、 HTTPS 向けに暗号化する前の平文のデータがフロントエンドの Web サーバーに残っていて、そこの情報が漏洩してしまうので、 Cookie のようなクライアントに返す情報は影響を受けて漏洩している可能性があります。
バックエンドのサーバーでしか読み込んでいなくて、フロントエンドには渡していない情報はこの経路では漏洩しません。
例えば、典型的な Rails アプリの構成ではデータベースサーバーへ接続するためのユーザー名やパスワードはクライアントには渡さないので、この経路では漏洩しません。
フロントエンドサーバーの秘密鍵
既に情報収集していれば知って可能性が高いと思いますが、 フロントエンドサーバーのプロセスが読み込んでいる情報にあたる SSL/TLS の秘密鍵は漏洩している可能性があります。
きちんとした対処としては CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ - めもおきば にも書いてあるように
- 秘密鍵から作り直して 証明書を再発行
- 過去の証明書を 失効
の両方が必要です。
余談
SPDY とか使いたいから HTTPS にしてるだけで HTTP で通信してても良いような内容しか扱ってないサーバーなら (VirtualHost の他のホストも含めてという条件付きで)、放置でも良いのかもしれませんが、少なくとも次の証明書の更新の時には秘密鍵を作り直した方が良いように思います。
まとめ
外部から SSL/TLS 接続を受けるプロセスが持っている情報が漏洩している可能性がある、ということで、具体例として Cookie について少し詳しく考えてみました。
簡単に言えば、脆弱性のある状態でクライアントと通信している内容はすべて漏洩している可能性がある、つまり HTTPS で通信していても HTTP と同じような機密性しかなかった可能性がある、と考えるのが良さそうです。
つまりクライアントから送った情報も漏洩の可能性があるので、 Heartbleed 脆弱性が残っているサーバーにはクレジットカード番号などの情報は 送らない方が良い、ということになります。
関連する話なので一緒に書いてしまったので、ちょっと紛らわしいですが、 サーバーの秘密鍵の漏洩の可能性もフロントエンドサーバーの管理者は別途対応する必要があります。