commit 15904a880af765b3febfc80d91440ac29b6d0e9e Author: Nick Mathewson <nickm@torproject.org> Date: Thu Oct 11 10:38:28 2012 -0400 Add mapaddress-tor-status as proposal 211 --- proposals/000-index.txt | 2 + proposals/211-mapaddress-tor-status.txt | 145 +++++++++++++++++++++++++++++++ proposals/xxx-mapaddress-tor-status.txt | 144 ------------------------------ 3 files changed, 147 insertions(+), 144 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 64aea49..2fa2be6 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -132,6 +132,7 @@ Proposals by number: 209 Limit reported bandwidth of unmeasured nodes [OPEN] 209 Tuning the Parameters for the Path Bias Defense [OPEN] 210 Faster Headless Consensus Bootstrapping [OPEN] +211 Internal Mapaddress for Tor Configuration Testing [OPEN] Proposals by status: @@ -180,6 +181,7 @@ Proposals by status: 209 Limit reported bandwidth of unmeasured nodes [for 0.2.4.x] 209 Tuning the Parameters for the Path Bias Defense [for 0.2.4.x+] 210 Faster Headless Consensus Bootstrapping [for 0.2.4.x+] + 211 Internal Mapaddress for Tor Configuration Testing [for 0.2.4.x+] ACCEPTED: 117 IPv6 exits [for 0.2.4.x] 140 Provide diffs between consensuses diff --git a/proposals/211-mapaddress-tor-status.txt b/proposals/211-mapaddress-tor-status.txt new file mode 100644 index 0000000..7cac4b7 --- /dev/null +++ b/proposals/211-mapaddress-tor-status.txt @@ -0,0 +1,145 @@ +Filename: 211-mapaddress-tor-status.txt +Title: Internal Mapaddress for Tor Configuration Testing +Author: Mike Perry +Created: 08-10-2012 +Status: Open +Target: 0.2.4.x+ + + +Overview + + This proposal describes a method by which we can replace the + https://check.torproject.org/ testing service with an internal XML + document provided by the Tor client. + +Motivation + + The Tor Check service is a central point of failure in terms of Tor + usability. If it is ever out of sync with the set of exit nodes on the + Tor network or down, user experience is degraded considerably. Moreover, + the check itself is very time-consuming. Users must wait seconds or more + for the result to come back. Worse still, if the user's software *was* + in fact misconfigured, the check.torproject.org DNS resolution and + request leaks out on to the network. + +Design Overview + + The system will have three parts: an internal hard-coded IP address + mapping (127.84.111.114:80), a hard-coded mapaddress to a DNS name + (selftest.torproject.org:80), and a DirPortFrontPage-style simple + HTTP server that serves an XML document for both addresses. + + Upon receipt of a request to the IP address mapping, the system will + create a new 128 bit randomly generated nonce and provide it + in the XML document. + + Requests to http://selftest.torproject.org/ must include a valid, + recent nonce as the GET url path. Upon receipt of a valid nonce, + it is removed from the list of valid nonces. Nonces are only valid + for 60 seconds or until SIGNAL NEWNYM, which ever comes first. + + The list of pending nonces should not be allowed to grow beyond 10 + entries. + + The timeout period and nonce limit should be configurable in torrc. + +Design: XML document format for http://127.84.111.114 + + To avoid the need to localize the message in Tor, Tor will only provide + a XML object with connectivity information. Here is an example form: + + <tor-test> + <tor-bootstrap-percent>100</tor-bootstrap-percent> + <tor-version-current>true</tor-version-current> + <dns-nonce>4977eb4842c7c59fa5b830ac4da896d9</dns-nonce> + <tor-test/> + + The tor-bootstrap-percent field represents the results of the Tor client + bootstrap status as integer percentages from bootstrap_status_t. + + The tor-version-current field represents the results of the Tor client + consensus version check. If the bootstrap process has not yet + downloaded a consensus document, this field will have the value + null. + + The dns-nonce field contains a 128-bit secret, encoded in base16. This + field is only present for requests that list the Host: header as + 127.84.111.114. + +Design: XML document format for http://selftest.torproject.org/nonce + + <tor-test> + <tor-bootstrap-percent>100</tor-bootstrap-percent> + <tor-version-current>true</tor-version-current> + <dns-nonce-valid>true</dns-nonce-valid> + <tor-test/> + + The first two fields are the same as for the IP address version. + + The dns-nonce-valid field is only true if the Host header matches + selftest.torproject.org and the nonce is current and valid. Upon + receipt of a valid nonce, that nonce is removed from the list of + valid nonces. + +Design: Request Servicing + + Care must be taken with the dns-nonce generation and usage, to prevent + users from being tracked through leakage of nonce value to application + content. While the usage of XML appears to make this impossible + due to stricter same-origin policy enforcement than JSON, same-origin + enforcement is still fraught with exceptions and loopholes. + + In particular: + + Any requests that contain the Origin: header MUST be ignored, + as the Origin: header is only included for third party web content + (CORS). + + dns-nonce fields MUST be omitted if the HTTP Host: header does not + match the IP address 127.84.111.114. + + Requests to selftest.torproject.org MUST return false for the + dns-nonce-valid field if the HTTP Host: header does not match + selftest.torproject.org, regardless of nonce value. + + Further, requests to selftest.torproject.org MUST validate that + 'selftest.torproject.org' was the actual hostname provided to + SOCKS4A, and not some alternate address mapping (due to DNS rebinding + attacks, for example). + +Design: Application Usage + + Applications will use the system in two steps. First, they will make an + HTTP request to http://127.84.111.114:80/ over Tor's SOCKS port and + parse the resulting XML, if any. + + If the request at this stage fails, the application should inform the + user that either their Tor client is too old, or that it is + misconfigured, depending upon the nature of the failure. + + If the request succeeds and valid XML is returned, the application + will record the value of the dns-nonce field, and then perform a second + request to http://selftest.torproject.org/nonce_value. If the second + request succeeds, and the dns-nonce-valid field is true, the application + may inform the user that their Tor settings are valid. + + If the second request fails, or does not provide the correct dns-nonce, + the application will inform the user that their Tor DNS proxy settings + are incorrect. + + If either tor-bootstrap-percent is not 100, or tor-version-current is + false, applications may choose to inform the user of these facts using + properly localized strings and appropriate UI. + +Security Considerations + + XML was chosen over JSON due to the risks of the identifier leaking + in a way that could enable websites to track the user[1]. + + Because there are many exceptions and circumvention techniques + to the same-origin policy, we have also opted for strict controls + on dns-nonce lifetimes and usage, as well as validation of the Host + header and SOCKS4A request hostnames. + + +1. http://www.hpenterprisesecurity.com/vulncat/en/vulncat/dotnet/javascript_hij... diff --git a/proposals/xxx-mapaddress-tor-status.txt b/proposals/xxx-mapaddress-tor-status.txt deleted file mode 100644 index 8475bd0..0000000 --- a/proposals/xxx-mapaddress-tor-status.txt +++ /dev/null @@ -1,144 +0,0 @@ -Title: Internal Mapaddress for Tor Configuration Testing -Author: Mike Perry -Created: 08-10-2012 -Status: Open -Target: 0.2.4.x+ - - -Overview - - This proposal describes a method by which we can replace the - https://check.torproject.org/ testing service with an internal XML - document provided by the Tor client. - -Motivation - - The Tor Check service is a central point of failure in terms of Tor - usability. If it is ever out of sync with the set of exit nodes on the - Tor network or down, user experience is degraded considerably. Moreover, - the check itself is very time-consuming. Users must wait seconds or more - for the result to come back. Worse still, if the user's software *was* - in fact misconfigured, the check.torproject.org DNS resolution and - request leaks out on to the network. - -Design Overview - - The system will have three parts: an internal hard-coded IP address - mapping (127.84.111.114:80), a hard-coded mapaddress to a DNS name - (selftest.torproject.org:80), and a DirPortFrontPage-style simple - HTTP server that serves an XML document for both addresses. - - Upon receipt of a request to the IP address mapping, the system will - create a new 128 bit randomly generated nonce and provide it - in the XML document. - - Requests to http://selftest.torproject.org/ must include a valid, - recent nonce as the GET url path. Upon receipt of a valid nonce, - it is removed from the list of valid nonces. Nonces are only valid - for 60 seconds or until SIGNAL NEWNYM, which ever comes first. - - The list of pending nonces should not be allowed to grow beyond 10 - entries. - - The timeout period and nonce limit should be configurable in torrc. - -Design: XML document format for http://127.84.111.114 - - To avoid the need to localize the message in Tor, Tor will only provide - a XML object with connectivity information. Here is an example form: - - <tor-test> - <tor-bootstrap-percent>100</tor-bootstrap-percent> - <tor-version-current>true</tor-version-current> - <dns-nonce>4977eb4842c7c59fa5b830ac4da896d9</dns-nonce> - <tor-test/> - - The tor-bootstrap-percent field represents the results of the Tor client - bootstrap status as integer percentages from bootstrap_status_t. - - The tor-version-current field represents the results of the Tor client - consensus version check. If the bootstrap process has not yet - downloaded a consensus document, this field will have the value - null. - - The dns-nonce field contains a 128-bit secret, encoded in base16. This - field is only present for requests that list the Host: header as - 127.84.111.114. - -Design: XML document format for http://selftest.torproject.org/nonce - - <tor-test> - <tor-bootstrap-percent>100</tor-bootstrap-percent> - <tor-version-current>true</tor-version-current> - <dns-nonce-valid>true</dns-nonce-valid> - <tor-test/> - - The first two fields are the same as for the IP address version. - - The dns-nonce-valid field is only true if the Host header matches - selftest.torproject.org and the nonce is current and valid. Upon - receipt of a valid nonce, that nonce is removed from the list of - valid nonces. - -Design: Request Servicing - - Care must be taken with the dns-nonce generation and usage, to prevent - users from being tracked through leakage of nonce value to application - content. While the usage of XML appears to make this impossible - due to stricter same-origin policy enforcement than JSON, same-origin - enforcement is still fraught with exceptions and loopholes. - - In particular: - - Any requests that contain the Origin: header MUST be ignored, - as the Origin: header is only included for third party web content - (CORS). - - dns-nonce fields MUST be omitted if the HTTP Host: header does not - match the IP address 127.84.111.114. - - Requests to selftest.torproject.org MUST return false for the - dns-nonce-valid field if the HTTP Host: header does not match - selftest.torproject.org, regardless of nonce value. - - Further, requests to selftest.torproject.org MUST validate that - 'selftest.torproject.org' was the actual hostname provided to - SOCKS4A, and not some alternate address mapping (due to DNS rebinding - attacks, for example). - -Design: Application Usage - - Applications will use the system in two steps. First, they will make an - HTTP request to http://127.84.111.114:80/ over Tor's SOCKS port and - parse the resulting XML, if any. - - If the request at this stage fails, the application should inform the - user that either their Tor client is too old, or that it is - misconfigured, depending upon the nature of the failure. - - If the request succeeds and valid XML is returned, the application - will record the value of the dns-nonce field, and then perform a second - request to http://selftest.torproject.org/nonce_value. If the second - request succeeds, and the dns-nonce-valid field is true, the application - may inform the user that their Tor settings are valid. - - If the second request fails, or does not provide the correct dns-nonce, - the application will inform the user that their Tor DNS proxy settings - are incorrect. - - If either tor-bootstrap-percent is not 100, or tor-version-current is - false, applications may choose to inform the user of these facts using - properly localized strings and appropriate UI. - -Security Considerations - - XML was chosen over JSON due to the risks of the identifier leaking - in a way that could enable websites to track the user[1]. - - Because there are many exceptions and circumvention techniques - to the same-origin policy, we have also opted for strict controls - on dns-nonce lifetimes and usage, as well as validation of the Host - header and SOCKS4A request hostnames. - - -1. http://www.hpenterprisesecurity.com/vulncat/en/vulncat/dotnet/javascript_hij...