3

XMPP RFCにはMUST、仕様で「セキュリティ層のバイト精度」と規定されているため、STARTTLSとSASLに使用されるXMLに空白を含めてはならないという2つのディレクティブがあります。それは何ですか？

RFCからの関連する抜粋：

..。

STARTTLSネゴシエーション中、エンティティはXML要素間の区切り文字として空白を送信してはなりません（つまり、送信された'urn：ietf：params：xml：ns：xmpp-tls'名前空間で修飾された第1レベル要素の最後の文字から）開始エンティティによって、受信エンティティによって送信された「urn：ietf：params：xml：ns：xmpp-tls」名前空間によって修飾された第1レベル要素の最後の文字まで）。この禁止は、適切なセキュリティ層のバイト精度を確保するのに役立ちます。

... SASLネゴシエーション中、エンティティはXML要素間の区切り文字として（つまり、「urn：ietf：params：xml：ns：xmpp-sasl」で修飾された第1レベル要素の最後の文字から）空白を送信してはなりません。開始エンティティによって送信された名前空間。受信エンティティによって送信された「urn：ietf：params：xml：ns：xmpp-sasl」名前空間によって修飾された第1レベル要素の最後の文字まで）。この禁止は、適切なセキュリティ層のバイト精度を確保するのに役立ちます。

4

1 に答える 1

3

このディレクティブは、バイトストリームの適切な処理を保証するためのものです。クライアントがXMLフラグメントの後に改行を送信すると、次のような応答が送信される可能性があります。

<response ... /> [LF]

サーバーは、最後の'>'までXMLを段階的に解析し、その時点で<success/>要素をクライアントに送り返します。これで、クライアントは新しいストリーム開始を送信します。つまり<stream:stream ... >、セキュリティレイヤーを使用します。これにより、サーバー側でセキュリティレイヤーが破損する可能性があります。これは、追加のLF文字がセキュリティレイヤーの一部であると想定されるためです。

サーバーはパケットを発行する前に受信バッファをクリアする必要があると言うかもしれません<success/>が、これはバイトストリームを処理する適切な方法ではありません。結局のところ、基盤となるサブシステムがそのLF文字の配信を遅らせた可能性があり、サーバーは<success/>パケットの送信後にそれを受信する可能性があります。

もちろん、解決策は、クライアントがそのような余分なデータを送信しないようにすることです。この特定の議論についての詳細は、メーリングリストでここで読むことができます。

于 2012-08-19T21:55:02.820 に答える