ウィキペディアによると: http://en.wikipedia.org/wiki/Transport_Layer_Security
TLSはSSLの代替品のようですが、ほとんどのWebサイトはまだSSLを使用していますか?
要するに、TLSv1.0は多かれ少なかれSSLv3.1です。詳細は ServerFaultに関するこの質問 で見つけることができます。
ほとんどのWebサイトは、実際には少なくともSSLv3とTLSv1.0の両方をサポートしています この調査は、(Lee、Malkin、およびNahumの論文:SSL/TLSサーバーの暗号強度:現在および最近のプラクティス、IMC 2007) ( IETF TLSリスト )から取得したリンク。 98%以上がTLSv1 +をサポートしています。
SSLv3がまだ使用されている理由は、レガシーサポートのためだと思います(ただし、ほとんどのブラウザはTLSv1と一部のTLSv1.1、または最近ではTLSv1.2もサポートしています)。少し前までは、一部のディストリビューションでは、他のディストリビューションと一緒にデフォルトでSSLv2(安全でないと考えられています)がオンのままでした。
( この質問 興味深いものもありますが、これはSSL対TLSではなくTLSの使用パターンに関するものです(実際、SSLでも同じパターンを使用できます)。これはHTTPSには適用されませんHTTPSは接続の最初からSSL/TLSを使用するため)
から http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/
90年代前半、World Wide Webのearly明期に、Netscapeの一部のエンジニアは、安全なHTTPリクエストを行うためのプロトコルを開発し、彼らが思いついたものはSSLと呼ばれていました。当時のセキュアなプロトコルに関する知識が比較的不足しており、Netscapeの全員が働いていた 強烈なプレッシャー を考えると、彼らの努力は信じられないほど英雄的としか言えません。同じビンテージのその他の多くのプロトコルとは対照的に、SSLがそれだけ長く耐えているのは驚くべきことです。しかし、それ以来、私たちは間違いなく多くのことを学びましたが、プロトコルとAPIについてのことは、後戻りがほとんどないということです。
SSLプロトコルには、SSL 2(1995)とSSL 3(1996)の2つの主要な更新がありました。導入を容易にするために、これらは下位互換性を保つために慎重に行われました。ただし、後方互換性は、セキュリティプロトコルの制約であり、後方互換性があります。
したがって、後方互換性を破ることが決定され、新しいプロトコル TLS 1. (1999)が命名されました。 (後知恵では、TLS 4という名前を付けた方が明確だったかもしれません)
このプロトコルとSSL 3.0の違いは劇的ではありませんが、TLS 1.0とSSL 3.0が相互運用できないほど重要です。
TLSは、TLS 1.1(2006)とTLS 1.2(2008)の2回改訂されました。
2015年の時点で、すべてのSSLバージョンは壊れていて安全ではなく(POODLE攻撃)、ブラウザーはサポートを削除しています。 TLS 1.0はいたるところに存在しますが、 60%のサイトがTLS 1.1および1.2をサポートしています のみです。
このようなものに興味があるなら、私は https://www.youtube.com/watch?v=Z7Wl2FW2TcA でMoxie Marlinspikeの賢く面白い話をお勧めします。
tls1.0はsslv3.1を意味します
tls1.1はsslv3.2を意味します
tls1.2はsslv3.3を意味します
rfcは名前を変更したばかりで、tls1.0の16進コードは0x0301であり、sslv3.1を意味します。
TLSはSSLとの下位互換性を維持するため、通信プロトコルはここに記載されているバージョンのいずれでもほぼ同じです。 SSL v.3、TLS 1.0、およびTLS 1.2の2つの重要な違いは、擬似ランダム関数(PRF)とHMACハッシュ関数(SHA、MD5、ハンドシェイク)です。アプリケーションデータの暗号化(サーバーキー+クライアントキー+ IV)。 TLS 1.1とTLS 1.2の主な違いは、1.2がCBC攻撃から保護するために「明示的な」IVの使用を必要とすることですが、これに必要なPRFまたはプロトコルへの変更はありません。 TLS 1.2 PRFは暗号スイート固有であるため、ハンドシェイク中にPRFをネゴシエートできます。 SSLはもともとNetscape Communications(歴史的)によって開発され、後にInternet Engineering Task Force(IETF、現在)によって保守されました。 TLSは、ネットワークワーキンググループによって維持されています。 TLSのPRF HMAC機能の違いは次のとおりです。
TLS 1.0および1.1
PRF(secret、label、seed)= P_MD5(S1、label + seed)XOR P_SHA-1(S2、label + seed);
TLS 1.2
PRF(secret、label、seed)= P_hash(secret、label + seed)
「壊れていない場合は、触れないでください」。 SSL3はほとんどのシナリオで正常に機能します(10月にSSL/TLSプロトコルで見つかった根本的な欠陥がありましたが、これはプロトコル自体よりもアプリケーションの欠陥です)。したがって、開発者は急いでSSLモジュールをアップグレードしません。 TLSは多くの便利な拡張機能とセキュリティアルゴリズムをもたらしますが、それらは便利な追加機能であり、必須ではありません。そのため、ほとんどのサーバーのTLSはオプションのままです。サーバーとクライアントの両方でサポートされている場合は、それが使用されます。
更新:2016年のSSL 3では、1.2までのTLSでさえ、さまざまな攻撃に対して脆弱であることが判明しており、TLS 1.2への移行が推奨されています。 TLS 1.2の実装にも攻撃が存在しますが、サーバーに依存しています。 TLS 1.3は現在開発中です。そして今、TLS 1.2は必須です。
https://hpbn.co/transport-layer-security-tls/ は良い紹介です
SSLプロトコルは元々Netscapeで開発され、Webでのeコマーストランザクションセキュリティを可能にします。これには、顧客の個人データを保護するための暗号化と、安全なトランザクションを保証するための認証および整合性保証が必要でした。これを実現するために、SSLプロトコルはアプリケーション層でTCP(図4-1)のすぐ上に実装され、その上のプロトコル(HTTP、電子メール、インスタントメッセージング、および他の多くの)ネットワークを介して通信するときに通信セキュリティを提供しながら、変更せずに動作します。
SSLが正しく使用されると、サードパーティのオブザーバーは接続エンドポイント、暗号化のタイプ、送信されるデータの頻度と概算量のみを推測できますが、実際のデータを読み取ったり変更したりすることはできません。
SSL 2.0は、このプロトコルの最初に公開されたバージョンでしたが、多くのセキュリティ上の欠陥が発見されたため、すぐにSSL 3.0に置き換えられました。 SSLプロトコルはNetscape独自のものであるため、IETFはプロトコルを標準化する努力を行い、RFC 2246を作成しました。これは1999年1月に公開され、TLS 1.0として知られるようになりました。それ以来、IETFはプロトコルの反復を続けてセキュリティの欠陥に対処し、その機能を拡張しています。2006年4月にTLS 1.1(RFC 2246)が、2008年8月にTLS 1.2(RFC 5246)が公開されました。 TLS 1.3の定義が進行中です。