SSLとTLSの違い


90

ウィキペディアによると:http//en.wikipedia.org/wiki/Transport_Layer_Security

TLSはSSLの代わりのようですが、ほとんどのWebサイトはまだSSLを使用していますか?


4
「ほとんどのウェブサイトはまだSSLを使用しています」。ここでは、プロトコルのサポートの良い調査だtrustworthyinternet.org/ssl-pulse/#chart-protocol-supportは
大佐はパニック

同様に、より人気の質問:security.stackexchange.com/questions/5126/...
ヴァジム・

回答:


60

要するに、TLSv1.0は多かれ少なかれSSLv3.1です。詳細については、ServerFaultのこの質問をご覧ください。

この調査が示すように、ほとんどのWebサイトは実際には少なくともSSLv3とTLSv1.0の両方をサポートしています(Lee、Malkin、およびNahumの論文:SSL / TLSサーバーの暗号強度:現在および最近の慣行、IMC 2007)IETFTLSリストから取得したリンク)。98%以上がTLSv1 +をサポートしています。

SSLv3がまだ使用されている理由は、レガシーサポートのためだと思います(ただし、ほとんどのブラウザーはTLSv1と一部のTLSv1.1、または最近ではTLSv1.2をサポートしています)。少し前まで、一部のディストリビューションでは、他のディストリビューションと一緒にデフォルトでSSLv2(安全でないと見なされます)がオンのままでした。

この質問は、SSLとTLSではなくTLSの使用パターンに関するものですが、興味深いと思うかもしれません(実際、SSLでも同じパターンを持つことができます)。HTTPSはSSL / TLSを使用するため、これはHTTPSには適用されません。接続の最初から。)


23

http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/から

90年代初頭、ワールドワイドウェブの黎明期に、Netscapeの一部のエンジニアは、安全なHTTP要求を行うためのプロトコルを開発し、彼らが思いついたのはSSLと呼ばれていました。当時の安全なプロトコルに関する知識が比較的不足しており、Netscapeの全員が取り組んでいた強いプレッシャーを考えると、彼らの努力は信じられないほど英雄的であるとしか見なされません。同じヴィンテージの他の多くのプロトコルとは対照的に、SSLが長い間耐えてきたことは驚くべきことです。それ以来、私たちは間違いなく多くのことを学びましたが、プロトコルとAPIについてのことは、戻ることはほとんどないということです。

SSLプロトコルには、SSL 2(1995)とSSL 3(1996)の2つの主要な更新がありました。これらは、採用を容易にするために、下位互換性があるように注意深く行われました。ただし、下位互換性はセキュリティプロトコルの制約であり、下位互換性を意味する可能性があります。

したがって、後方互換性を破ることが決定され、TLS 1.0(1999)という名前の新しいプロトコルが使用されました。(後から考えると、TLS 4という名前を付ける方が明確だったかもしれません)

このプロトコルとSSL3.0の違いは劇的ではありませんが、TLS1.0とSSL3.0が相互運用しないほど重要です。

TLSは、TLS 1.1(2006)とTLS 1.2(2008)の2回改訂されました。

2015年の時点で、すべてのSSLバージョンが壊れており、安全ではなく(POODLE攻撃)、ブラウザーはサポートを削除しています。TLS 1.0はどこにでもありますが、TLS 1.1と1.2をサポートしているサイト60%に過ぎず、残念な状況です。


このようなものに興味がある場合は、https://www.youtube.com/watch?v = Z7Wl2FW2TcAでのMoxieMarlinspikeの巧妙で面白い話をお勧めし ます。


1980年代後半にSecureSocketsLayerと呼ばれるUsenetnews:comp.sources.unixの投稿を覚えています。名前以外にNetscapeがやったことと何か関係があるのではないかと思う。
ローン侯爵2013年

11

tls1.0はsslv3.1を意味します

tls1.1はsslv3.2を意味します

tls1.2はsslv3.3を意味します

rfcが名前を変更しただけで、tls1.0の16進コードが0x0301であることがわかります。これは、sslv3.1を意味します。


2

TLSはSSLとの下位互換性を維持しているため、通信プロトコルはここに記載されているバージョンのいずれでもほぼ同じです。SSL v.3、TLS 1.0、およびTLS 1.2の2つの重要な違いは、疑似ランダム関数(PRF)とHMACハッシュ関数(SHA、MD5、ハンドシェイク)です。これらは、次の対称鍵のブロックを構築するために使用されます。アプリケーションデータの暗号化(サーバーキー+クライアントキー+ IV)。TLS1.1とTLS1.2の主な違いは、1.2ではCBC攻撃から保護するために「明示的な」IVを使用する必要があることですが、これに必要なPRFやプロトコルに変更はありません。TLS 1.2 PRFは暗号スイート固有です。つまり、ハンドシェイク中にPRFをネゴシエートできます。SSLは元々NetscapeCommunications(historic)によって開発され、後にInternet Engineering Task Force(IETF、現在)によって維持されました。TLSはネットワークワーキンググループによって維持されています。TLSのPRFHMAC関数の違いは次のとおりです。

TLS1.0および1.1

PRF(シークレット、ラベル、シード)= P_MD5(S1、ラベル+シード)XOR P_SHA-1(S2、ラベル+シード);

TLS 1.2

PRF(シークレット、ラベル、シード)= P_hash(シークレット、ラベル+シード)


0

「壊れていない場合は触れないでください」。SSL3はほとんどのシナリオで正常に機能します(10月にSSL / TLSプロトコルに根本的な欠陥が見つかりましたが、これはプロトコル自体よりもアプリケーションの欠陥です)。したがって、開発者はSSLモジュールのアップグレードを急いでいません。TLSは多くの便利な拡張機能とセキュリティアルゴリズムをもたらしますが、それらは便利な追加であり、必須ではありません。したがって、ほとんどのサーバーでのTLSはオプションのままです。サーバーとクライアントの両方がそれをサポートしている場合、それが使用されます。

更新:2016年のSSL 3では、1.2までのTLSでさえさまざまな攻撃に対して脆弱であることが判明しており、TLS1.2への移行が推奨されています。サーバーに依存しますが、TLS1.2の実装に対する攻撃も存在します。TLS1.3は現在開発中です。そして今、TLS1.2は必須です。


2
いいえ、これはプロトコルの欠陥であり、開発者はSSLスタックをアップグレードする必要があります。このビーイングはで再ネゴシエーション拡張使用する際のガイドラインがある、と述べたRFC 5746 TLSのためのもののために加えて、SSLv3のために。
ブルーノ

あなたがナイフで誰かを殺した場合、これはナイフの欠陥ではなく、あなたの脳の欠陥です。こっちも一緒。プロトコルが設計されていない方法で使用された場合、それはプロトコルの欠陥ではありません。
Eugene Mayevski 'コールバック2010

1
プロトコルは、その上にあるアプリケーションが可能な限り通常のソケットとして扱うように設計されています。新しい拡張機能がない場合の再ネゴシエーションの問題により、アプリケーション層(HTTPなど)による認識が強制されます。IETF TLSメーリングリストにこのトピックに関する関心のあるスレッドがあります:ietf.org/mail-archive/web/tls/current/msg04000.html
Bruno

1
一部はアプリケーションレベルで実行する必要があることに同意しますが、実装については認識しておらず、プロトコルはそれを考慮に入れています。スタックは通常、合法的に開始する再ネゴシエーションに対処できますが、MITMがそれを開始する場合はそれほど多くはありません(これが問題です)。これが、IETF TLSグループがTLSレベルで修正することを選択した理由です。また、人々が実際にその拡張機能をオンにするか、再ネゴシエーションを完全に無効にする必要がある理由でもあります。
ブルーノ

1
SSL 3.0には、あなたが言及した問題よりも根本的な問題があります。たとえば、CBCパディングオラクル、およびIVまたは以前のレコードの再利用。前者は依然としてTLSを悩ませていますが、回避策はありますが、後者はTLS1.1で修正されています。
ニコス2013年

0

https://hpbn.co/transport-layer-security-tls/は良い紹介です

SSLプロトコルは元々Netscapeで開発され、Web上でeコマーストランザクションのセキュリティを有効にしました。これには、顧客の個人データを保護するための暗号化と、安全なトランザクションを保証するための認証と整合性の保証が必要でした。これを実現するために、SSLプロトコルはTCPの真上にあるアプリケーション層に実装され(図4-1)、その上のプロトコル(HTTP、電子メール、インスタントメッセージング、その他多く)が変更されずに動作し、通信セキュリティを提供できるようになりました。ネットワークを介した通信。

SSLが正しく使用されている場合、サードパーティのオブザーバーは、接続エンドポイント、暗号化のタイプ、送信されるデータの頻度と概算量のみを推測できますが、実際のデータを読み取ったり変更したりすることはできません。

SSL 2.0は、プロトコルの最初の公開バージョンでしたが、多くのセキュリティ上の欠陥が発見されたため、すぐにSSL3.0に置き換えられました。SSLプロトコルはNetscape独自のものであったため、IETFはプロトコルを標準化する取り組みを行い、RFC 2246を作成しました。これは、1999年1月に公開され、TLS1.0として知られるようになりました。それ以来、IETFは、セキュリティの欠陥に対処し、その機能を拡張するためにプロトコルを繰り返し続けています。TLS1.1(RFC 2246)は2006年4月に、TLS 1.2(RFC 5246)は2008年8月に公開され、現在作業中です。 TLS1.3を定義するために進行中です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.