tor-commits August 2012

tor-commits@lists.torproject.org

19 participants
901 discussions

[research-web/master] Add George's morpher report.
by karsten＠torproject.org 22 Aug '12

22 Aug '12

commit 3873053b6280c9e9df5398752c85b9cb09deed88 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Aug 22 20:28:08 2012 +0200 Add George's morpher report. --- techreports.html | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/techreports.html b/techreports.html index 2d7f316..e2dc191 100644 --- a/techreports.html +++ b/techreports.html @@ -48,10 +48,11 @@ March 17, 2012. March 16, 2012. <a href="https://www.cl.cam.ac.uk/~sjm217/papers/tor12datagramtesting.pdf">PDF</a>.--> - +<a href="techreports/morpher-2012-03-13.pdf">PDF</a>. Karsten Loesing. What if the Tor network had 50,000 bridges?

1 0

[tech-reports/master] Add morpher sources.
by karsten＠torproject.org 22 Aug '12

22 Aug '12

commit e1eb25efc0eef9ed51cb23fd81d70a2bd655a4f4 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Mon Aug 20 19:55:58 2012 +0200 Add morpher sources. https://trac.torproject.org/projects/tor/attachment/ticket/5023/morpher_2.t… --- 2012/morpher/.gitignore | 3 + 2012/morpher/500000_cs.pdf | Bin 0 -> 27094 bytes 2012/morpher/500000_sc.pdf | Bin 0 -> 25864 bytes 2012/morpher/https_cs.pdf | Bin 0 -> 20287 bytes 2012/morpher/morpher.tex | 298 ++++++++++++++++++++++++++++++++++++++++++++ 2012/morpher/tor_cs.pdf | Bin 0 -> 12335 bytes 6 files changed, 301 insertions(+), 0 deletions(-) diff --git a/2012/morpher/.gitignore b/2012/morpher/.gitignore new file mode 100644 index 0000000..5f59b41 --- /dev/null +++ b/2012/morpher/.gitignore @@ -0,0 +1,3 @@ +morpher.pdf +morpher-2012-03-13.pdf + diff --git a/2012/morpher/500000_cs.pdf b/2012/morpher/500000_cs.pdf new file mode 100644 index 0000000..dd7abd0 Binary files /dev/null and b/2012/morpher/500000_cs.pdf differ diff --git a/2012/morpher/500000_sc.pdf b/2012/morpher/500000_sc.pdf new file mode 100644 index 0000000..fe954fe Binary files /dev/null and b/2012/morpher/500000_sc.pdf differ diff --git a/2012/morpher/https_cs.pdf b/2012/morpher/https_cs.pdf new file mode 100644 index 0000000..b4e5d55 Binary files /dev/null and b/2012/morpher/https_cs.pdf differ diff --git a/2012/morpher/morpher.tex b/2012/morpher/morpher.tex new file mode 100644 index 0000000..8fd4935 --- /dev/null +++ b/2012/morpher/morpher.tex @@ -0,0 +1,298 @@ +\documentclass[]{article} +\usepackage{graphicx} + +\usepackage[parfill]{parskip} +\begin{document} + +\title{Packet Size Pluggable Transport and Traffic Morphing} +\author{George Kadianakis} +\maketitle + +\section{Traffic Morphing} + +\subsection{Overview} + +It is well known \cite{herrmann} that Tor traffic can be distinguished +from other network protocols by its distinctive packet size. Due to the +sized Tor cells, most TCP packets of Tor traffic are 586 bytes in size +(See Figure \ref{tor_cs.pdf}). + +\begin{figure}[h] +\begin{center} +\includegraphics[scale=0.65]{tor_cs.pdf} +\end{center} +\caption{Packet size probability distribution of Tor Client-to-Server traffic \cite{caida}} +\label{tor_cs.pdf} +\end{figure} + +On the other hand, HTTPS, the protocol that Tor tries to simulate +\cite{tls_norm}, has a much more spread out packet size probability +distribution (See Figure \ref{https_cs.pdf}) + +\begin{figure}[h] +\begin{center} +\includegraphics[scale=0.65]{https_cs.pdf} +\end{center} +\caption{Packet size probability distribution of HTTPS Client-to-Server traffic \cite{caida}} +\label{https_cs.pdf} +\end{figure} + +This means that an adversary can detect Tor traffic by using packets +of size \textit{586} as distinguishers \cite{ll} \cite{herrmann}. + +\subsection{Solutions} + +An obvious solution to this problem is to introduce a padding scheme +to Tor. + +Some network protocols already use padding to defend against traffic +fingerprinting attacks. SSH and TLS, for example, both support padding +in their messages \cite{ssh} \cite{gnutls}. Most implementations of +those protocols don't pad by default. The ones that do, add a random +amount of padding to the protocol message. + +The Tor protocol also supports padding cells (named \textit{PADDING} +and \textit{VPADDING}) which attempt to generate covert traffic. + +While the random padding solution effectively hides the \textit{586} +bytes identifier, it does not fully make Tor traffic resemble HTTPS +traffic. This means that a sophisticated attacker can distinguish Tor +traffic, by searching for SSL handshakes that try to look like HTTPS +but actually follow a packet size probability distribution different +from the one of HTTPS. + +A solution to that, is to collect a large amount of HTTPS packets and +form their packet size probability distribution. We can then randomly +sample that probability distribution for every packet we need to +send. Specifically, for every Tor packet, we would sample the HTTPS +probability distribution, find a target packet size and split or pad +our packet accordingly. We call this method \textit{random sampling}. + +The problem with random sampling, is that it radically increases our +bandwidth overhead. + +To reduce this overhead, we looked into a paper of Charles Wright, +Scott Coulls and Fabian Monrose called \emph{Traffic Morphing: An + efficient defense against statistical traffic analysis} \cite{tm}. + +\subsection{Traffic Morphing} + +Traffic Morphing minimizes bandwidth overhead when transforming +packets from one packet size probability distribution to another. That +is, given two packet size probability distributions, one for the +source protocol and another for the target protocol, it produces a +\emph{morphing matrix} that acts as an oracle and describes how to +efficiently morph packets between those two probability distributions. + +Traffic Morphing works by modeling the problem of transforming packets +as a problem of linear programming. To construct the morphing matrix, +we consider \textit{bandwidth overhead} as the objective function of +our linear program, and use appropriate problem constraints that +transform the source probability distribution to the target +probability distribution. + +\section{Woes of Traffic Morphing} + +\subsection{Issues} + +Unfortunately, morphing matrices are not a panacea, for the following +reasons: + +\subsubsection{Statelessnes} + +Morphing matrices are not stateful. In other words, morphing matrices +don't handle protocols whose packet size probability distribution +changes through the protocol runtime. + +For example, HTTPS follows different packet size probability +distributions between the handshake and the data phase, and morphing +matrices are unable to understand the difference. + +\subsubsection{Splitting} + +The original traffic morphing paper did not specify an algorithm for +splitting packets: When a morphing matrix suggests a packet size +\textbf{smaller} than the original packet size, we have to split the +original packet into two parts. The problem is that the original paper +does not clearly define what should be done with the second half of +the split packet. + +Sending the second half of the packet to the network is not correct, +because its packet size does not belong to the packet size probability +distribution of the target protocol (specifically, it belongs to the +packet size probability distribution of the target protocol when split +once by its morphing matrix). + +Querying the morphing matrix again, for the size of the second half of +the split packet, is also not correct, since that packet size does +not belong to the probability distribution of the source protocol and +morphing matrices mishandle unknown packet sizes. + +Even though the original paper didn't specify the splitting algorithm +that should be used, it hinted that doing a random sampling of the +target probability distribution for the length of the split packet +is what they did in their implementation. + +\subsection{Evaluation of issues} + +Unfortunately, the splitting problem of the previous section is not +only theoretical. To evaluate the bandwidth overhead of morphing +matrices, we made software \cite{morpher_eval} that simulates the +morphing of a large number of packets. Specifically, our software +morphs 500000 packets using both random sampling and traffic morphing, +and plots the overhead. (In traffic morphing, we use random sampling +for the second parts of a split packet.) + +We can see that in the case of Server-to-Client Tor-to-HTTPS packet +morphing, morphing matrices actually reduce the bandwidth overhead by +a substantial amount (See Figure \ref{0.5m_sc}). + +\begin{figure}[h] +\begin{center} +\includegraphics[scale=0.65]{500000_sc.pdf} +\end{center} +\caption{Bandwidth overhead for 0.5 million Server-to-Client packets} +\label{0.5m_sc} +\end{figure} + +However, in the case of Client-to-Server Tor-to-HTTPS packet size +morphing, the bandwidth overhead of morphing matrices is actually +larger than the bandwidth overhead of random sampling (See Figure +\ref{0.5mcs}). +\begin{figure}[h] +\begin{center} +\includegraphics[scale=0.65]{500000_cs.pdf} +\end{center} +\caption{Bandwidth overhead for 0.5 million Client-to-server packets} +\label{0.5mcs} +\end{figure} + +Our guess is that this happens because in the Client-to-Server case, +HTTPS has large probabilities of outputting small packet sizes (See +Figure \ref{https_cs.pdf}). + +This means that our morphing matrix tries to split our packets into +small packets, and then when random sampling is used for the second +half of our packet it tries to pad it to 1460 (which is also a very +popular packet size in HTTPS): + +For example: + +\begin{verbatim} +Packet size 586. We must morph it to 127. Splitting to 127+459 and sending 127. +Packet size 459. We must morph it to 123. Splitting to 123+336 and sending 123. +Packet size 336. We must morph it to 1459. Padding with 1123 and sending. +\end{verbatim} + +In this case, morpher gets a packet of 586 bytes to morph. It queries +the morphing matrix which suggests a packet size of 127 bytes. Morpher +splits the original packet to 127+459 bytes, sends 127 bytes to the +network, and is left with 459 bytes. Since the packet was split, our +faulty splitting algorithm says that morpher should do a direct +sampling over the HTTPS probability distribution. Morpher gets 123 +bytes as the result of random sampling, and splits the packet to +123+336 bytes. It sends 123 bytes to the network, and is left with 459 +bytes. Morpher again does random sampling over the HTTPS probability +distribution, and gets 1459 bytes as the result. This means that it +must pad the 336 bytes packet to 1459 bytes. This results in an +overhead of 1123 bytes. + +For the same case, random sampling was better due to the randomness of +random sampling. + +\subsection{Fixes} + +A potential fix for the statelessness of morphing matrices, is to +generate multiple morphing matrices for each phase of the protocol. We +have not attempted this approach. + +A potential fix for the splitting algorithm issue, is to generate a +morphing matrix for every split level (since the number of splits that +can happen to a packet are finite), and use the appropriate morphing +matrix everytime we have a split packet. We have not implemented or +evaluated this fix yet. + +\section{Future} + +For the short-term future, we decided to postpone the development of +pluggable transports based on Traffic Morphing. We think that more +research is needed, as well as a stronger focus towards realistic +adversaries. + +Specifically, we believe that if we investigate the strength and +limitations of modern Deep Packet Inspection kits, we can provide +adequate defences without the implementation complexity and drawbacks +of the Traffic Morphing technology. + +We plan on investigating packet size pluggable transports with less +overhead, even if they don't deliver a perfect probability +distribution match to the target protocol, since we believe that such +pluggable transports can effectively mitigate many practical +packet-size-based detection attacks. + +At the same time, we also think it's important to remain up-to-date +with modern academic research. For example, modern website +fingerprinting research has showed that any kind of padding scheme is +insufficient to protect against sophisticated packet size +distinguishers \cite{ll} \cite{herrmann}. Furthermore, the academic +community has found other network traffic features that can be used as +distinguishers with surprisingly high accuracy \cite{panchenko}. + +Meanwhile, we are also researching alternative pluggable transports +with better resistance against payload fingerprinting, which we think +real-life attackers are likely to do, and also pluggable transports +which can get through HTTP proxy servers. + +\section{Acknowledgments} + +Thanks to Steven J. Murdoch and the Tor Project for the fruitful +conversations on packet size pluggable transports. + +\bibliographystyle{plain} +\begin{thebibliography}{9} + +\bibitem{ssh} https://www.ietf.org/rfc/rfc4344.txt + +\bibitem{gnutls} https://www.gnu.org/software/gnutls/manual/gnutls.html\#On-Record-Padding + +\bibitem{ll} + M. Liberatore, B. N. Levine, \textit{Inferring the Source + of Encrypted HTTP Connections}, CCS2006, October 2006. + +\bibitem{herrmann} + Dominik Herrmann, Rolf Wendolsky, and Hannes + Federrath. 2009. Website fingerprinting: attacking popular privacy + enhancing technologies with the multinomial naïve-bayes classifier. + +\bibitem{tls_norm} + http://archives.seul.org/or/dev/Jan-2011/msg00029.html + +\bibitem{morpher_eval} + \textit{Morpher pluggable transport: Select algorithm for packet size morphing} + + https://trac.torproject.org/projects/tor/ticket/5023 + http://archives.seul.org/or/dev/Jan-2011/msg00029.html + +\bibitem{panchenko} + Andriy Panchenko, Lukas Niessen, Andreas Zinnen, and Thomas + Engel. 2011. \textit{Website fingerprinting in onion routing based + anonymization networks}. + +\bibitem{tm} + Charles Wright, Scott Coulls , Fabian Monrose. \textit{Traffic + Morphing: An efficient defense against statistical traffic + analysis.} In Proceedings of the 14th Annual Network and + Distributed Systems Symposium (NDSS), Feb, 2009. + +\bibitem{caida} + The packet length probability distributions were formed after + analysis of traffic traces kindly provided by CAIDA. The traffic + traces were captured by monitoring an Equinix datacenter in Chicago, + IL. + + https://gitorious.org/morpher/morpher/blobs/master/ACKNOWLEDGMENTS + https://gitorious.org/morpher/morpher/trees/master/data + +\end{thebibliography} + +\end{document} diff --git a/2012/morpher/tor_cs.pdf b/2012/morpher/tor_cs.pdf new file mode 100644 index 0000000..5fe6483 Binary files /dev/null and b/2012/morpher/tor_cs.pdf differ

1 0

[tech-reports/master] Force morpher.tex into the Tor Tech Report template.
by karsten＠torproject.org 22 Aug '12

22 Aug '12

commit f117ab4b4303f480466c61856bda835565dccb37 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Mon Aug 20 20:23:07 2012 +0200 Force morpher.tex into the Tor Tech Report template. --- 2012/morpher/morpher.tex | 34 ++++++++++++++++++++-------------- 2012/morpher/tortechrep.cls | 1 + 2 files changed, 21 insertions(+), 14 deletions(-) diff --git a/2012/morpher/morpher.tex b/2012/morpher/morpher.tex index 8fd4935..43442df 100644 --- a/2012/morpher/morpher.tex +++ b/2012/morpher/morpher.tex @@ -1,11 +1,13 @@ -\documentclass[]{article} +\documentclass{tortechrep} \usepackage{graphicx} -\usepackage[parfill]{parskip} \begin{document} \title{Packet Size Pluggable Transport and Traffic Morphing} \author{George Kadianakis} +\contact{asn(a)torproject.org} +\date{March 13, 2012} +\reportid{2012-03-004} \maketitle \section{Traffic Morphing} @@ -19,7 +21,7 @@ sized Tor cells, most TCP packets of Tor traffic are 586 bytes in size \begin{figure}[h] \begin{center} -\includegraphics[scale=0.65]{tor_cs.pdf} +\includegraphics[width=\textwidth]{tor_cs.pdf} \end{center} \caption{Packet size probability distribution of Tor Client-to-Server traffic \cite{caida}} \label{tor_cs.pdf} @@ -31,7 +33,7 @@ distribution (See Figure \ref{https_cs.pdf}) \begin{figure}[h] \begin{center} -\includegraphics[scale=0.65]{https_cs.pdf} +\includegraphics[width=\textwidth]{https_cs.pdf} \end{center} \caption{Packet size probability distribution of HTTPS Client-to-Server traffic \cite{caida}} \label{https_cs.pdf} @@ -149,7 +151,7 @@ a substantial amount (See Figure \ref{0.5m_sc}). \begin{figure}[h] \begin{center} -\includegraphics[scale=0.65]{500000_sc.pdf} +\includegraphics[width=\textwidth]{500000_sc.pdf} \end{center} \caption{Bandwidth overhead for 0.5 million Server-to-Client packets} \label{0.5m_sc} @@ -161,7 +163,7 @@ larger than the bandwidth overhead of random sampling (See Figure \ref{0.5mcs}). \begin{figure}[h] \begin{center} -\includegraphics[scale=0.65]{500000_cs.pdf} +\includegraphics[width=\textwidth]{500000_cs.pdf} \end{center} \caption{Bandwidth overhead for 0.5 million Client-to-server packets} \label{0.5mcs} @@ -251,9 +253,11 @@ conversations on packet size pluggable transports. \bibliographystyle{plain} \begin{thebibliography}{9} -\bibitem{ssh} https://www.ietf.org/rfc/rfc4344.txt +\bibitem{ssh} + \url{https://www.ietf.org/rfc/rfc4344.txt} -\bibitem{gnutls} https://www.gnu.org/software/gnutls/manual/gnutls.html\#On-Record-Padding +\bibitem{gnutls} + \url{https://www.gnu.org/software/gnutls/manual/gnutls.html\#On-Record-Padding} \bibitem{ll} M. Liberatore, B. N. Levine, \textit{Inferring the Source @@ -265,13 +269,14 @@ conversations on packet size pluggable transports. enhancing technologies with the multinomial naïve-bayes classifier. \bibitem{tls_norm} - http://archives.seul.org/or/dev/Jan-2011/msg00029.html + \url{https://lists.torproject.org/pipermail/tor-dev/2011-January/001077.html} \bibitem{morpher_eval} \textit{Morpher pluggable transport: Select algorithm for packet size morphing} - https://trac.torproject.org/projects/tor/ticket/5023 - http://archives.seul.org/or/dev/Jan-2011/msg00029.html + \url{https://trac.torproject.org/projects/tor/ticket/5023} + + \url{https://lists.torproject.org/pipermail/tor-dev/2011-January/001077.html} \bibitem{panchenko} Andriy Panchenko, Lukas Niessen, Andreas Zinnen, and Thomas @@ -279,7 +284,7 @@ conversations on packet size pluggable transports. anonymization networks}. \bibitem{tm} - Charles Wright, Scott Coulls , Fabian Monrose. \textit{Traffic + Charles Wright, Scott Coulls, Fabian Monrose. \textit{Traffic Morphing: An efficient defense against statistical traffic analysis.} In Proceedings of the 14th Annual Network and Distributed Systems Symposium (NDSS), Feb, 2009. @@ -290,8 +295,9 @@ conversations on packet size pluggable transports. traces were captured by monitoring an Equinix datacenter in Chicago, IL. - https://gitorious.org/morpher/morpher/blobs/master/ACKNOWLEDGMENTS - https://gitorious.org/morpher/morpher/trees/master/data + \url{https://gitorious.org/morpher/morpher/blobs/master/ACKNOWLEDGMENTS} + + \url{https://gitorious.org/morpher/morpher/trees/master/data} \end{thebibliography} diff --git a/2012/morpher/tortechrep.cls b/2012/morpher/tortechrep.cls new file mode 120000 index 0000000..4c24db2 --- /dev/null +++ b/2012/morpher/tortechrep.cls @@ -0,0 +1 @@ +../../tortechrep.cls \ No newline at end of file

1 0

[tech-reports/master] Merge branch 'asn-report'
by karsten＠torproject.org 22 Aug '12

22 Aug '12

commit 24885cc6851d45dbab8be135dac8a91f7cf0413f Merge: df7b370 da2d794 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Aug 22 20:07:54 2012 +0200 Merge branch 'asn-report' 2012/morpher/.gitignore | 3 + 2012/morpher/500000_cs.pdf | Bin 0 -> 27094 bytes 2012/morpher/500000_sc.pdf | Bin 0 -> 25864 bytes 2012/morpher/https_cs.pdf | Bin 0 -> 20287 bytes 2012/morpher/morpher.bib | 44 +++++++ 2012/morpher/morpher.tex | 272 +++++++++++++++++++++++++++++++++++++++++++ 2012/morpher/tor_cs.pdf | Bin 0 -> 12335 bytes 2012/morpher/tortechrep.cls | 1 + 8 files changed, 320 insertions(+), 0 deletions(-)

1 0

[tech-reports/master] Turn manual bibliography into BibTeX and footnotes.
by karsten＠torproject.org 22 Aug '12

22 Aug '12

commit da2d7948c745bf7e9e74d450eba518010002e853 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Aug 22 08:52:53 2012 +0200 Turn manual bibliography into BibTeX and footnotes. --- 2012/morpher/morpher.bib | 44 +++++++++++++++++++++++++ 2012/morpher/morpher.tex | 80 ++++++++++++++-------------------------------- 2 files changed, 68 insertions(+), 56 deletions(-) diff --git a/2012/morpher/morpher.bib b/2012/morpher/morpher.bib new file mode 100644 index 0000000..7fa7712 --- /dev/null +++ b/2012/morpher/morpher.bib @@ -0,0 +1,44 @@ +@inproceedings{ll, + title = {{Inferring the Source of Encrypted HTTP Connections}}, + author = {Marc Liberatore and Brian Neil Levine}, + booktitle = {Proceedings of the 13th ACM conference on Computer and Communications + Security (CCS 2006)}, + year = {2006}, + month = {October}, + pages = {255--263}, + note = {\url{http://freehaven.net/anonbib/#Liberatore:2006}}, +} + +@inproceedings{herrmann, + title = {Website fingerprinting: attacking popular privacy enhancing technologies with + the multinomial na\"{\i}ve-bayes classifier}, + author = {Dominik Herrmann and Rolf Wendolsky and Hannes Federrath}, + booktitle = {Proceedings of the 2009 ACM workshop on Cloud computing security (CCSW + '09)}, + year = {2009}, + address = {New York, NY, USA}, + pages = {31--42}, + publisher = {ACM}, + note = {\url{http://freehaven.net/anonbib/#ccsw09-fingerprinting}}, +} + +@inproceedings{panchenko, + title = {Website Fingerprinting in Onion Routing Based Anonymization Networks}, + author = {Andriy Panchenko and Lukas Niessen and Andreas Zinnen and Thomas Engel}, + booktitle = {Proceedings of the Workshop on Privacy in the Electronic Society (WPES 2011)}, + year = {2011}, + month = {October}, + publisher = {ACM}, + note = {\url{http://freehaven.net/anonbib/#wpes11-panchenko}}, +} + +@inproceedings{tm, + title = {Traffic Morphing: An efficient defense against statistical traffic analysis}, + author = {Charles Wright and Scott Coull and Fabian Monrose}, + booktitle = {Proceedings of the Network and Distributed Security Symposium - {NDSS} '09}, + year = {2009}, + month = {February}, + publisher = {IEEE}, + note = {\url{http://freehaven.net/anonbib/#morphing09}}, +} + diff --git a/2012/morpher/morpher.tex b/2012/morpher/morpher.tex index 43442df..d1ee1de 100644 --- a/2012/morpher/morpher.tex +++ b/2012/morpher/morpher.tex @@ -23,19 +23,20 @@ sized Tor cells, most TCP packets of Tor traffic are 586 bytes in size \begin{center} \includegraphics[width=\textwidth]{tor_cs.pdf} \end{center} -\caption{Packet size probability distribution of Tor Client-to-Server traffic \cite{caida}} +\caption{Packet size probability distribution of Tor Client-to-Server traffic} \label{tor_cs.pdf} \end{figure} -On the other hand, HTTPS, the protocol that Tor tries to simulate -\cite{tls_norm}, has a much more spread out packet size probability +On the other hand, HTTPS, the protocol that Tor tries to simulate,% +\footnote{\url{https://lists.torproject.org/pipermail/tor-dev/2011-January/001077.html}} +has a much more spread out packet size probability distribution (See Figure \ref{https_cs.pdf}) \begin{figure}[h] \begin{center} \includegraphics[width=\textwidth]{https_cs.pdf} \end{center} -\caption{Packet size probability distribution of HTTPS Client-to-Server traffic \cite{caida}} +\caption{Packet size probability distribution of HTTPS Client-to-Server traffic} \label{https_cs.pdf} \end{figure} @@ -49,7 +50,11 @@ to Tor. Some network protocols already use padding to defend against traffic fingerprinting attacks. SSH and TLS, for example, both support padding -in their messages \cite{ssh} \cite{gnutls}. Most implementations of +in their messages% +\footnote{\url{https://www.ietf.org/rfc/rfc4344.txt}}% +\textsuperscript{,}% +\footnote{\url{https://www.gnu.org/software/gnutls/manual/gnutls.html\#On-Record-Padding}}. +Most implementations of those protocols don't pad by default. The ones that do, add a random amount of padding to the protocol message. @@ -139,7 +144,11 @@ is what they did in their implementation. Unfortunately, the splitting problem of the previous section is not only theoretical. To evaluate the bandwidth overhead of morphing -matrices, we made software \cite{morpher_eval} that simulates the +matrices, we made software% +\footnote{\url{https://trac.torproject.org/projects/tor/ticket/5023}}% +\textsuperscript{,}% +\footnote{\url{https://lists.torproject.org/pipermail/tor-dev/2011-January/001077.html}} +that simulates the morphing of a large number of packets. Specifically, our software morphs 500000 packets using both random sampling and traffic morphing, and plots the overhead. (In traffic morphing, we use random sampling @@ -245,60 +254,19 @@ with better resistance against payload fingerprinting, which we think real-life attackers are likely to do, and also pluggable transports which can get through HTTP proxy servers. -\section{Acknowledgments} +\section*{Acknowledgments} Thanks to Steven J. Murdoch and the Tor Project for the fruitful conversations on packet size pluggable transports. -\bibliographystyle{plain} -\begin{thebibliography}{9} +The packet length probability distributions were formed after +analysis of traffic traces kindly provided by CAIDA. The traffic +traces were captured by monitoring an Equinix datacenter in Chicago, +IL.% +\footnote{\url{https://gitorious.org/morpher/morpher/blobs/master/ACKNOWLEDGMENTS}}% +\textsuperscript{,}% +\footnote{\url{https://gitorious.org/morpher/morpher/trees/master/data}} -\bibitem{ssh} - \url{https://www.ietf.org/rfc/rfc4344.txt} - -\bibitem{gnutls} - \url{https://www.gnu.org/software/gnutls/manual/gnutls.html\#On-Record-Padding} - -\bibitem{ll} - M. Liberatore, B. N. Levine, \textit{Inferring the Source - of Encrypted HTTP Connections}, CCS2006, October 2006. - -\bibitem{herrmann} - Dominik Herrmann, Rolf Wendolsky, and Hannes - Federrath. 2009. Website fingerprinting: attacking popular privacy - enhancing technologies with the multinomial naïve-bayes classifier. - -\bibitem{tls_norm} - \url{https://lists.torproject.org/pipermail/tor-dev/2011-January/001077.html} - -\bibitem{morpher_eval} - \textit{Morpher pluggable transport: Select algorithm for packet size morphing} - - \url{https://trac.torproject.org/projects/tor/ticket/5023} - - \url{https://lists.torproject.org/pipermail/tor-dev/2011-January/001077.html} - -\bibitem{panchenko} - Andriy Panchenko, Lukas Niessen, Andreas Zinnen, and Thomas - Engel. 2011. \textit{Website fingerprinting in onion routing based - anonymization networks}. - -\bibitem{tm} - Charles Wright, Scott Coulls, Fabian Monrose. \textit{Traffic - Morphing: An efficient defense against statistical traffic - analysis.} In Proceedings of the 14th Annual Network and - Distributed Systems Symposium (NDSS), Feb, 2009. - -\bibitem{caida} - The packet length probability distributions were formed after - analysis of traffic traces kindly provided by CAIDA. The traffic - traces were captured by monitoring an Equinix datacenter in Chicago, - IL. - - \url{https://gitorious.org/morpher/morpher/blobs/master/ACKNOWLEDGMENTS} - - \url{https://gitorious.org/morpher/morpher/trees/master/data} - -\end{thebibliography} +\bibliography{morpher} \end{document}

1 0

[metrics-web/master] Update almost-fast-exits graph to new #6498 requirements.
by karsten＠torproject.org 22 Aug '12

22 Aug '12

commit 2ede19c6fe571f43b523de7ae662ae14a0e6aa70 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Aug 22 19:53:29 2012 +0200 Update almost-fast-exits graph to new #6498 requirements. --- rserve/graphs.R | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/rserve/graphs.R b/rserve/graphs.R index 4f444b3..c5712cd 100644 --- a/rserve/graphs.R +++ b/rserve/graphs.R @@ -926,7 +926,7 @@ plot_fast_exits <- function(start, end, path, dpi) { r$valid_after <= paste(end, "23:59:59") & r$valid_after < paste(Sys.Date() - 1, "23:59:59"), ] r <- r[r$min_rate == 11875 & r$ports == "80-443-554-1755" & - r$min_advbw == 5000, ] + r$min_advbw == 5000 & r$same_network == TRUE, ] r <- aggregate(list(relays = r$relays, P_exit = 100 * r$exit_prob), by = list(date = as.Date(cut.Date(as.Date(r$valid_after), "day"))), FUN = median) @@ -954,11 +954,11 @@ plot_almost_fast_exits <- function(start, end, path, dpi) { t$valid_after <= paste(end, "23:59:59") & t$valid_after < paste(Sys.Date() - 1, "23:59:59"), ] t1 <- t[t$min_rate == 11875 & t$ports == "80-443-554-1755" & - t$min_advbw == 5000, ] + t$min_advbw == 5000 & t$same_network == TRUE, ] t2 <- t[t$min_rate == 10000 & t$ports == "80-443" & - t$min_advbw == 2000, ] - t <- rbind( - data.frame(t1, var = "95+ Mbit/s, 5000+ KB/s, 80/443/554/1755"), + t$min_advbw == 2000 & t$same_network == FALSE, ] + t <- rbind(data.frame(t1, var = paste("95+ Mbit/s, 5000+ KB/s,", + "80/443/554/1755, 2- per /24")), data.frame(t2, var = "80+ Mbit/s, 2000+ KB/s, 80/443")) t <- aggregate(list(relays = t$relays, P_exit = 100 * t$exit_prob), by = list(date = as.Date(cut.Date(as.Date(t$valid_after), "day")),

1 0

[translation/https_everywhere] Update translations for https_everywhere
by translation＠torproject.org 22 Aug '12

22 Aug '12

commit 25e57b9f25d521b5ed05904b54f8b36d8c5d5c12 Author: Translation commit bot <translation(a)torproject.org> Date: Wed Aug 22 17:45:32 2012 +0000 Update translations for https_everywhere --- pl/ssl-observatory.dtd | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/pl/ssl-observatory.dtd b/pl/ssl-observatory.dtd index 9a9a592..211cf32 100644 --- a/pl/ssl-observatory.dtd +++ b/pl/ssl-observatory.dtd @@ -27,7 +27,7 @@ to turn it on?">--> ""> <!ENTITY ssl-observatory.prefs.alt_roots_tooltip -""> +"Jest bezpiecznym, (i dobrym pomysłem), by włączyć tą opcję, chyba że używasz intruzywnej sieci korporacyjnej lub antywirusa firmy Kaspersky, które monitorują twoje przeglądanie za pomocą TLS proxy i prywatnego roota CA. Jeżeli ta opcja jest włączona na takich właśnie sieciach, opcja ta może przyczynić się do publikacji dowodów na temat stron, które były odwiedzane przez ten proxy, ponieważ unikalne certyfikaty zostaną utworzone. Dlatego też opcja ta domyślnie jest wyłączona."> <!ENTITY ssl-observatory.prefs.anonymous "Sprawdź certyfikaty używając Tora dla prywatności"> <!ENTITY ssl-observatory.prefs.anonymous_unavailable

1 0

[translation/whisperback] Update translations for whisperback
by translation＠torproject.org 22 Aug '12

22 Aug '12

commit ed1136703beff10a0c862583fdb1d2981ec5cf10 Author: Translation commit bot <translation(a)torproject.org> Date: Wed Aug 22 17:45:28 2012 +0000 Update translations for whisperback --- nl/nl.po | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/nl/nl.po b/nl/nl.po index 1ffd603..19382f1 100644 --- a/nl/nl.po +++ b/nl/nl.po @@ -3,14 +3,15 @@ # This file is distributed under the same license as the PACKAGE package. # # Translators: +# <ayurveda63(a)gmail.com>, 2012. # Shondoit Walker <shondoit+transifex(a)gmail.com>, 2012. msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" "POT-Creation-Date: 2012-02-16 22:33+0100\n" -"PO-Revision-Date: 2012-08-16 09:20+0000\n" -"Last-Translator: Shondoit Walker <shondoit(a)gmail.com>\n" +"PO-Revision-Date: 2012-08-22 17:28+0000\n" +"Last-Translator: JerBen <ayurveda63(a)gmail.com>\n" "Language-Team: LANGUAGE <LL(a)li.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n"

1 0

[metrics-tasks/master] Update to new #6498 requirements.
by karsten＠torproject.org 22 Aug '12

22 Aug '12

commit 795c59b073582562bfcbc587b440cd9161366901 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Aug 22 13:34:12 2012 +0200 Update to new #6498 requirements. - Remove /24 requirement for almost fast exits. - Remove code for comparing different advertised bandwidhts. --- task-6498/plot.R | 32 ++++++-------------------------- task-6498/src/Main.java | 37 ++++++++++++++++--------------------- 2 files changed, 22 insertions(+), 47 deletions(-) diff --git a/task-6498/plot.R b/task-6498/plot.R index 9f7763d..cebe490 100644 --- a/task-6498/plot.R +++ b/task-6498/plot.R @@ -7,12 +7,12 @@ DETAIL <- "day" require(ggplot2) require(reshape) require(RColorBrewer) -data <- read.csv("results.csv", stringsAsFactors = FALSE) +data <- read.csv("task-6498-results.csv", stringsAsFactors = FALSE) data <- data[data$valid_after >= paste(CUTOFF, "00:00:00"), ] r <- data r <- r[r$min_rate == 11875 & r$ports == "80-443-554-1755" & - r$min_advbw == 5000, ] + r$min_advbw == 5000 & r$same_network == TRUE, ] r <- aggregate(list(relays = r$relays, P_exit = 100 * r$exit_prob), by = list(date = as.Date(cut.Date(as.Date(r$valid_after), DETAIL))), FUN = median) @@ -31,33 +31,13 @@ opts(title = paste("Fast relays (95+ Mbit/s configured bandwidth rate,\n", "at most 2 relays per /24 network)\n", sep = "")) ggsave("fast-exits.png", width = 8, height = 6, dpi = 100) -s <- data -s <- s[s$min_rate == 11875 & s$ports == "80-443-554-1755", ] -s <- aggregate(list(relays = s$relays, P_exit = 100 * s$exit_prob), - by = list(date = as.Date(cut.Date(as.Date(s$valid_after), DETAIL)), - min_advbw = s$min_advbw), FUN = median) -s <- melt(s, id.vars = c("date", "min_advbw")) -s <- data.frame(s, type = ifelse(s$variable == "P_exit", - "Total exit probability (in %)", "Number of relays")) -ggplot(s, aes(x = date, y = value, colour = as.factor(min_advbw))) + -geom_line() + -facet_grid(type ~ ., scales = "free_y") + -scale_x_date(name = "") + -scale_y_continuous(name = "") + -scale_colour_manual(name = "Advertised bandwidth (in KB/s)", - values = brewer.pal(6, "Purples")[2:6]) + -opts(title = paste("Relays meeting the fast-exit requirements\nwith", - "varying minimum advertised bandwidth capacities"), - legend.position = "top") -ggsave("advertised-bandwidths-requirement.png", width = 8, height = 6, - dpi = 100) - t <- data t1 <- t[t$min_rate == 11875 & t$ports == "80-443-554-1755" & - t$min_advbw == 5000, ] + t$min_advbw == 5000 & t$same_network == TRUE, ] t2 <- t[t$min_rate == 10000 & t$ports == "80-443" & - t$min_advbw == 2000, ] -t <- rbind(data.frame(t1, var = "95+ Mbit/s, 5000+ KB/s, 80/443/554/1755"), + t$min_advbw == 2000 & t$same_network == FALSE, ] +t <- rbind(data.frame(t1, var = paste("95+ Mbit/s, 5000+ KB/s,", + "80/443/554/1755, 2- per /24")), data.frame(t2, var = "80+ Mbit/s, 2000+ KB/s, 80/443")) t <- aggregate(list(relays = t$relays, P_exit = 100 * t$exit_prob), by = list(date = as.Date(cut.Date(as.Date(t$valid_after), DETAIL)), diff --git a/task-6498/src/Main.java b/task-6498/src/Main.java index 99e991b..8b24649 100644 --- a/task-6498/src/Main.java +++ b/task-6498/src/Main.java @@ -64,7 +64,8 @@ public class Main { BufferedWriter bw = new BufferedWriter(new FileWriter(resultsFile, true)); if (writeHeader) { - bw.write("valid_after,min_rate,min_advbw,ports,relays,exit_prob\n"); + bw.write("valid_after,min_rate,min_advbw,ports,same_network,relays," + + "exit_prob\n"); } while (descriptorFiles.hasNext()) { DescriptorFile descriptorFile = descriptorFiles.next(); @@ -184,17 +185,11 @@ public class Main { * consider the fastest 2 relays per /24 with respect to exit * probability. Also vary requirements. Overall, analyze these * settings: - * - rate >= 11875, advbw >= 5000, exit to 80, 443, 554, 1755 - * - rate >= 11875, advbw >= 5000, exit to 80, 443 - * - rate >= 11875, advbw >= 4000, exit to 80, 443, 554, 1755 - * - rate >= 11875, advbw >= 3000, exit to 80, 443, 554, 1755 - * - rate >= 11875, advbw >= 2000, exit to 80, 443, 554, 1755 - * - rate >= 11875, advbw >= 1000, exit to 80, 443, 554, 1755 + * - rate >= 11875, advbw >= 5000, exit to 80, 443, 554, 1755, + * at most 2 relays per /24 * - rate >= 10000, advbw >= 2000, exit to 80, 443 */ - int[] minimumBandwidthRates = new int[] { 11875, 11875, 11875, - 11875, 11875, 11875, 10000 }; - int[] minimumAdvertisedBandwidths = new int[] { 5000, 5000, 4000, - 3000, 2000, 1000, 2000 }; + int[] minimumBandwidthRates = new int[] { 11875, 10000 }; + int[] minimumAdvertisedBandwidths = new int[] { 5000, 2000 }; Set<Integer> defaultPorts = new HashSet<Integer>(); defaultPorts.add(80); defaultPorts.add(443); @@ -206,15 +201,12 @@ public class Main { List<Set<Integer>> requiredPorts = new ArrayList<Set<Integer>>(); requiredPorts.add(defaultPorts); requiredPorts.add(reducedPorts); - requiredPorts.add(defaultPorts); - requiredPorts.add(defaultPorts); - requiredPorts.add(defaultPorts); - requiredPorts.add(defaultPorts); - requiredPorts.add(reducedPorts); + boolean[] sameNetworks = new boolean[] { true, false }; for (int i = 0; i < minimumBandwidthRates.length; i++) { int minimumBandwidthRate = minimumBandwidthRates[i]; int minimumAdvertisedBandwidth = minimumAdvertisedBandwidths[i]; Set<Integer> minimumRequiredPorts = requiredPorts.get(i); + boolean sameNetwork = sameNetworks[i]; Map<String, List<Double>> exitWeightFractionsByAddressParts = new HashMap<String, List<Double>>(); for (String fingerprint : fingerprints) { @@ -242,9 +234,11 @@ public class Main { int totalRelays = 0; for (List<Double> weightFractions : exitWeightFractionsByAddressParts.values()) { - Collections.sort(weightFractions); - while (weightFractions.size() > 2) { - weightFractions.remove(0); + if (sameNetwork) { + Collections.sort(weightFractions); + while (weightFractions.size() > 2) { + weightFractions.remove(0); + } } for (double weightFraction : weightFractions) { totalExitWeightFraction += weightFraction; @@ -259,10 +253,11 @@ public class Main { * - ports: "80-443" or "80-443-554-1755" * - relays: number of relays matching the requirements * - exit_prob: sum of exit probabilities */ - bw.write(String.format("%s,%d,%d,%s,%d,%.4f%n", + bw.write(String.format("%s,%d,%d,%s,%s,%d,%.4f%n", validAfter, minimumBandwidthRate, minimumAdvertisedBandwidth, minimumRequiredPorts.size() <= 2 - ? "80-443" : "80-443-554-1755", totalRelays, + ? "80-443" : "80-443-554-1755", + sameNetwork ? "TRUE" : "FALSE", totalRelays, totalExitWeightFraction)); } }

1 0

[translation/https_everywhere] Update translations for https_everywhere
by translation＠torproject.org 22 Aug '12

22 Aug '12

commit 6d325c1ed24f3ca53d78ca5bb68ddfad4c5bedc7 Author: Translation commit bot <translation(a)torproject.org> Date: Wed Aug 22 17:15:31 2012 +0000 Update translations for https_everywhere --- pl/ssl-observatory.dtd | 22 +++++++++++----------- 1 files changed, 11 insertions(+), 11 deletions(-) diff --git a/pl/ssl-observatory.dtd b/pl/ssl-observatory.dtd index 5b2229c..9a9a592 100644 --- a/pl/ssl-observatory.dtd +++ b/pl/ssl-observatory.dtd @@ -31,12 +31,12 @@ to turn it on?">--> <!ENTITY ssl-observatory.prefs.anonymous "Sprawdź certyfikaty używając Tora dla prywatności"> <!ENTITY ssl-observatory.prefs.anonymous_unavailable -""> +"Sprawdź certyfikaty używając Tora dla prywatności (wymaga aplikacji Torbutton)"> <!ENTITY ssl-observatory.prefs.anonymous_tooltip -""> +"Ta opcja, do instalacji, wymaga Tora oraz aplikacji Torbutton "> <!ENTITY ssl-observatory.prefs.asn -""> +"Jeżeli dostrzeżesz nowe certyfikaty, potwierdź SLL Observatory, do którego ISP jesteś obecnie podłączony"> <!ENTITY ssl-observatory.prefs.asn_tooltip ""> @@ -44,7 +44,7 @@ to turn it on?">--> <!ENTITY ssl-observatory.prefs.done "Gotowe"> <!ENTITY ssl-observatory.prefs.explanation -""> +"HTTPS Everywhere może używać EFF's SSL Observatory. Daje to dwie rzeczy: (1) wysyła kopie certyfikatów HTTPS do SSL Observatory, pomagając nam wykryć ataki osób podsłuchujących; i (2) daje nam znać o niezabezpieczonych połączeniach lub atakach na twoją przeklądarkę.">  <!ENTITY ssl-observatory.prefs.explanation2 -""> +"Dla przykładu, jeżeli odwiedzasz https://www.something.com, certyfikat otrzymany przez SSL Observatory wskaże, że ktoś odwiedził https://www.something.com ale nie wskaże kto dokładnie ją odwiedzał i jakie strony przeglądał. Najedź kursorem na opcje by zobaczyć więcej szczegółów "> <!ENTITY ssl-observatory.prefs.hide "Schowaj zaawansowane opcje"> <!ENTITY ssl-observatory.prefs.nonanon -""> +"Sprawdź certyfikaty nawet jeżeli Tor nie jest dostępny"> <!ENTITY ssl-observatory.prefs.nonanon_tooltip -""> +"Postaramy się zachować anonimowość twoich danych, jednak ta opcja jest mniej bezpieczna."> <!ENTITY ssl-observatory.prefs.priv_dns -""> +"Wyślij i sprawdź certyfikaty dla niepublicznych nazw DNSów"> <!ENTITY ssl-observatory.prefs.priv_dns_tooltip ""> @@ -74,11 +74,11 @@ Mouseover the options for further details:">--> <!ENTITY ssl-observatory.prefs.title "Preferencje SLL Observatory"> <!ENTITY ssl-observatory.prefs.use "Użyj Observatory?"> -<!ENTITY ssl-observatory.warning.title ""> +<!ENTITY ssl-observatory.warning.title "OSTRZEŻENIE od EFF's SSL Observatory"> <!ENTITY ssl-observatory.warning.showcert "Pokaż łańcuch certyfikatu"> <!ENTITY ssl-observatory.warning.okay "Tak rozumie"> -<!ENTITY ssl-observatory.warning.text ""> -<!ENTITY ssl-observatory.warning.defense ""> +<!ENTITY ssl-observatory.warning.text "EFF's SSL Observatory wystawił ostrzeżenie na temat certyfikatów HTTPS dla tej stron:"> +<!ENTITY ssl-observatory.warning.defense "Jeżeli zalogowałeś się do tej strony, bezpiecznym będzie zmiana hasła, po ponownym połączeniu się z bezpieczną siecią."> <!ENTITY ssl-observatory.prefs.self_signed "">

1 0

← Newer
1
...
27
28
29
30
31
32
33
...
91
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits August 2012