すべてのSSL / TLS実装はHeartbleedバグに対して脆弱ですか？
SSL/TLSプロトコルの背後にある理論と、それらがクライアントとサーバー間の安全な通信を実現するためにどれほど効果的であるかを学びました。
OpenSSL、PolarSSL、MatrixSSL、およびMozilla NSSのすべての実装は、SSLおよびTLSの同じ基礎理論を使用していますか？もしそうなら、HeartbleedバグがSSL/TLSへの約束の度合いを変えることを意味しますか？
ハートブリードの要約を見ると、
Heartbleedバグは、人気のあるOpenSSL暗号化ソフトウェアライブラリの深刻な脆弱性です。この弱点により、通常の条件下では、インターネットを保護するために使用されるSSL/TLS暗号化によって保護された情報を盗むことができます。 SSL/TLSは、Web、電子メール、インスタントメッセージング（IM）、一部の仮想プライベートネットワーク（VPN）などのアプリケーションに、インターネット上の通信セキュリティとプライバシーを提供します。
ハートブリードバグにより、インターネット上の誰でも、脆弱なバージョンのOpenSSLソフトウェアによって保護されているシステムのメモリを読み取ることができます。これは、サービスプロバイダーを識別し、トラフィック、ユーザーの名前とパスワード、および実際のコンテンツを暗号化するために使用される秘密鍵を危険にさらします。これにより、攻撃者は通信を盗聴し、サービスとユーザーから直接データを盗み、サービスとユーザーになりすますことができます。
あなたは尋ねました：
HeartbleedバグがSSL/TLSへの約束の度合いを変えるということですか？
いいえ、ありません。あなたはそれがopensslについて特にであることがわかります。 Heartbleedはソフトウェアのバグ、プログラミングエラーでした。これは、たとえば CRIMEまたはBEAST のように、SSL/TLSプロトコル自体の弱点ではありませんでした。 Heartbleedから学んだ重要な教訓は、コードを使用する前にレビューする必要があるということです。 OpenSSLのメモリリークは重大なものでしたが、プログラミングエラーが存在し、今後も存在します。私たちにできることは、定期的なコードレビューを実行し、コードを簡素化/クリーンアップすることです（OpenSSLは少し混乱しています）。
他のライブラリー（実際には、そのためのソフトウェアの一部）にも簡単にライブラリーが存在する可能性があり、ここでの主な脅威は人為的エラーであり、緩和することが難しい場合があります。
SSL/TLSはプロトコルです。
OpenSSLは、これらのプロトコルの実装です。 2つのライブラリがあります。一連の暗号化アルゴリズムを実装するlibcryptoと、TLSプロトコルとその以前のSSLを実装するlibsslです。
特定のプロトコルの実装にエラーがある場合、それは問題がプロトコル自体にあることをしないことを意味します。 HeartBleedはOpenSSLに関係する問題にすぎませんが、 LibreSSL 、 GnuTLS 、 MatrixSSL などのその他のTLS/SSL実装には存在しません。
HeartBleedは、間違った実装の結果です。ハートブリードは、2011年の大晦日の1時間前にスティーブンヘンソンによって最初に導入されました。より正確に言うと、当時博士号を取得していたのはRobin Seggelmannです。 OpenSSLのHeartBeat拡張機能を開発したデュースブルクエッセン大学の学生（HeartBeatはすでにSSL2.0仕様に含まれていました）をOpenSSLリード開発者プロジェクトのStephen Hensonに提案し、バグを見つけてコミットしました（チェックしたことはありませんか？）リポジトリにあります。他の人は、この脆弱性が公に発表されるずっと前に知られ、悪用されたと示唆しています。
Stephen Hensonは、常にOpenSSLの唯一の永続的な開発者でした。永久にではなく彼を助けてくれた査読者は一人しかいません。 OpenSSLプロジェクトの他の11人のメンバーはすべて、適切に述べられている開発とは何の関係もありません。ご想像のとおり、開発者がどんなに賢いとしても、開発者が一人で開発している限り、開発者はエラーを起こしやすくなります。