Traffic Analysis Attacks and Defenses in Low Latency Anonymous

153 Pages·2014·3.92 MB·English

by  Sambuddho Chakravarty

Traffic Analysis Attacks and Defenses in Low Latency
Anonymous Communication
Sambuddho Chakravarty
Submittedinpartialfulfillmentofthe
requirementsforthedegree
ofDoctorofPhilosophy
intheGraduateSchoolofArtsandSciences
COLUMBIA UNIVERSITY
2014
(cid:13)c 2014
SambuddhoChakravarty
AllRightsReserved
ABSTRACT
Traffic Analysis Attacks and Defenses in Low Latency
Anonymous Communication
Sambuddho Chakravarty
Therecentpublicdisclosureofmasssurveillanceofelectroniccommunication,involv-
ing powerful government authorities, has drawn the public’s attention to issues regarding
Internetprivacy. Foralmostadecadenow,therehavebeenseveralresearcheffortstowards
designing and deploying open source, trustworthy and reliable systems that ensure users’
anonymityandprivacy. Thesesystemsoperatebyhidingthetruenetworkidentityofcom-
municatingpartiesagainsteavesdroppingadversaries. Tor,acronymforTheOnionRouter,
is an example of such a system. Such systems relay the traffic of their users through an
overlay of nodes that are called Onion Routers and are operated by volunteers distributed
across the globe. Such systems have served well as anti-censorship and anti-surveillance
tools. However,recentpublicationshavedisclosedthatpowerfulgovernmentorganizations
areseekingmeanstode-anonymizesuchsystemsandhavedeployeddistributedmonitoring
infrastructuretoaidtheirefforts.
Attacksagainstanonymouscommunicationsystems,likeTor,ofteninvolvetrafficanal-
ysis. Insuchattacks,anadversary,capableofobservingnetworktrafficstatisticsinseveral
different networks, correlates the traffic patterns in these networks, and associates other-
wise seemingly unrelated network connections. The process can lead an adversary to the
source of an anonymous connection. However, due to their design, consisting of globally
distributed relays, the users of anonymity networks like Tor, can route their traffic virtu-
allyviaanynetwork;hidingtheirtracksandtrueidentitiesfromtheircommunicationpeers
and eavesdropping adversaries. De-anonymization of a random anonymous connection is
hard,astheadversaryisrequiredtocorrelatetrafficpatternsinonenetworklinktothosein
virtuallyallothernetworks. Pastresearchmostlyinvolvedreducingthecomplexityofthis
processbyfirstreducingthesetofrelaysornetworkrouterstomonitor,andthenidentifying
the actual source of anonymous traffic among network connections that are routed via this
reduced set of relays or network routers to monitor. A study of various research efforts in
thisfieldrevealsthattherehavebeenmanymoreeffortstoreducethesetofrelaysorrouters
to be searched than to explore methods for actually identifying an anonymous user amidst
thenetworkconnectionsusingtheseroutersandrelays. Fewhavetriedtocomprehensively
studyacompleteattack,thatinvolvesreducingthesetofrelaysandrouterstomonitorand
identifying the source of an anonymous connection. Although it is believed that systems
likeToraretriviallyvulnerabletotrafficanalysis,therearevarioustechnicalchallengesand
issuesthatcanbecomeobstaclestoaccuratelyidentifyingthesourceofanonymousconnec-
tion. It is hard to adjudge the vulnerability of anonymous communication systems without
adequatelyexploringtheissuesinvolvedinidentifyingthesourceofanonymoustraffic.
Wetakestepstofillthisgapbyexploringtwonovelactivetrafficanalysisattacks, that
solely rely on measurements of network statistics. In these attacks, the adversary tries to
identifythesourceofananonymousconnectionarrivingtoaserverfromanexitnode. This
generally involves correlating traffic entering and leaving the Tor network, linking other-
wise unrelated connections. To increase the accuracy of identifying the victim connection
among several connections, the adversary injects a traffic perturbation pattern into a con-
nection arriving to the server from a Tor node, that the adversary wants to de-anonymize.
One way to achieve this is by colluding with the server and injecting a traffic perturbation
pattern using common traffic shaping tools. Our first attack involves a novel remote band-
widthestimationtechniquetoconfirmtheidentityofTorrelaysandnetworkroutersalong
thepathconnectingaTorclientandaserverbyobservingnetworkbandwidthfluctuations
deliberately injected by the server. The second attack involves correlating network statis-
tics,forconnectionsenteringandleavingtheTornetwork,availablefromexistingnetwork
infrastructure, such as Cisco’s NetFlow, for identifying the source of an anonymous con-
nection. Additionally, we explored a novel technique to defend against the latter attack.
Mostresearchtowardsdefendingagainsttrafficanalysisattacks,involvingtransmissionof
dummy traffic, have not been implemented due to fears of potential performance degra-
dation. Our novel technique involves transmission of dummy traffic, consisting of packets
withIPheadershavingsmallTime-to-Live(TTL)values. Suchpacketsarediscardedbythe
routersbeforetheyreachtheirdestination. TheydistortNetFlowstatistics,withoutdegrad-
ing the client’s performance. Finally, we present a strategy that employs transmission of
uniqueplain-textdecoytraffic,thatappearssensitive,suchasfakeusercredentials,through
Tornodestodecoyserversunderourcontrol. Periodictallyingofclientandserverlogsto
determine unsolicited connection attempts at the server is used to identify the eavesdrop-
ping nodes. Such malicious Tor node operators, eavesdropping on users’ traffic, could be
potentialtrafficanalysisattackers.
Table of Contents
1 Introduction 2
1.0.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.0.2 SummaryofAttacks . . . . . . . . . . . . . . . . . . . . . . . . 8
1.0.3 ProblemDescriptionandHypothesis . . . . . . . . . . . . . . . 11
1.0.4 ImportantAssumptionsandAttackerModels . . . . . . . . . . 13
Thesiscontributions: . . . . . . . . . . . . . . . . . . . . 15
Thesisroadmap: . . . . . . . . . . . . . . . . . . . . . . . 16
2 BackgroundInformationandRelatedResearch 17
2.1 BackgroundInformation . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1 AnonymousNetworkCommunicationSystems . . . . . . . . . . . 17
2.2 RelatedResearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1 AttacksAgainstAnonymousCommunicationSystems . . . . . . . 21
2.2.2 DefendingAgainstTrafficAnalysisAttacks . . . . . . . . . . . . . 27
2.2.3 DetectingEavesdroppingbyTorExitNodes: DetectionofPotential
TrafficAnalysisAttackers . . . . . . . . . . . . . . . . . . . . . . 28
3 TrafficAnalysisAgainstAnonymityNetworksUsingRemoteBandwidthEsti-
mation 31
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 LinkWidth: SingleEnd-ControlledBandwidthMeasurementTechnique . . 33
3.3 ThreatModelandAttackApproach . . . . . . . . . . . . . . . . . . . . . 35
3.4 ExperimentalEvaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
i
3.4.1 ExperimentsUsingtheDETERTestbed . . . . . . . . . . . . . . . 37
3.4.2 In-LabExperiments . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.3 ProbingTorRelays,ClientsandHiddenServices . . . . . . . . . . 42
3.5 Discussions,IssuesandLimitations . . . . . . . . . . . . . . . . . . . . . 48
3.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4 TrafficAnalysisAgainstAnonymityNetworksUsingFlowRecords 52
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2 NetworkMonitoring(NetFlow). . . . . . . . . . . . . . . . . . . . . . . . 54
4.3 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.1 ThreatModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.2 AttackApproach . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Implementation . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4 ExperimentalEvaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.1 Experimental Evaluation in Controlled Environments (Using In-
LabTestbed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4.2 ExperimentalEvaluationInvolvingPublicTorRelays . . . . . . . . 63
4.4.2.1 MonitoringmultipleTorrelays . . . . . . . . . . . . . . 71
4.5 DiscussionsandLimitations . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5 DefendingAgainstNetFlowTraffic
AnalysisAttacks 75
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2 AttackerModelandtheApproachTowardsDefending
AgainstTrafficAnalysisAttack. . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.1 AttackerModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.2 DefendingAgainstTrafficAnalysisAttack . . . . . . . . . . . . . 79
5.3 ExperimentalResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.3.1 DefendingAgainstNetFlowTrafficAnalysisUsingDummyTraffic 85
ii
5.3.2 DefendingAgainstNetFlowTrafficAnalysisAttackUsingTorTraf-
ficShapingandConditioningParameters . . . . . . . . . . . . . . 88
5.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6 DeterminingPotentialAdversariesofAnonymityNetworks: EavesdropDetec-
tioninAnonymityNetworks 92
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.2 RelevantResearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.3 SystemArchitecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.3.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.3.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
QualityofDecoyTrafficandHoneypotServices . . . . . . 103
TimeSynchronization . . . . . . . . . . . . . . . . . . . . 104
EavesdroppingIncidentVerification . . . . . . . . . . . . . 104
6.4 DeploymentResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.4.1 EavesdroppingIncidents . . . . . . . . . . . . . . . . . . . . . . . 105
6.4.2 Adversaries’Activities . . . . . . . . . . . . . . . . . . . . . . . . 107
6.4.3 VolumeofDecoyTrafficInjected . . . . . . . . . . . . . . . . . . 109
6.4.4 AttributesoftheExitNodesInvolvedintheIncidents . . . . . . . . 109
6.5 Other Efforts and Possibilities: HTTP Session Cookie Hijack and SSL
MITMdetection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.5.1 DetectionofHTTPSessionHijacking . . . . . . . . . . . . . . . . 110
6.5.2 SSLMan-In-The-MiddleAttackDetection . . . . . . . . . . . . . 111
6.6 DiscussionandFuturework . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.6.1 DetectionConfidence . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.6.2 TrafficEavesdroppingandAnonymityDegradation . . . . . . . . . 114
6.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7 LessonsLearnt: Discussion,Limitationsand
FutureWork 116
iii
7.1 DiscussionsandLimitations . . . . . . . . . . . . . . . . . . . . . . . . . 116
7.2 FutureWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
8 Conclusions 123
Bibliography 126
iv
List of Figures
2.1 BasicstepsforcommunicatingthroughTor. Theclientobtainsalistofthe
available Tor relays from a directory service (cid:13)1 , establishes a circuit using
multiple Tor nodes (cid:13)2 , and then starts forwarding its traffic through the
newlycreatedcircuit(cid:13)3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Layered (telescopic) encryption used by Tor client to encrypt Tor cells.
Eachrelaydecryptsonelayerofencryptionandforwardstheresultantcells
tothenextrelayalongthepath. Theexitnodeseestheoriginalpacket(M)
andfinallytransmitsittotheserver. . . . . . . . . . . . . . . . . . . . . . 19
2.3 Basic steps for communicating to hidden services. The client and server
create Tor circuits(cid:13)1 to nodes called Rendezvous Point(cid:13)2 and Introduction
Points(cid:13)3 , respectively. The client’s query to resolve “.onion” URI gets re-
turnedwithinformationoftheIntroductionPoints. FinallytheRendezvous
PointsconnecttoIntroductionPointsandthuscommunicatestothehidden
server(cid:13)4 .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 (a)Arrangement of packets in LinkWidth for measuring available band-
width,usingTCPmeasurementpackets,(b)andusingICMPmeasurement
packets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 DETERtestbednetworktopology. . . . . . . . . . . . . . . . . . . . . . . 38
3.3 The detected available bandwidth on the router connected to the victim
router3dropsuniformlyasclienttrafficincreases. . . . . . . . . . . . . 39
3.4 Wecorrectlymeasuredtheabsenceofconsistentavailablebandwidthfluc-
tuationonrouter5(notinthevictim’spath). . . . . . . . . . . . . . . . 40
v