Байтовая точность уровня безопасности?

В XMPP RFC есть две директивы MUST, устанавливающие, что XML, используемый для STARTTLS и SASL, не должен включать любые пробелы ради чего-то, что в спецификации указано как «точность байта уровня безопасности». Это что?

Соответствующие выдержки из RFC:

...

Во время согласования STARTTLS объекты НЕ ДОЛЖНЫ отправлять какие-либо пробелы в качестве разделителей между элементами XML (т. е. из последнего символа элемента первого уровня, определяемого пространством имен 'urn:ietf:params:xml:ns:xmpp-tls', как отправлено). инициирующим объектом до последнего символа элемента первого уровня, определенного пространством имен urn:ietf:params:xml:ns:xmpp-tls, отправленного принимающим объектом). Этот запрет помогает обеспечить надлежащую точность байтов на уровне безопасности.

... Во время согласования SASL объекты НЕ ДОЛЖНЫ отправлять какие-либо пробелы в качестве разделителей между элементами XML (т. е. из последнего символа элемента первого уровня, определяемого параметром 'urn:ietf:params:xml:ns:xmpp-sasl' пространство имен, отправленное инициирующим объектом, до последнего символа элемента первого уровня, квалифицированного пространством имен «urn:ietf:params:xml:ns:xmpp-sasl», отправленного принимающим объектом). Этот запрет помогает обеспечить надлежащую точность байтов на уровне безопасности.


security sasl xmpp starttls
person Manav    schedule 18.08.2012    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Эта директива предназначена для обеспечения правильной обработки потоков байтов. Представьте, что если клиент отправляет новую строку после фрагментов XML, он может отправить такой ответ:

<response ... /> [LF]

Сервер будет постепенно анализировать XML до конечного '>', после чего он отправит элемент <success/> обратно клиенту. Теперь клиент отправит новое начало потока, т. е. <stream:stream ... >, используя уровень безопасности. Это должно привести к нарушению уровня безопасности на стороне сервера, поскольку он будет ожидать, что дополнительный символ LF будет частью уровня безопасности, хотя это не так.

Вы можете сказать, что сервер должен просто очищать свой приемный буфер перед отправкой пакета <success/>, но это неправильный способ обработки потока байтов. В конце концов, базовая подсистема могла задержать доставку этого символа LF, и сервер мог получить его после отправки пакета <success/>.

Решение, конечно же, состоит в том, чтобы клиент НЕ отправлял такие дополнительные данные. Подробнее об этом обсуждении можно прочитать здесь в списке рассылки. .

person Abhinav Singh    schedule 19.08.2012