SSLとTLSの違いによる機能上の影響
TLSは本質的に新しいバージョンのSSLであり、一般に非セキュアからセキュアへの接続の移行をサポートすることを知っています（通常、STARTTLSコマンドを使用）。
私が理解していないのは、TLSがITプロフェッショナルにとって重要である理由と、選択肢を考えると、私はどちらかを選択する理由です。 TLSは本当に新しいバージョンにすぎませんか？互換性のあるプロトコルですか？
ITプロフェッショナルとして：いつどちらを使用しますか？いつ使用しないのですか？
短い答え：
SSLはTLSの前身です。 SSLはNetscape Communicationsによって開発された独自のプロトコルで、後にIETF内で標準化され、TLSに名前が変更されました。つまり、バージョンは、SSLv2、SSLv3、TLSv1.0、TLSv1.1、およびTLSv1.2の順になります。
これは、比較的広く普及している考えとは異なり、SSLを使用して個別のポートでサービスを実行し、プレーンテキストのバリアントと同じポートでサービスを実行できることをまったく意味しません。 TLS。 SSLとTLSの両方を2つのアプローチで使用できます。これは、接続時のSSL/TLS（「暗黙のSSL/TLS」と呼ばれることもあります）とSSL/TLSの違いです。コマンドはプロトコルレベルで発行され、通常はSTARTTLS（「明示的なSSL/TLS」と呼ばれることもあります）。 STARTTLSのキーワードは、TLSではなく「START」です。これは、アプリケーションプロトコルレベルでのメッセージであり、アプリケーションプロトコル交換の前に開始されていない場合は、SSL/TLSへの切り替えが必要であることを示します。
クライアントがプレーンテキスト接続にダウングレードされないように何らかの方法でSSL/TLSを期待するように構成されている場合、どちらのモードを使用しても同等です。
長い答え：
SSL対TLS
私の知る限り、SSLv1がラボを離れることはありません。 SSLv2 および SSLv3 は、Netscapeによって開発されたプロトコルです。 SSLv2はダウングレード攻撃になりやすいため、しばらくの間安全ではないと考えられてきました。 SSLv3は、バージョン番号として（ClientHelloメッセージ内で）_(3,0)_を内部的に使用します。
TLSは、IETF内のよりオープンなプロトコルとしての標準化の結果です。 （おそらくE. Rescorlaの本のどこかで読んだと思いますが、特定の会社を支持しないように、すべての参加者が等しく不満を抱くように名前が選択されていたと思います：これは標準でかなり一般的な慣習です本文。）移行がどのように行われたかに興味がある人は、 SSL-Talk リスト [〜＃〜] faq [〜＃を読むことができます。 〜] ;このドキュメントの複数のコピーがありますが、ほとんどのリンク（_netscape.com_への）は古くなっています。
TLSは非常に類似したメッセージを使用します（プロトコルを非互換にするために十分に異なります、 共通のバージョンをネゴシエートすることは可能です ）。 TLS 1.0 、 1.1 および 1.2ClientHelloメッセージは_(3,1)_、_(3,2)_、_(3,3)_を使用してバージョン番号を示し、SSLからの継続を明確に示しています。
this answer にプロトコルの違いに関する詳細があります。
いつ使用しますか？いつ使用しないのですか？
可能であれば、可能な限り最新のバージョンを使用してください。実際には、サービスプロバイダーとして、ユーザーはこれらのバージョンをサポートするクライアントを持っている必要があります。いつものように、それは常にリスク評価の演習です（できれば、適切な場合はビジネスケースで裏付けられることが望ましい）。そうは言っても、とにかくSSLv2を遮断してください。
さらに、SSL/TLSによって提供されるセキュリティは、使用するバージョンだけでなく、適切な構成も重要であることに注意してください。強力な暗号スイートを備えたSSLv3を使用することは、弱い（またはanonymous/null-encryption）暗号スイート。弱すぎると考えられている一部の暗号スイートは、新しいバージョンのTLSによって明示的に禁止されています。 Java 7 SunJSSEプロバイダー（およびその脚注） の表は、詳細が必要な場合に役立ちます。
少なくともTLS 1.1を使用することをお勧めしますが、残念ながらまだすべてのクライアントがそれらをサポートしているわけではありません（例Java 6）。1.1未満のバージョンを使用する場合、 BEAST脆弱性の緩和 。
私は一般的に Eric Rescorlaの本-SSLおよびTLS：Designing and Building Secure Systems、Addison-Wesley、2001 ISBN 0-201-61598-3 を本当にお勧めする人にお勧めします詳細が欲しい。
暗黙的対明示的なSSL/TLS
TLSでは同じポートを使用できるが、SSLでは使用できないという神話があります。それは真実ではありません（この議論ではport unificationは省略します）。残念ながら、この神話は、MS Outlookのような一部のアプリケーションが実際には暗黙的または明示的なSSL/TLSの選択を意味する場合に、構成オプションでSSLとTLSのどちらかを選択できるという事実によってユーザーに広まったようです。 （MicrosoftにはSSL/TLSの専門家がいますが、彼らはOutlookのUIに関与していなかったようです。）
この混乱が発生する理由は、 STARTTLS モードが原因であると思います。これをSTARTTLS = TLSと理解している人もいますが、そうではありません。 STARTTLSのキーワードは、TLSではなく「START」です。これがSTARTSSLまたはSTARTSSLORTLSと呼ばれなかった理由は、これらの拡張機能がIETF内で指定されたためです。これは、仕様で使用されている名前のみを使用していたためです（TLS名が最終的に唯一の永続性であると仮定すると、推測）。
- プレーンテキストサービスと同じポート上のSSL：HTTPSプロキシ。
現在、ほとんどのHTTPSサーバーはTLSを処理できますが、数年前はほとんどの人がHTTPSにSSLv3を使用していました。 HTTPS（厳密に言えば、 HTTP over TLS として標準化されています）は通常、TCP接続時にSSL/TLS接続を確立してから、HTTPメッセージを交換しますSSL/TLSレイヤーを介します。中間でHTTPプロキシを使用する場合、これには例外があります。この場合、クライアントはHTTPプロキシに平文で（通常はポート3128で）接続し、CONNECTを発行します。 HTTPコマンドは、応答が成功した場合、ClientHelloメッセージを送信してSSL/TLSハンドシェイクを開始します。これはすべて、ブラウザとプロキシの間の接続に関する限り、同じポートで発生します（明らかにプロキシとターゲットサーバー：同じマシンでもありません。これはSSLv3で正常に動作します。プロキシの背後にいる状況の多くの人が、少なくともTLS 1.0をサポートしていないサーバーに対してこれを使用しています。
- プレーンテキストサービスと同じポートのSSL：電子メール。
これは明らかに仕様外ですが、実際には多くの場合機能します。厳密に言うと、仕様では、STARTTLSコマンドを使用した後のSSLではなくTLSへの切り替えについて説明しています。実際には、SSLもしばしば機能します（「HTTP over TLS」の仕様もTLSの代わりにSSLを使用することも包含しているように）。ご自分でお試しいただけます。 STARTTLSをサポートするSMTPまたはIMAPサーバーがあると仮定して、Thunderbirdを使用し、設定、詳細オプション、設定エディターに移動して、_security.enable_tls_をオフにします。多くのサーバーは引き続き接続を受け入れます。これは、その実装がSSL/TLSレイヤーをSSL/TLSライブラリに委譲するためです。SSL/ TLSライブラリは、構成しない限り、通常は同じ方法でSSLおよびTLSを処理できます。 OpenLDAP FAQ は、「メカニズムはTLSv1で使用するように設計されていますが、ほとんどの実装は、SSLv3（およびSSLv2）にフォールバックします。必要です。 "。不明な場合は、Wiresharkなどのツールで確認してください。
- 別個のポート上のTLS。
セキュリティで保護されたバリアントが別のポートにあるプロトコルでは、多くのクライアントが（少なくとも）TLS 1.0を使用できます。明らかに、HTTPSにTLS 1.0（またはそれ以上）をサポートするブラウザーやWebサーバーは数多くあります。同様に、SMTPS、IMAPS、POPS、LDAPSもTLSを使用できます。 SSLに限定されません。
いつ使用しますか？いつ使用しないのですか？
明示的SSLと暗黙的SSL/TLSの間では、それは実際には問題になりません。重要なのは、クライアントが何を期待するのかを知っており、そのように適切に構成されていることです。 さらに重要なことに、SSL/TLS接続が予期される場合、暗黙的または明示的であるかどうかにかかわらず、プレーンテキスト接続を拒否するように構成する必要があります。
明示的なSSL/TLSと暗黙的なSSL/TLSの主な違いは、構成設定の明確さです。
たとえば、LDAPの場合、クライアントがApache Httpdサーバーの場合（ _mod_ldap_ -残念ながら、そのドキュメントにはSSLとTLSの違いのラベルが誤っています）、 _ldaps://_ URL（例_AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one_）を使用して暗黙のSSL/TLSを使用するか、追加のパラメーター（例_AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS_）を使用して明示的なSSL/TLSを使用できます。
一般に、URLスキームでセキュリティプロトコルを指定する場合（https、ldaps、...）は、クライアントがSSLを有効にするための追加設定を構成することを期待する場合よりも、少しリスクが低いと考えられます。/TLS、忘れる可能性があるため。これは議論の余地があります。また、どちらか一方の実装の正確さに問題がある可能性もあります（たとえば、Java LDAPクライアントは、_ldaps://_を使用する場合、ホスト名の検証をサポートしていません） 、必要なときに、_ldap://_ + StartTLSでサポートされます）。
疑わしいですし、可能であればより多くのクライアントと互換性を持たせるために、サーバーがサポートしている場合に両方のサービスを提供しても害はないようです（サーバーは同時に2つのポートでリッスンするだけです）。どちらかのモードで使用できるプロトコルのサーバー実装の多くは、両方をサポートします。
クライアント自身がプレーンテキスト接続にダウングレードされないようにするのはクライアントの責任です。サーバー管理者として、ダウングレード攻撃を防ぐために技術的にあなたができることは何もありません（おそらくクライアント証明書の要求は別として）。クライアントは、接続時でもSTARTTLSのようなコマンドの後でも、SSL/TLSが有効になっていることを確認する必要があります。ブラウザがそれ自体を_https://_から_http://_にリダイレクトしないようにする必要があるのと同じように、STARTTLSをサポートするプロトコルのクライアントは、応答が正でSSLであることを確認する必要があります/ TLS接続は、先に進む前に有効にされました。そうでない場合、アクティブなMITM攻撃者は、どちらの接続も簡単にダウングレードできます。
たとえば、 古いバージョンのThunderbirdには、「使用可能な場合はTLSを使用する」と呼ばれる悪いオプションがありました 。これは、MITM攻撃者がサーバーを変更できるかどうかを本質的に示唆していますSTARTTLSのサポートをアドバタイズしないようにメッセージを送信すると、クライアントはそれ自体をプレーンテキスト接続にダウングレードします。 （この安全でないオプションは、Thunderbirdでは使用できなくなりました。）
TLSはSSLよりも新しいプロトコルです（ただし、AFAIKはSSL v3と互換性があります）。通常、心配する必要がある違いは1つだけです。
通常、SSLで保護されたプロトコルには個別のポートがあります。たとえば、HTTPの場合は80、HTTPSの場合は443（HTTP/SSL）です。 SSLポートに接続すると、セッション全体が暗号化されます。
TLSはSSLよりも新しいため、別のポートを必要としません。代わりに、クライアントがネゴシエートする必要があります。たとえば、ポート143でIMAPを実行できます。メールサーバーとクライアントの両方がTLSをサポートしている場合、クライアントはSTARTTLSコマンドを送信してから、暗号化を有効にします。この方法では、SSLを使用しないアプリケーションとの互換性を維持しながら、別のSSL専用ポートは必要ありません。
概要：
[〜＃〜] ssl [〜＃〜]：少し古い。プレーンな接続と暗号化された接続用に別々のポート。 SSLポート上のすべてのトラフィックは常に暗号化されます。
[〜＃〜] tls [〜＃〜]：プレーン接続と暗号化接続の両方に単一のポート。暗号化は、クライアントがSTARTTLSコマンドを発行した後にのみ有効になります。
TLSは単にSSLの新しいバージョンです。オプションがある場合はTLSを使用します。さらに、いつものように Wikipedia で。
これから インディアナ大学知識ベース 記事：
SSLはSecure Sockets Layerの略です。 Netscapeは当初、このプロトコルを開発して情報を非公開で送信し、メッセージの整合性を確保し、サーバーのアイデンティティを保証していました。 SSLは、主にデータに公開鍵/秘密鍵の暗号化を使用することで機能します。一般的にWebブラウザで使用されますが、SSLは電子メールサーバーまたはあらゆる種類のクライアント/サーバートランザクションでも使用できます。たとえば、一部のインスタントメッセージングサーバーは、SSLを使用して会話を保護します。
TLSはTransport Layer Securityの略です。 Internet Engineering Task Force（IETF）は、SSLの後継としてTLSを作成しました。これは、電子メールプログラムの設定として最もよく使用されますが、SSLと同様に、TLSはあらゆるクライアントサーバートランザクションで役割を果たすことができます。
2つのプロトコルの違いはごくわずかで技術的ですが、標準は異なります。 TLSはより強力な暗号化アルゴリズムを使用し、さまざまなポートで機能します。さらに、TLSバージョン1.0はSSLバージョン3.0と相互運用できません。
TLSはSSLの新しいバージョンです。一部の場所では、これらの単語はプロトコル以外の何かを意味する場合がありますので、質問を明確にしてください。