Proxytunnel / HTTPSを介してSSHをトンネリングすることは、StunnelでSSLを介してそれを行うこととどのように異なりますか？
SSL、TLS、およびHTTPSの違いは何ですか への回答では、HTTPSはSSL over TLS上のHTTPであると言われています。つまり、最初にSSL/TLS接続が確立され、次に通常のHTTPデータがSSL/TLS接続を介して交換されます。
では、stunnelを使用してSSLトンネルを作成し、それを介してHTTPトラフィックを通過させると、通常のHTTPSの使用と同じになりますか？
次に、プロキシ/ファイアウォールが暗号化されたトラフィックを使用したSSL/TLS接続のみを認識している場合、トラフィックがHTTPでないことをどのようにして知ることができますか？
理論的には、プロキシ/ファイアウォールが違いに気付かない場合は、HTTPではなくSSL/TLS接続（stunnelで作成）を介してSSHトラフィックをトンネリングできるはずです。ただし、実際には、これが機能しないことがわかりました。プロキシ/ファイアウォールは、HTTPSトラフィックではないことを検出できるようです。
これがProxytunnelが使用される理由だと思いますが、検出を回避するためにProxytunnelがどのように異なるのか理解できません。偽のHTTPヘッダーを作成するだけですか？
ファイアウォールは、HTTPとSSHの両方がSSL/TLSを介してトンネリングされている場合、HTTPとSSHの違いをどのように検出できますか？
TL; DR-あなたの問題はSSLとはまったく関係ないと思いますが、プロキシヘッダーなしでプロキシサーバーを使用しようとしています。
では、stunnelを使用してSSLトンネルを作成し、それを介してHTTPトラフィックを通過させると、通常のHTTPSの使用と同じになりますか？
はい。職場では、httpをstunnel経由で使用して、httpsサーバーと通信します。これは、Java httpsクライアントがISS https-serverと通信できない場合があるhttpsクライアントのバグの回避策です。
次に、プロキシ/ファイアウォールが暗号化されたトラフィックを使用したSSL/TLS接続のみを認識している場合、トラフィックがHTTPでないことをどのようにして知ることができますか？
通常のプロキシ/ファイアウォールは、何が入っているかを知ることができません。
復号化https-proxiesがあります。彼らが機能するためには、クライアントをだまして実サーバーの公開鍵の代わりに自分の公開鍵を受け入れさせる必要があります。 httpsでは、公開鍵はサーバー名に関する情報を含む証明書の一部です。通常、証明書はCAによって署名されており、ブラウザーはこれを信頼できるものとして認識しています。
クライアントが自分の公開鍵を使用できるようにするために、プロキシサーバーはサーバー証明書を偽装する必要があります。通常のクライアントは、無効な証明書に関する警告を表示します。ただし、プロキシは独自のCAを使用して偽の証明書に署名できます。そして 管理者はクライアント上で信頼できるものとしてCAをインストールできます 。
理論的には、プロキシ/ファイアウォールが違いに気付かない場合は、HTTPではなくSSL/TLS接続（stunnelで作成）を介してSSHトラフィックをトンネリングできるはずです。
SSHをトンネルする一般的な方法は、非復号化httpsプロキシのSSLレイヤーなしでも機能します。
ただし、実際には、これが機能しないことがわかりました。プロキシ/ファイアウォールは、HTTPSトラフィックではないことを検出できるようです。
あなたは何か間違ったことをしている、またはあなたは上で説明したように復号化httpsの後ろにいます。
これがProxytunnelが使用される理由だと思いますが、検出を回避するためにProxytunnelがどのように異なるのか理解できません。偽のHTTPヘッダーを作成するだけですか？
ここでは、ファイアウォールとプロキシを区別する必要があります。ネットワークファイアウォールのみの場合は、通常、ポート443のターゲットIPアドレスに接続できます。ただし、プロキシがある場合は、プロキシのIPアドレスとポートに接続し、HTTPプロトコルを使用してターゲットに接続するように指示する必要があります。コマンドは：CONNECT target:port HTTP/1.1 <cr><lf>
ほとんどの場合、https-proxy-serversは任意のIPアドレスへの接続を許可しますが、ポート443にのみ接続できます。接続文字列を送信した後、http応答ヘッダーを取得します。通常のhttpsプロキシでは、それ以上の情報はそのまま任意の方向に転送されます。したがって、必要なプロトコルをすべて話すことができます。ここからネイティブにsshを使用して動作します。
理論的には、ファイアウォールまたはダムプロキシは、SSL以外のトラフィックを検出することにより、このネイティブトンネリングを防ぐことができます。しかし、これは非常にまれです。この種のトンネルを効果的に防止できるのは、https復号化プロキシのみです。
Stunnelインスタンスのサーバーポートに対してHTTPを実行する場合：
client <--- TCP ---> stunnel <--- TCP ---> server
<--- TLS --->
<------------- HTTP -------------->
これはHTTPSの使用とほぼ同じですが、クライアントがまだTCP over HTTPを使用していると認識しているため、完全ではありません。たとえば、ブラウザのURLバーに「セキュア」と表示されず、ブラウザで実行されているJavascriptコードは、接続がHTTPSでない場合、処理を拒否する可能性があります。
残りの質問については、使用している「ファイアウォール」または「プロキシ」で何が起こっているのかを正確に把握する必要があります。接続を処理するために使用するさまざまな手法がいくつかあり、使用するときに特定の手法を許可または禁止します。
1.直接TCP接続
TCP接続がリモートホストで終了する（上記の図））場合、何らかの方法で変更されていても（たとえば、NATを介してアドレスが変更されている）、TLSを設定した場合その上の接続TCP接続、中間ルーターは、その量、IPアドレス、およびTCPポート、およびTLSであるという事実。IPレベルのファイアウォールは、443以外のポートへの接続を許可しないように構成されているか、TLSでないことが判明した場合は443への接続をドロップするように構成されている可能性があります。最初にポート自体に接続して、サーバーがそのポートでHTTP/TLSを実行しているようです。
2. HTTPプロキシCONNECT
[〜＃〜] connect [〜＃〜] 動詞を使用してHTTPプロキシを経由する場合、 Proxytunnel と同様に、2つのTCP接続が含まれますが、それらを介して1つのTLS接続を実行します。
client <---- TCP 1 ----> proxy <---- TCP 2 ----> server
CONNECT
<------------------ TLS ---------------->
TLSを相手側の実サーバーとネゴシエートしているので、状況は上記の＃1とほとんど同じです。 TCP接続を介してTLSを実行する必要はありません。実際には、単にCONNECT server.mydom.com:22プロキシがその要求を拒否しない場合は、その接続を介してSSHの通信を開始します。一部の人々は、まさにこの目的のために、ポート443でリッスンするSSHサーバーを持っています。プロキシが使用中のプロトコルをチェックするのに十分に洗練されている場合、TLSが起動すると、その接続で何が起こっているのか正確に確認できない場合でも、標準のTLSセットアップを実行していないことがわかると、接続が切断される可能性があります。 。
3. MITM
一部の組織は、HTTPS接続に対して中間者攻撃を行います（「SSLインターセプト」と呼ばれることもあります）。直接TCP接続または上記のいずれかの場合のプロキシを介して、リモートサーバーに接続しようとすると、ネットワークデバイスはそれがリモートサーバーであると偽装します。
client <---- TCP 1 ----> MITM <---- TCP 2 ----> server
<---- TLS 1 ----> <---- TLS 2 ---->
<---------------- HTTP ---------------->
WebブラウザーはTLSセットアップを試み、証明書をチェックします。これは、実際の証明書ではなく、デバイスがプライベートCA（認証局）によって署名された証明書を生成し、IT部門も証明書リストを変更したためですそのCAを信頼するブラウザまたはOS。 （これは、Firefoxなど、その証明書を使用せずに別の証明書リストを使用する別のプログラムと同じ接続を試し、同じ接続を試すことで発生していることを確認できます。）MITMデバイスへの安全な接続がありますが、すべてを復号化していますデータを転送するときに、サーバーへの別の安全な接続のために再暗号化します。
この場合、リモートサーバーと通信しているように見えますが、実際には、接続上のすべてのデータへのフルアクセスがあり、必要に応じてそれを表示および変更できるプロキシに対してのみ安全に通信しています。