You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An evil exit Node can add extra garbage ("mud") to the end of an HTTP response in order to cost the originating Node extra money for exit and routing services. It can do this in such a way that the browser does not make the discrepancy obvious to the user (for example, if the garbage is all whitespace).
Any exit Node that does this should be malefactor-banned as soon as the offense is discovered, the route containing that Node removed, and the user notified (since he may lose his application session when the exit Node changes).
Most responses with bodies have Content-Length headers. The Node could compare the actual response length with the Content-Length value to detect malice, but since HTTP is not protected, the exit Node could adjust the Content-Length header to include the garbage.
Responses with bodies but no Content-Length header generally have Transfer-Encoding: chunked headers, and the response body comes in chunks where each chunk has its own length field. Comparing actual length to length fields could be done here as well, but the exit Node could forge valid-looking response-body chunks as well.
Perhaps some heuristic scanning of the response-body data could be done to identify trailing garbage designed not to show up on a browser, but A) this would probably be fairly easy to defeat for an attacker who had the source code, and B) some legitimate response bodies might come with a small amount of whitespace at the ends.
Explore these options and brainstorm a few more, then write a card about how to address Muddy Boots in HTTP. The card may be simply "Don't use naked HTTP;" but if there's a reasonable solution, we'd want to know about it.
The text was updated successfully, but these errors were encountered:
An evil exit Node can add extra garbage ("mud") to the end of an HTTP response in order to cost the originating Node extra money for exit and routing services. It can do this in such a way that the browser does not make the discrepancy obvious to the user (for example, if the garbage is all whitespace).
Any exit Node that does this should be malefactor-banned as soon as the offense is discovered, the route containing that Node removed, and the user notified (since he may lose his application session when the exit Node changes).
Most responses with bodies have
Content-Length
headers. The Node could compare the actual response length with theContent-Length
value to detect malice, but since HTTP is not protected, the exit Node could adjust theContent-Length
header to include the garbage.Responses with bodies but no
Content-Length
header generally haveTransfer-Encoding: chunked
headers, and the response body comes in chunks where each chunk has its own length field. Comparing actual length to length fields could be done here as well, but the exit Node could forge valid-looking response-body chunks as well.Perhaps some heuristic scanning of the response-body data could be done to identify trailing garbage designed not to show up on a browser, but A) this would probably be fairly easy to defeat for an attacker who had the source code, and B) some legitimate response bodies might come with a small amount of whitespace at the ends.
Explore these options and brainstorm a few more, then write a card about how to address Muddy Boots in HTTP. The card may be simply "Don't use naked HTTP;" but if there's a reasonable solution, we'd want to know about it.
The text was updated successfully, but these errors were encountered: