OpenSSLの1.01で、TLS1.1/TLS1.2の認証を非活性にしている場合、今回の脆弱性は避けられたのでしょうか。

CentOS 6.5 上で実験してみました。
サーバ側：

openssl s_server -cert 証明書ファイル -key 秘密鍵ファイル -ssl3

クライアント側：

echo B | openssl s_client -connect localhost:4433

結果：

（略）
SSL-Session:
    Protocol  : SSLv3
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Session-ID-ctx:
    Master-Key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1398341090
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
HEARTBEATING
DONE

SSLv3 でつながっているのけど heartbeat は使えています。

余談：
検証してみようと試している中で、RHEL / CentOS 6.5 の httpd で SSLProtocol で SSLv3 のみを指定している場合、TLSv1.0 でのネゴシエーションに失敗するのに、TLSv1.1、TLSv1.2 ではつながる、という不思議な現象を発見...。

閑話休題。

結論としては、TLSv1.1、1.2 を無効にしても heartbeat が使えるので、Heartbleed の問題は避けられないことになります。

うーん。1.01gを信用するべきなのか。信用するにしても当面TLS1.1/1.2は非活性にするべきなのか。。。

ピンポイントで今回の Heartbleed の問題に対して、1.0.1g や各ディストリビューションの update での修正が信用できるか？ ということであれば、十分に信用できます。というのは、原因が極めて単純なバグだったからです。ですので、Heartbleed の問題は、きちんとアップデートして置けば、今後は発生しません。

ただ、OpenSSL というプログラムがどうか？ という事に関しては、ケチが付いた格好にはなります。

一度、こういった事があると、「他に同様の問題はないか？」と疑心暗鬼になるのは仕方がないことです。OpenSSL のプロジェクトのあり方にも疑問が示され、OpenBSD プロジェクトが LibreSSL という代替プログラムのプロジェクトを立ち上げています。

なので、OpenSSL 自体を信用ならないとするなら、どのバージョンを使うべきか、ではなく、OpenSSL 以外の実装（例えば GnuTLS）を選択する、という話になります。

確かに Heartbleed は、久しぶりに見る「大きな穴」でしたが、正直、これほどの大きな穴が、ほいほいと見つかるかというと、確率は低いと思います。

これよりも小さな穴は、どんなソフトでも見つかる話で、一番肝心なのは、アップデートが出たら、面倒がらずにアップデートする、という方が、トータルで考えると、簡単で確実な方法だと思います。