問題タブ [handshake]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
safari - ハンドシェイクはSafariでは機能しませんが、Chromeでは機能します
WebSocketアプリケーションをテストしようとして問題が見つかりました。私のサーバーはDelphi7で作成されており、クライアントブラウザを接続しようとしています。
Chromeは「draft-ietf-hybi-thewebsocketprotocol-06」プロトコルを使用し、Safariは「draft-ietf-hybi-thewebsocketprotocol-00」プロトコルを使用していることを知っています。だから、私は両方の詳細を行いました。
そのため、Chromeでクライアントコードを実行すると、正常に動作します。eハンドシェイクがブラウザに受け入れられるようになりました。その後、両側との間でメッセージを送受信できます。
しかし、Safariブラウザで同じクライアントコードを実行すると、まったく機能しません。次のように、サーバーのブラウザーからハンドシェイクを取得しました。
だから、私のサーバーは答えます:
大丈夫そうです!しかし、クライアントは答えを受け入れず、すぐに接続を閉じます。
最初に頭に浮かんだのは、Safariに対するハンドシェイクの回答(draft-ietf-hybi-thewebsocketprotocol-00)に何か問題があったことです。しかし、Webで検索すると、「Echo Test」(http://www.websocket.org/echo.html)があるWebSocket.orgWebサイトが見つかりました。私が見つけた中で最も好奇心が強いのは、通常のテストを行ったところ、ChromeとSafariの両方が正常に機能したことです。ただし、ページにあるサンプルコードを保存してローカルで実行し、WebSocketサーバーに接続しても、Safariは機能しません。ですから、Safariには何か違うところがあると思います。以下のコードを保存して両方のブラウザ(SafariとChrome)で実行し、両方で動作するかどうかを確認してください。そして、誰かが何が起こるか知っていますか?
ありがとう!
html - クライアント側で「Sec-WebSocket-Accept」を確認したい
私は websocket の C サーバーを作成しています:D 実際に一度接続に成功しましたが、その後、この onOpen は再びトリガーされません...そして教えてくれます
だから今、クライアントHTMLが特にSec-WebSocket-Accept
フィールドを取るものを確認する必要があります
Sec-WebSocket-Accept
JavaScriptクライアント側でフィールドを確認する方法はありますか? これを確認するには、どの値を確認する必要がありますか?
php - PHP WebSocketServerがWebKit(Safari)に接続できません
私はPHPでWebSocketサーバーを作成しました。これは、Firefoxにはうまく接続できますが、Safariには接続できません。握手に何か問題があると思います。Safariには古いドラフトhybi00が必要です...しかし間違いを見つけることができません:/
接続しようとした直後にSafariで接続が閉じられました。よろしくお願いします!
c++ - InitializeSecurityContext(Schannel)によるTLSハンドシェイクプロセス
SSPIインターフェイスを使用してTLSハンドシェイクプロセスを実装する必要があります。
私のアプリはクライアント側を実装しています。ここから見たように、一般的なフローは次のとおりです。
- InitializeSecurityContext-最初の呼び出しは、SecBufferDesc構造体へのポインターを返します。
- 出力バッファーを使用してsend(= WinSock API)関数を呼び出します。
- recv関数を呼び出す
- バッファーを使用して、InitializeSecurityContextを再度呼び出します。
これらのバッファに関するMSDNの説明:
「最初の呼び出し後のこの関数の呼び出しでは、2つのバッファーが必要です。最初のバッファーのタイプはSECBUFFER_TOKENで、サーバーから受信したトークンが含まれます。2番目のバッファーのタイプはSECBUFFER_EMPTYです。pvBufferメンバーとcbBufferメンバーの両方をゼロに設定してください。」
私の質問:
- もう少し説明が必要です:バッファの意味は何ですか?2番目のバッファには何が含まれていますか?それらは何のため?
- MSDNには、InitializeSecurityContext関数のTargetDataRep入力パラメーターがSchannelに使用されると書かれていますが、私が見た多くのサンプルでは、SECURITY_NATIVE_DREPに設定されています。SECURITY_NATIVE_DREPフラグとは何ですか?なぜMSDNはそれをゼロに設定すると言うのですか?
私は本当にどんな助けにも感謝します。
ありがとう!。
java - キャッシュされたセッションの再開中のハンドシェイク中のSSLException
重複の可能性:
SSLハンドシェイクアラート:Java1.7.0へのアップグレード以降のunrecognized_nameエラー
私のJ2SEアプリは、HttpsUrlConnectionを使用して安全な場所にアクセスします。JREを1.7に更新するまでは、問題なく機能していました。これで、「ハンドシェイク中にリモートホストが接続を閉じました」SSLExceptionが発生します。JRE1.6とJRE1.7の両方で-Djavax.net.debug=ssl:handshakeを使用してアプリを実行した後、1.7ではキャッシュされたクライアントセッションを再開できないという印象があります。
更新:JRE 1.6では、クライアントアプリがSSLv2Helloカプセル化を使用していることを理解しました。ただし、JRE 1.7ではそれは行われません。これが、おそらく例外の原因です。私の質問はこれです:JRE 1.7で実行されているクライアントに対してSSLv2Helloカプセル化を有効にするにはどうすればよいですか?
更新#2:SSLv2Helloは、System.setProperty( "https.protocols"、 "TLSv1、SSLv2Hello")を介してJRE7で実行されます。ただし、これによってハンドシェイクの例外がなくなるわけではありません。例外の本当の理由は暗号スイートであることが判明しました。JRE 6では、サーバーはクライアントのオプションからSSL_RSA_WITH_RC4_128_MD5を選択しますが、JRE 7では、サーバーは常にTLS_DHE_RSA_WITH_AES_128_CBC_SHAを使用します。何らかの理由で、サーバーはTLS_DHE_RSA_WITH_AES_128_CBC_SHAを使用してキャッシュされたセッションを再開できません。System.setProperty( "https.cipherSuites"、suggestedCipherSuites)を使用してパッチが適用された問題。suggestedCipherSuitesは常にSSL_RSA_WITH_RC4_128_MD5で始まります。このアプローチの欠点はありますか?
更新#3:クライアントのSNI拡張機能は、サーバーを悩ませるものです。http://docs.oracle.com/javase/7/docs/technotes/guides/security/enhancements7.htmlの「JSSEクライアントのサーバー名表示(SNI)」を参照してください。
java - rxtxComm を使用した RS232 DB9 でのハンドシェイク ラインの処理
rxtxComm を使用して、Arduino (USB シリアル ポート) と通信 (データの送受信) を行いました。rxtxComm ライブラリを使用して DTR のようなハンドシェイク ラインを処理するにはどうすればよいですか? このチュートリアルまたはサンプル コードを教えてください。
- 注:win7 OSを使用しています。今日 (2012 年 4 月 21 日)、USB シリアル (DB9) アダプターを購入しました。LEDアレイをrs232に直接接続することを計画しています...
web-services - javax.net.ssl.SSLHandshakeException: 致命的なアラートを受信しました: handshake_failure
私は、サーバー担当者が開発およびホストしている特定の Web サービスを使用する予定です。SSL が関係し、クライアントは Axis 1x であり、証明書は信頼できる CA からのものではありません。
カスタム キーストアの作成、カスタム SocketFactory の作成、カスタム TrustManager の作成など、必要なすべてに対応したと思います。それでもhandshake_failureを受け取り続けます。
これが私がこれまでに行ったことです:
私のコードからの抜粋:
以下を持つテスト JSP:
サーバーの男は私のために次の情報を持っています:
そして報告します:
アクセスログ:
エラーログ:
リクエストログ:
最後に、SSL デバッグの一部 (証明書情報を出力する最初の行をいくつか削除しました。ところで、前述の証明書は SSL デバッグに表示されます):
- allowUnsafeRenegotiation にコメントするか、true/false に設定しようとしました
- setEnabledCiphers の有効化またはコメントアウト
- 提供されたクライアント証明書を、カスタム キーストアではなくデフォルト キーストアにインポートする
- SSLContext.getInstance("TLS") および "SSL" を使用
- SSLSocket::setEnabledProtocols と SSLv3、TLSv1、およびそのような組み合わせ。
- keytool 操作全体を最初からやり直す
まだ運がありません。私はまったく同じエラーで立ち往生しています-3日以来です!
この点で何か助けていただければ幸いです。
ティア。
ssl - SSL サーバーのハロー メッセージに指定されていないバイトがあります
SSL 3.0 ハンドシェーク中、サーバーは次の serverhello メッセージで応答します
私はこの回答を次のように理解しています。
しかし、最後の 7 バイトをどのように解釈すべきか理解できません: 00 05 ff 01 00 01 00
java - SSLSocketハンドシェイク完了のイベント通知を受信するための登録
SSLSocketのドキュメントによると:
ハンドシェイク完了のイベント通知を受信するために登録できます。
なぜあなたはこれに登録しないのですか?SSLExceptionが発生せずにSSLSocket.startHandshake()が成功するという事実は、証明書が信頼できることを保証しますか?または、ハンドシェイクが完了するのを待つことで、ある程度の保証が得られますか?
c++ - Sha1 の C++ Base64 - WebSocket ハンドシェイク
現在、WebSocket と通信できる C++ サーバーを実行しようとしています。HandShake はいくつかのステップで構成されており、最後のステップではうまくいきません。
最初のステップは、SHA1 でエンコードされた文字列を生成することで、正しい 16 進文字列を正常に取得できました。(例http://en.wikipedia.org/wiki/WebSocket & https://www.rfc-editor.org/rfc/rfc6455 )。
私の出力は、どちらの場合もドキュメントに記載されているものと同じです:
これは正しいです。Base64エンコーディングを行うと、次の結果になります。
そして、これは完全に異なります。Base64 アルゴリズムが特定のオンライン コンバーターで動作し、サーバーが出力した出力がすべて生成されることを確認しました。問題は入力形式です。同じ問題を抱えている JavaScript フォーラムでフォーラム エントリを見つけました。答えは、40 文字の 16 進文字列を渡す代わりに、20 文字のバイナリ表現を渡す必要があるというものでした。
openssl SHA1 がバイナリ表現を返すことは知っていますが、特定の理由でライブラリを使用できません。私が使用するSHA1ライブラリは、エンコードされた出力をint配列に入れます。出力は次のようになります (IETF の例)。
私はこれを次のように16進数に変換します:
今、大きな問題です。16 進文字列をバイナリに変換するにはどうすればよいですか?
よろしくお願いします。マーカス
編集
誰かがコードに興味がある場合: https://github.com/MarkusPfundstein/C---Websocket-Server