SSLとSSHの違いは何ですか？どちらがより安全ですか？

SSLとSSHの両方が暗号化を提供します整合性がチェックされた機密データ転送用のトンネルを構築するための要素。その部分では、同様の手法を使用し、同じ種類の攻撃を受ける可能性があるため、両方が適切に実装されていると仮定して、同様のセキュリティ（つまり優れたセキュリティ）を提供する必要があります。両方が存在するのは一種の NIH 症候群です。SSH開発者はトンネル部分にSSLを再利用する必要があります（SSLプロトコルは、さまざまなバリエーションに対応するのに十分な柔軟性があります。証明書を使用しないでください。

トンネルの周りにあるものが異なります。 SSLは従来、サーバーとクライアントの公開鍵を通知するためにX.509証明書を使用します。 SSHには独自の形式があります。また、SSHには、トンネル内に入る ための一連のプロトコル（複数の転送の多重化、トンネル内でのパスワードベースの認証の実行、端末管理など）が付属していますが、SSLにはそのようなものはありません。 、またはより正確には、そのようなものがSSLで使用される場合、それらはSSLの一部とは見なされません（たとえば、SSLトンネルでパスワードベースのHTTP認証を行う場合、「HTTPS」の一部であると言いますが、実際には、SSHで発生するのと同じように機能します。

概念的には、SSHを使用して、トンネル部分をSSLのものに置き換えることができます。また、HTTPSを使用して、SSLをSSH-with-data-transportとフックに置き換えて、証明書からサーバーの公開鍵を抽出することもできます。科学的な不可能性はなく、適切に行われた場合、セキュリティは同じままになります。ただし、そのための広範な規則や既存のツールはありません。

したがって、SSLとSSHを同じ目的で使用することはありませんが、これは、これらの実装に歴史的に付属していたツールが原因です。プロトコル、 セキュリティ関連の違いのためではありません。SSLまたはSSHを実装する人は、両方のプロトコルでどのような種類の攻撃が試みられたかを確認することをお勧めします。

コメント

• お疲れ様でした。実際、SSHはSSLよりも設定が簡単なため、多くの人がSSH内でhttp（httpsではなく）をトンネリングします。たとえば、Webでリモートシステム管理を行う場合などです。 eboxやwebminなどのGUIツール。
• 指摘しておきますが、’ SSHの担当者が” should “はSSLを使用する必要があります：SSHは、攻撃面が小さく、非常に安全であるように特別に設計されています。SSHv2には問題がなく、 SSL / TLSの落とし穴なので、小さなことを実行します。よく理解されていて、複雑さが少なく、状況にはるかに適したものが出てきました。それはあなたがどれほど妄想的であるかによります：SSLはアプリケーションによっては’使用できませんが、SSH ‘の設計により、状況に応じて受け入れられます/ SSLが単に信頼されていないセキュリティコミュニティ。
• @NicholasWilson ” SSH ‘の設計により、SSLが単純な状況/セキュリティコミュニティで受け入れられます信頼されていません “など…
• SSLとSSHは並行して開発されたため（どちらも1995年にリリースされました）、SSHでさえできた SSLを使用できたかどうかは明らかではありません。現代のSSL2.0を使用すべきだったかどうかも非常に疑わしいです：-）
• SSH 2.0はプロトコルを完全に書き直したもので、1999年頃に登場したため、 SSL3.0またはTLS1.0を再利用することもできます。しかし、もちろん、TLSは X.509と結びついているように見えます。これは開発者を怖がらせます。

これは合理的な比較ではありません。SSLはネットワーク経由で転送されるデータを保護するための一般的な方法ですが、SSHはログインしてリモートコンピューターとデータを共有するためのネットワークアプリケーションです。

SSHのトランスポートレイヤー保護はSSLと機能が似ているため、どちらが「より安全」であるかは、特定の脅威モデルが何を要求するか、およびそれぞれの実装が対処しようとしている問題に対処するかどうかによって異なります。

SSHには、SSLに欠けているユーザー認証レイヤーがあります（SSLには必要ないため、SSLはSSHでも実行できる2つの接続インターフェイスを認証する必要があります）。UTF-8アートでは：

 SSL SSH +-------------+ +-----------------+ | Nothing | | RFC4254 | Connection multiplexing +-------------+ +-----------------+ | Nothing | | RFC4252 | User authentication +-------------+ +-----------------+ | RFC5246 | | RFC4253 | Encrypted data transport +-------------+ +-----------------+ 

潜在的な攻撃が多い問題に関しては、SSHの方が攻撃面が大きいことは明らかです。しかし、それはSSHが全体を持っているからです。適用する組み込み： SSL +提供する必要のあるアプリケーションの攻撃対象領域は、十分な情報がないため比較できません。

コメント

• -1これは妥当な比較です。 OPがSSLをUNIXプログラム ssh（1）と比較していると誤って想定しています。 SSHは、実際にはトランスポート層のセキュリティを提供する別のプロトコルであり、リモートシェルとリモート実行のための特別なプロビジョニングがあります。
• +1 @jpillora 2つを比較するのは理にかなっていると思いますが、SSHという用語は通常、SSL / TLSに直接匹敵するトランスポート層セキュリティを処理するSSHプロトコルのサブセットを指すために使用されることはありません。これは、この回答で説明されている方法でSSL / TLSとは異なるアプリケーション層プロトコルに関してほぼ独占的に使用されます。
• @freb方法’一般的に再参照されても、問題の真実は変わりません。 SSHは、sshユーティリティのトランスポート層として使用されるプロトコルです。受け入れられ、最も投票された回答は、この事実を反映しています。
• @jpillora私は、SSHトランスポート層プロトコルがほとんどの人の意味するものだとは思わないことを意味しました’質問の言い回しを考えると。ただし、正解として受け入れられた回答を考えると、それはOPが求めていたものであったに違いありません。
• @frebそうです、ほとんどの人は言い回しを考えると、この共通点を修正することがさらに重要になると考えています。誤解。

厳密な暗号化の観点からは、どちらも認証付き暗号化を提供しますが、2つあります。違う方法。

SSHは、いわゆるEncrypt-and-MACを使用します。つまり、暗号化されたメッセージがクリアメッセージのメッセージ認証コード（MAC）に並置され、整合性が追加されます。これは常に完全に安全であるとは限りません（実際には十分であるはずです）。

SSLはMAC-then-Encryptを使用します。MACはクリアテキストに並置され、両方とも暗号化されます。 。一部のブロック暗号モードでは、MACの一部が推測可能であり、暗号に関する何かを明らかにする可能性があるため、これも最善ではありません。これにより、TLS 1.0（BEAST攻撃）に脆弱性が発生しました。

したがって、両方に潜在的な理論上の弱点があります。最も強力な方法は、Encrypt-then-MAC（暗号化されたメッセージのMACを追加する）です。これは、たとえば、IPsecESPに実装されます。

コメント

• SSH ‘のバイナリパケットプロトコルはencrypt-and-MACであり、プレーンテキストメッセージ（m）ごとに暗号文E（m）++ MAC（m）（暗号化された連結）を送信します。 E（m ++ MAC（m））を実行するSSLに対して、MACを使用したメッセージ）。ただし、SSHはバイナリパケットプロトコル（キー管理、リモートシェルクライアント/サーバー、ファイル転送など）だけではありませんが、SSL（現在はTLSと呼ばれています）は、追加する他のプロトコルで使用されるトランスポート層プロトコルです。必要な機能（HTTPS、FTPS、IMAPSなど）。 crypto.stackexchangeでEtM、E & M、MtEの比較も参照してください。com / questions / 202
• 完全に同意しました。私が書いたものよりもはるかに多くのものがあります。 ‘は、厳密な暗号化の観点から、 incipit “で意味したことです”。
• BEASTはMtEとは関係がなく、既知のIVとCBC（SSL3およびTLS1.0）が原因です。これはSSH2でも修正され、修正されませんでした。それとTLSの両方がより良い代替としてAEAD = GCM（TLSもCCM）（および両方のChaCha / Poly）を取得する前に、代替としてCTRを取得しましたが。 MtE + CBCパディングベースの攻撃はPOODLEとLucky13です。
• 出力サイズ=入力サイズで、暗号への弱いデータ入力がない暗号に対してMAC-then-Encryptを安全にするソリューションがあります。コア。
• これはTLSが現在行っていることではないため、この回答は古くなっています。

この比較には、見落とされていた側面が1つあると思います。 user185は近づきましたが、完全には到達しませんでした。これらはリンゴとオレンジであり、HTTPSとSSHと比較して、リンゴとリンゴの比較が優れていると感じています。HTTPSとSSHはOSIモデルの異なるレイヤーを利用するため、異なるデータを暗号化します。次に、送信中にこのデータが暗号化され、暗号化されていないのはいつかという線に沿って、実際に質問する必要があります。これにより、潜在的な攻撃面が明らかになります。HTTPSを使用すると、宛先ネットワーク（Webサーバー、ボーダールーター、ロードバランサーなど）は暗号化されておらず、残りの旅程はプレーンテキストで費やされます。トラフィックは内部にあるため、これは大したことではないと多くの人が主張します。今回は、ペイロードに機密データが含まれている場合、最終的な宛先に到達するまで、通過するすべてのネットワークデバイスのログファイルに暗号化されずに保存されます。SSHでは、通常、宛先デバイスが指定され、送信は、このデバイスに到達するまで暗号化されます。 HTTPSデータを再暗号化する方法はいくつかありますが、これらは、環境にHTTPSソリューションを実装するときに実行することをほとんど忘れる追加の手順です。

SSLは、次のようなプロトコルレイヤーです。トンネリングされているコンテンツから抽象化されます。 SSHはシェル（SH）の安全なバージョンであり、その下に抽象層を含むようには設計されておらず、シェルトラフィックを伝送するために特別に設計されています。したがって、暗号化操作は両方で使用され、それらの暗号化操作は同じである可能性もありますが、目的、したがって全体的な設計はまったく異なります。

特定の違いがあることに注意してください（上記で引用したように） ）、ただし、これらの違いのすべてではないにしても、ほとんどは異なるプロトコルの目的に根ざしています。

コメント

• -1誤った仮定をしているそのOPはSSLをUNIXプログラム ssh（1）と比較しています。 SSHは、実際にはトランスポート層のセキュリティを提供する別のプロトコルであり、リモートシェルとリモート実行のための特別なプロビジョニングがあります。

本当にSSHとSSL（TLS）を探しているなら、答えはSSHです。

SSHがSSLに勝つ理由の1つは、認証を実行する方法です。このため、FTPを使用する場合は、FTPS（FTP over SSL）ではなくSSHプロトコル（SFTP）を使用してください。

SSHは、企業ネットワークで次の目的で使用されます。

• ユーザーと自動化されたプロセスに安全なアクセスを提供する
• インタラクティブで自動化されたファイル転送
• リモートコマンドを発行する

ソース： https://www.ssh.com/ssh/protocol/#sec-Typical-uses-of-the-SSH-protocol

コメント

• ” SSHがSSLに勝つ理由の1つは、認証を実行する方法です”このアサーションのソースまたは説明はありますか？
• SSHでは、サーバーに接続するための2つのオプションがあります。鍵ベースの認証オプションでは、最初にSSH秘密鍵と公開鍵を事前に生成する必要があります。これは追加の作業ではありません。これは、セキュリティのベストプラクティスも考慮されています。 SSLには非常に多くのバージョンがあり、最新のものはTLS1.2です。つまり、’はまだそれほど安全ではありませんが、改善の過程にあります。
• TLSにはクライアント側の証明書もあります。 SSH “が”に勝つ理由を説明していません。
• どこかからコピー/貼り付けする場合は、ソースを引用していることを確認してください。
• ” SSLには非常に多くのバージョンがあります”したがって、6つのバージョンは”非常に多い”？ OpenSSHはバージョン7.7です。 “つまり、’はまだそれほど安全ではありませんが、改善の過程にあります。”ここでは論理が意味をなしません。

問題は2つあります。」暗号化の長所と短所だけでなく、配信の容易さと便利さです。したがって、ビジネスの観点からは、SSL / TLSはブラウザと、パブリックまたはプライベートの証明書が必要なだけなので、より便利で簡単です。

SSHを使用するには、アプリケーションまたはシンクライアントのいずれかがインストールされている必要があります。これは、ユーザーのインターネットクライアントの観点とサポートからするとさらに問題になります。