diff options
| author | Rasmus Dahlberg <rasmus@rgdd.se> | 2024-10-15 16:08:16 +0200 |
|---|---|---|
| committer | Rasmus Dahlberg <rasmus@rgdd.se> | 2024-10-15 16:08:16 +0200 |
| commit | 385cc92bc91e1a6c3724085c060e76bf40c13ed3 (patch) | |
| tree | 26d0a8f81f2caa472830fd40a51844bb202c1355 /summary/src/tlwo | |
Import PhD thesis
Diffstat (limited to 'summary/src/tlwo')
37 files changed, 2904 insertions, 0 deletions
diff --git a/summary/src/tlwo/.gitignore b/summary/src/tlwo/.gitignore new file mode 100644 index 0000000..8bb88c8 --- /dev/null +++ b/summary/src/tlwo/.gitignore @@ -0,0 +1,9 @@ +main.pdf +*.blg +*.bbl +*.fls +*.fdb_latexmk +*.log +*.out +*.aux +*.swp diff --git a/summary/src/tlwo/img/.gitkeep b/summary/src/tlwo/img/.gitkeep new file mode 100644 index 0000000..8b13789 --- /dev/null +++ b/summary/src/tlwo/img/.gitkeep @@ -0,0 +1 @@ + diff --git a/summary/src/tlwo/img/attack.pdf b/summary/src/tlwo/img/attack.pdf Binary files differnew file mode 100644 index 0000000..c99c22c --- /dev/null +++ b/summary/src/tlwo/img/attack.pdf diff --git a/summary/src/tlwo/img/cached.pdf b/summary/src/tlwo/img/cached.pdf Binary files differnew file mode 100644 index 0000000..c0a4524 --- /dev/null +++ b/summary/src/tlwo/img/cached.pdf diff --git a/summary/src/tlwo/img/plot_cache_entries-permissive.pdf b/summary/src/tlwo/img/plot_cache_entries-permissive.pdf Binary files differnew file mode 100644 index 0000000..2016a3f --- /dev/null +++ b/summary/src/tlwo/img/plot_cache_entries-permissive.pdf diff --git a/summary/src/tlwo/img/plot_cache_entries-web.pdf b/summary/src/tlwo/img/plot_cache_entries-web.pdf Binary files differnew file mode 100644 index 0000000..1373ed0 --- /dev/null +++ b/summary/src/tlwo/img/plot_cache_entries-web.pdf diff --git a/summary/src/tlwo/img/plot_cache_hits-permissive.pdf b/summary/src/tlwo/img/plot_cache_hits-permissive.pdf Binary files differnew file mode 100644 index 0000000..6a92fe9 --- /dev/null +++ b/summary/src/tlwo/img/plot_cache_hits-permissive.pdf diff --git a/summary/src/tlwo/img/plot_cache_hits-web.pdf b/summary/src/tlwo/img/plot_cache_hits-web.pdf Binary files differnew file mode 100644 index 0000000..f56588b --- /dev/null +++ b/summary/src/tlwo/img/plot_cache_hits-web.pdf diff --git a/summary/src/tlwo/img/plot_lookups-permissive.pdf b/summary/src/tlwo/img/plot_lookups-permissive.pdf Binary files differnew file mode 100644 index 0000000..172046d --- /dev/null +++ b/summary/src/tlwo/img/plot_lookups-permissive.pdf diff --git a/summary/src/tlwo/img/plot_lookups-web.pdf b/summary/src/tlwo/img/plot_lookups-web.pdf Binary files differnew file mode 100644 index 0000000..8936b14 --- /dev/null +++ b/summary/src/tlwo/img/plot_lookups-web.pdf diff --git a/summary/src/tlwo/img/plot_popularity_match-permissive.pdf b/summary/src/tlwo/img/plot_popularity_match-permissive.pdf Binary files differnew file mode 100644 index 0000000..ccd2d4c --- /dev/null +++ b/summary/src/tlwo/img/plot_popularity_match-permissive.pdf diff --git a/summary/src/tlwo/img/plot_popularity_match-web.pdf b/summary/src/tlwo/img/plot_popularity_match-web.pdf Binary files differnew file mode 100644 index 0000000..fc49a4b --- /dev/null +++ b/summary/src/tlwo/img/plot_popularity_match-web.pdf diff --git a/summary/src/tlwo/img/plot_preload_entries-permissive.pdf b/summary/src/tlwo/img/plot_preload_entries-permissive.pdf Binary files differnew file mode 100644 index 0000000..a08e43a --- /dev/null +++ b/summary/src/tlwo/img/plot_preload_entries-permissive.pdf diff --git a/summary/src/tlwo/img/plot_preload_entries-web.pdf b/summary/src/tlwo/img/plot_preload_entries-web.pdf Binary files differnew file mode 100644 index 0000000..e3f3ebf --- /dev/null +++ b/summary/src/tlwo/img/plot_preload_entries-web.pdf diff --git a/summary/src/tlwo/img/plot_preload_hits-permissive.pdf b/summary/src/tlwo/img/plot_preload_hits-permissive.pdf Binary files differnew file mode 100644 index 0000000..1f6cacc --- /dev/null +++ b/summary/src/tlwo/img/plot_preload_hits-permissive.pdf diff --git a/summary/src/tlwo/img/plot_preload_hits-web.pdf b/summary/src/tlwo/img/plot_preload_hits-web.pdf Binary files differnew file mode 100644 index 0000000..ce38004 --- /dev/null +++ b/summary/src/tlwo/img/plot_preload_hits-web.pdf diff --git a/summary/src/tlwo/img/plot_preload_lists-permissive.pdf b/summary/src/tlwo/img/plot_preload_lists-permissive.pdf Binary files differnew file mode 100644 index 0000000..9c79a77 --- /dev/null +++ b/summary/src/tlwo/img/plot_preload_lists-permissive.pdf diff --git a/summary/src/tlwo/img/plot_preload_lists-web.pdf b/summary/src/tlwo/img/plot_preload_lists-web.pdf Binary files differnew file mode 100644 index 0000000..a864f65 --- /dev/null +++ b/summary/src/tlwo/img/plot_preload_lists-web.pdf diff --git a/summary/src/tlwo/img/preload.pdf b/summary/src/tlwo/img/preload.pdf Binary files differnew file mode 100644 index 0000000..9f06a14 --- /dev/null +++ b/summary/src/tlwo/img/preload.pdf diff --git a/summary/src/tlwo/img/preload.svg b/summary/src/tlwo/img/preload.svg new file mode 100644 index 0000000..e507b66 --- /dev/null +++ b/summary/src/tlwo/img/preload.svg @@ -0,0 +1,1009 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> + +<svg + width="284.57263mm" + height="251.33842mm" + viewBox="0 0 284.57263 251.33843" + version="1.1" + id="svg5" + inkscape:version="1.1.2 (0a00cf5339, 2022-02-04)" + sodipodi:docname="preload.svg" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:xlink="http://www.w3.org/1999/xlink" + xmlns="http://www.w3.org/2000/svg" + xmlns:svg="http://www.w3.org/2000/svg"> + <sodipodi:namedview + id="namedview7" + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1.0" + inkscape:pageshadow="2" + inkscape:pageopacity="0.0" + inkscape:pagecheckerboard="0" + inkscape:document-units="mm" + showgrid="false" + inkscape:zoom="0.58081186" + inkscape:cx="445.06667" + inkscape:cy="513.93579" + inkscape:window-width="1870" + inkscape:window-height="1000" + inkscape:window-x="20" + inkscape:window-y="50" + inkscape:window-maximized="1" + inkscape:current-layer="layer1" + inkscape:showpageshadow="2" + inkscape:deskcolor="#d1d1d1" /> + <defs + id="defs2"> + <marker + style="overflow:visible" + id="Arrow1Lstart" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow1Lstart" + inkscape:isstock="true"> + <path + transform="matrix(0.8,0,0,0.8,10,0)" + style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + id="path20233" /> + </marker> + <marker + style="overflow:visible" + id="Arrow1Lend" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow1Lend" + inkscape:isstock="true"> + <path + transform="matrix(-0.8,0,0,-0.8,-10,0)" + style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + id="path20236" /> + </marker> + <marker + style="overflow:visible" + id="EmptyTriangleOutL" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="EmptyTriangleOutL" + inkscape:isstock="true"> + <path + transform="matrix(0.8,0,0,0.8,-4.8,0)" + style="fill:context-fill;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt" + d="M 5.77,0 -2.88,5 V -5 Z" + id="path20393" /> + </marker> + <clipPath + id="clipPath4258" + clipPathUnits="userSpaceOnUse"> + <path + id="path4260" + d="M 0,11.34 H 11.34 V 0 H 0 Z" /> + </clipPath> + <clipPath + id="clipPath4258-3" + clipPathUnits="userSpaceOnUse"> + <path + id="path4260-6" + d="M 0,11.34 H 11.34 V 0 H 0 Z" /> + </clipPath> + <clipPath + id="clipPath4258-7" + clipPathUnits="userSpaceOnUse"> + <path + id="path4260-0" + d="M 0,11.34 H 11.34 V 0 H 0 Z" /> + </clipPath> + <marker + style="overflow:visible" + id="Arrow1Lstart-3" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow1Lstart" + inkscape:isstock="true"> + <path + transform="matrix(0.8,0,0,0.8,10,0)" + style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + id="path20233-6" /> + </marker> + <marker + style="overflow:visible" + id="Arrow1Lend-1" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow1Lend" + inkscape:isstock="true"> + <path + transform="matrix(-0.8,0,0,-0.8,-10,0)" + style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + id="path20236-0" /> + </marker> + <clipPath + id="clipPath4258-0" + clipPathUnits="userSpaceOnUse"> + <path + id="path4260-61" + d="M 0,11.34 H 11.34 V 0 H 0 Z" /> + </clipPath> + <symbol + id="AuxillaryOp"> + <title + id="title18961">Auxiliary Operation</title> + <desc + id="desc18963">Offline operation.</desc> + <rect + x="9.260417" + y="9.260417" + width="21.166666" + height="21.166666" + style="stroke-width:0.529167" + id="rect18965" /> + </symbol> + <symbol + id="Connector"> + <title + id="title19024">Connector</title> + <desc + id="desc19026">Exit to or entry from another part of chart.</desc> + <circle + cx="19.84375" + cy="19.84375" + r="5.2916665" + style="stroke-width:0.529167" + id="circle19028" /> + </symbol> + <marker + style="overflow:visible" + id="Arrow1Lstart-8" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow1Lstart" + inkscape:isstock="true"> + <path + transform="matrix(0.8,0,0,0.8,10,0)" + style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + id="path20233-5" /> + </marker> + <marker + style="overflow:visible" + id="Arrow1Lend-6" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow1Lend" + inkscape:isstock="true"> + <path + transform="matrix(-0.8,0,0,-0.8,-10,0)" + style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + id="path20236-1" /> + </marker> + <filter + inkscape:collect="always" + style="color-interpolation-filters:sRGB" + id="filter350648" + x="-0.10917709" + y="-0.10917709" + width="1.2183542" + height="1.2183542"> + <feGaussianBlur + inkscape:collect="always" + stdDeviation="0.85263812" + id="feGaussianBlur350650" /> + </filter> + <clipPath + id="clipPath4258-9" + clipPathUnits="userSpaceOnUse"> + <path + id="path4260-7" + d="M 0,11.34 H 11.34 V 0 H 0 Z" /> + </clipPath> + <marker + style="overflow:visible" + id="Arrow1Lend-3" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow1Lend" + inkscape:isstock="true"> + <path + transform="matrix(-0.8,0,0,-0.8,-10,0)" + style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + id="path20236-6" /> + </marker> + </defs> + <g + inkscape:label="Layer 1" + inkscape:groupmode="layer" + id="layer1" + transform="translate(-39.016081,-39.231054)"> + <use + xlink:href="#AuxillaryOp" + style="fill:#800080;stroke:#59316b;stroke-width:0.0822417;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;filter:url(#filter350648)" + id="use132437" + x="0" + y="0" + width="100%" + height="100%" + transform="matrix(6.4761141,0,0,4.2447218,50.339004,138.18261)" /> + <use + xlink:href="#AuxillaryOp" + style="fill:#ffffff;stroke:#000000" + id="use265468" + x="0" + y="0" + width="100%" + height="100%" + transform="matrix(1.3391931,0,0,0.9961219,170.10623,195.62004)" /> + <text + xml:space="preserve" + style="font-size:7.76111px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="120.89084" + y="279.25372" + id="text39324-8-9"><tspan + sodipodi:role="line" + style="font-size:7.76111px;stroke-width:0.264583" + x="120.89084" + y="279.25372" + id="tspan193052"><tspan + style="font-weight:bold" + id="tspan161473-6">Phase 3</tspan> - periodically resolve</tspan><tspan + sodipodi:role="line" + style="font-size:7.76111px;stroke-width:0.264583" + x="120.89084" + y="288.95511" + id="tspan191514">all domains in allowlist locally</tspan></text> + <text + xml:space="preserve" + style="font-size:7.76111px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="204.31744" + y="151.77661" + id="text39324-8"><tspan + sodipodi:role="line" + style="font-size:7.76111px;stroke-width:0.264583" + x="204.31744" + y="151.77661" + id="tspan123782"><tspan + style="font-weight:bold" + id="tspan161473">Phase 2</tspan> - compile allowlist</tspan><tspan + sodipodi:role="line" + style="font-size:7.76111px;stroke-width:0.264583" + x="204.31744" + y="161.478" + id="tspan28648">with unqiue domain names</tspan></text> + <g + id="g42075" + transform="translate(0,-4.7923209)"> + <image + preserveAspectRatio="none" + inkscape:svg-dpi="96" + width="31.920643" + height="41.946896" + xlink:href="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIj8+CjxzdmcKICAgIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5v cmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyIKICAgIHhtbG5zPSJodHRwOi8vd3d3LnczLm9y Zy8yMDAwL3N2ZyIKICAgIHhtbG5zOmNjPSJodHRwOi8vd2ViLnJlc291cmNlLm9yZy9jYy8iCiAg ICB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIKICAgIHhtbG5zOmRj PSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyIKICAgIHhtbG5zOnN2Zz0iaHR0cDov L3d3dy53My5vcmcvMjAwMC9zdmciCiAgICB4bWxuczppbmtzY2FwZT0iaHR0cDovL3d3dy5pbmtz Y2FwZS5vcmcvbmFtZXNwYWNlcy9pbmtzY2FwZSIKICAgIHhtbG5zOnNvZGlwb2RpPSJodHRwOi8v c29kaXBvZGkuc291cmNlZm9yZ2UubmV0L0RURC9zb2RpcG9kaS0wLmR0ZCIKICAgIHhtbG5zOm5z MT0iaHR0cDovL3NvemkuYmFpZXJvdWdlLmZyIgogICAgYmFzZVByb2ZpbGU9ImZ1bGwiCiAgICB2 ZXJzaW9uPSIxLjEiCiAgICB2aWV3Qm94PSIwIDAgMzUwIDUwMCIKICA+CiAgPGRlZnMKICAgID4K ICAgIDxwYXRoCiAgICAgICAgaWQ9ImNvZyIKICAgICAgICB0cmFuc2Zvcm09InNjYWxlKC40KSIK ICAgICAgICBmaWxsPSJkYXJrcmVkIgogICAgICAgIGQ9Im0yMTMgMGwtNCAzOS01IDM5LTIwIDkt MjAgOS0zMi0yNi0zMS0yNS0yNyAyNy0yNyAyNyAyNSAzMSAyNSAzMi05IDE5LTkgMTktMzUgNWMt MjAgMy0zNyA1LTQwIDZzLTQgMTItNCAzOXYzN2wzOSA0YzI0IDMgNDAgNiA0MCA4czMgMTIgOCAy MWw4IDE4LTI1IDMwLTI1IDMxIDI3IDI3IDI3IDI3IDMwLTIzIDMwLTI0IDE4IDljMTAgNSAyMCAx MCAyMiAxMCAxIDEgNCAxNiA3IDM0IDIgMTggNCAzNCA1IDM3czExIDQgMzggNGgzOGw0LTM2YzMt MjggNS0zNyAxMC0zOCAzLTEgMTMtNSAyMy0xMGwxNy04IDI5IDI0IDMwIDIzIDI2LTI3YzIwLTIw IDI2LTI4IDI0LTMxcy0xMy0xNi0yMy0yOWwtMjAtMjUgOS0xOGM1LTEwIDgtMjAgOC0yMiAwLTQg OC02IDUyLTExbDIyLTMgMS0zOCAxLTM4LTM4LTRjLTIzLTMtMzgtNi0zOC04cy0zLTEyLTgtMjJs LTktMTkgMjQtMjkgMjQtMzAtMjctMjctMjctMjctMzAgMjQtMzAgMjQtMjEtOS0yMS05LTUtMzct NS0zOC0zOC0xLTM4LTF6bTM3IDE3MGM0NCAwIDgwIDM2IDgwIDgwcy0zNiA4MC04MCA4MC04MC0z Ni04MC04MCAzNi04MCA4MC04MHoiCiAgICAvPgogIDwvZGVmcwogID4KICA8dXNlCiAgICAgIG9w YWNpdHk9Ii4zIgogICAgICB4bGluazpocmVmPSIjY29nIgogIC8+CiAgPHVzZQogICAgICBvcGFj aXR5PSIuNiIKICAgICAgeGxpbms6aHJlZj0iI2NvZyIKICAgICAgdHJhbnNmb3JtPSJ0cmFuc2xh dGUoMTIwLDEyMCkgcm90YXRlKDIyLjUgMTAwLDEwMCkiCiAgLz4KICA8dXNlCiAgICAgIHhsaW5r OmhyZWY9IiNjb2ciCiAgICAgIHRyYW5zZm9ybT0idHJhbnNsYXRlKDAsMjQwKSIKICAvPgogIDxt ZXRhZGF0YQogICAgPgogICAgPHJkZjpSREYKICAgICAgPgogICAgICA8Y2M6V29yawogICAgICAg ID4KICAgICAgICA8ZGM6Zm9ybWF0CiAgICAgICAgICA+aW1hZ2Uvc3ZnK3htbDwvZGM6Zm9ybWF0 CiAgICAgICAgPgogICAgICAgIDxkYzp0eXBlCiAgICAgICAgICAgIHJkZjpyZXNvdXJjZT0iaHR0 cDovL3B1cmwub3JnL2RjL2RjbWl0eXBlL1N0aWxsSW1hZ2UiCiAgICAgICAgLz4KICAgICAgICA8 Y2M6bGljZW5zZQogICAgICAgICAgICByZGY6cmVzb3VyY2U9Imh0dHA6Ly9jcmVhdGl2ZWNvbW1v bnMub3JnL2xpY2Vuc2VzL3B1YmxpY2RvbWFpbi8iCiAgICAgICAgLz4KICAgICAgICA8ZGM6cHVi bGlzaGVyCiAgICAgICAgICA+CiAgICAgICAgICA8Y2M6QWdlbnQKICAgICAgICAgICAgICByZGY6 YWJvdXQ9Imh0dHA6Ly9vcGVuY2xpcGFydC5vcmcvIgogICAgICAgICAgICA+CiAgICAgICAgICAg IDxkYzp0aXRsZQogICAgICAgICAgICAgID5PcGVuY2xpcGFydDwvZGM6dGl0bGUKICAgICAgICAg ICAgPgogICAgICAgICAgPC9jYzpBZ2VudAogICAgICAgICAgPgogICAgICAgIDwvZGM6cHVibGlz aGVyCiAgICAgICAgPgogICAgICAgIDxkYzp0aXRsZQogICAgICAgICAgPlBpbmsgY29nd2hlZWxz PC9kYzp0aXRsZQogICAgICAgID4KICAgICAgICA8ZGM6ZGF0ZQogICAgICAgICAgPjIwMTMtMDkt MTRUMTY6MDA6NDE8L2RjOmRhdGUKICAgICAgICA+CiAgICAgICAgPGRjOmRlc2NyaXB0aW9uCiAg ICAgICAgICA+U29tZSBjb2d3aGVlbHMgZnJvbSBodHRwczovL2NvbW1vbnMud2lraW1lZGlhLm9y Zy93aWtpL0ZpbGU6Q29nLXNjcmlwdGVkLXN2Zy5zdmc8L2RjOmRlc2NyaXB0aW9uCiAgICAgICAg PgogICAgICAgIDxkYzpzb3VyY2UKICAgICAgICAgID5odHRwczovL29wZW5jbGlwYXJ0Lm9yZy9k ZXRhaWwvMTgzNDM2L3BpbmstY29nd2hlZWxzLWJ5LWxpZnRhcm4tMTgzNDM2PC9kYzpzb3VyY2UK ICAgICAgICA+CiAgICAgICAgPGRjOmNyZWF0b3IKICAgICAgICAgID4KICAgICAgICAgIDxjYzpB Z2VudAogICAgICAgICAgICA+CiAgICAgICAgICAgIDxkYzp0aXRsZQogICAgICAgICAgICAgID5s aWZ0YXJuPC9kYzp0aXRsZQogICAgICAgICAgICA+CiAgICAgICAgICA8L2NjOkFnZW50CiAgICAg ICAgICA+CiAgICAgICAgPC9kYzpjcmVhdG9yCiAgICAgICAgPgogICAgICAgIDxkYzpzdWJqZWN0 CiAgICAgICAgICA+CiAgICAgICAgICA8cmRmOkJhZwogICAgICAgICAgICA+CiAgICAgICAgICAg IDxyZGY6bGkKICAgICAgICAgICAgICA+Y29nPC9yZGY6bGkKICAgICAgICAgICAgPgogICAgICAg ICAgICA8cmRmOmxpCiAgICAgICAgICAgICAgPmNvZ3doZWVsPC9yZGY6bGkKICAgICAgICAgICAg PgogICAgICAgICAgICA8cmRmOmxpCiAgICAgICAgICAgICAgPmNvZ3doZWVsczwvcmRmOmxpCiAg ICAgICAgICAgID4KICAgICAgICAgICAgPHJkZjpsaQogICAgICAgICAgICAgID5nZWFyPC9yZGY6 bGkKICAgICAgICAgICAgPgogICAgICAgICAgICA8cmRmOmxpCiAgICAgICAgICAgICAgPmdlYXJz PC9yZGY6bGkKICAgICAgICAgICAgPgogICAgICAgICAgICA8cmRmOmxpCiAgICAgICAgICAgICAg PnBpbms8L3JkZjpsaQogICAgICAgICAgICA+CiAgICAgICAgICAgIDxyZGY6bGkKICAgICAgICAg ICAgICA+cmVkPC9yZGY6bGkKICAgICAgICAgICAgPgogICAgICAgICAgPC9yZGY6QmFnCiAgICAg ICAgICA+CiAgICAgICAgPC9kYzpzdWJqZWN0CiAgICAgICAgPgogICAgICA8L2NjOldvcmsKICAg ICAgPgogICAgICA8Y2M6TGljZW5zZQogICAgICAgICAgcmRmOmFib3V0PSJodHRwOi8vY3JlYXRp dmVjb21tb25zLm9yZy9saWNlbnNlcy9wdWJsaWNkb21haW4vIgogICAgICAgID4KICAgICAgICA8 Y2M6cGVybWl0cwogICAgICAgICAgICByZGY6cmVzb3VyY2U9Imh0dHA6Ly9jcmVhdGl2ZWNvbW1v bnMub3JnL25zI1JlcHJvZHVjdGlvbiIKICAgICAgICAvPgogICAgICAgIDxjYzpwZXJtaXRzCiAg ICAgICAgICAgIHJkZjpyZXNvdXJjZT0iaHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbnMjRGlz dHJpYnV0aW9uIgogICAgICAgIC8+CiAgICAgICAgPGNjOnBlcm1pdHMKICAgICAgICAgICAgcmRm OnJlc291cmNlPSJodHRwOi8vY3JlYXRpdmVjb21tb25zLm9yZy9ucyNEZXJpdmF0aXZlV29ya3Mi CiAgICAgICAgLz4KICAgICAgPC9jYzpMaWNlbnNlCiAgICAgID4KICAgIDwvcmRmOlJERgogICAg PgogIDwvbWV0YWRhdGEKICA+Cjwvc3ZnCj4K " + id="image746-2" + x="212.19563" + y="87.908249" /> + <g + id="g42049" + transform="translate(-12.160676,6.5898579)"> + <image + preserveAspectRatio="none" + inkscape:svg-dpi="96" + width="45.069122" + height="49.637085" + xlink:href="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+Cjwh LS0gQ3JlYXRlZCB3aXRoIElua3NjYXBlIChodHRwOi8vd3d3Lmlua3NjYXBlLm9yZy8pIC0tPgo8 c3ZnIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5z IyIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxuczpjYz0iaHR0cDovL2Ny ZWF0aXZlY29tbW9ucy5vcmcvbnMjIiB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1l bnRzLzEuMS8iIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOmlu a3NjYXBlPSJodHRwOi8vd3d3Lmlua3NjYXBlLm9yZy9uYW1lc3BhY2VzL2lua3NjYXBlIiB4bWxu czpzb2RpcG9kaT0iaHR0cDovL3NvZGlwb2RpLnNvdXJjZWZvcmdlLm5ldC9EVEQvc29kaXBvZGkt MC5kdGQiIHhtbG5zOm5zMT0iaHR0cDovL3NvemkuYmFpZXJvdWdlLmZyIiB4bWxuczp4bGluaz0i aHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgaWQ9InN2ZzM2MDkiIHZpZXdCb3g9IjAgMCAx NzAuMzQgMjI1LjIzIiB2ZXJzaW9uPSIxLjEiIGlua3NjYXBlOnZlcnNpb249IjAuOTEgcjEzNzI1 Ij4KICA8dGl0bGUgaWQ9InRpdGxlMzYzMCI+RG9jdW1lbnQ8L3RpdGxlPgogIDxnIGlkPSJsYXll cjEiIHRyYW5zZm9ybT0idHJhbnNsYXRlKC0yMTQuODMgLTQyMi42KSI+CiAgICA8ZyBpZD0iZzU1 MDgiIHRyYW5zZm9ybT0ibWF0cml4KC43NTI0OSAwIDAgLjc0MDI4IC0yMDUuMzkgNTI5LjgxKSI+ CiAgICAgIDxwYXRoIGlkPSJyZWN0NTQ5OCIgc3R5bGU9InN0cm9rZTojMDAwMDAwO3N0cm9rZS13 aWR0aDoxMy4zOTg7ZmlsbDpub25lIiBkPSJtNTY1LjEyLTEzOC4xMnYyOTAuODhoMjEyLjc1di0y MjAuMDlsLTEzMi42OS03MC43ODFoLTgwLjA2MnoiLz4KICAgICAgPHBhdGggaWQ9InJlY3Q1NTAw IiBzdHlsZT0iZmlsbDojYzhiN2I3IiBkPSJtNzMzLjUyLTAuMTUyMTEgMzguMDc4LTUyLjQwMy0x MzIuNTUtNzUuMTU5IDg5LjU0OCAxMjEuMjYgNC45MjM0IDYuMzAyNHoiLz4KICAgICAgPHBhdGgg aWQ9InBhdGg1NTAzIiBzdHlsZT0ic3Ryb2tlLWxpbmVqb2luOnJvdW5kO3N0cm9rZTojMDAwMDAw O3N0cm9rZS1saW5lY2FwOnJvdW5kO3N0cm9rZS13aWR0aDoxMy4zOTg7ZmlsbDojZmZmZmZmIiBk PSJtNzQ2LjM1LTM4LjY5MiAzMS43Ny0zOC41OTktMTI5LjI1LTU3LjkyNyA5Ny40ODMgOTYuNTI2 eiIvPgogICAgPC9nPgogIDwvZz4KICA8bWV0YWRhdGE+CiAgICA8cmRmOlJERj4KICAgICAgPGNj Oldvcms+CiAgICAgICAgPGRjOmZvcm1hdD5pbWFnZS9zdmcreG1sPC9kYzpmb3JtYXQ+CiAgICAg ICAgPGRjOnR5cGUgcmRmOnJlc291cmNlPSJodHRwOi8vcHVybC5vcmcvZGMvZGNtaXR5cGUvU3Rp bGxJbWFnZSIvPgogICAgICAgIDxjYzpsaWNlbnNlIHJkZjpyZXNvdXJjZT0iaHR0cDovL2NyZWF0 aXZlY29tbW9ucy5vcmcvbGljZW5zZXMvcHVibGljZG9tYWluLyIvPgogICAgICAgIDxkYzpwdWJs aXNoZXI+CiAgICAgICAgICA8Y2M6QWdlbnQgcmRmOmFib3V0PSJodHRwOi8vb3BlbmNsaXBhcnQu b3JnLyI+CiAgICAgICAgICAgIDxkYzp0aXRsZT5PcGVuY2xpcGFydDwvZGM6dGl0bGU+CiAgICAg ICAgICA8L2NjOkFnZW50PgogICAgICAgIDwvZGM6cHVibGlzaGVyPgogICAgICAgIDxkYzp0aXRs ZT5Eb2N1bWVudDwvZGM6dGl0bGU+CiAgICAgICAgPGRjOmRhdGU+MjAxMi0wNC0wOFQwNjo1MDoz MzwvZGM6ZGF0ZT4KICAgICAgICA8ZGM6ZGVzY3JpcHRpb24+QSBkb2N1bWVudCBpY29uIGZyb20g dGhlIGZhY2lsaXRhdGlvbiBzZXQuPC9kYzpkZXNjcmlwdGlvbj4KICAgICAgICA8ZGM6c291cmNl Pmh0dHBzOi8vb3BlbmNsaXBhcnQub3JnL2RldGFpbC8xNjk0MTYvZG9jdW1lbnQtYnktYml0dGVy anVnPC9kYzpzb3VyY2U+CiAgICAgICAgPGRjOmNyZWF0b3I+CiAgICAgICAgICA8Y2M6QWdlbnQ+ CiAgICAgICAgICAgIDxkYzp0aXRsZT5iaXR0ZXJqdWc8L2RjOnRpdGxlPgogICAgICAgICAgPC9j YzpBZ2VudD4KICAgICAgICA8L2RjOmNyZWF0b3I+CiAgICAgICAgPGRjOnN1YmplY3Q+CiAgICAg ICAgICA8cmRmOkJhZz4KICAgICAgICAgICAgPHJkZjpsaT5Eb2N1bWVudDwvcmRmOmxpPgogICAg ICAgICAgICA8cmRmOmxpPmFic3RyYWN0PC9yZGY6bGk+CiAgICAgICAgICAgIDxyZGY6bGk+Y29y bmVyPC9yZGY6bGk+CiAgICAgICAgICAgIDxyZGY6bGk+Zm9sZDwvcmRmOmxpPgogICAgICAgICAg ICA8cmRmOmxpPnBhcGVyPC9yZGY6bGk+CiAgICAgICAgICA8L3JkZjpCYWc+CiAgICAgICAgPC9k YzpzdWJqZWN0PgogICAgICA8L2NjOldvcms+CiAgICAgIDxjYzpMaWNlbnNlIHJkZjphYm91dD0i aHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbGljZW5zZXMvcHVibGljZG9tYWluLyI+CiAgICAg ICAgPGNjOnBlcm1pdHMgcmRmOnJlc291cmNlPSJodHRwOi8vY3JlYXRpdmVjb21tb25zLm9yZy9u cyNSZXByb2R1Y3Rpb24iLz4KICAgICAgICA8Y2M6cGVybWl0cyByZGY6cmVzb3VyY2U9Imh0dHA6 Ly9jcmVhdGl2ZWNvbW1vbnMub3JnL25zI0Rpc3RyaWJ1dGlvbiIvPgogICAgICAgIDxjYzpwZXJt aXRzIHJkZjpyZXNvdXJjZT0iaHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbnMjRGVyaXZhdGl2 ZVdvcmtzIi8+CiAgICAgIDwvY2M6TGljZW5zZT4KICAgIDwvcmRmOlJERj4KICA8L21ldGFkYXRh Pgo8L3N2Zz4K " + id="image844-6" + x="258.59555" + y="74.910477" /> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="269.35754" + y="97.615578" + id="text47096-4"><tspan + sodipodi:role="line" + id="tspan47094-3" + style="font-size:6.35px;stroke-width:0.264583" + x="269.35754" + y="97.615578">foo.org</tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="263.29333" + y="105.99963" + id="text47096-2-1"><tspan + sodipodi:role="line" + id="tspan47094-0-4" + style="font-size:6.35px;stroke-width:0.264583" + x="263.29333" + y="105.99963">cdn.foo.org</tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="263.32269" + y="114.00768" + id="text47096-23-9"><tspan + sodipodi:role="line" + style="font-size:6.35px;stroke-width:0.264583" + x="263.32269" + y="114.00768" + id="tspan115821">ads.foo.org</tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="278.09979" + y="117.81873" + id="text118919-0"><tspan + sodipodi:role="line" + style="stroke-width:0.264583" + x="278.09979" + y="117.81873" + id="tspan118921-6">...</tspan></text> + </g> + </g> + <text + xml:space="preserve" + style="font-size:9.87778px;line-height:1.25;font-family:sans-serif;stroke-width:0.384866" + x="150.32043" + y="46.735851" + id="text141573-3"><tspan + sodipodi:role="line" + style="font-weight:bold;font-size:9.87778px;stroke-width:0.384866" + x="150.32043" + y="46.735851" + id="tspan141583-5">central party</tspan></text> + <text + xml:space="preserve" + style="font-size:9.87778px;line-height:1.25;font-family:sans-serif;stroke-width:0.384866" + x="163.69237" + y="172.31128" + id="text141573-3-3"><tspan + sodipodi:role="line" + style="font-weight:bold;font-size:9.87778px;stroke-width:0.384866" + x="163.69237" + y="172.31128" + id="tspan141583-5-5">relay</tspan></text> + <use + xlink:href="#AuxillaryOp" + style="fill:#ffffff;stroke:#000000" + id="use195341" + x="0" + y="0" + width="100%" + height="100%" + transform="matrix(2.7111909,0,0,3.0465015,91.170814,167.07129)" /> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="125.21515" + y="207.75603" + id="text197942"><tspan + sodipodi:role="line" + id="tspan197940" + style="stroke-width:0.264583" + x="125.21515" + y="207.75603">foo.org <IP></tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="124.58415" + y="237.75603" + id="text197942-2"><tspan + sodipodi:role="line" + style="stroke-width:0.264583" + x="124.58415" + y="237.75603" + id="tspan216926">bar.org <IP></tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="123.3081" + y="247.79585" + id="text197942-2-2"><tspan + sodipodi:role="line" + style="stroke-width:0.264583" + x="123.3081" + y="247.79585" + id="tspan216926-2">baz.org <IP></tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="117.81051" + y="217.75603" + id="text197942-0"><tspan + sodipodi:role="line" + id="tspan197940-4" + style="stroke-width:0.264583" + x="117.81051" + y="217.75603">cdn.foo.org <IP></tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="117.7795" + y="227.75603" + id="text197942-0-8"><tspan + sodipodi:role="line" + style="stroke-width:0.264583" + x="117.7795" + y="227.75603" + id="tspan205582">ads.foo.org <IP></tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="132.48187" + y="253.71907" + id="text222454"><tspan + sodipodi:role="line" + style="stroke-width:0.264583" + x="132.48187" + y="253.71907" + id="tspan243464">... </tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="159.98187" + y="253.71907" + id="text242464"><tspan + sodipodi:role="line" + id="tspan242462" + style="stroke-width:0.264583" + x="159.98187" + y="253.71907">...</tspan></text> + <path + style="fill:none;stroke:#000000;stroke-width:0.188829;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow1Lend-3)" + d="M 87.769169,229.39894 H 110.90383" + id="path245597-7" /> + <text + xml:space="preserve" + style="font-size:5.64444px;line-height:1.25;font-family:sans-serif;fill:#e3dbdb;stroke-width:0.264583" + x="146.05469" + y="184.60161" + id="text247911"><tspan + sodipodi:role="line" + id="tspan247909" + style="font-weight:bold;font-size:5.64444px;text-align:center;text-anchor:middle;fill:#e3dbdb;stroke-width:0.264583" + x="146.05469" + y="184.60161">Shared</tspan><tspan + sodipodi:role="line" + style="font-weight:bold;font-size:5.64444px;text-align:center;text-anchor:middle;fill:#e3dbdb;stroke-width:0.264583" + x="146.05469" + y="191.65717" + id="tspan249695">preload cache</tspan></text> + <text + xml:space="preserve" + style="font-size:5.64444px;line-height:1.25;font-family:sans-serif;fill:#e3dbdb;stroke-width:0.264583" + x="212.68121" + y="184.60161" + id="text247911-0"><tspan + sodipodi:role="line" + style="font-weight:bold;font-size:5.64444px;text-align:center;text-anchor:middle;fill:#e3dbdb;stroke-width:0.264583" + x="212.68121" + y="184.60161" + id="tspan249695-1">Per-circuit caches</tspan><tspan + sodipodi:role="line" + style="font-weight:bold;font-size:5.64444px;text-align:center;text-anchor:middle;fill:#e3dbdb;stroke-width:0.264583" + x="212.68121" + y="191.65717" + id="tspan252089">without any sharing</tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;fill:#e3dbdb;stroke-width:0.264583" + x="182.99969" + y="203.61807" + id="text267626"><tspan + sodipodi:role="line" + id="tspan267624" + style="font-size:6.35px;fill:#e3dbdb;stroke-width:0.264583" + x="182.99969" + y="203.61807">Circuit A</tspan></text> + <use + xlink:href="#AuxillaryOp" + style="fill:#ffffff;stroke:#000000" + id="use265468-0" + x="0" + y="0" + width="100%" + height="100%" + transform="matrix(1.3391931,0,0,0.9961219,201.44371,195.62004)" /> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;fill:#e3dbdb;stroke-width:0.264583" + x="214.33716" + y="203.61807" + id="text267626-9"><tspan + sodipodi:role="line" + id="tspan267624-1" + style="font-size:6.35px;fill:#e3dbdb;stroke-width:0.264583" + x="214.33716" + y="203.61807">Circuit B</tspan></text> + <use + xlink:href="#AuxillaryOp" + style="fill:#ffffff;stroke:#000000" + id="use265468-7" + x="0" + y="0" + width="100%" + height="100%" + transform="matrix(1.3391931,0,0,0.9961219,170.10592,219.76682)" /> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;fill:#e3dbdb;stroke-width:0.264583" + x="182.70322" + y="256.8056" + id="text267626-7"><tspan + sodipodi:role="line" + id="tspan267624-11" + style="font-size:6.35px;fill:#e3dbdb;stroke-width:0.264583" + x="182.70322" + y="256.8056">Circuit C</tspan></text> + <use + xlink:href="#AuxillaryOp" + style="fill:#ffffff;stroke:#000000" + id="use265468-0-5" + x="0" + y="0" + width="100%" + height="100%" + transform="matrix(1.3391931,0,0,0.9961219,201.4434,219.76683)" /> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;fill:#e3dbdb;stroke-width:0.264583" + x="214.04068" + y="256.8056" + id="text267626-9-9"><tspan + sodipodi:role="line" + id="tspan267624-1-7" + style="font-size:6.35px;fill:#e3dbdb;stroke-width:0.264583" + x="214.04068" + y="256.8056">Circuit D</tspan></text> + <use + xlink:href="#Connector" + style="fill:#000000;stroke:#000000" + id="use286452" + x="0" + y="0" + width="100%" + height="100%" + transform="translate(260.60151,203.49378)" /> + <use + xlink:href="#Connector" + style="fill:#000000;stroke:#000000" + id="use286485" + x="0" + y="0" + width="100%" + height="100%" + transform="matrix(0.62627983,0,0,0.62627983,287.26915,201.16267)" /> + <use + xlink:href="#Connector" + style="fill:#000000;stroke:#000000" + id="use286514" + x="0" + y="0" + width="100%" + height="100%" + transform="matrix(1.7675124,0,0,1.8148081,267.16148,197.49215)" /> + <use + xlink:href="#Connector" + style="fill:#000000;stroke:#000000" + id="use286543" + x="0" + y="0" + width="100%" + height="100%" + transform="matrix(0.32203591,0,0,0.32203591,285.88929,214.32011)" /> + <use + xlink:href="#Connector" + style="fill:#000000;stroke:#000000" + id="use286572" + x="0" + y="0" + width="100%" + height="100%" + transform="matrix(0.22896026,0,0,0.22896026,271.99081,227.94076)" /> + <use + xlink:href="#Connector" + style="fill:#000000;stroke:#000000" + id="use286601" + x="0" + y="0" + width="100%" + height="100%" + transform="matrix(0.41887097,0,0,0.41887097,276.71473,232.09806)" /> + <use + xlink:href="#Connector" + style="fill:#000000;stroke:#000000" + id="use286630" + x="0" + y="0" + width="100%" + height="100%" + transform="matrix(0.59805015,0,0,0.59805015,308.39824,225.69642)" /> + <use + xlink:href="#Connector" + style="fill:#000000;stroke:#000000" + id="use286659" + x="0" + y="0" + width="100%" + height="100%" + transform="matrix(0.18981869,0,0,0.18981869,312.59608,214.1791)" /> + <use + xlink:href="#Connector" + style="fill:#000000;stroke:#000000" + id="use286688" + x="0" + y="0" + width="100%" + height="100%" + transform="matrix(0.17756172,0,0,0.17756172,314.32185,218.07642)" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 282.84226,224.72766 16.89521,8.22082" + id="path286788" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 282.84226,224.72766 9.24705,-3.97375" + id="path286792" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 318.13979,221.99684 2.58324,15.8614" + id="path286794" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 316.41794,217.92136 -15.95991,-4.4174" + id="path286796" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 276.92327,233.15939 8.19229,7.47513" + id="path286798" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 285.11556,240.63452 -3.56695,-13.33556" + id="path286800" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 301.54124,225.40244 -1.44981,-9.58557" + id="path286915" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 309.50144,235.61937 9.20475,2.17804" + id="path287030" /> + <text + xml:space="preserve" + style="font-size:7.05556px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="277.85809" + y="205.14281" + id="text291742"><tspan + sodipodi:role="line" + id="tspan291740" + style="font-size:7.05556px;text-align:center;text-anchor:middle;stroke-width:0.264583" + x="277.85809" + y="205.14281">DNS</tspan><tspan + sodipodi:role="line" + style="font-size:7.05556px;text-align:center;text-anchor:middle;stroke-width:0.264583" + x="277.85809" + y="213.96225" + id="tspan300714">hierarchy</tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="193.21259" + y="216.56465" + id="text310768"><tspan + sodipodi:role="line" + style="stroke-width:0.264583" + x="193.21259" + y="216.56465" + id="tspan310770">...</tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="224.71259" + y="216.26466" + id="text310768-8"><tspan + sodipodi:role="line" + style="stroke-width:0.264583" + x="224.71259" + y="216.26466" + id="tspan310770-4">...</tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="224.71259" + y="240.26466" + id="text315480"><tspan + sodipodi:role="line" + style="stroke-width:0.264583" + x="224.71259" + y="240.26466" + id="tspan315482">...</tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="193.21259" + y="240.26466" + id="text320216"><tspan + sodipodi:role="line" + id="tspan320214" + style="stroke-width:0.264583" + x="193.21259" + y="240.26466">...</tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="114.83587" + y="53.926041" + id="text86572"><tspan + sodipodi:role="line" + style="text-align:center;text-anchor:middle;stroke-width:0.264583" + x="114.83587" + y="53.926041" + id="tspan86594">Store domains found</tspan><tspan + sodipodi:role="line" + style="text-align:center;text-anchor:middle;stroke-width:0.264583" + x="114.83587" + y="61.863541" + id="tspan12129">while loading foo.org,</tspan><tspan + sodipodi:role="line" + style="text-align:center;text-anchor:middle;stroke-width:0.264583" + x="114.83587" + y="69.801041" + id="tspan12237">bar.org, baz.org, ..., from</tspan><tspan + sodipodi:role="line" + style="text-align:center;text-anchor:middle;stroke-width:0.264583" + x="114.83587" + y="77.738541" + id="tspan262940">several vantage points</tspan><tspan + sodipodi:role="line" + style="text-align:center;text-anchor:middle;stroke-width:0.264583" + x="114.83587" + y="85.676041" + id="tspan12670" /></text> + <text + xml:space="preserve" + style="font-size:7.76111px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="75.484276" + y="151.77661" + id="text141573"><tspan + sodipodi:role="line" + style="font-size:7.76111px;stroke-width:0.264583" + x="75.484276" + y="151.77661" + id="tspan141579"><tspan + style="font-weight:bold" + id="tspan149241">Phase 1</tspan> - visit sites</tspan><tspan + sodipodi:role="line" + style="font-size:7.76111px;stroke-width:0.264583" + x="75.484276" + y="161.478" + id="tspan141583">on a popularity list</tspan></text> + <g + id="g42025" + transform="translate(5.2384051,-10.302621)"> + <image + preserveAspectRatio="none" + inkscape:svg-dpi="96" + width="45.069122" + height="49.637085" + xlink:href="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+Cjwh LS0gQ3JlYXRlZCB3aXRoIElua3NjYXBlIChodHRwOi8vd3d3Lmlua3NjYXBlLm9yZy8pIC0tPgo8 c3ZnIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5z IyIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxuczpjYz0iaHR0cDovL2Ny ZWF0aXZlY29tbW9ucy5vcmcvbnMjIiB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1l bnRzLzEuMS8iIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOmlu a3NjYXBlPSJodHRwOi8vd3d3Lmlua3NjYXBlLm9yZy9uYW1lc3BhY2VzL2lua3NjYXBlIiB4bWxu czpzb2RpcG9kaT0iaHR0cDovL3NvZGlwb2RpLnNvdXJjZWZvcmdlLm5ldC9EVEQvc29kaXBvZGkt MC5kdGQiIHhtbG5zOm5zMT0iaHR0cDovL3NvemkuYmFpZXJvdWdlLmZyIiB4bWxuczp4bGluaz0i aHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgaWQ9InN2ZzM2MDkiIHZpZXdCb3g9IjAgMCAx NzAuMzQgMjI1LjIzIiB2ZXJzaW9uPSIxLjEiIGlua3NjYXBlOnZlcnNpb249IjAuOTEgcjEzNzI1 Ij4KICA8dGl0bGUgaWQ9InRpdGxlMzYzMCI+RG9jdW1lbnQ8L3RpdGxlPgogIDxnIGlkPSJsYXll cjEiIHRyYW5zZm9ybT0idHJhbnNsYXRlKC0yMTQuODMgLTQyMi42KSI+CiAgICA8ZyBpZD0iZzU1 MDgiIHRyYW5zZm9ybT0ibWF0cml4KC43NTI0OSAwIDAgLjc0MDI4IC0yMDUuMzkgNTI5LjgxKSI+ CiAgICAgIDxwYXRoIGlkPSJyZWN0NTQ5OCIgc3R5bGU9InN0cm9rZTojMDAwMDAwO3N0cm9rZS13 aWR0aDoxMy4zOTg7ZmlsbDpub25lIiBkPSJtNTY1LjEyLTEzOC4xMnYyOTAuODhoMjEyLjc1di0y MjAuMDlsLTEzMi42OS03MC43ODFoLTgwLjA2MnoiLz4KICAgICAgPHBhdGggaWQ9InJlY3Q1NTAw IiBzdHlsZT0iZmlsbDojYzhiN2I3IiBkPSJtNzMzLjUyLTAuMTUyMTEgMzguMDc4LTUyLjQwMy0x MzIuNTUtNzUuMTU5IDg5LjU0OCAxMjEuMjYgNC45MjM0IDYuMzAyNHoiLz4KICAgICAgPHBhdGgg aWQ9InBhdGg1NTAzIiBzdHlsZT0ic3Ryb2tlLWxpbmVqb2luOnJvdW5kO3N0cm9rZTojMDAwMDAw O3N0cm9rZS1saW5lY2FwOnJvdW5kO3N0cm9rZS13aWR0aDoxMy4zOTg7ZmlsbDojZmZmZmZmIiBk PSJtNzQ2LjM1LTM4LjY5MiAzMS43Ny0zOC41OTktMTI5LjI1LTU3LjkyNyA5Ny40ODMgOTYuNTI2 eiIvPgogICAgPC9nPgogIDwvZz4KICA8bWV0YWRhdGE+CiAgICA8cmRmOlJERj4KICAgICAgPGNj Oldvcms+CiAgICAgICAgPGRjOmZvcm1hdD5pbWFnZS9zdmcreG1sPC9kYzpmb3JtYXQ+CiAgICAg ICAgPGRjOnR5cGUgcmRmOnJlc291cmNlPSJodHRwOi8vcHVybC5vcmcvZGMvZGNtaXR5cGUvU3Rp bGxJbWFnZSIvPgogICAgICAgIDxjYzpsaWNlbnNlIHJkZjpyZXNvdXJjZT0iaHR0cDovL2NyZWF0 aXZlY29tbW9ucy5vcmcvbGljZW5zZXMvcHVibGljZG9tYWluLyIvPgogICAgICAgIDxkYzpwdWJs aXNoZXI+CiAgICAgICAgICA8Y2M6QWdlbnQgcmRmOmFib3V0PSJodHRwOi8vb3BlbmNsaXBhcnQu b3JnLyI+CiAgICAgICAgICAgIDxkYzp0aXRsZT5PcGVuY2xpcGFydDwvZGM6dGl0bGU+CiAgICAg ICAgICA8L2NjOkFnZW50PgogICAgICAgIDwvZGM6cHVibGlzaGVyPgogICAgICAgIDxkYzp0aXRs ZT5Eb2N1bWVudDwvZGM6dGl0bGU+CiAgICAgICAgPGRjOmRhdGU+MjAxMi0wNC0wOFQwNjo1MDoz MzwvZGM6ZGF0ZT4KICAgICAgICA8ZGM6ZGVzY3JpcHRpb24+QSBkb2N1bWVudCBpY29uIGZyb20g dGhlIGZhY2lsaXRhdGlvbiBzZXQuPC9kYzpkZXNjcmlwdGlvbj4KICAgICAgICA8ZGM6c291cmNl Pmh0dHBzOi8vb3BlbmNsaXBhcnQub3JnL2RldGFpbC8xNjk0MTYvZG9jdW1lbnQtYnktYml0dGVy anVnPC9kYzpzb3VyY2U+CiAgICAgICAgPGRjOmNyZWF0b3I+CiAgICAgICAgICA8Y2M6QWdlbnQ+ CiAgICAgICAgICAgIDxkYzp0aXRsZT5iaXR0ZXJqdWc8L2RjOnRpdGxlPgogICAgICAgICAgPC9j YzpBZ2VudD4KICAgICAgICA8L2RjOmNyZWF0b3I+CiAgICAgICAgPGRjOnN1YmplY3Q+CiAgICAg ICAgICA8cmRmOkJhZz4KICAgICAgICAgICAgPHJkZjpsaT5Eb2N1bWVudDwvcmRmOmxpPgogICAg ICAgICAgICA8cmRmOmxpPmFic3RyYWN0PC9yZGY6bGk+CiAgICAgICAgICAgIDxyZGY6bGk+Y29y bmVyPC9yZGY6bGk+CiAgICAgICAgICAgIDxyZGY6bGk+Zm9sZDwvcmRmOmxpPgogICAgICAgICAg ICA8cmRmOmxpPnBhcGVyPC9yZGY6bGk+CiAgICAgICAgICA8L3JkZjpCYWc+CiAgICAgICAgPC9k YzpzdWJqZWN0PgogICAgICA8L2NjOldvcms+CiAgICAgIDxjYzpMaWNlbnNlIHJkZjphYm91dD0i aHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbGljZW5zZXMvcHVibGljZG9tYWluLyI+CiAgICAg ICAgPGNjOnBlcm1pdHMgcmRmOnJlc291cmNlPSJodHRwOi8vY3JlYXRpdmVjb21tb25zLm9yZy9u cyNSZXByb2R1Y3Rpb24iLz4KICAgICAgICA8Y2M6cGVybWl0cyByZGY6cmVzb3VyY2U9Imh0dHA6 Ly9jcmVhdGl2ZWNvbW1vbnMub3JnL25zI0Rpc3RyaWJ1dGlvbiIvPgogICAgICAgIDxjYzpwZXJt aXRzIHJkZjpyZXNvdXJjZT0iaHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbnMjRGVyaXZhdGl2 ZVdvcmtzIi8+CiAgICAgIDwvY2M6TGljZW5zZT4KICAgIDwvcmRmOlJERj4KICA8L21ldGFkYXRh Pgo8L3N2Zz4K " + id="image844" + x="33.777676" + y="213.74522" /> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="44.5397" + y="236.45029" + id="text47096"><tspan + sodipodi:role="line" + id="tspan47094" + style="font-size:6.35px;stroke-width:0.264583" + x="44.5397" + y="236.45029">foo.org</tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="38.428299" + y="244.90999" + id="text47096-2"><tspan + sodipodi:role="line" + id="tspan47094-0" + style="font-size:6.35px;stroke-width:0.264583" + x="38.428299" + y="244.90999">cdn.foo.org</tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="38.571056" + y="252.73021" + id="text47096-23"><tspan + sodipodi:role="line" + id="tspan47094-7" + style="font-size:6.35px;stroke-width:0.264583" + x="38.571056" + y="252.73021">ads.foo.org</tspan></text> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="52.293133" + y="257.54556" + id="text118919"><tspan + sodipodi:role="line" + style="stroke-width:0.264583" + x="52.293133" + y="257.54556" + id="tspan118921">...</tspan></text> + </g> + <image + preserveAspectRatio="none" + inkscape:svg-dpi="96" + width="31.920643" + height="41.946896" + xlink:href="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIj8+CjxzdmcKICAgIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5v cmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyIKICAgIHhtbG5zPSJodHRwOi8vd3d3LnczLm9y Zy8yMDAwL3N2ZyIKICAgIHhtbG5zOmNjPSJodHRwOi8vd2ViLnJlc291cmNlLm9yZy9jYy8iCiAg ICB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIKICAgIHhtbG5zOmRj PSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyIKICAgIHhtbG5zOnN2Zz0iaHR0cDov L3d3dy53My5vcmcvMjAwMC9zdmciCiAgICB4bWxuczppbmtzY2FwZT0iaHR0cDovL3d3dy5pbmtz Y2FwZS5vcmcvbmFtZXNwYWNlcy9pbmtzY2FwZSIKICAgIHhtbG5zOnNvZGlwb2RpPSJodHRwOi8v c29kaXBvZGkuc291cmNlZm9yZ2UubmV0L0RURC9zb2RpcG9kaS0wLmR0ZCIKICAgIHhtbG5zOm5z MT0iaHR0cDovL3NvemkuYmFpZXJvdWdlLmZyIgogICAgYmFzZVByb2ZpbGU9ImZ1bGwiCiAgICB2 ZXJzaW9uPSIxLjEiCiAgICB2aWV3Qm94PSIwIDAgMzUwIDUwMCIKICA+CiAgPGRlZnMKICAgID4K ICAgIDxwYXRoCiAgICAgICAgaWQ9ImNvZyIKICAgICAgICB0cmFuc2Zvcm09InNjYWxlKC40KSIK ICAgICAgICBmaWxsPSJkYXJrcmVkIgogICAgICAgIGQ9Im0yMTMgMGwtNCAzOS01IDM5LTIwIDkt MjAgOS0zMi0yNi0zMS0yNS0yNyAyNy0yNyAyNyAyNSAzMSAyNSAzMi05IDE5LTkgMTktMzUgNWMt MjAgMy0zNyA1LTQwIDZzLTQgMTItNCAzOXYzN2wzOSA0YzI0IDMgNDAgNiA0MCA4czMgMTIgOCAy MWw4IDE4LTI1IDMwLTI1IDMxIDI3IDI3IDI3IDI3IDMwLTIzIDMwLTI0IDE4IDljMTAgNSAyMCAx MCAyMiAxMCAxIDEgNCAxNiA3IDM0IDIgMTggNCAzNCA1IDM3czExIDQgMzggNGgzOGw0LTM2YzMt MjggNS0zNyAxMC0zOCAzLTEgMTMtNSAyMy0xMGwxNy04IDI5IDI0IDMwIDIzIDI2LTI3YzIwLTIw IDI2LTI4IDI0LTMxcy0xMy0xNi0yMy0yOWwtMjAtMjUgOS0xOGM1LTEwIDgtMjAgOC0yMiAwLTQg OC02IDUyLTExbDIyLTMgMS0zOCAxLTM4LTM4LTRjLTIzLTMtMzgtNi0zOC04cy0zLTEyLTgtMjJs LTktMTkgMjQtMjkgMjQtMzAtMjctMjctMjctMjctMzAgMjQtMzAgMjQtMjEtOS0yMS05LTUtMzct NS0zOC0zOC0xLTM4LTF6bTM3IDE3MGM0NCAwIDgwIDM2IDgwIDgwcy0zNiA4MC04MCA4MC04MC0z Ni04MC04MCAzNi04MCA4MC04MHoiCiAgICAvPgogIDwvZGVmcwogID4KICA8dXNlCiAgICAgIG9w YWNpdHk9Ii4zIgogICAgICB4bGluazpocmVmPSIjY29nIgogIC8+CiAgPHVzZQogICAgICBvcGFj aXR5PSIuNiIKICAgICAgeGxpbms6aHJlZj0iI2NvZyIKICAgICAgdHJhbnNmb3JtPSJ0cmFuc2xh dGUoMTIwLDEyMCkgcm90YXRlKDIyLjUgMTAwLDEwMCkiCiAgLz4KICA8dXNlCiAgICAgIHhsaW5r OmhyZWY9IiNjb2ciCiAgICAgIHRyYW5zZm9ybT0idHJhbnNsYXRlKDAsMjQwKSIKICAvPgogIDxt ZXRhZGF0YQogICAgPgogICAgPHJkZjpSREYKICAgICAgPgogICAgICA8Y2M6V29yawogICAgICAg ID4KICAgICAgICA8ZGM6Zm9ybWF0CiAgICAgICAgICA+aW1hZ2Uvc3ZnK3htbDwvZGM6Zm9ybWF0 CiAgICAgICAgPgogICAgICAgIDxkYzp0eXBlCiAgICAgICAgICAgIHJkZjpyZXNvdXJjZT0iaHR0 cDovL3B1cmwub3JnL2RjL2RjbWl0eXBlL1N0aWxsSW1hZ2UiCiAgICAgICAgLz4KICAgICAgICA8 Y2M6bGljZW5zZQogICAgICAgICAgICByZGY6cmVzb3VyY2U9Imh0dHA6Ly9jcmVhdGl2ZWNvbW1v bnMub3JnL2xpY2Vuc2VzL3B1YmxpY2RvbWFpbi8iCiAgICAgICAgLz4KICAgICAgICA8ZGM6cHVi bGlzaGVyCiAgICAgICAgICA+CiAgICAgICAgICA8Y2M6QWdlbnQKICAgICAgICAgICAgICByZGY6 YWJvdXQ9Imh0dHA6Ly9vcGVuY2xpcGFydC5vcmcvIgogICAgICAgICAgICA+CiAgICAgICAgICAg IDxkYzp0aXRsZQogICAgICAgICAgICAgID5PcGVuY2xpcGFydDwvZGM6dGl0bGUKICAgICAgICAg ICAgPgogICAgICAgICAgPC9jYzpBZ2VudAogICAgICAgICAgPgogICAgICAgIDwvZGM6cHVibGlz aGVyCiAgICAgICAgPgogICAgICAgIDxkYzp0aXRsZQogICAgICAgICAgPlBpbmsgY29nd2hlZWxz PC9kYzp0aXRsZQogICAgICAgID4KICAgICAgICA8ZGM6ZGF0ZQogICAgICAgICAgPjIwMTMtMDkt MTRUMTY6MDA6NDE8L2RjOmRhdGUKICAgICAgICA+CiAgICAgICAgPGRjOmRlc2NyaXB0aW9uCiAg ICAgICAgICA+U29tZSBjb2d3aGVlbHMgZnJvbSBodHRwczovL2NvbW1vbnMud2lraW1lZGlhLm9y Zy93aWtpL0ZpbGU6Q29nLXNjcmlwdGVkLXN2Zy5zdmc8L2RjOmRlc2NyaXB0aW9uCiAgICAgICAg PgogICAgICAgIDxkYzpzb3VyY2UKICAgICAgICAgID5odHRwczovL29wZW5jbGlwYXJ0Lm9yZy9k ZXRhaWwvMTgzNDM2L3BpbmstY29nd2hlZWxzLWJ5LWxpZnRhcm4tMTgzNDM2PC9kYzpzb3VyY2UK ICAgICAgICA+CiAgICAgICAgPGRjOmNyZWF0b3IKICAgICAgICAgID4KICAgICAgICAgIDxjYzpB Z2VudAogICAgICAgICAgICA+CiAgICAgICAgICAgIDxkYzp0aXRsZQogICAgICAgICAgICAgID5s aWZ0YXJuPC9kYzp0aXRsZQogICAgICAgICAgICA+CiAgICAgICAgICA8L2NjOkFnZW50CiAgICAg ICAgICA+CiAgICAgICAgPC9kYzpjcmVhdG9yCiAgICAgICAgPgogICAgICAgIDxkYzpzdWJqZWN0 CiAgICAgICAgICA+CiAgICAgICAgICA8cmRmOkJhZwogICAgICAgICAgICA+CiAgICAgICAgICAg IDxyZGY6bGkKICAgICAgICAgICAgICA+Y29nPC9yZGY6bGkKICAgICAgICAgICAgPgogICAgICAg ICAgICA8cmRmOmxpCiAgICAgICAgICAgICAgPmNvZ3doZWVsPC9yZGY6bGkKICAgICAgICAgICAg PgogICAgICAgICAgICA8cmRmOmxpCiAgICAgICAgICAgICAgPmNvZ3doZWVsczwvcmRmOmxpCiAg ICAgICAgICAgID4KICAgICAgICAgICAgPHJkZjpsaQogICAgICAgICAgICAgID5nZWFyPC9yZGY6 bGkKICAgICAgICAgICAgPgogICAgICAgICAgICA8cmRmOmxpCiAgICAgICAgICAgICAgPmdlYXJz PC9yZGY6bGkKICAgICAgICAgICAgPgogICAgICAgICAgICA8cmRmOmxpCiAgICAgICAgICAgICAg PnBpbms8L3JkZjpsaQogICAgICAgICAgICA+CiAgICAgICAgICAgIDxyZGY6bGkKICAgICAgICAg ICAgICA+cmVkPC9yZGY6bGkKICAgICAgICAgICAgPgogICAgICAgICAgPC9yZGY6QmFnCiAgICAg ICAgICA+CiAgICAgICAgPC9kYzpzdWJqZWN0CiAgICAgICAgPgogICAgICA8L2NjOldvcmsKICAg ICAgPgogICAgICA8Y2M6TGljZW5zZQogICAgICAgICAgcmRmOmFib3V0PSJodHRwOi8vY3JlYXRp dmVjb21tb25zLm9yZy9saWNlbnNlcy9wdWJsaWNkb21haW4vIgogICAgICAgID4KICAgICAgICA8 Y2M6cGVybWl0cwogICAgICAgICAgICByZGY6cmVzb3VyY2U9Imh0dHA6Ly9jcmVhdGl2ZWNvbW1v bnMub3JnL25zI1JlcHJvZHVjdGlvbiIKICAgICAgICAvPgogICAgICAgIDxjYzpwZXJtaXRzCiAg ICAgICAgICAgIHJkZjpyZXNvdXJjZT0iaHR0cDovL2NyZWF0aXZlY29tbW9ucy5vcmcvbnMjRGlz dHJpYnV0aW9uIgogICAgICAgIC8+CiAgICAgICAgPGNjOnBlcm1pdHMKICAgICAgICAgICAgcmRm OnJlc291cmNlPSJodHRwOi8vY3JlYXRpdmVjb21tb25zLm9yZy9ucyNEZXJpdmF0aXZlV29ya3Mi CiAgICAgICAgLz4KICAgICAgPC9jYzpMaWNlbnNlCiAgICAgID4KICAgIDwvcmRmOlJERgogICAg PgogIDwvbWV0YWRhdGEKICA+Cjwvc3ZnCj4K " + id="image746" + x="85.593079" + y="83.116173" /> + <g + style="stroke:#58928a;stroke-opacity:1" + clip-path="url(#clipPath4258)" + id="g4256" + transform="matrix(2.0735697,-0.38889921,-0.43078373,-1.8719593,173.29626,93.1446)"> + <g + style="stroke:#58928a;stroke-opacity:1" + transform="translate(0.563,5.6699)" + id="g4262"> + <path + id="path4264" + style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1" + d="m 0,0 c 0,2.82 2.287,5.107 5.107,5.107 2.82,0 5.107,-2.287 5.107,-5.107 0,-2.82 -2.287,-5.107 -5.107,-5.107 C 2.287,-5.107 0,-2.82 0,0 Z" /> + </g> + <g + style="stroke:#6c6c6c;stroke-opacity:1" + transform="translate(8.4111,5.6704)" + id="g4266"> + <path + id="path4268" + style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1" + d="m 0,0 c 0,2.819 -1.259,5.106 -2.811,5.106 -1.552,0 -2.811,-2.287 -2.811,-5.106 0,-2.823 1.259,-5.108 2.811,-5.108 C -1.259,-5.108 0,-2.823 0,0 Z" /> + </g> + <g + style="stroke:#6c6c6c;stroke-opacity:1" + transform="translate(5.6699,10.647)" + id="g4270"> + <path + id="path4272" + style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1" + d="M 0,0 V -9.855" /> + </g> + <g + style="stroke:#6c6c6c;stroke-opacity:1" + transform="translate(0.563,5.6699)" + id="g4274"> + <path + id="path4276" + style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1" + d="M 0,0 H 10.214" /> + </g> + </g> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="171.64845" + y="97.92038" + id="text3572"><tspan + sodipodi:role="line" + id="tspan3570" + style="font-size:7.05556px;stroke-width:0.264583" + x="171.64845" + y="97.92038">foo.org</tspan><tspan + sodipodi:role="line" + style="font-size:7.05556px;stroke-width:0.264583" + x="171.64845" + y="106.73983" + id="tspan68806" /></text> + <g + style="stroke:#58928a;stroke-opacity:1" + clip-path="url(#clipPath4258-9)" + id="g4256-3" + transform="matrix(2.0735697,-0.38889921,-0.43078373,-1.8719593,173.29628,139.42531)"> + <g + style="stroke:#58928a;stroke-opacity:1" + transform="translate(0.563,5.6699)" + id="g4262-6"> + <path + id="path4264-1" + style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1" + d="m 0,0 c 0,2.82 2.287,5.107 5.107,5.107 2.82,0 5.107,-2.287 5.107,-5.107 0,-2.82 -2.287,-5.107 -5.107,-5.107 C 2.287,-5.107 0,-2.82 0,0 Z" /> + </g> + <g + style="stroke:#6c6c6c;stroke-opacity:1" + transform="translate(8.4111,5.6704)" + id="g4266-2"> + <path + id="path4268-9" + style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1" + d="m 0,0 c 0,2.819 -1.259,5.106 -2.811,5.106 -1.552,0 -2.811,-2.287 -2.811,-5.106 0,-2.823 1.259,-5.108 2.811,-5.108 C -1.259,-5.108 0,-2.823 0,0 Z" /> + </g> + <g + style="stroke:#6c6c6c;stroke-opacity:1" + transform="translate(5.6699,10.647)" + id="g4270-3"> + <path + id="path4272-1" + style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1" + d="M 0,0 V -9.855" /> + </g> + <g + style="stroke:#6c6c6c;stroke-opacity:1" + transform="translate(0.563,5.6699)" + id="g4274-9"> + <path + id="path4276-4" + style="fill:none;stroke:#6c6c6c;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1" + d="M 0,0 H 10.214" /> + </g> + </g> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="171.64847" + y="144.20119" + id="text3572-7"><tspan + sodipodi:role="line" + id="tspan3570-8" + style="font-size:7.05556px;stroke-width:0.264583" + x="171.64847" + y="144.20119">foo.org</tspan><tspan + sodipodi:role="line" + style="font-size:7.05556px;stroke-width:0.264583" + x="171.64847" + y="153.02063" + id="tspan68806-4" /></text> + <path + style="fill:none;stroke:#000000;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow1Lstart);marker-end:url(#Arrow1Lend)" + d="m 120.28722,108.51063 19.30483,7.65883 3.56213,-4.825 -1.72511,10.81668 5.84978,-8.92633 -0.47502,5.37605 18.52116,7.40042" + id="path9445" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#Arrow1Lstart);marker-end:url(#Arrow1Lend)" + d="m 119.75925,97.003192 20.08697,-6.068938 -1.26348,-7.255973 5.72206,10.656067 -1.48746,-11.573417 3.69027,6.41613 18.3502,-5.493549" + id="path9471" /> + <text + xml:space="preserve" + style="font-size:6.35px;line-height:1.25;font-family:sans-serif;stroke-width:0.264583" + x="142.28778" + y="103.97533" + id="text22310"><tspan + sodipodi:role="line" + id="tspan22308" + style="stroke-width:0.264583" + x="142.28778" + y="103.97533">...</tspan></text> + <path + style="fill:none;stroke:#000000;stroke-width:0.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:1.5, 1.5;stroke-dashoffset:0;stroke-opacity:1;marker-start:url(#Arrow1Lstart);marker-end:url(#Arrow1Lend)" + d="m 271.47134,228.65635 -24.769,0.0425" + id="path42256" /> + <image + preserveAspectRatio="none" + inkscape:svg-dpi="96" + width="21.618526" + height="34.065556" + xlink:href="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHN2ZyB3aWR0aD0iNjZweCIg aGVpZ2h0PSIxMDRweCIgdmlld0JveD0iMCAwIDY2IDEwNCIgdmVyc2lvbj0iMS4xIiB4bWxucz0i aHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9y Zy8xOTk5L3hsaW5rIj4KICAgIDwhLS0gR2VuZXJhdG9yOiBTa2V0Y2ggNDcuMSAoNDU0MjIpIC0g aHR0cDovL3d3dy5ib2hlbWlhbmNvZGluZy5jb20vc2tldGNoIC0tPgogICAgPHRpdGxlPm9uaW9u LWJnPC90aXRsZT4KICAgIDxkZXNjPkNyZWF0ZWQgd2l0aCBTa2V0Y2guPC9kZXNjPgogICAgPGRl ZnM+PC9kZWZzPgogICAgPGcgaWQ9IlBhZ2UtMSIgc3Ryb2tlPSJub25lIiBzdHJva2Utd2lkdGg9 IjEiIGZpbGw9Im5vbmUiIGZpbGwtcnVsZT0iZXZlbm9kZCI+CiAgICAgICAgPGcgaWQ9InN0eWxl Z3VpZGUtcG9ydGFsIiB0cmFuc2Zvcm09InRyYW5zbGF0ZSgtMi4wMDAwMDAsIC0yMy4wMDAwMDAp IiBmaWxsLXJ1bGU9Im5vbnplcm8iPgogICAgICAgICAgICA8ZyBpZD0ib25pb24tYmciIHRyYW5z Zm9ybT0idHJhbnNsYXRlKDIuMDAwMDAwLCAyMy4wMDAwMDApIj4KICAgICAgICAgICAgICAgIDxn IGlkPSJsYXllcjVfMTdfIj4KICAgICAgICAgICAgICAgICAgICA8ZyBpZD0icGF0aDI1NTRfMjhf IiB0cmFuc2Zvcm09InRyYW5zbGF0ZSgzMC4yOTcxNDMsIDAuMDAwMDAwKSIgZmlsbD0iIzY4QjA0 NCI+CiAgICAgICAgICAgICAgICAgICAgICAgIDxwYXRoIGQ9Ik04LjEzMjM5MTA1LDcuNzUyNTA1 NDUgTDUuNDIxNTk0MDMsMTguNzM1MjIxNSBDOS4yNDg2MDE1OSwxMC45ODI3MTYgMTUuNDY3NDg4 OSw1LjE2ODMzNjk2IDIyLjQ4MzY2OTQsLTcuMTA1NDI3MzZlLTE1IEMxNy4zODA5OTI2LDYuMTM3 NDAwMTUgMTIuNTk3MjMzMiwxMi4xMTMyODk4IDkuNzI2OTc3NTMsMTguMjUwNjg5OSBDMTQuNjcw MTk1NiwxMS4zMDU3MzcxIDIxLjIwODAwMDIsNy40Mjk0ODQzOSAyOC41NDMwOTgsNS4wMDY4MjY0 MyBDMTguNjU2NjYxOCwxMy44ODk5MDU2IDExLjAwMjY0NjcsMjMuNDE5MDI2OSA0Ljk0MzIxODA5 LDMyLjk0ODE0ODEgTDAuMTU5NDU4NjQ4LDMwLjg0ODUxMTMgQzEuMTE2MjEwNTQsMjMuMDk2MDA1 OCAzLjk4NjQ2NjIsMTUuMzQzNTAwNCA4LjEzMjM5MTA1LDcuNzUyNTA1NDUgTDguMTMyMzkxMDUs Ny43NTI1MDU0NSBaIiBpZD0iU2hhcGUiPjwvcGF0aD4KICAgICAgICAgICAgICAgICAgICA8L2c+ CiAgICAgICAgICAgICAgICAgICAgPGcgaWQ9InBhdGgyNTM0XzdfIiB0cmFuc2Zvcm09InRyYW5z bGF0ZSgwLjAwMDAwMCwgMjguMjI3MTYwKSIgZmlsbD0iI0Y1RjhERSI+CiAgICAgICAgICAgICAg ICAgICAgICAgIDxwYXRoIGQ9Ik0yNS44MzIzMDEsMC41MjE3MTM4NzEgTDM0Ljc2MTk4NTMsNC4y MzY0NTYwNiBDMzQuNzYxOTg1Myw2LjQ5NzYwMzQ5IDM0LjYwMjUyNjYsMTMuNjA0MDY2OCAzNi4w Mzc2NTQ1LDE1LjcwMzcwMzcgQzUxLjAyNjc2NzQsMzUuMjQ2NDc3OSA0OC40NzU0MjksNzQuMTcw NTE1NiAzMy4wMDc5NDAxLDc1LjEzOTU3ODggQzkuNTY3NTE4ODgsNzUuMTM5NTc4OCAwLjQ3ODM3 NTk0NCw1OC45ODg1MjU4IDAuNDc4Mzc1OTQ0LDQ0LjEyOTU1NyBDMC40NzgzNzU5NDQsMzAuNTYy NjcyNSAxNi41ODM2OTk0LDIxLjUxODA4MjggMjYuMTUxMjE4MywxMy42MDQwNjY4IEMyOC43MDI1 NTY2LDExLjUwNDQyOTkgMjguMjI0MTgwNyw2LjY1OTExNDAyIDI1LjgzMjMwMSwwLjUyMTcxMzg3 MSBMMjUuODMyMzAxLDAuNTIxNzEzODcxIFoiIGlkPSJTaGFwZSI+PC9wYXRoPgogICAgICAgICAg ICAgICAgICAgIDwvZz4KICAgICAgICAgICAgICAgICAgICA8ZyBpZD0icGF0aDI1MzZfMThfIiB0 cmFuc2Zvcm09InRyYW5zbGF0ZSgzNC44MTkyOTEsIDMyLjMwMjEwNikiIGZpbGw9IiM2MjM2NzYi PgogICAgICAgICAgICAgICAgICAgICAgICA8cGF0aCBkPSJNMC4xMDIxNTMxOTYsMCBMMy4yOTEz MjYxNiwxLjYxNTEwNTMgQzIuOTcyNDA4ODYsMy43MTQ3NDIxOSAzLjQ1MDc4NDgsOC41NjAwNTgx IDUuNTIzNzQ3MjMsOS44NTIxNDIzNCBDMTQuOTMxODA3NSwxNS44MjgwMzIgMjMuODYxNDkxOCwy Mi4yODg0NTMyIDI3LjM2OTU4MiwyOC43NDg4NzQ0IEMzOS44MDczNTY2LDUxLjUyMTg1OTEgMTgu NTk5MzU2NCw3Mi42Nzk3Mzg2IDAuMjYxNjExODQ0LDcwLjU4MDEwMTcgQzEwLjE0ODA0OCw2My4x NTA2MTczIDEzLjE3Nzc2MjMsNDcuODA3MTE2OSA5LjM1MDc1NDc4LDMxLjAxMDAyMTggQzcuNzU2 MTY4MywyNC4zODgwOTAxIDUuNTIzNzQ3MjMsMTguNTczNzExIDEuMjE4MzYzNzMsMTEuNzkwMjY4 NyBDLTAuMzc2MjIyNzQ4LDguNzIxNTY4NjMgMC4yNjE2MTE4NDQsNC42ODM4MDUzNyAwLjEwMjE1 MzE5NiwwIEwwLjEwMjE1MzE5NiwwIFoiIGlkPSJTaGFwZSI+PC9wYXRoPgogICAgICAgICAgICAg ICAgICAgIDwvZz4KICAgICAgICAgICAgICAgIDwvZz4KICAgICAgICAgICAgICAgIDxnIGlkPSJs YXllcjRfMTdfIiB0cmFuc2Zvcm09InRyYW5zbGF0ZSg5LjAwMDAwMCwgMzIuMDAwMDAwKSIgZmls bD0iIzAxMDEwMSI+CiAgICAgICAgICAgICAgICAgICAgPGcgaWQ9InBhdGgyNTQwXzE4XyIgdHJh bnNmb3JtPSJ0cmFuc2xhdGUoMC4wMDAwMDAsIDEwLjMyOTY2MSkiPgogICAgICAgICAgICAgICAg ICAgICAgICA8cGF0aCBkPSJNMjIuOTY0NjY3OCwwLjUwMjY1MDQwNSBDMjIuMzM1NDk4OSw0LjAw NzIyMTYzIDIxLjU0OTAzNzYsMTAuMzc5MTY5MyAxOC41NjA0ODUsMTIuNjA5MzUxIEMxNy4zMDIx NDcsMTMuNTY1MTQzMSAxNi4wNDM4MDksMTQuMzYxNjM2NiAxNC42MjgxNzg4LDE1LjMxNzQyODgg QzkuMjgwMjQyNDksMTguOTgxMjk4NyAzLjc3NTAxMzg5LDIyLjQ4NTg2OTkgMS40MTU2MzAyMSwz MS41NjU4OTUzIEMwLjk0Mzc1MzQ3MywzMy40Nzc0Nzk2IDEuNDE1NjMwMjEsMzUuNTQ4MzYyNiAx LjczMDIxNDcsMzcuNDU5OTQ2OSBDMy4xNDU4NDQ5MSw0Mi44NzYxMDI1IDYuOTIwODU4OCw0OC45 Mjk0NTI3IDkuOTA5NDExNDcsNTIuMjc0NzI1MyBDOS45MDk0MTE0Nyw1Mi40MzQwMjQgMTAuNTM4 NTgwNCw1Mi43NTI2MjE0IDEwLjUzODU4MDQsNTIuOTExOTIgQzEzLjA1NTI1NjQsNTUuOTM4NTk1 MiAxMy44NDE3MTc2LDU2LjczNTA4ODYgMjMuMTIxOTYwMSw1OC44MDU5NzE2IEwyMi45NjQ2Njc4 LDU5LjkyMTA2MjUgQzE3LjMwMjE0Nyw1OC4zMjgwNzU2IDEyLjc0MDY3MTksNTcuMDUzNjg2IDku NzUyMTE5MjIsNTMuNTQ5MTE0OCBDOS43NTIxMTkyMiw1My41NDkxMTQ4IDkuMjgwMjQyNDksNTIu OTExOTIgOS4yODAyNDI0OSw1Mi45MTE5MiBDNi4xMzQzOTc1OCw0OS4yNDgwNTAxIDIuMzU5Mzgz NjgsNDMuMTk0Njk5OCAwLjk0Mzc1MzQ3MywzNy40NTk5NDY5IEMwLjQ3MTg3NjczNywzNS4yMjk3 NjUyIC04Ljg4MTc4NDJlLTE0LDMzLjQ3NzQ3OTYgMC42MjkxNjg5ODIsMzEuMDg3OTk5MyBDMy4x NDU4NDQ5MSwyMS44NDg2NzUxIDguODA4MzY1NzUsMTguMTg0ODA1MiAxNC4zMTM1OTQzLDE0LjM2 MTYzNjYgQzE1LjU3MTkzMjMsMTMuNTY1MTQzMSAxNy4xNDQ4NTQ4LDEyLjc2ODY0OTcgMTguMjQ1 OTAwNSwxMS44MTI4NTc1IEMyMC40NDc5OTE5LDEwLjA2MDU3MTkgMjEuNzA2MzI5OSw0LjgwMzcx NTA5IDIyLjk2NDY2NzgsMC41MDI2NTA0MDUgTDIyLjk2NDY2NzgsMC41MDI2NTA0MDUgWiIgaWQ9 IlNoYXBlIj48L3BhdGg+CiAgICAgICAgICAgICAgICAgICAgPC9nPgogICAgICAgICAgICAgICAg ICAgIDxnIGlkPSJwYXRoMjU0Ml8xOF8iIHRyYW5zZm9ybT0idHJhbnNsYXRlKDYuMjkxNjkwLCAy NS4yMjIyOTMpIj4KICAgICAgICAgICAgICAgICAgICAgICAgPHBhdGggZD0iTTE5LjAzMjM2MTcs MC4xMDYxOTkxMjggQzE5LjAzMjM2MTcsNC4wODg2NjY0MyAxOC43MTc3NzcyLDYuMDAwMjUwNzMg MTkuNjYxNTMwNyw4Ljg2NzYyNzE4IEMyMC4yOTA2OTk3LDEwLjQ2MDYxNDEgMjIuMzM1NDk4OSwx Mi44NTAwOTQ1IDIyLjk2NDY2NzgsMTUuMDgwMjc2MiBDMjMuNzUxMTI5MSwxOC4xMDY5NTEzIDI0 LjY5NDg4MjUsMjEuMjkyOTI1MiAyNC41Mzc1OTAzLDIzLjM2MzgwODEgQzI0LjUzNzU5MDMsMjUu NTkzOTg5OCAyNC4zODAyOTgxLDI5Ljg5NTA1NDUgMjMuNDM2NTQ0NiwzNC41MTQ3MTY2IEMyMi42 NTAwODM0LDM4LjMzNzg4NTIgMjAuOTE5ODY4Nyw0MS41MjM4NTkgMTguMDg4NjA4Miw0My4yNzYx NDQ2IEMxNS4xMDAwNTU2LDQyLjYzODk0OTkgMTEuNjM5NjI2Miw0MS42ODMxNTc3IDkuNTk0ODI2 OTgsMzkuNzcxNTczNCBDNS42NjI1MjA4NCwzNi4yNjcwMDIyIDIuMDQ0Nzk5MTksMzAuMzcyOTUw NiAxLjU3MjkyMjQ2LDI1LjI3NTM5MjQgQzEuMjU4MzM3OTYsMjEuMTMzNjI2NSA1LjAzMzM1MTg2 LDE0LjkyMDk3NzUgMTAuMzgxMjg4MiwxMS44OTQzMDIzIEMxNC45NDI3NjMzLDkuMTg2MjI0NTcg MTUuODg2NTE2OCw2LjE1OTU0OTQyIDE2LjgzMDI3MDMsMS4zODA1ODg2NiBDMTUuNDE0NjQwMSw1 LjY4MTY1MzM0IDE0LjE1NjMwMjEsOS4xODYyMjQ1NyA5LjkwOTQxMTQ3LDExLjQxNjQwNjMgQzMu NjE3NzIxNjUsMTQuNzYxNjc4OCAwLjMxNDU4NDQ5MSwyMC4zMzcxMzMgMC42MjkxNjg5ODIsMjUu NzUzMjg4NSBDMS4xMDEwNDU3MiwzMi42MDMxMzIzIDMuNzc1MDEzODksMzcuMjIyNzk0MyA5LjEy Mjk1MDI0LDQwLjg4NjY2NDMgQzExLjMyNTA0MTcsNDIuNDc5NjUxMiAxNS41NzE5MzIzLDQ0LjIz MTkzNjggMTguMjQ1OTAwNSw0NC41NTA1MzQyIEwxOC4yNDU5MDA1LDQ0LjIzMTkzNjggQzIwLjI5 MDY5OTcsNDMuOTEzMzM5NCAyMi44MDczNzU2LDQwLjU2ODA2NjkgMjQuMDY1NzEzNiwzNi4xMDc3 MDM1IEMyNS4xNjY3NTkzLDMyLjEyNTIzNjIgMjUuNjM4NjM2LDI2Ljg2ODM3OTQgMjUuNDgxMzQz OCwyMy42ODI0MDU1IEMyNS40ODEzNDM4LDIxLjc3MDgyMTIgMjQuNTM3NTkwMywxNy42MjkwNTUy IDIzLjEyMTk2MDEsMTMuOTY1MTg1MyBDMjIuMzM1NDk4OSwxMS44OTQzMDIzIDIxLjA3NzE2MDks OS44MjM0MTkzMyAyMC4xMzM0MDc0LDguMzg5NzMxMTEgQzE5LjUwNDIzODQsNi45NTYwNDI4OCAx OS41MDQyMzg0LDMuNzcwMDY5MDQgMTkuMDMyMzYxNywwLjEwNjE5OTEyOCBaIiBpZD0iU2hhcGUi PjwvcGF0aD4KICAgICAgICAgICAgICAgICAgICA8L2c+CiAgICAgICAgICAgICAgICAgICAgPGcg aWQ9InBhdGgyNTQ0XzE4XyIgdHJhbnNmb3JtPSJ0cmFuc2xhdGUoMTcuMzAyMTQ3LCA0MC41OTY0 MTIpIj4KICAgICAgICAgICAgICAgICAgICAgICAgPHBhdGggZD0iTTcuMzkyNzM1NTQsMC4zNDMz NTE3MTMgQzcuMzkyNzM1NTQsMy4wNTE0Mjk0OCA4LjQ5Mzc4MTI2LDYuMzk2NzAyMDEgOC45NjU2 NTc5OSw5LjkwMTI3MzIzIEM5LjI4MDI0MjQ5LDEyLjQ1MDA1MjMgOS4xMjI5NTAyNCwxNS4xNTgx MzAxIDkuMTIyOTUwMjQsMTcuMzg4MzExNyBDOS4xMjI5NTAyNCwyMC4wOTYzODk1IDguMTc5MTk2 NzcsMjQuNzE2MDUxNiA2LjkyMDg1ODgsMjcuMTA1NTMyIEM1LjgxOTgxMzA4LDI2LjYyNzYzNTkg NS4zNDc5MzYzNSwyNS45OTA0NDExIDQuNTYxNDc1MTIsMjUuMDM0NjQ5IEMzLjYxNzcyMTY1LDIz Ljc2MDI1OTQgMi45ODg1NTI2NiwyMi40ODU4Njk5IDIuNTE2Njc1OTMsMjAuODkyODgzIEMyLjA0 NDc5OTE5LDE5Ljc3Nzc5MjEgMS41NzI5MjI0NiwxOC41MDM0MDI2IDEuMjU4MzM3OTYsMTYuOTEw NDE1NyBDMC45NDM3NTM0NzMsMTQuNjgwMjM0IDEuMTAxMDQ1NzIsMTEuMDE2MzY0MSAzLjYxNzcy MTY1LDcuMzUyNDk0MTYgQzUuNTA1MjI4NTksNC40ODUxMTc3IDUuOTc3MTA1MzMsNC4xNjY1MjAz MiA2Ljc2MzU2NjU2LDAuOTgwNTQ2NDgxIEM1LjgxOTgxMzA4LDQuMDA3MjIxNjMgNS4xOTA2NDQx LDQuMTY2NTIwMzIgMy4xNDU4NDQ5MSw2LjcxNTI5OTM5IEMwLjc4NjQ2MTIyOCw5LjQyMzM3NzE1 IDAuNDcxODc2NzM3LDEzLjQwNTg0NDQgMC40NzE4NzY3MzcsMTYuNzUxMTE3IEMwLjQ3MTg3Njcz NywxOC4xODQ4MDUyIDAuOTQzNzUzNDczLDE5LjYxODQ5MzQgMS41NzI5MjI0NiwyMS4wNTIxODE3 IEMyLjIwMjA5MTQ0LDIyLjY0NTE2ODYgMi42NzM5NjgxNywyNC4wNzg4NTY4IDMuNDYwNDI5NCwy NS4xOTM5NDc3IEM0LjcxODc2NzM3LDI3LjEwNTUzMiA2LjI5MTY4OTgyLDI4LjA2MTMyNDEgNy4w NzgxNTEwNSwyOC4yMjA2MjI4IEM3LjA3ODE1MTA1LDI4LjIyMDYyMjggNy4wNzgxNTEwNSwyOC4y MjA2MjI4IDcuMDc4MTUxMDUsMjguMjIwNjIyOCBDNy4wNzgxNTEwNSwyOC4yMjA2MjI4IDcuMDc4 MTUxMDUsMjguMjIwNjIyOCA3LjA3ODE1MTA1LDI4LjIyMDYyMjggTDcuMDc4MTUxMDUsMjguMDYx MzI0MSBDOC40OTM3ODEyNiwyNi40NjgzMzcyIDkuNDM3NTM0NzMsMjQuNzE2MDUxNiA5Ljc1MjEx OTIyLDIzLjEyMzA2NDcgQzEwLjA2NjcwMzcsMjEuMjExNDgwNCAxMC4yMjM5OTYsMTkuMTQwNTk3 NCAxMC4zODEyODgyLDE2Ljc1MTExNyBDMTAuNTM4NTgwNCwxNC44Mzk1MzI3IDEwLjM4MTI4ODIs MTIuMTMxNDU0OSA5LjkwOTQxMTQ3LDkuNDIzMzc3MTUgQzkuMTIyOTUwMjQsNi4yMzc0MDMzMSA3 Ljg2NDYxMjI4LDIuNzMyODMyMDkgNy4zOTI3MzU1NCwwLjM0MzM1MTcxMyBMNy4zOTI3MzU1NCww LjM0MzM1MTcxMyBaIiBpZD0iU2hhcGUiPjwvcGF0aD4KICAgICAgICAgICAgICAgICAgICA8L2c+ CiAgICAgICAgICAgICAgICAgICAgPGcgaWQ9InBhdGgyNTUwXzE4XyIgdHJhbnNmb3JtPSJ0cmFu c2xhdGUoMjQuMzczODM3LCA3LjE0MzY4NykiPgogICAgICAgICAgICAgICAgICAgICAgICA8cGF0 aCBkPSJNMC43OTI5MjI0NTUsMC4zNDMzNTE3MTMgQzAuNzkyOTIyNDU1LDQuMzI1ODE5MDEgMS4x MDc1MDY5NSwxMS42NTM1NTg4IDIuMjA4NTUyNjYsMTQuNTIwOTM1MyBDMi41MjMxMzcxNiwxNS40 NzY3Mjc0IDUuMzU0Mzk3NTgsMTkuNzc3NzkyMSA3LjI0MTkwNDUyLDI1LjAzNDY0OSBDOC42NTc1 MzQ3MywyOC42OTg1MTg5IDguODE0ODI2OTgsMzIuMDQzNzkxNCA5LjEyOTQxMTQ3LDMyLjk5OTU4 MzYgQzEwLjA3MzE2NDksMzcuMzAwNjQ4MiA4Ljk3MjExOTIyLDQ0LjYyODM4ODEgNy4zOTkxOTY3 Nyw1MS40NzgyMzE4IEM2LjYxMjczNTU0LDU1LjE0MjEwMTcgNC4wOTYwNTk2MSw1OS43NjE3NjM4 IDEuMTA3NTA2OTUsNjEuNjczMzQ4MSBMMC40NzgzMzc5NjQsNjIuNzg4NDM4OSBDMi4wNTEyNjA0 Miw2Mi43ODg0Mzg5IDYuMTQwODU4OCw1OC42NDY2NzMgNy41NTY0ODkwMSw1My43MDg0MTM1IEM5 LjkxNTg3MjcsNDUuMjY1NTgyOCAxMC44NTk2MjYyLDQxLjI4MzExNTUgOS43NTg1ODA0NSwzMS44 ODQ0OTI3IEM5LjYwMTI4ODIsMzAuOTI4NzAwNiA5LjI4NjcwMzcxLDI3LjkwMjAyNTQgNy44NzEw NzM1LDI0LjU1Njc1MjkgQzUuODI2Mjc0MzEsMTkuNDU5MTk0NyAyLjgzNzcyMTY1LDE0LjY4MDIz NCAyLjM2NTg0NDkxLDEzLjU2NTE0MzEgQzEuODkzOTY4MTcsMTEuOTcyMTU2MiAwLjk1MDIxNDcw MSw1LjEyMjMxMjQ3IDAuNzkyOTIyNDU1LDAuMzQzMzUxNzEzIEwwLjc5MjkyMjQ1NSwwLjM0MzM1 MTcxMyBaIiBpZD0iU2hhcGUiPjwvcGF0aD4KICAgICAgICAgICAgICAgICAgICA8L2c+CiAgICAg ICAgICAgICAgICAgICAgPGcgaWQ9InBhdGgyNTUyXzE4XyIgdHJhbnNmb3JtPSJ0cmFuc2xhdGUo MjQuMzczODM3LCAwLjAwMDAwMCkiPgogICAgICAgICAgICAgICAgICAgICAgICA8cGF0aCBkPSJN Mi4yMDg1NTI2NiwwLjQ3Nzg5NjA3NiBDMi4wNTEyNjA0Miw0LjQ2MDM2MzM3IDEuODkzOTY4MTcs Ny44MDU2MzU5IDIuNjgwNDI5NCwxMC42NzMwMTI0IEMzLjQ2Njg5MDYzLDE0LjAxODI4NDkgNy43 MTM3ODEyNiwxOC42Mzc5NDcgOS40NDM5OTU5NiwyNC4wNTQxMDI1IEMxMi43NDcxMzMxLDM0LjQw ODUxNzUgMTEuOTYwNjcxOSw0Ny45NDg5MDYzIDkuNDQzOTk1OTYsNTguNDYyNjE5OSBDOC41MDAy NDI0OSw2Mi4xMjY0ODk4IDQuMjUzMzUxODYsNjcuNTQyNjQ1NCAwLjAwNjQ2MTIyNzU4LDY5LjI5 NDkzMSBMMy4xNTIzMDYxNCw3MC4wOTE0MjQ0IEM0Ljg4MjUyMDg0LDcwLjA5MTQyNDQgOS4yODY3 MDM3MSw2NS43OTAzNTk4IDExLjAxNjkxODQsNjEuMDExMzk5IEMxMy44NDgxNzg4LDUzLjUyNDM2 MDUgMTQuMzIwMDU1Niw0NC42MDM2MzM3IDEzLjIxOTAwOTksMzUuMDQ1NzEyMiBDMTMuMjE5MDA5 OSwzNC4wODk5MjAxIDExLjY0NjA4NzQsMjUuOTY1Njg2OCAxMC4yMzA0NTcyLDIyLjYyMDQxNDMg QzguMTg1NjU3OTksMTcuNTIyODU2MSA1LjAzOTgxMzA4LDE0LjAxODI4NDkgMy43ODE0NzUxMiwx MC44MzIzMTEgQzIuODM3NzIxNjUsOC40NDI4MzA2NyAyLjUyMzEzNzE2LDIuMjMwMTgxNjkgMy4x NTIzMDYxNCwwLjc5NjQ5MzQ2IEwyLjIwODU1MjY2LDAuNDc3ODk2MDc2IFoiIGlkPSJTaGFwZSI+ PC9wYXRoPgogICAgICAgICAgICAgICAgICAgIDwvZz4KICAgICAgICAgICAgICAgIDwvZz4KICAg ICAgICAgICAgPC9nPgogICAgICAgIDwvZz4KICAgIDwvZz4KPC9zdmc+ " + id="image1098" + x="99.816887" + y="168.93225" /> + </g> +</svg> diff --git a/summary/src/tlwo/img/repeat-attack.pdf b/summary/src/tlwo/img/repeat-attack.pdf Binary files differnew file mode 100644 index 0000000..36e2f73 --- /dev/null +++ b/summary/src/tlwo/img/repeat-attack.pdf diff --git a/summary/src/tlwo/img/resolve.pdf b/summary/src/tlwo/img/resolve.pdf Binary files differnew file mode 100644 index 0000000..ff7ab6e --- /dev/null +++ b/summary/src/tlwo/img/resolve.pdf diff --git a/summary/src/tlwo/img/setting.pdf b/summary/src/tlwo/img/setting.pdf Binary files differnew file mode 100644 index 0000000..aee9012 --- /dev/null +++ b/summary/src/tlwo/img/setting.pdf diff --git a/summary/src/tlwo/img/uncached.pdf b/summary/src/tlwo/img/uncached.pdf Binary files differnew file mode 100644 index 0000000..2a83a17 --- /dev/null +++ b/summary/src/tlwo/img/uncached.pdf diff --git a/summary/src/tlwo/main.tex b/summary/src/tlwo/main.tex new file mode 100644 index 0000000..09110c4 --- /dev/null +++ b/summary/src/tlwo/main.tex @@ -0,0 +1,69 @@ +\begin{kaupaper}[ + author={% + \textbf{Rasmus Dahlberg} and + Tobias Pulls + }, + title={% + Timeless Timing Attacks and Preload Defenses in Tor's DNS Cache + }, + reference={% + USENIX Security (2023) + }, + summary={% + Tor relays cache resolved domains with constant time-to-live values not to + reveal information about past exit traffic while boosting performance. We + show that this caching strategy and its implementation in the live Tor + network can be exploited by a \emph{timeless timing attack} that leaks if a + domain is (not) cached. Further, the time that a domain was inserted into + the cache can be inferred by repeated probes. Our attack prototype's + experimental evaluation in real conditions shows that there are neither + false positives nor false negatives (10M~repetitions). Thus, it is useful + for instantiating a real-world website oracle without requiring any special attacker + capabilities or reach (just a modest computer that can create a Tor + circuit). One of our mitigations has been merged in Tor: probabilistic + time-to-live values that make the time-of-insertion fuzzy. Long-term, + Tor's DNS cache could be redesigned to \emph{preload} the same domains at all + exits. Such preloading would eliminate all (timeless) timing attacks in + Tor's DNS cache because the same domains would always be (un)cached across + different circuits. To retain performance within the same circuit, we + propose that the preloaded domains should be complemented by a dynamic + same-circuit cache that is not shared across circuits. Our + four-month-long DNS cache measurement at two 100~Mbit/s exit relays + informs on today's baseline performance. It is compared to a preloaded + DNS cache based on different variations of three popularity lists: Alexa, + Tranco, and Umbrella. A preloaded DNS cache can be as performant as today + with similar resource usage or significantly improve cache-hit ratios by + 2-3x. However, the increased cache-hit ratios have the cost of modest + increases in memory and resolver load. + }, + participation={\vspace{-.25cm} + Tobias and I collaborated closely from start to finish with the following + exceptions. I did most implementation work. Volunteers from DFRI---a + Swedish non-profit and non-partisan organization that promotes digital + rights---operated our exit relays. Tobias did most DNS cache data + analysis. Tobias also had the initial idea, which was refined with + feedback~from~Roger~Dingledine. + }, + label={ + paper:tlwo + }, +] + \maketitle + \begin{abstract} + \input{src/tlwo/src/abstract} + \end{abstract} + + \input{src/tlwo/src/introduction} + \input{src/tlwo/src/background} + \input{src/tlwo/src/tor-cache} + \input{src/tlwo/src/attack} + \input{src/tlwo/src/short} + \input{src/tlwo/src/long} + \input{src/tlwo/src/related} + \input{src/tlwo/src/conclusion} + \input{src/tlwo/src/acknowledgements} + \input{src/tlwo/src/availability} + + \bibliographystyle{plain} + \bibliography{src/tlwo/src/ref} +\end{kaupaper} diff --git a/summary/src/tlwo/src/abstract.tex b/summary/src/tlwo/src/abstract.tex new file mode 100644 index 0000000..df4fa1b --- /dev/null +++ b/summary/src/tlwo/src/abstract.tex @@ -0,0 +1,25 @@ +\noindent +We show that Tor's DNS cache is vulnerable to a timeless timing attack, allowing +anyone to determine if a domain is cached or not without any false positives. +The attack requires sending a single TLS record. It can be repeated to determine +when a domain is no longer cached to leak the insertion time. Our evaluation in +the Tor network shows no instances of cached domains being reported as uncached +and vice versa after 12M repetitions while only targeting our own domains. This +shifts DNS in Tor from an unreliable side-channel---using traditional timing +attacks with network jitter---to being perfectly reliable. We responsibly +disclosed the attack and suggested two short-term mitigations. + +As a long-term defense for the DNS cache in Tor against all types of (timeless) +timing attacks, we propose a redesign where only an allowlist of domains is +preloaded to always be cached across circuits. We compare the performance of a +preloaded DNS cache to Tor's current solution towards DNS by measuring +aggregated statistics for four months from two exits (after engaging with the +Tor Research Safety Board and our university ethical review process). The +evaluated preload lists are variants of the following top-lists: Alexa, Cisco +Umbrella, and Tranco. Our results show that four-months-old preload lists can be +tuned to offer comparable performance under similar resource usage or to +significantly improve shared cache-hit ratios (2--3x) with a modest increase in +memory usage and resolver load compared to a 100 Mbit/s exit. We conclude that +Tor's current DNS cache is mostly a privacy harm because the majority of cached +domains are unlikely to lead to cache hits but remain there to be probed by +attackers. diff --git a/summary/src/tlwo/src/acknowledgements.tex b/summary/src/tlwo/src/acknowledgements.tex new file mode 100644 index 0000000..84302c0 --- /dev/null +++ b/summary/src/tlwo/src/acknowledgements.tex @@ -0,0 +1,20 @@ +\section*{Acknowledgments} +Many thanks to + Georg Koppen and + Marc Juarez +for engaging with us in continuous Tor Research Safety Board discussions, as +well as + Elias Rudberg, + Johan Nilsson, and + Linus Nordberg +who operated our modified Tor relays at the premises of DFRI. +We would further like to thank our shepherd, the anonymous reviewers, + Mike Perry, + Nick Mathewson, + Paul Syverson, and + Roger Dingledine +for their valuable feedback. +The authors were supported by + Mullvad VPN, + the Swedish Foundation for Strategic Research, and + the Swedish Internet Foundation. diff --git a/summary/src/tlwo/src/attack.tex b/summary/src/tlwo/src/attack.tex new file mode 100644 index 0000000..542cdb3 --- /dev/null +++ b/summary/src/tlwo/src/attack.tex @@ -0,0 +1,247 @@ +\section{Timeless Timing Attack} \label{tlwo:sec:attack} + +Past work demonstrated timing attacks against Tor's DNS cache~\cite{wfwo}. In +short, anyone can observe the latency of a domain lookup to determine if it is +more or less likely that an answer is (not) cached. A quick response is more +likely to be cached, thereby leaking information about past traffic on an exit. +A downside of such a remote timing attack is that it is subject to network +jitter while traversing hops in the Tor network. We show how to bypass this +limitation by constructing a timeless timing attack that is immune to network +jitter~\cite{timeless}. Notably the attack only requires Internet access and a +very modest computer. + +Section~\ref{tlwo:sec:attack:detailed} outlines the attack, followed by a description +of our prototype implementation in Section~\ref{tlwo:sec:attack:prototype}, +evaluation in Section~\ref{tlwo:sec:attack:measurements}, as well as ethical +considerations in Section~\ref{tlwo:sec:attack:ethical}. + +\subsection{Detailed Description} \label{tlwo:sec:attack:detailed} +An exit's processing of an incoming RESOLVE cell depends on if an answer is +cached or not, see Figure~\ref{tlwo:fig:resolve}. An answer may already be available +and a RESOLVED cell can be scheduled for sending immediately (``cached''). +Otherwise an answer is not yet available and a resolve process needs to take +place concurrently to avoid blocking (``uncached''). We construct a timeless +timing attack by exploiting the fact that scheduling RESOLVED cells for sending +with different concurrent timings depend on if an answer is cached (send +immediately) or uncached (send based on an event later on)~\cite{ctor-1}. + +\begin{figure}[!t] + \centering + \includegraphics[width=.67\columnwidth]{src/tlwo/img/resolve} + \caption{% + Processing of an incoming RESOLVE cell at an exit relay. + Answers of concurrent resolves are triggered by events. + } + \label{tlwo:fig:resolve} +\end{figure} + +\subsubsection{Attack Outline} + +Suppose that we craft two RESOLVE cells for \texttt{example.com} and +\texttt{evil.com} such that they are processed by an exit \emph{directly after +each other without any events in between}. Further suppose that +\texttt{evil.com} is cached. The first RESOLVE cell is \texttt{example.com}. +The second RESOLVE cell is \texttt{evil.com}. Following from the flow in +Figure~\ref{tlwo:fig:resolve}, we can determine if \texttt{example.com} is (un)cached +by observing only the order in which the two RESOLVED cells come back. The +order will be switched if \texttt{example.com} needs concurrent resolving +because \emph{the answer is not available until after an event} (uncached). +Otherwise the order is preserved (cached). Sending two requests to be processed +at the same time and exploiting concurrency as well as differences in processing +time that affects the response order is what makes it +\emph{timeless}~\cite{timeless}. + +Figure~\ref{tlwo:fig:timeless} provides a detailed description on how to satisfy the +presumed setup. The attacker starts by looking up its own domain name for a +selected exit. This ensures that \texttt{evil.com} is cached. Next, two RESOLVE +cells are sent in the same TLS record from a hop proceeding the exit. Both cells +will be unpacked at the same time by TLS~\cite{ctor-2}, +% Note: input parameter at_most is set to -1 by tor's main loop +and when processing starts all available cells will be handled before giving +control back to Tor's main loop~\cite{ctor-3}. +Now recall that Tor is single-threaded. An event from any concurrent DNS +resolve can thus not be completed before all unpacked cells were fully +processed. This ensures that the order in which our two RESOLVED cells come +back in is guaranteed to leak if \texttt{example.com} is (un)cached as long as +both RESOLVE cells arrived together in-order and \texttt{evil.com} is really +cached. + +\begin{figure}[!t] + \centering + \subfloat[][uncached]{% + \includegraphics[width=.7\columnwidth]{src/tlwo/img/uncached} + \label{tlwo:fig:timeless:a} + }\\ + \subfloat[][cached]{% + \includegraphics[width=.7\columnwidth]{src/tlwo/img/cached} + \label{tlwo:fig:timeless:b} + } + \caption{% + The attacker ensures a domain \texttt{evil.com} is cached. Next, two + RESOLVE cells are sent to arrive at the same time in-order. The relay + processes both cells before triggering any resolve event. This means + that answers can only be sent directly if no resolving is needed. The + order of RESOLVED cells switch if \texttt{example.com} is uncached. + Otherwise the order is preserved. } + \label{tlwo:fig:timeless} +\end{figure} + +It should be noted that an attacker can gain full control of how their TLS +records are packed to exits by either running a modified Tor relay or creating +one-hop circuits. In practise, it is also possible to omit the step of caching +\texttt{evil.com} and instead send a \texttt{RESOLVE} cell containing an IP +address. Tor will simply echo the IP as if it was cached~\cite{ctor-4}. We +describe the attack without this optimization because it is more general. + +\subsubsection{Repeated Attack to Learn Insertion Time} +So far we described how to determine if a domain is (un)cached at an exit. +Figure~\ref{tlwo:fig:attack-repeated} shows how to derive the exact time that a +domain was added to an exit's DNS cache. First determine whether the domain's +TTL will be clipped to 300 or 3,600 seconds by observing the TTL returned from +the authoritative name server or the configured resolvers of the +exit~\cite{GreschbachPRWF17}. Then repeat the timeless timing attack +periodically until the domain is no longer cached, say, once per second. Suppose +the expected clip is 300 seconds and the attack started at time $t$. If it +takes $x < 300$ seconds for the entry to become uncached, it was added to the +exit's DNS cache at time $t+x - 300\textrm{s}$. Observing $x > 300$ seconds +means that a different party inserted the entry into the cache between probes +(may happen for some of the most frequently looked-up domains, depending on +probing frequency). To recover, the attacker can perform the same steps again +until they succeed. For example, with two tries the initial insertion happened +at $t+x - 600\textrm{s}$. Notably these estimates cannot be more precise than +the attacker's repetition interval. + +\begin{figure}[!t] + \centering + \includegraphics[width=.53\columnwidth]{src/tlwo/img/repeat-attack} + \caption{% + Repeated timeless timing attack to infer the exact time that a domain + was cached by someone at an exit relay. For example, if the expected + clip is 300s ($\mathsf{ttl}\le300$s), the attack is repeated every + second, and the observed $x$ is 40s, then caching of + \texttt{example.com} happened at time $\approx t-260$s. } + \label{tlwo:fig:attack-repeated} +\end{figure} + +\subsubsection{Discussion} +While an attacker can determine if a domain is cached by an exit and if so the +exact time it was added, the attacker cannot determine the number or timings of +lookups for a domain after entering the cache. In isolation, the attacker also +cannot determine which identifiable user cached a given domain. + +It is easy to conduct the attack in parallel because +probing for the status of \texttt{foo.org} is completely independent from +\texttt{bar.org} at the same relay as well as other probes on different relays. +In other words, an attacker can probe a single domain on all exits +simultaneously, many different domains at a single exit, or both. Network-wide +probes for the same domain may be detectable by observing the DNS caches of +multiple relays and correlating their contents. However, note that a risk-averse +attacker~\cite{AumannL07} may spread their probes over time (five or sixty +minutes) and domains (expected twelve domains per website on Alexa top-1M +websites~\cite{GreschbachPRWF17}), if the goal is to confirm a website visit. + +An example use-case for a parallel attack is answering network-wide queries, for +example, ``is \texttt{foo.org} visited more frequently than \texttt{bar.org}, or +did any Tor user visit \texttt{baz.org} at a particular point in time?'' The +latter is an instantiation of a so-called website oracle~\cite{wfwo}. Website +oracles remove virtually all false positives in WF attacks for all but the most +popular websites on the web, and WF attacks may connect identifiable users with +visited websites. See Figure~\ref{tlwo:fig:setting} in +Section~\ref{tlwo:sec:introduction} for an overview of this attack setting. + +\subsection{Prototype Implementation} \label{tlwo:sec:attack:prototype} + +We prototyped our timeless timing attack so that it runs for a given exit and a +list of domains. Figure~\ref{tlwo:fig:attack} shows the overall setup which consists +of \texttt{carml}, +\texttt{tor-resolve}, a locally patched Tor process, and a Python script +automating the entire setup. First Tor is started, a \emph{one-hop circuit} is +built to the selected exit, and all streams are attached to it using +\texttt{carml}. Next, \texttt{tor-resolve} is used to send a special lookup +query for \texttt{example.com} by simply appending a magic string +\texttt{---sc}. The patched Tor process splits such requests into two RESOLVE +cells in the same TLS record: one for the specified domain, and another one that +is guaranteed to not need any concurrent resolving. Finally Tor sets the output +to \texttt{0.0.0.0} if the resulting RESOLVED cells switched order, otherwise +\texttt{1.1.1.1} (arbitrary constants). +After processing all domains Tor is closed and the output +is a list where each item is zero (uncached), one (cached), or negative +(unknown, e.g., due to a resolve timeout, a stream attach failure, or a vanished +circuit). +The complete attack required less than 100 lines of C to patch Tor, as well as +200 lines of Python to make it fully automated. + +\begin{figure}[!t] + \centering + \includegraphics[width=.53\columnwidth]{src/tlwo/img/attack} + \caption{% + Local attack setup consisting of \texttt{carml} to build one-hop + circuits, \texttt{tor-resolve} to inject queries, and a patched + tor process that transforms them into timeless timing attacks. + } + \label{tlwo:fig:attack} +\end{figure} + +\subsection{Network Measurements} \label{tlwo:sec:attack:measurements} + +We conducted measurements in the live Tor network to evaluate the reliability of +our prototype with four parallel instances of +the setup in Figure~\ref{tlwo:fig:attack} on a system with an Intel(R) Xeon(R) CPU +E5-2630 @ 2.30GHz and 4GB of DRAM. All targeted domains were our own, see +ethical considerations in Section~\ref{tlwo:sec:attack:ethical}. In total there were +$14,446$ runs between May 17--26, 2022. Each run used an exit that was sampled +uniformly at random. Assuming $1,000$ exits at all times (conservative), the +individual select probability should not exceed $0.004$ per run. Each run +performed up to $1,000$ timeless timing attacks, chunked into $500$ attacks per +circuit and alternating between uncached and cached lookups by specifying a +unique domain twice in a row: \texttt{<counter>.<timestamp>.<instance +id>.example.com}. The maximum runtime was set to ten minutes. Each query also +had a ten second timeout. In the advent of errors like circuit failure or +timeouts, the remainder of the run was canceled but all results up until that +point were collected. The average number of DNS requests leaving the Tor +network from \emph{all four combined instances} was $8.6$ per second. The +effective queries per second was slightly higher due to brief pauses while +setting up a new run. For reference, Sonntag reported in 2018 that the DNS +resolver of an exit with $200$Mbit/s received an average and maximum of $18$ and +$81$ requests per second~\cite{sonntag-metrics}. Earlier, +Figure~\ref{tlwo:fig:lookups} also showed significant variability in lookups. +Handling our per-exit overhead during a couple of minutes should thus be +insignificant when compared to regular patterns for DNS traffic in the network. + +Table~\ref{tlwo:tab:attack} summarizes our results. After 12M timeless timing +attacks, there were no cases of uncached lookups being reported as cached and +vice versa. This is consistent with the description in +Section~\ref{tlwo:sec:attack:detailed}: neither false positives nor false negatives +are expected. The observed probability to not get an answer due to +detectable failures were $0.00025$. + +\begin{table}[!t] + \centering + \caption{% + Timeless timing attack results. Neither false negatives nor + false positives were observed with 6M repetitions each. + } + \begin{tabular}{c|ccc} + Type & Got uncached & Got cached & Failures \\ + \hline + Uncached & $6,034,779$ & $0$ & $2,858$ \\ + Cached & $0$ & $6,034,594$ & $142$ \\ + \end{tabular} + \label{tlwo:tab:attack} +\end{table} + +\subsection{Ethical Considerations} \label{tlwo:sec:attack:ethical} + +We responsibly disclosed our attack to the Tor Project through their security +list. The submitted disclosure included a theoretical attack description, a +prototype implementation with measurements showing how reliable it was, as well +as a sketch of short-term and long-term defenses. As part of our dialog, we also +coordinated with the Tor Project on submitting this paper to USENIX Security to +get peer review. + +The conducted network measurements targeted domains under our own control. This +ensured that we did not learn anything about real Tor users. Performance +overhead on exits and the Tor network at large was also modest, see +Section~\ref{tlwo:sec:attack:measurements}. In other words, the downsides were +negligible while the significance of evaluating \emph{real-world reliability} +was helpful to inform and motivate the need for mitigations and defenses. diff --git a/summary/src/tlwo/src/availability.tex b/summary/src/tlwo/src/availability.tex new file mode 100644 index 0000000..cff4dbc --- /dev/null +++ b/summary/src/tlwo/src/availability.tex @@ -0,0 +1,19 @@ +\section*{Availability} \label{tlwo:sec:availability} +We make the following three artifacts available: + +\begin{enumerate} + \item Patches to Tor, associated scripts and data, and documentation for + performing timeless timing attacks. + \item The measurement data from our two exits, a detailed timeline of + operations, scripts for creating extended preload lists, and associated + Python scripts for parsing all stats and generating figures. + Sharing of the dataset was discussed as part of the contact with the Tor + Research Safety Board and our university ethical review process. Relevant + parts of our research safety board contact are included in our artifact. + \item Contributions to the Tor Project, including source code and associated + tooling for our Fuzzy TTLs mitigation and preload defense. +\end{enumerate} + +See +\url{https://gitlab.torproject.org/rgdd/ttapd} +to locate the above. diff --git a/summary/src/tlwo/src/background.tex b/summary/src/tlwo/src/background.tex new file mode 100644 index 0000000..719dec6 --- /dev/null +++ b/summary/src/tlwo/src/background.tex @@ -0,0 +1,73 @@ +\section{Background} \label{tlwo:sec:background} +The remainder of the paper requires preliminaries about DNS +(Section~\ref{tlwo:sec:background:dns}), in particular in relation to Tor +(Section~\ref{tlwo:sec:background:tor}). + +\subsection{DNS} \label{tlwo:sec:background:dns} DNS is a hierarchical system that +maps domain names (``domains'') to IP addresses. The hierarchy is composed of +root servers, top-level domain (TLD) servers, and authoritative name servers. +Root servers are aware of TLD servers like \texttt{.com}. TLD servers are aware +of authoritative name servers in their zone like \texttt{example.com}. +Authoritative name servers are aware of the actual answers to a domain lookup. +A domain lookup for \texttt{example.com} involves asking the root server for the +TLD server of \texttt{.com}; the TLD server for the authoritative name server of +\texttt{example.com}; and finally the authoritative name server for the IP +address of \texttt{example.com}. The resolve process is typically performed +iteratively in plaintext over UDP by a third-party resolver that caches +responses, e.g., to improve performance. The default is usually to rely on ISP +DNS resolvers. It is also possible to configure other ones, e.g., Google's +\texttt{8.8.8.8} or self-hosted using \texttt{unbound}, \texttt{bind}, etc. + +Of note is that the resolved domains are associated with a Time To Live (TTL) +value. As the name suggest, it is the amount of time that a resolved domain +should be considered fresh. TTL values are sometimes overridden in caches to +improve reliability~\cite{rfc8767,MouraHMSD18} or preserve +privacy~\cite{GreschbachPRWF17}. + +\subsection{Tor} \label{tlwo:sec:background:tor} +The Tor network is composed of thousands of relays that route encrypted traffic +on behalf of millions of daily users~\cite{tor,ManiWJJS18}. Ordinary uses of +Tor include preserving privacy, safety and freedom as well as facilitating +dissent and circumventing censorship~\cite{tpo-russia,tpo-who-uses-tor}. Access +to the Tor network is easy using Tor Browser (TB), which is configured to proxy +all traffic through a local Tor process that takes care of routing. TB adds +many other protections that are orthogonal to our work~\cite{tb}. + +During a regular website visit a circuit is built through a guard, middle, and +exit relay. The first relay is fixed in a small guard set that rarely changes +once selected, while the middle and exit relays are randomly selected weighted +by bandwidth for each new circuit. A circuit may have many streams (analogous +to TCP/IP connections), typically corresponding to separate flows for a +particular destination. Control traffic and data is transported through the +network in fixed-size cells that are encrypted in layers. At each hop in a +circuit, one layer of encryption is peeled-off. Outstanding cells from relay A +to relay B are sent in a shared channel that is TLS protected. Public keys, +relay identities, and more are discovered in Tor's consensus, which is secure if +a threshold of trusted directory authorities act honestly. + +We are particularly interested in how Tor interacts with DNS. To look up a +domain, the user's Tor process may send a RESOLVE cell that requests resolution +by the exit. Some exits are configured with their own iterative resolvers, +while others rely on DNS from their ISP or other +third-parties~\cite{GreschbachPRWF17}. The answer to a lookup is stored in the +exit's cache, but with the TTL \emph{clipped} to 300 or 3600 seconds depending +on if the TTL is $\le 300$ seconds or not. A RESOLVED cell is then sent to the +user, who only gets to see the clipped TTL regardless of how long it has been +stored in the cache to avoid leaking information about past exit traffic (like +the insertion time which would be trivial to infer from a counted-down TTL). If +too many entries are added to Tor's DNS cache and memory becomes a scarce +resource, an Out-Of-Memory (OOM) job deletes domains until freeing enough +memory. This is all controlled by an event-driven single-threaded main loop. + +Of further note is that TB is based on Firefox. As part of connecting to a +website, DNS is handled transparently through a SOCKS proxy provided by the +local Tor process. Requests to connect to a domain through the SOCKS proxy +results in the user's Tor process sending a BEGIN cell to establish a connection +to the destination, which in turn triggers domain resolution at the exit. In +other words, there are two ways to look up domains: RESOLVE cells and BEGIN +cells. At no point is any resolved IP address cached in TB or in the user's Tor +process. This prevents shared state (the cache) from being used to +fingerprint a user's activity across different circuits. + +We continue our introduction to Tor's DNS cache next while describing the +first measurement of its performance. diff --git a/summary/src/tlwo/src/conclusion.tex b/summary/src/tlwo/src/conclusion.tex new file mode 100644 index 0000000..485c593 --- /dev/null +++ b/summary/src/tlwo/src/conclusion.tex @@ -0,0 +1,52 @@ +\section{Conclusion} \label{tlwo:sec:conclusion} +Our timeless timing attack on Tor's DNS cache is virtually perfect, +significantly improving over earlier timing attacks~\cite{wfwo}. Based on 12 +million measurements in the live Tor network, we only observed a 0.00025 failure +rate due to vanished circuits and other transient networking errors that are +easy to account for. We responsibly disclosed the attack to the Tor Project +and coordinated the process around defenses with them. + +Our proposed mitigations are just that---mitigations---and do not completely +address the underlying issues. The fuzzy TTLs mitigation primarily addresses +confirmation with WF attacks involving moderately popular domains. Cover +lookups, while valuable if done, does not scale and requires continuous efforts +that are not easily automated on a large scale. + +Setting out to find long-term solutions, we landed in redesigning Tor's DNS +cache completely with a preload design. To inform the design and to evaluate its +feasibility, we ran a four-month experiment starting in May 2022 measuring key +performance metrics. To ensure that our measurements were safe, we repeatedly +consulted the Tor Research Safety Board and completed our university ethical +review process. We received positive feedback as well as invaluable suggestions +along the way to minimize any potential harm to the Tor network and its users. + +First, the preload design is immune to timing and timeless attacks due to never +sharing any data in the DNS cache injected due to user activity across circuits. +Secondly, the preload lists of domains based on extended Alexa, extended Tranco, +and Cisco Umbrella all show impressive cache-hit ratios. Depending on list, it +is possible to get comparable cache-hit ratios, memory usage, and resolver load +as Tor today. More extensive lists can trade modest increases in memory and +resolver load with significantly higher cache-hit ratios, especially for web +traffic. Important future work is improving how the extended lists are +generated---e.g., by tailoring them specifically for relays in certain regions +(location sensitivity), excluding unique tracking domains, or crawling websites +to discover subdomains---which is likely to lead to higher cache-hit ratios and +smaller lists. + +One of the biggest downsides of the preload design is that the most effective +preload lists are extended lists based on Alexa or Tranco, requiring continuous +efforts to update. Fortunately, our measurements show that even four-month-old +extended lists remain effective with significant improvement over baseline Tor. +It is likely feasible for the Tor Project to generate and ship hard-coded +preload lists as part of regular Tor releases and still improve performance +compared to today. + +Like Mani \emph{et~al.}~\cite{ManiWJJS18}, we see that traffic in the Tor +network appears to reasonably match website/domain popularity lists like Alexa, +Tranco, and Umbrella. This is fundamental for the preload design, and likely +also a contributing factor for the observed long stability of the extended +preload lists, since the most popular sites see relatively little +churn~\cite{PochatGJ19}. Finally, our measurements indicate that the Tor network +has grown by about 300\% in terms of number of streams since 2018, and that the +large majority of Tor's current DNS caching is a privacy harm rather than a +cross-circuit performance boost. diff --git a/summary/src/tlwo/src/introduction.tex b/summary/src/tlwo/src/introduction.tex new file mode 100644 index 0000000..04dd6bc --- /dev/null +++ b/summary/src/tlwo/src/introduction.tex @@ -0,0 +1,151 @@ +\section{Introduction} \label{tlwo:sec:introduction} +Tor~\cite{tor} is a volunteer-operated anonymity network composed of relays that +route encrypted traffic with low latency. +One of Tor's trade-offs is to not provide anonymity against a global passive +attacker that observes traffic as it enters and leaves the +network~\cite{trilemma,tor}. +A typical attacker setting is therefore to only observe encrypted traffic as it +enters the network from an identifiable user, forcing traffic analysis of the +encrypted packets to classify the user's behavior. An attacker that tries to +classify visited websites is said to perform Website Fingerprinting +(WF)~\cite{cheng1998traffic,HerrmannWF09,Hintz02,DBLP:conf/ccs/LiberatoreL06,PanchenkoNZE11,DBLP:conf/sp/SunSWRPQ02}. +Many questions about the practicality of WF attacks have been raised, ranging +from how to keep a trained dataset updated to managing false +positives~\cite{onlinewf,JuarezAADG14,perryCrit,realistic}. False positives in +WF may be ruled out using side-channels~\cite{JuarezAADG14,wfwo}. For example, +an attacker with access to (traffic to~\cite{SibyJDVT20}) Google's public DNS +resolver can use it to confirm if a website visit really happened over +Tor~\cite{GreschbachPRWF17}. + +Side-channels that leak information about exiting traffic are in fact +many~\cite{wfwo}. For example, during the course of a website visit there may +be interactions with DNS resolvers, OCSP responders, real-time bidding +platforms, and CDNs. An attacker that is able to query or gain access to the +resulting datasets learns partial information about destination traffic, notably +without ever observing any of the exiting TCP flows typically associated with +correlation attacks on Tor~\cite{JohnsonWJSS13,deepcorr}. Depending on the ease +of accessibility (e.g., does it require Google reach), reliability (e.g., are +there any false positives), and coverage (e.g., is it only applicable for a +small fraction of exit traffic), the impact of a given side-channel will be more +or less urgent to address with mitigations and/or defenses~\cite{tor}. + +\subsection{Timeless Timing Attacks in Tor's DNS} +Timing attacks exploit that an operation takes more or less time to execute +depending on something secret. The attacker's goal is to infer the secret +information by merely observing the non-constant execution times, e.g., to +recover a private key~\cite{timing-attack}, decrypt a ciphertext~\cite{lucky13}, +or check if a domain is cached by a Tor exit~\cite{wfwo}. A remote timing +attack takes place over a network. Repeated measurements and statistics are +usually required to account for network jitter, which adds noise to the observed +timings~\cite{remote-timing-attacks}. Van Goethem~\emph{et~al.}~\cite{timeless} +proposed a technique that eliminates all network jitter in remote attacks. It is applicable if +two requests can be sent to arrive at the same time, request processing is +concurrent, and the order in which responses are returned reflects differences in +execution time. + +We find that Tor's DNS cache at exits fulfills all three criteria of a timeless +timing attack, allowing anyone to determine if a domain is cached or not by +sending a single TLS record. The attack is reliable (neither false positives +nor negatives), confirmed by using our prototype to make 12M network +measurements against our own domains. The attack is also repeatable, making the +exact time that a domain was inserted into the cache inferable due to +determinism in Tor's TTL logic. + +Figure~\ref{tlwo:fig:setting} provides a summary of how the ability to infer whether +domains are (un)cached at exits make WF attacks more practical. +The attacker observes encrypted traffic from a client +to a guard relay at time $t$, classifying the network trace as associated with +\texttt{foo.org}. The attacker then conducts timeless timing attacks against +all exits in the Tor network to determine if \texttt{foo.org} was really visited +by \emph{someone} at time $t$. If the answer is yes the classification is +accepted, otherwise it is rejected. Prior work by Pulls and Dahlberg show that +the capability to determine whether a website was visited from Tor at time $t$ +removes virtually all false positives in WF attacks for all but the most popular +websites on the web~\cite{wfwo}. We provide further evidence that this is a +realistic capability to assume by demonstrating that \emph{any attacker with an +Internet connection could have used it in attacks for the last two decades}. +While it is a powerful capability to eliminate false positives, the overall +success in linking users with their website visits also depends on the WF +attack~\cite{onlinewf,JuarezAADG14,perryCrit,realistic}. + +\begin{figure}[!t] + \centering + \includegraphics[width=0.67\columnwidth]{src/tlwo/img/setting} + \caption{% + WF with an attacker that rules out false positives by checking + that the expected DNS records were cached at the right time by + conducting timeless timing attacks against exits. + } + \label{tlwo:fig:setting} +\end{figure} + +\subsection{Preload Defenses and Measurements} +Patching Tor's DNS cache to resist (timeless) timing attacks is challenging +without hurting performance. For example, making all DNS lookups constant time +would defeat the purpose of having a cache. The idea of our long-term defense +is to remove harmful cross-circuit caching that is unlikely to boost performance +while still safely caching useful domains. The Tor-network measurements of Mani +\emph{et~al.}~\cite{ManiWJJS18} tell us that web-traffic from the Tor network +matches that of the rest of the Internet, following popularity lists like +Alexa~\cite{alexa}. What should boost cross-circuit performance is the upper +parts of a representative popularity list; not the long tail of infrequently +visited sites. This is the intuition of our defense. Preload a list of popular +domains that are cached and continuously refreshed by all exits. A domain name +is either always cached as part of the preload list or not shared across +circuits at all. + +We conduct four months of measurements in the live Tor network to evaluate 400 +popularity lists derived from Alexa~\cite{alexa}, Cisco +Umbrella~\cite{umbrella}, and Tranco~\cite{tranco}. To put our results into +perspective, we also measure a baseline of Tor's current DNS cache performance. +The measurement method is to collect aggregated counters every 15 minutes, e.g., +the number of lookups cache-hits, and memory overhead, from two 100 Mbit/s +relays with web and permissive exit port policies. + +Tor's mean \emph{cross-circuit} cache-hit ratio is currently 11\% (web) and 17\% +(permissive). Variants of Alexa/Tranco top-200 (web) and Alexa/Tranco top-700 +(permissive) achieve the same cross-circuit cache-hit ratios. A preload list +from the top-10k can achieve 2--3 times higher cross-circuit cache-hit ratios at +the cost of at most 60 MiB memory and some increased resolver load (manageable +in part due to RFC 8767~\cite{rfc8767}). Throughout the entire measurement we +noted only a slight decline in effectiveness while using stale preload lists +(i.e., when using four-month-old lists at the end). This adds to the feasibility +of using preload lists, as in practice someone has to assemble and deliver them +to all exits in the Tor network. + +\subsection{Contributions and Outline} +Our contributions are as follows: + +\begin{itemize} + \item Performance measurements of the DNS cache in Tor over four months from + two exits, showing an average 80--83\% cache-hit ratio with approximately + 10,000 entries in the cache; around 11--17\% of the observed cache hits are + due to the cache being shared across circuits, and the number of lookups + appears weakly correlated with exit probability + (Section~\ref{tlwo:sec:torcache}). + \item Demonstration of a timeless timing attack that probes for cached + domains in Tor's DNS cache without any false positives or false + negatives after 12M repetitions against our own domain in the Tor + network (Section~\ref{tlwo:sec:attack}). + \item Mitigations based on fuzzy TTLs and cover lookups that add some + limited short-term protections (Section~\ref{tlwo:sec:short}). + \item A long-term redesign of Tor's DNS cache that defends against + (timeless) timing attacks. Cache-hit ratios can be tuned to offer + comparable performance under similar resource usage as today or to + significantly improve shared cache-hit ratios (2--3x) with a modest + increase in memory usage and resolver load, notably invariant to + exit probability as preload lists are fixed (Section~\ref{tlwo:sec:long}). +\end{itemize} + +Section~\ref{tlwo:sec:background} provides necessary background on DNS and Tor, +Section~\ref{tlwo:sec:related} discusses related work, and +Section~\ref{tlwo:sec:conclusion} offers conclusions, followed by the availability of +our research artifacts. + +We would like to highlight that Sections~\ref{tlwo:sec:torcache:ethics}, +\ref{tlwo:sec:attack:ethical}, and \ref{tlwo:sec:long:preload:ethics} describe ethical and +safety precautions to ensure that no users were harmed by our research and to +maximize its positive impact. We responsibly disclosed our timeless timing +attack to the Tor Project and engaged with the Tor Research Safety Board as well +as our university's ethical review process as part of performing network +measurements to inform our defenses. diff --git a/summary/src/tlwo/src/long.tex b/summary/src/tlwo/src/long.tex new file mode 100644 index 0000000..16331ac --- /dev/null +++ b/summary/src/tlwo/src/long.tex @@ -0,0 +1,473 @@ +\section{Redesigning Tor's DNS Cache} \label{tlwo:sec:long} +To address (timeless) timing attacks in Tor's DNS cache we considered a +number of possible smaller changes. All of them failed for different reasons, +however. Section~\ref{tlwo:sec:long:strawman} presents a straw-man design that is +helpful to understand \emph{why}, while at the same time being closely related +to the properties achieved by the preload DNS cache design in +Section~\ref{tlwo:sec:long:preload}. Section~\ref{tlwo:sec:long:evaluation} presents an +extensive evaluation that answers questions about how feasible and performant +our proposal is. + +\subsection{Straw-man Design} \label{tlwo:sec:long:strawman} +We omit all but one +straw-man design that is particularly important to understand the proposed +redesign in Section~\ref{tlwo:sec:long:preload}: \emph{simply remove Tor's DNS +cache}. If there is no DNS cache to speak of in Tor, it is easy to see that +there cannot be any (timeless) timing attacks against Tor's DNS cache (because +it does not exist). What these attacks would instead target is the exit's DNS +resolver which also has a cache. At a first glance it may seem like an +insignificant improvement that just moves the problem elsewhere. This would be +the case if every exit used its own dedicated DNS resolver. However, an exit may +share a resolver with other exits or most importantly clients outside of the Tor +network. A prime example is the resolver of the ISP of the exit. Any inference +made from the state of shared resolvers would thus not be directly attributable +to activity on the Tor network. This would therefore make \emph{false positives} +a reality with regards to if a domain was cached or not as a consequence of +activity in the Tor network. + +Introducing false positives to the timeless timing attack itself is in general +challenging because an answer needs to be available at the same time regardless +of there being a cache hit or miss. False negatives may seem easier and could +make the attacker discard otherwise correct classifications, e.g., because an +attack only works half of the time. However, without false positives, attackers +are still able to reliably remove otherwise incorrect classification through +confirmation~\cite{wfwo}. Because websites typically make use of multiple domain +names, defenses that add random delays to responses (to cause false negatives) +would need to consistently add similar delays for all relevant domains tied to +websites or other user activity the attacker is trying to infer. The semantics +surrounding user activity is hard if not impossible to capture at the DNS level. +Therefore, all false negative defenses we could think of failed. + +Now suppose that Tor has no DNS cache and exits always use a shared resolver +that may introduce false positives. +A major downside is that performance would take a significant hit due to the +lack of a cache in Tor, especially since a shared resolver is likely not running +locally, but provided by the ISP or some third-party. It is likely that both +page-load latency and resolver load would increase. Worsening performance and +especially latency is the opposite of what the Tor project is working +towards~\cite{tor,tor-congestion}. Next we show how to get the good properties +of not having a DNS cache in Tor (potential for false positives) while improving +performance. + +\subsection{The Preload DNS Cache} \label{tlwo:sec:long:preload} +This is not only a defense against (timeless) timing attacks in the DNS cache, +but a complete redesign of Tor's DNS cache. Ultimately, \emph{what we want to +achieve is false positives for an attacker trying to determine client activity +in the Tor network with the help of DNS}. The only way to achieve this---upon +learning that a domain associated with some activity has been looked up---is if +there is a possibility that this domain lookup was caused from outside of the +Tor network. Therefore, as a starting point, we assume that the Tor Project +would strongly encourage exit operators to not run local resolvers dedicated to +exits. Instead, exit operators should configure their systems to use their ISP +resolvers or use a third-party provider. Greschbach +\emph{et~al.}~\cite{GreschbachPRWF17} investigated the effect of DNS on Tor's +anonymity, including resolver configuration, and found that using the ISP's +resolver would be preferable. + +First remove all of Tor's current DNS caching as in our straw-man design. The +preloaded DNS cache instead contains two types of caches: a same-circuit cache +and a shared preload cache, see Figure~\ref{tlwo:fig:preload}. The preloaded cache +only contains domains from an allowlist. This allowlist is compiled by a +central party (e.g., by the Network Health team in the Tor Project) by visiting +popular sites from several different vantage points. The allowed domains are +then delivered to exits and continuously resolved to IPs by each exit. During +domain resolution on a circuit, the client's lookup first hits the preload +cache. If the domain is preloaded, a cache hit is guaranteed regardless of if +anyone performed a lookup before. Therefore, it is safe to share this cache +across circuits without leaking information about past exit traffic. On a cache +miss, the circuit's same-circuit cache is consulted. As the name suggests, this +cache is shared for streams on the same circuit but not across different +circuits. Due to Tor's circuit isolation, an attacker is unable to probe any +other cache than their own. Therefore, (timeless) timing attacks are eliminated +(similar to if Tor did not have a DNS cache at all), but without removing the +possibility of cache hits. + +\begin{figure}[!t] + \centering + \includegraphics[width=.85\columnwidth]{src/tlwo/img/preload} + \caption{% + Overview of the preloaded DNS cache design. A central party + visits sites on a popularity list from different vantage points + to compile an allowlist of domains that each relay keeps + preloaded at all times by resolving them continuously. DNS + looks-ups start in the shared preload cache and moves on to a + dynamic cache that is never shared across circuits on cache + misses. + } + \label{tlwo:fig:preload} +\end{figure} + +Including a same-circuit cache in the defense is motivated by Tor's significant +same-circuit caching to retain performance, see +Figures~\ref{tlwo:fig:metrics:hitsweb} and~\ref{tlwo:fig:metrics:hitsperm} in +Section~\ref{tlwo:sec:torcache:metrics}. One can confirm that this is most likely due +to Tor Browser opening several concurrent connections by referring to the +\texttt{network.http.max-persistent-con +nections-per-proxy} option and/or +enabling debug logging,\footnote{% + Enable debug logging in Tor Browser: \url{https://gitlab.torproject.org/tpo/applications/tor-browser/-/wikis/Hacking\#debugging-the-tor-browser} +} observing that multiple streams are often created to the same destination. +Note that these destinations are domains and not IPs, and that neither TB nor +the client-side Tor process has any notion of a DNS cache to prevent +cross-circuit fingerprinting (see Section~\ref{tlwo:sec:background:tor}). While a +hypothetical \emph{per-circuit client-side cache} would be an option, it would +per definition not be able to generate cache hits for concurrent resolves +(without violating circuit isolation, potentially leading to cross-circuit +fingerprinting) and put pressure on exits unless they do the appropriate +caching. This is why our design places the same-circuit cache at exits instead +of clients. + +A preload cache is also motivated by performance, however without any of the +harmful cross-circuit sharing. The remainder of this section explores the +performance impact of compiling an allowlist from popularity lists---like +Alexa~\cite{alexa}, Cisco Umbrella~\cite{umbrella}, and +Tranco~\cite{tranco}---by comparing the resulting cache-hit ratios to baseline +Tor today. The preloaded DNS cache is inspired by RFC 8767~\cite{rfc8767} which +allows resolvers to serve stale data in some cases (see +Section~\ref{tlwo:sec:related}). Here, exits keep domains on a preloaded allowlist +fresh on a best-effort level, serving stale records if necessary. Upon shutdown, +exits could persist IPs in the preload cache to disk as a starting point on +startup. Upon startup, if the preload cache have yet to be populated with IPs, +simply treat lookups as cache misses. We discuss periodic refresh overhead +further in Section~\ref{tlwo:sec:long:preload:resolverload}. + +\subsection{Data Collection} \label{tlwo:sec:long:preload:collection} + +As part of understanding Tor's DNS cache (Section~\ref{tlwo:sec:torcache}) we also +collected data to be able to evaluate the performance of the preload design. In +particular, we evaluate different popularity lists, the impact on cache-hit +ratio, estimated DNS cache size, and how these change over time. + +Central to the preload design is domain popularity lists. We included the Alexa +list~\cite{alexa} because that is what Mani \emph{et~al.} showed to be accurate for +Tor~\cite{ManiWJJS18}, the newer Tranco list because it may be more +accurate~\cite{tranco}, and the Cisco Umbrella list because it also contains +``non-web'' domains~\cite{umbrella}. + +In addition to considering the popularity lists, we also created \emph{extended} +lists from Alexa and Tranco by visiting each domain on those lists using the +Chromium browser and recording all requests for additional domains. We repeated +this three times from Europe, twice from the US, and twice from Hong Kong by +using a popular VPN service. Each visit was given a timeout of 20 seconds. No +pruning of the resulting extended lists of domains was done. Much can likely be +done to make these lists of domains significantly more comprehensive (e.g., by +considering popular subpages that might contain domains not on the front-page of +websites) and smaller (e.g., by pruning unique tracking domains: in one of our +biggest lists, \texttt{*.safeframe.googlesyndication.com} makes up 8\% of +domains with unique tracking subdomains with no value for caching). Another +direction to explore that could result in lists that are smaller and/or more +comprehensive would be to tailor them specifically for relays in certain +regions. For example, website visits from Europe may be treated differently by +website operators due to regulations like the GDPR. (In other words, there could +be differences with regards to \emph{domains}---not to be confused with IPs that +each relay already resolves locally---that are encountered during website +visits.) + +Based on the regular and extended popularity lists, we made several lists from +top-10 up to and including top-10,000 in increments. Further, the weekend before +each of the \emph{first four weeks} of data collection (see +Section~\ref{tlwo:sec:torcache}), we downloaded fresh popularity lists (Fridays) and +generated new extended lists (Saturdays and Sundays). We generated in total +$4*20*5 = 400$ lists: for the first four weeks, 20 lists each for \{Alexa, +Tranco, Umbrella, extended Alexa, extended Tranco\}. + +Our data collection involving the lists took place in three phases. The first +phase consisted of the first four weeks with increasingly more lists, which was +followed by two weeks of analysis of our results and dialog with the Tor +Research Safety Board. This lead us to the third and final phase of data +collection where we excluded the vast majority of lists, focusing only on +getting extended data for about eleven more weeks on the most informative and +useful lists (see Section~\ref{tlwo:sec:long:evaluation}). + +\subsection{Further Ethical Considerations} \label{tlwo:sec:long:preload:ethics} + +We discussed the preload additions as part of our other data collection, +received feedback from the Tor Research Safety Board, and passed our +university's ethical review process. + +Our rationale for why including counters for preload lists is safe was as +follows. We collect counters of aggregate lookups that would have been +cache-hits on each list over 15 minutes. Except for the top-10 lists +(non-extended), all other lists contain in the order of 100--1,000 unique +domains aggregated into a single counter. The main harm associated with the +dataset is if they enable an attacker to \emph{rule out} that a particular +website or Tor-user activity took place at our exits (see following paragraph). +So, little to no zero counters in our data is what we set out to achieve. As an +additional safety precaution our exits only have a $0.1$\% exit probability, +further making any zero counter less useful. + +Let us look more closely at the potential harm. For websites, the results of Mani +\emph{et~al.}~\cite{ManiWJJS18} tell an attacker to expect a power-law-like +distribution of website popularity in the network. As discussed in +Section~\ref{tlwo:sec:torcache:ethics}, we expect on average about 725 website visits +to each exit per 15 minute period. This is \emph{the prior of an attacker} +wishing to perform confirmation or correlation attacks. Most of the visits +should be to popular websites (per definition) and if the dataset allows an +attacker to rule such visits out it may cause harm because it is useful +information to the attacker~\cite{wfwo}. Because of this, we grouped our lists +into intervals of 100s (for top-?00) and 1000s (for top-?000). We stopped at +top-10k because we estimated little utility of caching domains of even less +popular websites. Further, to illustrate when the type of data we collect can be +harmful, the results of Mani \emph{et~al.}~\cite{ManiWJJS18} and Pulls and +Dahlberg~\cite{wfwo} tell us that at some point the logic becomes flipped in +terms of attacker utility: confirming that it was possible that a visit took +place to a \emph{rarely visited website} is useful. The popularity (i.e., +network base rate) of websites is central. We set out to only collect data on +the most popular of websites/domains, so for us, the focus is on when the +attacker can rule out website visits or some user activity: an attacker already +expects that popular websites/domains are visited. + +We analyzed the 1,330,400 sample counters we collected over the first four weeks +for different popularity lists. We found 33 zero counters. All of them belonged +to Alexa top-10 lists from different weeks! Besides Alexa top-10, the next list +with the lowest counter was Tranco top-100 from 20 May with 39 hits. Finding +empty counters for Alexa top-10 was at first very surprising, because the list +contains the most popular websites on the web (e.g., from 20 May: +\texttt{google.com}, \texttt{youtube.com}, \texttt{baidu.com}, +\texttt{facebook.com}, \texttt{instagram.com}, \texttt{bilibili.com}, +\texttt{qq.com}, \texttt{wikipedia.org}, \texttt{amazon.com}, and +\texttt{yahoo.com}). H-owever, note how the actual \emph{domains} on the list (of +\emph{websites}) do not contain the \texttt{www} prefix nor any other popular subdomain +associated with the sites. This highlights how poor the regular non-extended +lists are at capturing actual \emph{website} traffic. We can further see this +for both Alexa and Tranco in Figure~\ref{tlwo:fig:preload:heatmap}, presented next in +Section~\ref{tlwo:sec:long:preload:lists}. Even the top-10k lists have low +cache-hit ratios. + +By comparing a list with a more popular list (which should be a strict subset) +and observing the same counter value it is also possible to infer that +\emph{likely} no visits took place to the unique domains on the less popular +list. (This could happen by chance though.) We found 16,055 (1.2\%) such +samples: 5,073 to top-10k lists, 3,703 to top-[1k,10k) lists, and 7,279 to +top-[200,1k) lists. None of them were to top-100 lists. This might seem alarming +at first glance, but taking a closer look at the lists we find that only 135 of +the samples were to extended lists (77 to x-Tranco top-10k, the highest rank +list was x-Tranco top-600 with one sample). Further, only five of the samples +belonged to a list from Umbrella. The remaining 15,915 samples were to the +regular (non-extended) Alexa and Tranco lists. This is of limited use to +attackers for popular domains, because while the lists capture popular +\emph{websites}, our dataset contains counters of \emph{aggregate domain +lookups}. An inferred zero counter \emph{does not mean that no visits took +place} to \emph{websites} for the \emph{non-extended} lists. For example, if you +enter \texttt{www.google.com} or \texttt{www.wikipedia.org} into Tor Browser, +neither \texttt{google.com} nor \texttt{wikipedia.org} are actually connected +to. The recursive resolver of the exit may perform the lookup, but Tor will not, +so it is not captured in our dataset for the non-extended lists. The extended +lists, due to being generated from actual website visits, include domains +typically connected to by Tor Browser. Another example is users visiting direct +links to websites and not entering the domain manually in the browser, such as +when following links from search engines or sent through social media. + +When designing our measurements the above detail was not considered. We included +the regular popularity lists for sake of comparison. Ideally the non-extended +lists would have been effective sources for preload lists. This was evidently +not the case for Alexa and Tranco (see later results), but was the case for +Umbrella. So while what we did learn helped us understand the value of using +extended lists to improve cache hits, in hindsight we could have come to the +same conclusion without the same granularity for non-extended lists. + +In the second phase of our data collection (see +Section~\ref{tlwo:sec:long:preload:collection}), we discussed the above detail with +the Tor Research Safety Board and concluded to stop collecting data for +(non-extended) Alexa and Tranco, and to minimize the lists for future collection +to those necessary to determine the longevity of potentially useful preload +lists (based on our findings). Out of an abundance of caution, we will only +share the collected counters for non-extended Alexa and Tranco lists with +researchers for research purposes (the rest of the data is public). The counters +collected during the second phase were consistent with the data from the first +phase. + +During the third phase of data collection, we limited the collection to extended +Tranco top-\{10, 100, 1k, 2k, 4k, 5k, 7k, 10k\} lists and the Umbrella top-10k +list, all from April 29. The goal was to learn how cache hits get worse over +time with old lists. Out of 141,624 sample counters collected, three were zero +and 59 were relatively zero when compared to the more popular list. + +\subsection{Performance Evaluation} \label{tlwo:sec:long:evaluation} + +The goal of our evaluation is to determine over time: + cache-hit ratio of potential preload lists (Section~\ref{tlwo:sec:long:preload:lists}), + memory usage at exits (Section~\ref{tlwo:sec:long:preload:entries}), and + resolver load (Section~\ref{tlwo:sec:long:preload:resolverload}). + +\subsubsection{Results: Preload Lists} \label{tlwo:sec:long:preload:lists} + +\begin{figure} + \centering + \subfloat[][web]{% + \includegraphics[width=.75\columnwidth]{src/tlwo/img/plot_preload_lists-web.pdf} + \label{tlwo:fig:preload:heatmap:web} + }\\ + \subfloat[][permissive]{% + \includegraphics[width=.75\columnwidth]{src/tlwo/img/plot_preload_lists-permissive.pdf} + \label{tlwo:fig:preload:heatmap:perm} + } + \caption{% + Shared cross-circuit cache-hit ratios (\%) for selected preload lists during + the first six weeks (x-axis) of data collection. The plotted values are medians over + 24h, and dates on the y-axis show the date of original list download.} + \label{tlwo:fig:preload:heatmap} +\end{figure} + +Our dataset is extensive with 2,498,424 sample counters from 400 popularity +lists spanning about four months. Figure~\ref{tlwo:fig:preload:heatmap} shows +comprehensive heatmaps of shared cross-circuit cache-hit ratios for the web +(Figure~\ref{tlwo:fig:preload:heatmap:web}) and permissive +(Figure~\ref{tlwo:fig:preload:heatmap:perm}) exits over the first six weeks of data +collection (first and second phases). Cache-hit ratios are medians (very similar +to the mean) for 24h periods. In each figure, the groupings of the four weeks +when we added new lists are visible (top to bottom), as well as baseline Tor at +the bottom row for sake of comparison. Note how the regular Alexa and Tranco +top-10k lists perform poorly: the two black ($<5\%$ cache-hit ratio) lines at +the top of each grouping. Even Umbrella 1k is better, with Umbrella 10k being +comparable to baseline Tor. The extended lists clearly improve over baseline +Tor, with the extended 10k-lists even reaching over 30\% cross-circuit cache-hit +ratios some days. Look at how the lists change over time: we see no real +difference between lists generated at end of April and those generated during +May, but consistent changes across all lists over time, likely due to varying +traffic at the exits. The differences between using Alexa or Tranco to generate +extended lists are negligible, so we focus on Tranco for the remainder of this +analysis as it is open, maintained, and a more recent source of website +popularity~\cite{tranco}. + + +\begin{figure}[!t] + \centering + \subfloat[][web]{% + \includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_preload_hits-web.pdf} + \label{tlwo:fig:preload:hits:web} + }\\ + \subfloat[][permissive]{% + \includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_preload_hits-permissive.pdf} + \label{tlwo:fig:preload:hits:perm} + } + \caption{% + Shared cross-circuit cache-hit ratios for eight different extended Tranco + lists, Umbrella top-10k, and Tor baseline during four months in 2022.} + \label{tlwo:fig:preload:hits} +\end{figure} + +Figure~\ref{tlwo:fig:preload:hits} shows the observed \emph{cross-circuit} cache-hit +ratios for eight different extended Tranco lists, Umbrella top-10k, and Tor +baseline. We used lists from the end of April because they have the most data. +As a baseline, Tor's current DNS cache has a mean cache-hit ratio of 11\% for +web and 17\% for permissive. In terms of different popularity lists, the regular +(non-extended) Tranco and Alexa lists are ineffective: the top-10k lists are +regularly below $5\%$ for web and permissive (see +Figure~\ref{tlwo:fig:preload:heatmap}). Umbrella top-10k does much better with mean +17\% (web) and 16\% (permissive). This is slightly worse (permissive) and +comparable (web) to baseline Tor. + +The extended lists show a further improvement, comparable in terms of +\emph{average} (full duration of lists) cross-circuit cache-hit ratios to +baseline Tor at top-200 for Alexa and Tranco for web and at top-700 for +permissive. The extended lists from top-1k get (depending on which of the +compiled extended Tranco lists) 20--24\% (web) and 15--18\% (permissive) and up +to 27--32\% (web) and 22--27\% (permissive) at 10k. There is very little gain +between top-7k and top-10k. In general, the extended lists do relatively worse +on the permissive exit and the Tor baseline is higher: this makes sense, since +Alexa and Tranco are focused on websites. This is further confirmed by Umbrella +doing better as a more general-purpose domain popularity list. + +Note that Figure~\ref{tlwo:fig:preload:hits} shows the cross-circuit cache-hit ratios +for a selection of the very first preload lists we created on the April 29. The +results are very encouraging: time seems to have only a slight detrimental +impact on cache hits. After four months the larger extended lists show a +noticable performance improvement over baseline, with the exception of an odd +spike in baseline in early September (we speculate that this is DDoS-related). +The robustness of preload lists removes one of the main downsides of the preload +design, i.e., to maintain and deliver a current list to exits. It is likely +feasible to ship hard-coded preload lists as part of regular Tor releases and +still improve performance, assuming that exit operators upgrade their software a +couple of times per year. + +\subsubsection{Results: Cache Entries} \label{tlwo:sec:long:preload:entries} + +\begin{figure} + \centering + \subfloat[][web]{% + \includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_preload_entries-web.pdf} + \label{tlwo:fig:preload:entries:web} + }\\ + \subfloat[][permissive]{% + \includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_preload_entries-permissive.pdf} + \label{tlwo:fig:preload:entries:perm} + } + \caption{% + Estimated cache entries for eight different extended Tranco lists, Umbrella + top-10k, and Tor baseline.} + \label{tlwo:fig:preload:entries} +\end{figure} + +Figure~\ref{tlwo:fig:preload:entries} shows the number of cache entries needed in Tor +as-is (``baseline Tor'') and for the preload design for a range of different +popularity lists. We can accurately estimate an upper bound because we collected +the total number of entires in all same-circuit caches as part of our +measurements. This count is an upper bound, because some of those entries would +have already been cached in the preload cache. The popularity lists have static +sizes, and to be an accurate upper bound we used the largest observed size for +each list over the four weeks. + +Starting with the same-circuit cache, look at the line for extended Tranco +top-10 (``x-Tranco 10'') in Figure~\ref{tlwo:fig:preload:entries}: this extended list +contains only 90 entries, so the lines at the bottom show mostly the number of +entries used by the same circuit cache. The size of the same-circuit caches +should be proportional to the number of open circuits, and therefore follow exit +probability. Based on the data from Figure~\ref{tlwo:fig:preload:entries}, we do not +suspect this to be a significant burden. It would be trivial to cap the size +and/or prune the size as part of OOM-management, or dropping entries based on +their age would probably have little impact on performance (presumably most +value is at the start of the circuit when most streams are attached). + +Recall from Section~\ref{tlwo:sec:torcache:metrics} and +Figures~\ref{tlwo:fig:metrics:cacheweb} and~\ref{tlwo:fig:metrics:cacheperm} that the +permissive exit had a mean of 12,130 entries compared to the web exit's 7,672 +mean. We see the same figures for the baseline in +Figure~\ref{tlwo:fig:preload:entries}. Albeit slightly higher on average for the web +exit but more stable, we see that Umbrella 10k as well as extended Tranco top-1k +are about the same as Tor baseline. So with about the same memory usage as now +the preload design would offer slightly (permissive) or noticeably (web) better +cache-hit ratios. Looking at the top-2k up until top-10k extended lists we see a +significant higher memory usage (only slightly sublinear) but that comes with +significantly higher cache-hit ratios, as seen in Figure~\ref{tlwo:fig:preload:hits}. +In absolute terms, for extended Tranco top-10k, about 60,000 cache +entries---even if pessimistically assuming 1 KiB per entry---would end up using +about 60 MiB of memory for the cache. Since domains can be at most 255 bytes and +most domains are much shorter, one could clearly implement the cache +more memory-efficiently. Also, as mentioned earlier, it is likely possible to +reduce the size of the extended top-10k lists by removing useless tracking +domains. Further note that the memory needed to cache the preload list---unlike +the same-circuit cache---only depends on the size of the list, not the number +circuits or streams created at the exit. + +\subsubsection{Results: Resolver Load} \label{tlwo:sec:long:preload:resolverload} + +In general, on the one hand, improving cache-hit ratios will reduce resolver load +and scale well with increased traffic. On the other hand, continuously +refreshing domains on the preload list increases resolver load. Consider the +mean number of lookups at the web exit, 17,529, and its mean/median cache-hit +ratio of 0.80 (see Section~\ref{tlwo:sec:torcache}). This implies an expected +$3.9\gets\frac{17529(1-0.80)}{15\cdot60}$ requests per second to the exit's +resolver. For the permissive exit we observed about 7.8 requests per second. As +a source of comparison, Sonntag~\cite{sonntag-metrics,Sonntag19} reports for a +DNS resolver dedicated to a 200 Mbit/s exit in 2018 an average of 18.5 requests +per second. + +The resolver load for the different preload lists should be proportional to the +estimated number of cache entries shown in Figure~\ref{tlwo:fig:preload:entries}. The +estimated load for an extended top-1k list would be similar to current Tor, +while the extended top-10k list would see about a seven-fold increase without +changes. This may or may not be problem. Given the variability of lookups we +observed throughout our data collection (Figure~\ref{tlwo:fig:lookups}) and reported +by Sonntag, resolvers are clearly capable of dealing with increased loads. +Requests due to the preload list should be predictable, consistent, and cheap in +terms of bandwidth even for a low-capacity exit. + +Regardless, the load on resolvers could be lowered by reducing the number of +domains, e.g., the increased cache-hit ratio from top-7k to top-10k is very +small ($\approx$1\%) for a 20--30\% increase in entries. One could also increase +the internal TTLs, i.e., the frequency of refreshing the entries in the preload +cache. In Tor, this is especially practical since circuits use random exits. In +the rare case of stale data causing issues, simply create a fresh circuit. +Serving stale data is not uncommon in DNS~\cite{rfc8767}, further discussed next +in Section~\ref{tlwo:sec:related}. diff --git a/summary/src/tlwo/src/ref.bib b/summary/src/tlwo/src/ref.bib new file mode 100644 index 0000000..c62bea8 --- /dev/null +++ b/summary/src/tlwo/src/ref.bib @@ -0,0 +1,352 @@ +@misc{ctor-1, + author = {Tor Project}, + title = {{Tor source code}}, + howpublished = {\url{https://gitlab.torproject.org/tpo/core/tor/-/blob/tor-0.4.7.7/src/feature/relay/dns.c\#L600-689}, accessed 2022-06-01}, +} + +@misc{ctor-2, + author = {Tor Project}, + title = {{Tor source code}}, + howpublished = {\url{https://gitlab.torproject.org/tpo/core/tor/-/blob/tor-0.4.7.7/src/lib/tls/buffers\_tls.c\#L43-100}, accessed 2022-06-01}, +} + +@misc{ctor-3, + author = {Tor Project}, + title = {{Tor source code}}, + howpublished = {\url{https://gitlab.torproject.org/tpo/core/tor/-/blob/tor-0.4.7.7/src/core/or/connection\_or.c\#L2361-2426}, accessed 2022-06-01}, +} + +@misc{ctor-4, + author = {Tor Project}, + title = {{Tor source code}}, + howpublished = {\url{https://gitlab.torproject.org/tpo/core/tor/-/blob/tor-0.4.7.7/src/feature/relay/dns.c\#L725-732}, accessed 2022-06-01}, +} + +@misc{network-ddos, + author = {Tor Project}, + title = {{Tor Project status}}, + howpublished = {\url{https://web.archive.org/web/20220906145324/https://status.torproject.org/}}, +} + +@article{jung, + author = {Jaeyeon Jung and Emil Sit and Hari Balakrishnan and Robert Tappan Morris}, + title = {{DNS} performance and the effectiveness of caching}, + journal = {{IEEE/ACM} Trans. Netw.}, + volume = {10}, + number = {5}, + year = {2002}, +} + +@article{hao-and-wang, + author = {Shuai Hao and Haining Wang}, + title = {Exploring Domain Name Based Features on the Effectiveness of {DNS} Caching}, + journal = {CCR}, + volume = {47}, + number = {1}, + year = {2017}, +} + + + +@inproceedings{trilemma, + author = {Debajyoti Das and Sebastian Meiser and Esfandiar Mohammadi and Aniket Kate}, + title = {Anonymity Trilemma: Strong Anonymity, Low Bandwidth Overhead, Low Latency---Choose Two}, + booktitle = {{IEEE} {S\&P}}, + year = {2018}, +} + +@article{remote-timing-attacks, + author = {Scott A. Crosby and Dan S. Wallach and Rudolf H. Riedi}, + title = {Opportunities and Limits of Remote Timing Attacks}, + journal = {{ACM} Trans. Inf. Syst. Secur.}, + volume = {12}, + number = {3}, + year = {2009}, +} + + +@inproceedings{lucky13, + author = {Nadhem J. AlFardan and Kenneth G. Paterson}, + title = {Lucky Thirteen: Breaking the {TLS} and {DTLS} Record Protocols}, + booktitle = {{IEEE} {S\&P}}, + year = {2013}, +} + +@inproceedings{timing-attack, + author = {Paul C. Kocher}, + title = {Timing Attacks on Implementations of {Diffie-Hellman}, {RSA}, {DSS}, and Other Systems}, + booktitle = {{CRYPTO}}, + year = {1996}, +} + +@inproceedings{tor, + author = {Roger Dingledine and Nick Mathewson and Paul F. Syverson}, + title = {Tor: The Second-Generation Onion Router}, + booktitle = {USENIX Security}, + year = {2004}, +} + +@article{wfwo, + author = {Tobias Pulls and Rasmus Dahlberg}, + title = {Website Fingerprinting with Website Oracles}, + journal = {PETS}, + volume = {2020}, + number = {1}, +} + +@inproceedings{timeless, + author = {Tom van Goethem and Christina P{\"{o}}pper and Wouter Joosen and Mathy Vanhoef}, + title = {Timeless Timing Attacks: Exploiting Concurrency to Leak Secrets over Remote Connections}, + booktitle = {{USENIX} Security}, + year = {2020}, +} + +@inproceedings{sonntag-metrics, + author = {Michael Sonntag}, + title = {{DNS} Traffic of a {Tor} Exit Node---An Analysis}, + booktitle = {{SpaCCS}}, + year = {2018}, +} + +@inproceedings{ManiWJJS18, + author = {Akshaya Mani and T. Wilson{-}Brown and Rob Jansen and Aaron Johnson and Micah Sherr}, + title = {Understanding {Tor} Usage with Privacy-Preserving Measurement}, + booktitle = {{IMC}}, + year = {2018}, +} + +@inproceedings{tranco, + author = {{Le Pochat}, Victor and {Van Goethem}, Tom and Tajalizadehkhoob, Samaneh and Korczy\'{n}ski, Maciej and Joosen, Wouter}, + title = {Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation}, + booktitle = {NDSS}, + year = {2019}, +} + +@misc{umbrella, + author = {Cisco}, + title = {Umbrella Popularity List}, + howpublished = {\url{https://umbrella-static.s3-us-west-1.amazonaws.com/index.html}, accessed 2022-04-29}, +} + +@misc{alexa, + author = {Amazon}, + title = {Alexa Top 1 Million}, + howpublished = {\url{https://www.alexa.com/}, accessed 2022-04-29}, +} + +@inproceedings{GreschbachPRWF17, + author = {Benjamin Greschbach and Tobias Pulls and Laura M. Roberts and Philipp Winter and Nick Feamster}, + title = {The Effect of {DNS} on {Tor}'s Anonymity}, + booktitle = {NDSS}, + year = {2017}, +} + +@techreport{rfc8767, + author = {David C Lawrence and Warren Kumari and Puneet Sood}, + title = {Serving Stale Data to Improve {DNS} Resiliency}, + type = {RFC}, + institution = {IETF}, + number = {8767}, + year = {2020}, +} + +@inproceedings{Sonntag19, + title = {Malicious {DNS} Traffic in {Tor}: Analysis and Countermeasures}, + author = {Sonntag, Michael}, + booktitle = {ICISSP}, + year = {2019} +} + +@inproceedings{privcount, + author = {Rob Jansen and Aaron Johnson}, + title = {Safely Measuring {Tor}}, + booktitle = {{CCS}}, + year = {2016}, +} + +@inproceedings{privex, + author = {Tariq Elahi and George Danezis and Ian Goldberg}, + title = {{PrivEx}: Private Collection of Traffic Statistics for Anonymous Communication Networks}, + booktitle = {{CCS}}, + year = {2014}, +} + + +@inproceedings{FenskeMJS17, + author = {Ellis Fenske and Akshaya Mani and Aaron Johnson and Micah Sherr}, + title = {Distributed Measurement with Private Set-Union Cardinality}, + booktitle = {{CCS}}, + year = {2017}, +} + +@inproceedings{JansenTH18, + author = {Rob Jansen and Matthew Traudt and Nicholas Hopper}, + title = {Privacy-Preserving Dynamic Learning of {Tor} Network Traffic}, + booktitle = {{CCS}}, + year = {2018}, +} + +@inproceedings{MouraHMSD18, + author = {Giovane C. M. Moura and John S. Heidemann and Moritz M{\"{u}}ller and Ricardo de Oliveira Schmidt and Marco Davids}, + title = {When the Dike Breaks: Dissecting {DNS} Defenses During {DDoS}}, + booktitle = {{IMC}}, + year = {2018}, +} + +@misc{unbound, + author = {{NLnet Labs}}, + title = {Serving Stale Data---Unbound 1.14.0 documentation}, + howpublished = {\url{https://unbound.docs.nlnetlabs.nl/en/latest/topics/serve-stale.html}, accessed 2022-06-01}, +} + +@article{cheng1998traffic, + title = {Traffic analysis of {SSL} encrypted web browsing}, + author = {Cheng, Heyning and Avnur, Ron}, + journal = {Project paper, University of Berkeley}, + year = {1998} +} + +@inproceedings{DBLP:conf/sp/SunSWRPQ02, + author = {Qixiang Sun and Daniel R. Simon and Yi{-}Min Wang and Wilf Russell and Venkata N. Padmanabhan and Lili Qiu}, + title = {Statistical Identification of Encrypted Web Browsing Traffic}, + booktitle = {{IEEE S\&P}}, + year = {2002} +} + +@inproceedings{Hintz02, + author = {Andrew Hintz}, + title = {Fingerprinting Websites Using Traffic Analysis}, + booktitle = {{PETS}}, + year = {2002} +} + +@inproceedings{DBLP:conf/ccs/LiberatoreL06, + author = {Marc Liberatore and Brian Neil Levine}, + title = {Inferring the source of encrypted {HTTP} connections}, + booktitle = {{CCS}}, + year = {2006} +} + +@inproceedings{HerrmannWF09, + author = {Dominik Herrmann and Rolf Wendolsky and Hannes Federrath}, + title = {Website fingerprinting: attacking popular privacy enhancing technologies with the multinomial na{\"{\i}}ve-bayes classifier}, + booktitle = {{CCSW}}, + year = {2009} +} + +@inproceedings{PanchenkoNZE11, + author = {Andriy Panchenko and Lukas Niessen and Andreas Zinnen and Thomas Engel}, + title = {Website fingerprinting in onion routing based anonymization networks}, + booktitle = {{WPES}}, + year = {2011} +} + +@inproceedings{PochatGJ19, + author = {Victor Le Pochat and Tom van Goethem and Wouter Joosen}, + title = {Evaluating the Long-term Effects of Parameters on the Characteristics of the {Tranco} Top Sites Ranking}, + booktitle={{USENIX Security}}, + year={2019} +} + +@inproceedings{JuarezAADG14, + author = {Marc Ju{\'{a}}rez and Sadia Afroz and Gunes Acar and Claudia D{\'{\i}}az and Rachel Greenstadt}, + title = {A Critical Evaluation of Website Fingerprinting Attacks}, + booktitle = {{CCS}}, + year = {2014}, +} + +@misc{perryCrit, + author = {Mike Perry}, + title = {A Critique of Website Traffic Fingerprinting Attacks}, + howpublished = {\url{https://blog.torproject.org/critique-website-traffic-fingerprinting-attacks}, accessed 2022-06-01}, +} + +@article{realistic, + author = {Tao Wang and Ian Goldberg}, + title = {On Realistically Attacking {Tor} with Website Fingerprinting}, + journal = {PETS}, + volume = {2016}, + number = {4}, +} + +@inproceedings{JohnsonWJSS13, + author = {Aaron Johnson and Chris Wacek and Rob Jansen and Micah Sherr and Paul F. Syverson}, + title = {Users get routed: traffic correlation on {Tor} by realistic adversaries}, + booktitle = {{CCS}}, + year = {2013} +} + +@inproceedings{deepcorr, + author = {Milad Nasr and Alireza Bahramali and Amir Houmansadr}, + title = {DeepCorr: Strong Flow Correlation Attacks on {Tor} Using Deep Learning}, + booktitle = {{CCS}}, + year = {2018} +} + +@inproceedings{AumannL07, + author = {Yonatan Aumann and Yehuda Lindell}, + title = {Security Against Covert Adversaries: Efficient Protocols for Realistic Adversaries}, + booktitle = {{TCC}}, + year = {2007}, +} + +@inproceedings{chen, + author = {Yizheng Chen and Manos Antonakakis and Roberto Perdisci and Yacin Nadji and David Dagon and Wenke Lee}, + title = {{DNS} Noise: Measuring the Pervasiveness of Disposable Domains in Modern {DNS} Traffic}, + booktitle = {{IEEE/IFIP} {DSN}}, + year = {2014}, +} + + +@inproceedings{exitmap, + author = {Philipp Winter and Richard K{\"{o}}wer and Martin Mulazzani and Markus Huber and Sebastian Schrittwieser and Stefan Lindskog and Edgar R. Weippl}, + title = {Spoiled Onions: Exposing Malicious {Tor} Exit Relays}, + booktitle = {{PETS}}, + year = {2014}, +} + +@inproceedings{SibyJDVT20, + author = {Sandra Siby and Marc Ju{\'{a}}rez and Claudia D{\'{\i}}az and Narseo Vallina{-}Rodriguez and Carmela Troncoso}, + title = {Encrypted {DNS} -{\textgreater} Privacy? {A} Traffic Analysis Perspective}, + booktitle = {NDSS}, + year = {2020}, +} + +@misc{tpo-russia, + author = {Gustavo Gus}, + title = {Responding to {Tor} censorship in {Russia}}, + year = {2021}, + howpublished = {\url{https://blog.torproject.org/tor-censorship-in-russia/}, accessed 2022-06-01}, +} + +@misc{tpo-who-uses-tor, + author = {Al Smith}, + title = {Tor and the humans who use it}, + howpublished = {\url{https://blog.torproject.org/tor-and-the-humans-who-use-it/}, accessed 2022-06-01}, +} + +@misc{tb, + author = {Mike Perry and Erinn Clark and Steven Murdoch and Georg Koppen}, + title = {The Design and Implementation of the {Tor Browser} {[DRAFT]}}, + howpublished = {\url{https://2019.www.torproject.org/projects/torbrowser/design/}, accessed 2022-06-01}, +} + +@misc{tor-congestion, + author = {Mike Perry}, + title = {Congestion Control Arrives in {Tor} 0.4.7-stable!}, + howpublished = {\url{https://blog.torproject.org/congestion-contrl-047/}, accessed 2022-06-01}, +} + +@inproceedings{histor, + author = {Akshaya Mani and Micah Sherr}, + title = {HisTor{\(\epsilon\)}: Differentially Private and Robust Statistics Collection for {Tor}}, + booktitle = {NDSS}, + year = {2017}, +} + +@inproceedings{onlinewf, + title={Online Website Fingerprinting: Evaluating Website Fingerprinting Attacks on {Tor} in the Real World}, + author={Cherubin, Giovanni and Jansen, Rob and Troncoso, Carmela}, + booktitle={{USENIX Security}}, + year={2022} +} diff --git a/summary/src/tlwo/src/related.tex b/summary/src/tlwo/src/related.tex new file mode 100644 index 0000000..3521d45 --- /dev/null +++ b/summary/src/tlwo/src/related.tex @@ -0,0 +1,174 @@ +\section{Related Work} \label{tlwo:sec:related} + +Van Goethem \emph{et~al.}~\cite{timeless} originally proposed timeless timing +attacks, showing significant improvements against HTTP/2 web servers, Tor onion +services, and EAP-pwd. All timeless timing attacks exploit concurrent +processing, e.g., in HTTP/2, by filling buffers at the relay closest to an onion +service, or packing two authentication requests in EAP-pwd into the same RadSec +(TLS over TCP) packet. The latter was the inspiration for our timeless timing +attack on Tor's DNS cache, i.e., packing two RESOLVE cells into a single TLS +record. + +There has been a long body of work on how to safely perform measurements of the +Tor network~\cite{privex,FenskeMJS17,privcount,histor}, laying the foundation +for safely performing large-scale measurements~\cite{JansenTH18,ManiWJJS18}. Our +timeless timing attack enables anyone to do network-wide measurements for exact +domains on specific exits with a precision of at least one second. This is +highly invasive and a useful resource to deanonymize Tor-users, discussed +further shortly. Our network measurements to inform the design of defenses have +been focused around the DNS in Tor. Similar to other related work (see below), +we focused on how to make those limited measurements safe; not on how to broadly +perform a much wider range of measurements safely. + +%% ATTACK +Greschbach \emph{et~al.}~\cite{GreschbachPRWF17} investigated the effect of DNS on +Tor's anonymity. They quantified the use of DNS resolvers in the network, the +impact of choice of resolver on correlation and confirmation attacks, and how to +incorporate observed DNS traffic with website fingerprinting +attacks~\cite{cheng1998traffic,HerrmannWF09,Hintz02,DBLP:conf/ccs/LiberatoreL06,PanchenkoNZE11,DBLP:conf/sp/SunSWRPQ02} +to make improved correlation attacks. In their construction, DNS traffic is used +to either reduce the number of websites to consider during classification or to +confirm classification. A key observation was that Tor, due to a bug, clipped +all TTLs to 60 seconds. This was resolved and lead to the current approach of +clipping to 300 or 3,600 seconds. One of our short-time mitigations update +these clips to be fuzzy. + +Greschbach \emph{et~al.}~\cite{GreschbachPRWF17} also measured DNS requests from +an exit for both web and a more permissive exit policy in 2016. The collection +was done by observing DNS requests to the exit's resolver and aggregating +results into five-minute buckets. Similarly, we aggregate over time in 15-minute +buckets and do not directly collect resolved domains. They found a small +difference between exit policies, with the permissive exit having slightly fewer +(3\% smaller median) lookups. Our results are very different: the permissive +exit policy resulted in significantly more (double the median) lookups. + +Pulls and Dahlberg~\cite{wfwo} generalized the classifier confirmation attack of +Greschbach \emph{et~al.}~\cite{GreschbachPRWF17} into a new security notion for website +fingerprinting attacks, and further explored the use of DNS. They showed that +timing attacks were possible in Tor's DNS cache, performing network-wide +measurements on a domain under their control with a true positive +rate of 17.3\% when attempting to minimize false positives. We use a similar +method for measurements, but our attack is significantly better with a +100\% true positive rate and no false positives at all. + +Sonntag collected hourly data from the resolver of an exit during five months in +2018~\cite{sonntag-metrics,Sonntag19}. In terms of frequency, they noted about +18.5 requests per second, with a peak of 291,472 requests in an hour. The +average is higher than ours (3.9 and 7.8 requests per second) while the peak +significantly smaller (1,183,275 requests in 15 minutes). Sonntag also analyzed +the actual domains looked up, including categorization (porn, social network, +shopping, advertisement etc). We do not collect domains; only cache-hits as part +of popularity lists by aggregating domains into buckets like top-100, top-1k, +etc. + +Mani \emph{et~al.}~\cite{ManiWJJS18} used PrivCount~\cite{privcount} and +PSC~\cite{FenskeMJS17} to safely make extensive network-wide measurements of the +Tor network. They measured, e.g., circuits, streams, destination ports, and exit +domains at exits, as well as client connections, churn, composition, and +diversity at clients. Their exit probability ranged between 1.5--2.2\%, compared +to our peak of 0.1\%. While our data is much more limited and targeted around +DNS, there are two interesting comparisons to consider: +\begin{itemize} + % mean lookups: 17529.813 and 41099.697 + % 15 minutes x4 = 1h, 24h per day + % mean exit probabilities: 0.041% and 0.049% + % (17529.813+41099.697)×4×24÷(0.01×(0.041+0.049)) = 6,253,814,400 + + \item Mani \emph{et~al.} observed 2.1 billion exit streams inferred in the + network every 24 hours. Extrapolating on our lookup statistics we have an + average of 6.3 billion lookups, which corresponds to the number of + streams.\footnote{Streams either do a lookup with RELAY\_BEGIN or are closed + after a RELAY\_RESOLVE cell. Timeout and retries are possible on resolver + failure, but the way we measure hides those extra lookups.} This suggests a + significant increase ($\approx3x$) in the number of streams in the Tor network since 2018. + \item Mani \emph{et~al.} measured the frequency of how well the primary + domain on a circuit matched the Alexa top-one-million list. We transform + their reported relative counts and compare it to the relative count of + average lookups in the same intervals in our dataset for top-10k, shown in + Figure~\ref{tlwo:fig:mani:popularity}. Note that this only uses data from phase + one of our data collection. Broadly, we see that their results show + significantly more traffic to top-10 than any of the lists we use. That + said, our data supports one of Mani \emph{et~al.}'s conclusion that the + popularity lists are reasonably accurate representations of traffic from the + Tor network. +\end{itemize} + +\begin{figure}[!t] + \centering + \subfloat[][web]{% + \includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_popularity_match-web.pdf} + \label{tlwo:fig:mani:popularity:web} + }\\ + \subfloat[][permissive]{% + \includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_popularity_match-permissive.pdf} + \label{tlwo:fig:mani:popularity:perm} + } + \caption{% + Comparison of \emph{relative popularity} of popularity rankings with the + results of Mani \emph{et~al.}~\cite{ManiWJJS18}.} + \label{tlwo:fig:mani:popularity} +\end{figure} + +%% DNS prefetching paragraphs and software from there +% Defenses can expand on DNS prefetching +% https://datatracker.ietf.org/doc/html/rfc8767 +% https://unbound.docs.nlnetlabs.nl/en/latest/topics/serve-stale.html + +The relatively recent RFC 8767~\cite{rfc8767} allows for DNS data to be served +``stale'', i.e., after expiry according to its TTL, in the exceptional +circumstance that a recursive resolver is unable to refresh the information. In +case data goes stale, RFC 8767 suggests serving it for at most one to three days. +The background of RFC 8767 aptly motivates this with the saying that +\emph{``stale bread is better than no bread''}. In addition to serving +potentially stale data, modern resolvers like Unbound~\cite{unbound} further +support prefetching: preemptively refreshing domains in the cache before TTL +expiry. These measures all serve to improved reliability and have been found to +be used for sake of resiliency~\cite{MouraHMSD18}. Tor already clips TTLs, in a +sense serving stale data for the vast majority of domains. Our preload design +takes this further by introducing continuous prefetching of domains on a fixed +allowlist. + +Two decades ago, Jung \emph{et~al.}~\cite{jung} found that cache-hit ratios on +the order of 80--87\% are achieved if a resolver has ten or more clients and +TTLs are at least ten minutes. More recently Hao and Wang~\cite{hao-and-wang} +reported that 100k cached entries are required to achieve a baseline of 86\% +cache-hits for a first-come first-serve cache in a university network. Their +dataset had similar characteristics to a DNS trace collected for an ISP resolver +by Chen \emph{et~al.}~\cite{chen} with regards to \emph{disposable domains} that +are never requested more than once in the long-tail of DNS; out of the 11\% of +domains that are not disposable, 5\% and 30\% of them have cache-hit ratios of +at least 95\% and 80\% respectively. It appears that fewer disposable domains +are resolved in Tor because the observed cache sizes are not large enough for +89\% unique lookups. Achieving an 80\% cache-hit ratio with a cache of 10k +entries does not seem to be an outlier. + +% Chen et al. (2014), DNS noise: Measuring the pervasiveness of disposable domains in modern DNS traffic +% - ISP data set from end of 2011 +% - Fig 3, long-tail of domains with no additional look-ups (89%) +% - Fig 4, cache hit distribution +% - Fig 7, 30% of all non-unique domain names have at least 80% cache hit ratio +% and 5% have at least 95% cache-hit ratios. +% +% Hao and Wang. (2017) Exploring Domain Name Based Features on the Effectiveness of DNS Caching +% - University data set +% - "we observe that a size of 100,000 entries would have a cache hit rate of about 86%" +% - (context is to use this baseline for other policies than fifo/lru etc.) +% +% Avoiding to cache "disposable domains", i.e., domains that are only used +% once seems to be a thing to research. This is what Hao and Wang does. +% +% Jung et al. (2002) DNS Performance and the Effectiveness of Caching +% - MIT network 80-86% cache hits, much because multiple TCP connections from +% browsers +% - "We find that the distribution of names is Zipf-like, which immeaditely +% limits even the theoretical effectivness of caching" +% - 10 min TTL yields almost the same cache-hit ratio as a longer TTL +% - Already with 10 clients, same cache-hit ratio as 1000 clients +% +% https://developers.google.com/speed/public-dns/docs/performance +% - "While a few sites (and consequently DNS names) are very popular, most are of +% interest to only a few users and are accessed rarely; so the majority of +% requests result in cache misses" +% - (Could not find anything about Google/Cloudflare cache-hit ratios for DNS) +% - (Found a white paper saying 70-90%, but not a good source) +% - https://www.senki.org/wp-content/uploads/2017/08/213049567-How-to-Measure-Resolver-Performance.pdf diff --git a/summary/src/tlwo/src/short.tex b/summary/src/tlwo/src/short.tex new file mode 100644 index 0000000..6d06c86 --- /dev/null +++ b/summary/src/tlwo/src/short.tex @@ -0,0 +1,63 @@ +\section{Mitigations} \label{tlwo:sec:short} + +Until a more comprehensive defense can be deployed we propose two short-term +mitigations that require little (fuzzy TTLs) or no (cover lookups) changes to +Tor. The former adds some uncertainty with regards to when a domain was added +to an exit's DNS cache. The latter can remove or reduce the attacker's ability +to conduct attacks against specific domains but is limited in its scalability. + +\subsection{Fuzzy TTLs} \label{tlwo:sec:short:fuzzy} +Recall that it is possible to determine when a domain was inserted into an +exit's DNS cache (Section~\ref{tlwo:sec:attack:detailed}) once you know the time $t$ +when the timeless timing attack started, the duration until the domain was no +longer cached $x$ (repeated probes), and the expected clip value +$\mathsf{clipped\_ttl}$ of the domain. The idea of fuzzy TTLs is to add +uncertainty by randomizing the length of time that an entry is cached. + +In more detail, keep Tor's DNS cache as-is but sample the cache duration +uniformly at random from $[m, \mathsf{clipped\_ttl}]$, where $m$ is the minimum +duration to cache. Upon observing the exact time of removal $t+x$, the attacker +now learns that the domain has been in the cache for the duration $x$ and was +thus cached between $[t+x-\mathsf{clipped\_ttl}, t-m]$. Note that if $m = +\mathsf{clipped\_ttl}$, then $x = 0$; the same as in Tor today. + +The reality of websites is unfortunately that they consist of multiple domains, +reducing the effectiveness of fuzzy TTLs because the attacker uses the most +lucky sample. For a list of domains $d_1,\hdots,d_k$ that were added at the same +time with identical clips, then $x \leftarrow \mathsf{max}(x_1,\hdots,x_k)$. +Based on our preload list measurements presented in +Section~\ref{tlwo:sec:long:preload}, we expect around 8--13 domains per site +available for an attacker to potentially query for. Earlier work found +a median of two unique domains out of ten domains in total per website on Alexa +top 1M~\cite{GreschbachPRWF17}. + +Fuzzy TTLs are an ineffective mitigation if the attacker just wants to confirm +suspected activity with a low base rate, i.e., the mere existence of cached +domains anywhere in the network is enough of a signal~\cite{wfwo}. Fuzzy TTLs +are a plus for websites that are modestly popular in the network, since the +attacker has to determine which of several exits with cached domains is the +correct one. Having to consider multiple domains and exits (to narrow down the +exact time) is more noisy in the network and increases the risk of +detection~\cite{AumannL07}. Attackers may be forced to consider a time-window of +several seconds or even minutes, which is a big win for defending against +correlation and confirmation attacks~\cite{GreschbachPRWF17,wfwo}. + +\subsection{Cover Lookups} +The idea of the cover lookups mitigation is to simply inject domains into DNS +caches in the Tor network to create false positives. Injected domains must be +indistinguishable from domains cached from real Tor user activity. For this, a +distribution that models website visits for a particular base rate should be +used rather than running, e.g., a deterministic cron job. Further, care has to +be taken to capture all predictable domains for each website to defend. + +A more drastic mitigation would be to keep a site's domains cached at every exit +all the time, e.g., by running \texttt{exitmap}~\cite{exitmap} every five +minutes. This obviously scales poorly. The network overhead would already be +significant for a few hundred sites, e.g., estimates based on Alexa top-1k would +add about 26.7~requests per second to each exit. + +Cover lookups do not scale, even if just injected at few exits probabilistically +according to some target base rate. It is a last resort mitigation for site +operators that fear that their users are targeted by motivated attackers and +where, for some reason, the site cannot transition to being completely (no +resources loaded from other domains) hosted as an onion service. diff --git a/summary/src/tlwo/src/tor-cache.tex b/summary/src/tlwo/src/tor-cache.tex new file mode 100644 index 0000000..392b755 --- /dev/null +++ b/summary/src/tlwo/src/tor-cache.tex @@ -0,0 +1,167 @@ +\section{Tor's DNS Cache Today} \label{tlwo:sec:torcache} + +To better understand the DNS cache of Tor today, we set out to collect +performance metrics from exits in the live Tor network. +Section~\ref{tlwo:sec:torcache:ethics} covers ethical considerations, followed by +data collection in Section~\ref{tlwo:sec:torcache:collection} and resulting metrics +in Section~\ref{tlwo:sec:torcache:metrics}. + +\subsection{Ethical Considerations} \label{tlwo:sec:torcache:ethics} + +We submitted a proposal to the Tor Research Safety Board describing measurements +that would ultimately inform the design of a long-term defense +(Section~\ref{tlwo:sec:long}) against our improved attack (Section~\ref{tlwo:sec:attack}). +To be able to assess the impact of the defense we needed to better understand +the DNS cache Tor has today as a baseline. After a couple of iterations with the +Tor Research Safety Board we reached consensus, and then successfully completed +our university's ethical review process. The proposal also included measurements +needed for our defense, described later in +Section~\ref{tlwo:sec:long:preload:collection}. During the measurements period of +four months we consulted the Tor Research Safety Board to discuss our results. + +The intuition of our measurement is as follows. Two exit relays are operated to +collect counters related to domain lookups. For example, the number of lookups +and cache hits (Section~\ref{tlwo:sec:torcache:collection}). These counters are the +result of all traffic at the exit, aggregated over 15 minutes intervals before +being written to disk and then reset in memory. Based on an exit probability of +about $0.0005$ ($\approx 100$Mbit/s), we extrapolated from the measurements of +Mani \emph{et~al.}~\cite{ManiWJJS18} that we should expect about 725 website +visits during 15 minutes. Each website visit typically triggers multiple domain +lookups~\cite{GreschbachPRWF17} that affect our global counters. A collection +interval of 15 minutes should thus aggregate hundreds of website visits for a +small fraction of the network, making the resulting dataset hardly useful for an +attacker performing correlation or confirmation attacks on the network. +This sketch appears to be confirmed by our measurement results: out of 23,632 +15-minute intervals, only 18 contained less than 1,000 lookups. +Our conclusion together with the Tor Research Safety Board was that the +resulting dataset should be safe to make public (further discussed later). + +\subsection{Data Collection} \label{tlwo:sec:torcache:collection} + +Two 100 Mbit/s exit relays were operated by volunteers on the premises of +DFRI\footnote{More information about DFRI can be found at their website: +\url{https://www.dfri.se}.} +from May 2 until September 3, 2022. One exit was configured in its exit policy +with \emph{web} ports.\footnote{% + Reject all ports except 80 and 443. (The exit can still do DNS for users.) +} The other relay was configured with +\emph{permissive} ports to also allow non-web traffic.\footnote{% + Allow all ports except 25, 119, 135--139, 445, 563, 1214, 4661--4666, + 6346--6429, 6699, and 6881--6999. +} Otherwise the two exits were identical, +running on the same VM with a dedicated \texttt{unbound} process that had +caching disabled by setting the \texttt{rrset-cache-size} to zero (to avoid TTL +biases). We collected the following counters every 15 minutes at both exits: + +\begin{description} + \item[timestamp] UNIX timestamp when the data was collected. + \item[lookups] Total number of observed domain lookups. + \item[hits\_5m] Number of cache hits with a TTL of 300 seconds. + \item[hits\_60m] Number of cache hits with a TTL of 3,600 seconds. + \item[hits\_pending] Number of cache hits with a pending resolve, i.e., + an answer has been requested but is not yet available. + \item[hits\_same\_circuit] Number of streams that looked up a domain + that was previously looked up on the same circuit. + \item[num\_cache\_entries] Number of entries in Tor's DNS cache. +\end{description} + +A timestamp is needed to plot metrics as a function of time. Timestamps are +also crucial for the additional counters described in +Section~\ref{tlwo:sec:long:preload:collection}. The number of lookups and different +types of cache hits are needed to get a baseline of cache-hit ratios. The +number of entries in Tor's DNS cache (at the time of collection) is needed to +get a baseline of memory usage. The necessary Tor changes to collect all metrics +(including Section~\ref{tlwo:sec:long:preload:collection}) were relatively modest: +400 lines of code. + +\subsection{Metrics} \label{tlwo:sec:torcache:metrics} + +Regarding lookups per 15 minutes, the web exit processed a mean of 17,530 and +median of 13,393 lookups (Figure~\ref{tlwo:fig:metrics:lookweb}), and the permissive +exit processed a mean of 41,100 and median of 26,940 lookups +(Figure~\ref{tlwo:fig:metrics:lookperm}). The permissive exit policy results in +significantly more lookups. Around August 1, our exits experienced downtime, +visible as dips in lookups in both figures (at times fewer than 1,000 lookups, +as noted in Section~\ref{tlwo:sec:torcache:ethics}). Exit probability is weakly +correlated with lookups: Pearson correlation 0.30 (web) and 0.16 (permissive). + +\begin{figure}[!t] + \centering + \subfloat[][web]{% + \includegraphics[width=.5\columnwidth]{src/tlwo/img/plot_lookups-web.pdf} + \label{tlwo:fig:metrics:lookweb} + } + \subfloat[][permissive]{% + \includegraphics[width=.5\columnwidth]{src/tlwo/img/plot_lookups-permissive.pdf} + \label{tlwo:fig:metrics:lookperm} + } + \caption{Lookups every 15 minutes and exit probability.} + \label{tlwo:fig:lookups} +\end{figure} + +Figures~\ref{tlwo:fig:metrics:cacheweb} and~\ref{tlwo:fig:metrics:cacheperm} show the +number of entries in Tor's DNS cache. The web exit has a mean of 7,672 and +median of 7,325 entries, and the permissive exit a mean of 12,130 and median of +11,408 entries. Both appear relatively stable compared to the number of lookups +(note log-scale y-axis in Figure~\ref{tlwo:fig:lookups}). Likely, this is +because traffic on the Tor network is not uniformly distributed, but rather +concentrated to relatively few destinations, e.g., as shown with website +popularity~\cite{ManiWJJS18}. + +\begin{figure}[!t] + \centering + \subfloat[][web]{% + \includegraphics[width=.5\columnwidth]{src/tlwo/img/plot_cache_entries-web.pdf} + \label{tlwo:fig:metrics:cacheweb} + } + \subfloat[][permissive]{% + \includegraphics[width=.5\columnwidth]{src/tlwo/img/plot_cache_entries-permissive.pdf} + \label{tlwo:fig:metrics:cacheperm} + } + \caption{Cache entries every 15 minutes.} + \label{tlwo:fig:cache} +\end{figure} + +Central to a DNS cache is its \emph{cache-hit} ratio: how often lookups can be +resolved using cached entries instead of asking DNS resolvers. +Figures~\ref{tlwo:fig:metrics:hitsweb} and~\ref{tlwo:fig:metrics:hitsperm} show the +cache-hit ratios for the two exits, with a mean cache-hit ratio of 0.80 (web) +and 0.83 (permissive). We also show if the cache hits occurred due to a cache +entry used earlier on the same circuit (``same'') or from another circuit +(``shared''). Further, over all the cache hits, we show if the hits were because +of DNS entries with a five-minute cached TTL (``5min''), a 60-minute cached TTL +(``60min''), or pending entries in the DNS cache (``pending''). Same circuit +hits are likely due to Tor Browser improving performance by creating multiple +streams to the same destination. The cross-circuit cache-hit ratio is much +smaller (``shared'') with a mean of 0.11 (web) and 0.17 (permissive). We return +to these ratios in Section~\ref{tlwo:sec:long:evaluation} to compare with our +defense. + +\begin{figure}[!t] + \centering + \subfloat[][web]{% + \includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_cache_hits-web.pdf} + \label{tlwo:fig:metrics:hitsweb} + }\\ + \subfloat[][permissive]{% + \includegraphics[width=.67\columnwidth]{src/tlwo/img/plot_cache_hits-permissive.pdf} + \label{tlwo:fig:metrics:hitsperm} + } + \caption{% + Cache-hit ratio every 15 minutes. The total ratio can be split + by same+shared hits or 60min+5min+pending hits. + } + \label{tlwo:fig:hits} +\end{figure} + +During the four months of measurements, our exits experienced sporadic downtime +(early August) and the Tor-network endured significant network DDoS +activities~\cite{network-ddos}. This shows in our data, e.g., with the drop to +close to zero lookups in Figure~\ref{tlwo:fig:lookups}, huge spikes of cached entries +in Figure~\ref{tlwo:fig:cache}, and periods where the cache-hit ratio was almost +one in Figure~\ref{tlwo:fig:hits}. + +To summarize, Tor's DNS cache has a cache-hit ratio over 80\% using a modestly +sized DNS cache. About 11--17\% of these hits are due to sharing the cache +across circuits. The number of lookups are weakly correlated to exit +probability. |
