セキュリティと認証：SSL vs SASL
私の理解では、SSLは暗号化アルゴリズム（AES、DESなど）と鍵交換方式（Diffier-Hellmanなど）を組み合わせて、安全でないネットワーク（インターネットなど）の2つのエンドポイント間で安全な暗号化および識別サービスを提供します。
私の理解では、SASLはMD5/Kerberosプロトコルであり、ほぼ同じことを行います。
だから私の質問：両方を選択することの賛否両論と、どちらがより望ましいシナリオは何ですか？基本的に、SSLを選択する場合、またはSASLを使用する場合に従うべきガイドラインを探しています。前もって感謝します！
SSL/TLSは通信プロトコルであり、SASLは他のプロトコルと統合されたフレームワークであるため、SSL/TLSとSASLを比較することは非常に困難です。 （実際、状況によっては両方を同時に使用できます。）
さらに、実際には認証プロトコルであるKerberosについても言及しています（SSL/TLSまたはSASL、またはその両方で使用できます）。あなたの質問は、Kerberosを使用するかどうかは、最初に選択すべき主な副問題の1つであることを示唆しているようです。
SASLは本質的に、既存のアプリケーションプロトコル（LDAP、SMTP、Subversionなど）のプラガブル認証システムとデータセキュリティを可能にするインダイレクションレイヤーですが、これらのプロトコルはこの拡張を認識する必要があります（例 SMTP auth ）。安全な認証とデータ暗号化を提供するかどうか、そしてどのように提供するかは、このフレームワーク内で使用されるもの 基礎となるメカニズム に大きく依存します。次に、 svnserve documentation の例を示します： "組み込みのCRAM-MD5メカニズムは暗号化をサポートしませんが、DIGEST-MD5はサポートします」。 SASLでKerberosを使用する場合は、別のレベルの間接参照が必要になります： GSS-API （これはKerberosで最も一般的に使用されますが、他のメカニズムも可能です）。 （SASLのコンテキストでのGSSAPIは、その GS2後継者 とは異なり、とにかくKerberosを暗示するようです。）
SSL/TLSの一般的な目標は、クライアントとサーバー間の通信（整合性と機密性）を保護することです。クライアントは常にSSL/TLSサーバーのIDを確認する必要があり、サーバーがクライアントのIDも確認するメカニズムを提供します。できることは、設定方法によっても異なります。 SSL/TLSは、X.509証明書で最も一般的に使用されます。これにより、ブラウザはHTTPSサーバーのIDを確認できます。証明書を使用して自分自身を識別するようにクライアントに要求するようにサーバーを構成することもできます（クライアント証明書認証）。ただし、Kerberosを使用する場合は、TLS Kerberos cipher suites を使用できます。これはあまり一般的ではありませんが、 JSSEで実装されています です。
通常、その実装は、プレーンTCP接続で得られるものと同様のAPIを提供します。Javaでは、いったん構成すると、SSLSocketを使用できます。プレーンSocketを使用します。一部のプロトコルにはプレーン接続からSSL/TLSに切り替える明示的なコマンドがありますが（ Implicit vs Explicit SSL/TLS ）、認証も提供できます。 [〜＃〜] jsse [〜＃〜] はデフォルトのSSL/TLS実装であり、SSLSocket（または勇気があればSSLEngine）にアクセスできます。
「 When Java GSS-API vs. JSSE 」を使用する場合」を読んでください。 「SASL vs. SSL/TLS」に似ています（ただし、JSSEdoesはKerberosをサポートしているため、しばらく更新されていないようです）少なくともOracle Java 6）以降、暗号スイート。
SASLについてはSSL/TLSよりも知識が少ないことは認めますが、SASLを介してデータ暗号化を行うことは、より手間がかかるようです。 EDH暗号スイートが提供するPerfect Forward Secrecy などの特定のSSL/TLS機能を備えていないようです。 JGSSチュートリアルでGSSAPI（ここではKerberos）でSASLを使用する例 ：データを明示的にラップ/アンラップする必要があります。これはSSLSocketsを使用する場合は必要ありません。
あなたの主な関心事は、最初に使用する認証メカニズムを決定することだと思います：Kerberos、X.509証明書、または他の何か。これは、全体のアーキテクチャにより大きな影響を与え、両方ともSASLおよびSSL/TLSで使用できます（SSL/TLS接続の上にあるときにEXTERNALメカニズムを使用してSASLを使用する場合はさらにそうです）。
- Kerberosは非常に集中化されています。クライアントは、アプリケーションサーバーに接続できることに加えて、認証のためにKDCに接続できる必要があります。クライアントは、そのKDCを使用するように構成する必要もあります。ユーザーの観点からは、ユーザーはパスワードを使用できます。
- X.509はより分散されています。ただし、ユーザー証明書に対して証明機関を展開する（または商用の証明機関を使用する）必要がある場合があります。ユーザーには証明書と秘密鍵を与える必要がありますが、それらは複雑すぎる場合があります。
JAASは、一般的なJava認証と承認を処理するためのフレームワークです。セキュリティマネージャーの概念と非常に密接にリンクされているためです。 SubjectおよびPrincipal これは、プロトコルや通信に直接リンクされているのではなく、アプリケーション内で認証と承認をモデル化する方法にリンクされています（そうするためのクラスの標準セットを提供します）。
（一般的に Javaリファレンスドキュメント を参照することをお勧めします。読みます。）
SSL vs SASL
SASLがプロトコルではなく抽象化レイヤーであることは事実です。 SSLとSASLが同様の機能を提供していることも事実です。どちらも認証、データ署名、暗号化を提供します。
SSLはトランスポート層で行われ、通常は下層プロトコルに対して透過的です。たとえば、LDAPまたはHTTPでSSLを使用できます。ただし、場合によっては、セキュリティで保護されたモードに切り替えるために、既存のプロトコルを変更する必要があります。たとえば、POP3およびIMAPは、SSLの使用を開始するコマンド [〜＃〜] starttls [〜＃〜] を持つように拡張されています。その角度から見ると、これはSASLが行っていることに似ています。
一方、SASL機能を提供するために、多くのプロトコルも拡張されています。 ここ はプロトコルのリストです。繰り返しますが、POP3とIMAPはその2つであり、認証を開始するために異なるコマンドを使用しています。
それでは、いつSSLを使用し、SASLを使用する必要がありますか？
SSLとSASLの明らかな違いは、SSLが証明書に基づいて認証を行うためにバインドされているのに対し、SASLではさまざまなメカニズムを選択してクライアントを認証できることです。 SASLでは、GSSAPI、Kerberos、NTLMなどの使用を選択できます。
この違いのため、状況によっては、SSLではなくSASLを使用する方が直感的です。たとえば、クライアントアプリケーションはKerberosを使用してエンドユーザーを認証しています。サーバーはクライアントを認証する必要があります。クライアントアプリケーションには既にKerberos資格情報（Kerberosの用語ではチケット）があるため、Kerberos資格情報を使用してサーバーで認証することは理にかなっています。もちろん、同じことをするためにいつでもSSLをセットアップできます。ただし、既存のKerberosインフラストラクチャの上に、認証局インフラストラクチャをセットアップし、何らかの方法でクライアント証明書をKerberos資格情報と関連付ける必要があります。それは実行可能ですが、多くの作業が必要です。
また、場合によっては、SSLではなくSASLメカニズムでのみ使用可能な機能を使用する必要があります。たとえば、Kerberosでは、チケットをクライアントからサーバーに転送して、サーバーがクライアントに代わってチケットを使用して一部のリソースを照会できるようにします。一般的な例の1つは、アプリケーションサーバーとデータベースがあることです。クライアントアプリケーションはアプリケーションサーバーで認証され、アプリケーションサーバーはクライアントの資格情報を使用して、クライアントに代わってデータベースを照会する必要があります。 SSLはこの機能を提供できませんが、Kerberosはこれをサポートしています。したがって、その場合、SASLを使用することを選択する必要があります。
場合によっては、SSLを使用し、SASLは使用しないことがあります。たとえば、プロトコルを拡張することはオプションではないか、プロトコルの下で交換されるすべてのパケットを暗号化する必要があります。
GSSAPIはKerberosおよびSASLとどのように関係しますか
これによれば wikiページ 、SASLではGSSAPIとKerberosの両方がサポートされています。 GSSAPIは汎用プログラミングインターフェイスです。その考えは、アプリケーションライターが単一の共通APIを使用して、その下で使用されるプロトコルに関係なく、認証、暗号化などを行うことです。 GSSAPIはKerberosを実装しています。したがって、GSSAPIを使用してKerberos認証を行うことができます。
JAASとSASLの関係
正直なところ、私はJavaエキスパートではありません。私が読んだことから、JAASは単なるプラグイン可能な認証フレームワークのように聞こえます。 GSSAPIは認証と安全なメッセージ交換に焦点を当てていますが、JAASは認証と承認に焦点を当てていますが、JAASもSASLメカニズムの1つであるという証拠は見当たりません。カスタムSASLメカニズムの実装を支援するJavaライブラリのヘルパークラス。
SASLはプロトコルではなく、何らかの認証メカニズムの抽象化レイヤーです。 SASLメカニズムとしてDigest-MD5またはGSS-APIを使用する場合、SASLにデータトラフィックを完全に暗号化するよう要求できます。これは、たとえば、Active Directoryサーバーと通信するために行うことです。 SSLは必要ありません。あなたのユースケースは何ですか。詳しく説明してください！