mitedu httpnmslcsmiteduprojectsi nfranet Abstract An incr easing number of countries and companies ou tinely bloc or monitor access to parts of the Internet counter act these measur es we pr opose Infranet sys tem that enables clients to surr eptitio ID: 67220
Download Pdf The PPT/PDF document "Infranet Cir cumv enting eb Censorship a..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Infranet:CircumventingWebCensorshipandSurveillanceNickFeamster,MagdalenaBalazinska,GregHarfst,HariBalakrishnan,DavidKargerMITLaboratoryforComputerScience feamster,mbalazin,gch,hari,karger@lcs.mit.eduhttp://nms.lcs.mit.edu/projects/infranetAbstractAnincreasingnumberofcountriesandcompaniesrou-tinelyblockormonitoraccesstopartsoftheInternet.Tocounteractthesemeasures,weproposeInfranet,asys-temthatenablesclientstosurreptitiouslyretrievesensitivecontentviacooperatingWebserversdistributedacrosstheglobalInternet.TheseInfranetserversprovideclientsac-cesstocensoredsiteswhilecontinuingtohostnormalun-censoredcontent.Infranetusesatunnelprotocolthatpro-videsacovertcommunicationchannelbetweenitsclientsandservers,modulatedoverstandardHTTPtransactionsthatresembleinnocuousWebbrowsing.Intheupstreamdirection,InfranetclientssendcovertmessagestoInfranetserversbyassociatingmeaningtothesequenceofHTTPrequestsbeingmade.Inthedownstreamdirection,Infranetserversreturncontentbyhidingcensoreddatainuncen-soredimagesusingsteganographictechniques.Wedescribethedesign,aprototypeimplementation,securityproperties,andperformanceofInfranet.OursecurityanalysisshowsthatInfranetcansuccessfullycircumventseveralsophisti-catedcensoringtechniques.1IntroductionTheWorldWideWebisaprimefacilitatoroffreespeech;manypeoplerelyonittovoicetheirviewsandtogainaccesstoinformationthattraditionalpublishingvenuesmaybeloathtopublish.However,overthepastfewyears,manycountries,politicalregimes,andcorporationshaveat-temptedtomonitorandoftenrestrictaccesstoportionsoftheWebbyclientswhousenetworkstheycontrol.Manyoftheseattemptshavebeensuccessful,andtheuseoftheWebasafree-owingmediumforinformationexchangeisbeingseverelycompromised.SeveralcountrieslterInternetcontentattheirborders,fearfulofalternatepoliticalviewsorexternalinuences.Forexample,Chinaforbidsaccesstomanynewssitesthathavebeencriticalofthecountry'sdomesticpolicies.SaudiArabiaiscurrentlysolicitingcontentltervendorstohelpblockaccesstositesthatthegovernmentdeemsinappro-priateforpoliticalorreligiousreasons[10].Germanycen-sorsallNazi-relatedmaterial.Australia'slawsbanpornog-raphy.Inaddition,Internetcensorshiprepeatedlythreat-enstocrosspoliticalboundaries.Forexample,theU.S.SupremeCourtrecentlyrejectedFrance'srequesttocensorNazi-relatedmaterialonYahoo'ssite[12].Censorshipandsurveillancealsoextendintofreeenterprise,withseveralcompaniesintheU.S.reportedlyblockingaccesstositesthatarenotrelatedtoconductingbusiness.Inadditiontoblockingsites,manycompaniesroutinelymonitortheirem-ployees'Websurnghabits.Thispaperfocusesonthechallengingtechnicalprob-lemsofcircumventingWebcensorshipandlargelyignoresthemanyrelatedpolitical,legal,andpolicyissues.Inpar-ticular,weinvestigatehowtoleverageWebcommunicationwithaccessibleserversinordertosurreptitiouslyretrievecensoredcontent,whilesimultaneouslymaintainingplausi-bledeniabilityagainstreceivingthatcontent.Tothisend,wedevelopacovertcommunicationtunnelthatsecurelyhidestheexchangeofcensoredcontentinnormal,innocu-ousWebtransactions.Oursystem,calledInfranet,consistsofrequestersandresponderscommunicatingoverthiscoverttunnel.Are-quester,runningonauser'scomputer,rstusesthetunneltorequestcensoredcontent.Uponreceivingtherequest,theresponder,astandardpublicWebserverrunningInfranetsoftware,retrievesthesoughtcontentfromtheWebandre-turnsittotherequesterviathetunnel.1ThecoverttunnelprotocolbetweenanInfranetrequesterandrespondermustbedifculttodetectandblock.Morespecically,acensorshouldnotbeabletodetectthataWebserverisanInfranetresponderorthataclientisanIn-1WeusethetermsrequesterandresponderratherthanthemoretraditionalclientandservertoavoidconfusionwithWebclients(browsers)andWebservers.Wealsoconsideredanumberoftermslikeproxy,gateway,front-end,etc.,butrejectedthemforsimilarreasons. franetrequester.NothingintheirHTTPtransactionsoughttoarousesuspicion.TheInfranettunnelprotocolusesnoveltechniquesforcovertupstreamcommunication.Itmodulatescovertmes-sagesonstandardHTTPrequestsforuncensoredcon-tentusingacondentiallynegotiatedfunctionwhichmapsURLstomessagefragmentsthatcomposerequestsforcen-soredcontent.Fordownstreamcommunication,thetunnelprotocolleveragesexistingdatahidingtechniques,suchassteganography.Whilesteganographyprovideslittledefenseagainstcertainattacks,wearecondentthattheideaswepresentcanbeusedinconjunctionwithotherdatahidingtechniques.Themainchallengeinthedesignofthetunnelprotocolisensuringcovertnesswhileprovidingalevelofperformancesuitableforinteractivebrowsing.Furthermore,thetunnelprotocolmustdefendagainstacensorcapableofpassiveat-tacksbasedonloggingalltransactionsandpackets,activeattacksthatmodifymessagesortransactions,andimper-sonationattackswheretheadversarypretendstobealegit-imateInfranetrequesterorresponder.Oursecurityanaly-sisindicatesthatInfranetcansuccessfullycircumventsev-eralsophisticatedcensoringtechniques,includingvariousactiveandpassiveattacks.Oursystemhandlesalmostallofthesethreatswhileachievingreasonableperformance.Thisisachievedbytakingadvantageoftheasymmetricband-widthrequirementsofWebtransactions,whichrequiresig-nicantlylessupstreambandwidththandownstreamband-width.Toassessthefeasibilityofourdesign,weimplementedanInfranetprototypeandconductedaseriesoftestsusingclient-sideWebtracestoevaluatetheperformanceofoursystem.OurexperimentalevaluationshowsthatInfranetprovidesacceptablebandwidthforcovertWebbrowsing.Ourrange-mappingalgorithmforupstreamcommunicationallowsarequestertoinnocuouslytransmitahiddenrequestinanumberofvisibleHTTPrequeststhatisproportionaltothebinaryentropyofthehiddenrequestdistribution.FortwotypicalWebsitesrunningInfranetresponders,wendthatarequesterusingrange-mappingcanmodulate50%ofallrequestsforhiddencontentin6visibleHTTPrequestsorfewerand90%ofallhiddenrequestsin10visibleHTTPre-questsorfewer.UsingtypicalWebimages,ourimplemen-tationofdownstreamhidingtransmitsapproximately1kBofhiddendatapervisibleHTTPresponse.2RelatedWorkManyexistingsystemsseektocircumventcensorshipandsurveillanceofInternettrafc.Anonymizer.comprovidesanonymousWebsessionsbyrequiringuserstomakeWebrequeststhroughaproxythatanonymizesuser-specicinformation,suchastheuser'sIPaddress[2].ThecompanyalsoprovidesaproductthatencryptsHTTPre-queststoprotectuserprivacy;ZeroKnowledgeprovidesasimilarproduct[24].SquidisacachingWebproxythatcanbeusedasananonymizingproxy[21].Theprimaryshortcomingoftheseschemesisthatawell-knownproxyissubjecttobeingblockedbyacensor.Additionally,theuseofanencryptedtunnelbetweenauserandtheanonymizingproxy(e.g.,portforwardingoverssh)engenderssuspicion.Becausecensoringorganizationsareactivelydiscover-ingandblockinganonymizingproxies,SafeWebhaspro-posedaproductcalledTriangleBoy,apeer-to-peerappli-cationthatvolunteersrunontheirpersonalmachinesandthatforwardsclients'WebrequeststoSafeWeb'sanonymiz-ingproxy[19,27].SafeWebrecentlyformedanalliancewiththeVoiceofAmerica[28],whosemissionistoen-ableChineseInternetuserstogainaccesstocensoredsites.However,TriangleBoyhasseveraldrawbacks.First,theencryptedconnectiontoamachinerunningTriangleBoyissuspiciousandcanbetriviallyblockedsinceSSLhandshak-ingisunencrypted.Second,SafeWeb'sdependenceonanencryptedchannelforcondentialitymakesitsusceptibletotrafcanalysis,sinceWebsitengerprintingcanexposetheWebsitesthatauserrequests,eveniftherequestitselfisen-crypted[7].Third,SafeWebisvulnerabletoseveralattacksthatallowanadversarytodiscovertheidentityofaSafeWebuser,aswellaseveryWebsitevisitedbythatuser[11].PeekabootyalsoattemptstocircumventcensoringrewallsbysendingSSL-encryptedrequestsforcensoredcontenttoathirdparty,butitsrelianceonSSLalsomakesitsuscepti-bletotrafcanalysisandblockingattacks[26].Varioussystemshaveattemptedtoprotectanonymityforuserswhopublishandretrievecensoredcontent.InCrowds,usersjoinalarge,geographicallydiversegroupwhosememberscooperateinissuingrequests,thusmak-ingitdifculttoassociaterequestswiththeoriginatinguser[18].Onionroutingalsoseparatesrequestsfromtheuserswhomakethem[25].Publius[30],Tangler[29],andFreeHaven[4]focusonprotectingtheanonymityofpub-lishersofcensoredcontentandthecontentitself.Freenetprovidesanonymouscontentstorageandretrieval[3].Infranetaimstoovercomecensorshipandsurveillance,butalsoprovidesplausibledeniabilityforusers.InadditiontoestablishingasecurechannelbetweenusersandInfranetresponders,oursystemcreatesacovertchannelwithinHTTP,i.e.,acommunicationchannelthattransmitsinfor-mationinamannernotenvisionedbytheoriginaldesignofHTTP[9].Incontrastwithtechniquesthatattempttoover-comecensorshipusingacondentialchannel(e.g.,usingSSL,whichistrivialtodetectandblock)[19,23,24,26],ourapproachissignicantlyhardertodetectorblock.Tobeeffectiveagainstblocking,aschemeforcircumventingcensorshipmustbecovertaswellassecure. Infranet\rRequester\rInfranet\rResponder\rUser\rWeb\rBrowser\rOrigin\rWeb\rServer\rCommunication Tunnel\rCensor\rVisible HTTP\rReq/\rHidden msg\rStandard\rHTTP\rVisible HTTP\rResp/\rHidden content\rVisible HTTP\rResp/\rHidden content\rVisible HTTP\rReq/\rHidden msg\rUser Machine\rFigure1.Infranetsystemarchitecture.3SystemArchitectureThissectionpresentsInfranet'sdesignconsiderationsandsystemarchitectureandgivesanoverviewofthesys-tem'scommunicationprotocols.3.1TerminologyFigure1showsthesystemarchitectureofInfranetandintroducesrelevantterminology.UserssurfWebcontentasusualviaaWebbrowser.Toretrievecensoredcontent,thebrowserusesasoftwareentitythatrunsonthesamehost,calledtheInfranetrequester,asitslocalproxy.TheIn-franetrequesterknowsaboutoneormoreInfranetrespon-ders,whichareWebserversintheglobalInternetthatim-plementadditionalInfranetfunctionality.TheideaisfortheWebbrowsertorequestcensoredcontentviatheIn-franetrequester,whichinturnsendsamessagetoanIn-franetresponder.TheresponderretrievesthiscontentfromtheappropriateoriginWebserverandreturnsittothere-quester,whichdeliverstherequestedcontenttothebrowser.Therequesterandrespondercommunicatewitheachotherusingacoverttunnel.Technically,Infranetinvolvesthreedistinctfunctionsissuingahiddenrequest,decodingthehiddenrequest,andservingtherequestedcontent.Werstdescribeasystemwherebytheresponderperformsthelattertwofunctions.WedescribeadesignenhancementinSec-tion8wherebyanuntrustedforwardercanforwardhiddenrequestsandservehiddencontent,therebymakingitmoredifcultforacensortoblockaccesstothesystem.ThecensorshowninFigure1mighthaveawiderangeofcapabilities.Ataminimum,thecensorcanblockspecicIPaddresses(e.g.,ofcensoredsitesandsuspectedInfranetresponders).Morebroadly,thecensormighthavethecapa-bilitytoanalyzelogsofallobservedWebtrafc,oreventomodifythetrafcitself.Thelong-termsuccessofInfranetdependsonthewidespreaddeploymentofInfranetrespondersintheInter-net.OnewayofachievingthismightbetobundlerespondersoftwarewithstandardWebserversoftware(e.g.,Apache).Hopefully,asignicantnumberofpeoplewillrunInfranetrespondersduetoaltruismorbecausetheybelieveinfreespeech.3.2DesignGoalsWedesignedInfranettomeetanumberofgoals.Or-deredbypriority,thegoalsare:1.DeniabilityforanyInfranetrequester.ItshouldbecomputationallyintractabletoconrmthatanyindividualisintentionallydownloadinginformationviaInfranet,ortodeterminewhatthatinformationmightbe.2.Statisticaldeniabilityfortherequester.EvenifitisimpossibletoconrmthataclientisusingInfranet,anad-versarymightnoticestatisticalanomaliesinbrowsingpat-ternsthatsuggestaclientisusingInfranet.Ideally,anIn-franetuser'sbrowsingpatternsshouldbestatisticallyindis-tinguishablefromthoseofnormalWebusers.3.Respondercovertness.SinceanadversarywilllikelyblockallknownInfranetresponders,itmustbedifculttodetectthataWebserverisrunningInfranetsimplybywatchingitsbehavior.Ofcourse,anyrequesterusingtheserverwillknowthattheserverisanInfranetresponder;however,thisknowledgeshouldonlyarisefrompossessionofasecretthatremainsunavailabletothecensor.Ifthecen-sorchoosesnottoblockaccesstotheresponderbutrathertowatchclientsconnectingtoitforsuspiciousactivities,de-niabilityshouldnotbecompromised.TherespondermustassumethatallclientsareInfranetrequesters.ThisensuresthatInfranetrequesterscannotbedistinguishedfrominno-centusersbasedontheresponder'sbehavior.4.Communicationrobustness.TheInfranetchannelshouldberobustinthepresenceofcensorshipactivitiesde-signedtointerferewithInfranetcommunication.Notethatitisimpossibletobeinnitelyrobust,becauseacensorwhoblocksallInternetaccesswillsuccessfullypreventInfranetcommunication.Thus,weassumethecensorpermitssomecommunicationwithnon-censoredsites. AnytechniquethatpreventsasitefrombeingusedasanInfranetrespondershouldmakethatsitefundamentallyun-usablebynon-Infranetclients.Asanexampleofaschemethatisnotrobust,considerusingSSLasourInfranetchan-nel.Whilethisprovidesfullrequesterandresponderde-niabilityandcovertness(sincemanyWebserversrunSSLforinnocentreasons),itisquiteplausibleforacensortoblockallSSLaccesstotheInternet,sincevastamountsofinformationremainaccessiblethroughnon-encryptedcon-nections.Thus,acensorcanblockSSL-InfranetwithoutcompletelyrestrictingInternetaccess.Inasimilarvein,ifthecensorhasconcludedthatapar-ticularsiteisanInfranetresponder,weshouldensurethattheironlyoptionforblockingInfranetaccessistoblockallaccesstothesuspectedsite.Hopefully,thiswillmakethecensormorereluctanttoblocksites,whichwillallowmoreInfranetresponderstoremainaccessible.5.Performance.WeseektomaximizetheperformanceofInfranetcommunication,subjecttoourotherobjectives.3.3OverviewArequestermustbeabletobothjoinanduseInfranetwithoutarousingsuspicion.TojoinInfranet,ausermustobtaintheInfranetrequestersoftware,plustheIPaddressandpublickeyofatleastoneInfranetresponder.UsersmustbeabletoobtainInfranetrequestersoftwarewithoutrevealingthattheyaredoingso.InformationaboutInfranetrespondersmustbeavailabletolegitimateusers,butshouldnotfallintothehandsofanadversarywhocouldthencon-gureasimpleIP-basedlteringproxy.Onewaytodis-tributesoftwareisout-of-bandviaaCD-ROMoroppydisk.UserscansharecopiesofthesoftwareandlearnaboutInfranetrespondersdirectlyfromoneanother.Thedesignandimplementationofagoodtunnelproto-colbetweenanInfranetrequesterandresponderisthecrit-icaldeterminantofInfranet'sviability.Therestofthissec-tiongivesanoverviewoftheprotocol,andSection4de-scribestheprotocolindetail.Wedenethetunnelprotocolbetweentherequesterandresponderintermsofthreeabstractionlayers:1.Messageexchange.Thislayerofabstractionspecieshigh-levelnotionsofinformationthatrequesterandre-spondercommunicatetoeachother.2.Symbolconstruction.Anycommunicationsystemmustspecifyanunderlyingalphabetofsymbolsthataretransmitted.Thislayerofabstractionspeciesthealphabetsforbothdirectionsofcommunication.Theprimarydesignconstraintiscovertness.3.Modulation.Thelowestlayerofabstractionspeci-esthemappingbetweensymbolsinthealphabetandmessagefragments.Themaindesigngoalisreason-ablecommunicationbandwidth,withoutcompromis-ingcovertness. \n \r \r\n \n \r \r \r\n=0;=0; "!"#%$'&)(+*-,/.10+2354-687"9":%;'G H"I-J@KML-N/O+P1QR5S-T8UWVX+Y5Z@[B\+Z@]_^`a\rbdcefFigure2.Topmostlayerofabstractionincommunicationtunnel.Thetop-mostlayerofabstractionistheexchangeofmes-sagesbetweentherequesterandresponder.Therequestersendsrequestsforcontenttotheresponder,hiddeninvis-ibleHTTPtrafc.Theresponderanswerswithrequestedcontent,hiddeninvisibleHTTPresponses,afterobtainingitfromtheoriginserver.AsshowninFigure2,messagesarehiddenwithahidingfunctiongihMSGjCOVERjSECRETk,whereMSGisthemessagetobehidden,COVERisthevisi-bletrafcmediuminwhichMSGishidden,andSECRETen-suresthatonlytherequesterandrespondercanrevealMSG.Designingthehidingfunctionginvolvesdeningasetofsymbolsthatmapontomessagefragments.Thesetofallsymbolsusedtotransmitmessagefragmentsiscalledanalphabet.Sinceanorderedsequenceoffragmentsformsamessage,anorderedsequenceofsymbols,alongwiththehidingfunction,alsorepresentamessage.Bothupstreamanddownstreamcommunicationrequireasetofsymbolsfortransmittingmessages.Thelowestabstractionlayerismodulation,whichspeci-esthemappingbetweenmessagefragmentsandsymbols.Wediscussseveralwaystomodulatemessagesintheup-streamanddownstreamdirectionsinSections4.2and4.3.3.3.1UpstreamCommunicationInourdesign,thecovermediumforupstreamcommunica-tion,COVERl-m,issequencesofHTTPrequests(notethatwhichlinkisselectedonthepagecontainsinformationandcanthereforebeusedforcommunication).ThealphabetisthesetofURLsontheresponder'sWebsite.Otherpossiblealphabetsexist,suchasvariouseldsintheHTTPandTCPheaders.WechoosetousethesetofURLsasouralphabetbecauseitismoredifcultforthetransmissionofmessagestobedetected,itisimmunetomaliciouseldmodicationsbyacensor,anditprovidesreasonablebandwidth.CarefulmeteringoftheorderandtimingofthecoverHTTPcommunicationmakesitdif-cultforthecensortodistinguishInfranet-relatedtrafcfromregularWebbrowsing.Upstreammodulationcorresponds no pqrso t"uv tsw x t"ysut"qno pqrso tsuv tsysz {)o | tsq}d~~@s sWd 'dWs1 ¡£¢¤¦¥§d¨©sª«¬¯®°s±"²"³M´µ¶)··¹¸»º)¼s½»¾"¿À)Á"ÂsÃÅĹÆ-ÇÈÇɦÊË\rÌÍ"ÎÏBÐÒÑ5ÓÔÓÕ Ö¦×)ØØÙ»Ú)Û"Ü"ÝßÞ"àá)âsã"äæåDçèsé"ê ëìíî"ïð'ñò\róôõõö÷+ø@ù)úúûýü)þ"ÿ \n \r ! "#%$& '')(+* ,-/.0)1 23457698:;&#x=000;@?ACBDEFHGI JK L)MKLONQP RR)S+T UVW XY)Z [\] ^Q_`abcdfemnmopgpqrpsetvuqgpuoyzxogpu|f}k{k~eehjwgetvuwqgpuyzxgpulqoikpg exeikglqoikpg eikuoikejjjvjjFigure3.Messagesexchangedduringthetunnelsetupandsteadystatecommunicationphases.Messageexchangesaredrivenbyacommonstatemachineshownontheleft.IntheoptionalInitializeModulationFunctionstate,therespondersendsaninitialmodulationfunction ¢¡)£¤¡totherequester.tomappingasequenceofoneormoreURLretrievals,visi-bletoacensor,toasurreptitiousrequestforacensoredWebobject.3.3.2DownstreamCommunicationThecovermediuminthedownstreamdirection,COVER¦9§©¨£,isprovidedbyJPEGimages(withinHTTPresponsestreams).Theresponderusesthehighfrequencycomponentsofimagesasitsalphabetforsendingmessagestotherequester.Thistechniqueprovidesgoodbandwidthandhidingproperties.Downstreammodulationconsistsofmappingasequenceofhigh-frequencyimagecomponentstothecensoredwebobject,suchasHTMLorMIME-encodedcontent.4TunnelProtocolTheInfranettunnelprotocolisdividedintothreemaincomponents:tunnelsetup,upstreamcommunication,anddownstreamcommunication.Tunnelsetupallowsbothpartiestoagreeoncommunicationparameters.Upstreamcommunicationconsistsofmessagetransmissionsfromre-questertoresponder.Downstreamcommunicationconsistsofmessagetransmissionsintheoppositedirection.BoththerequesterandresponderoperateaccordingtothenitestatemachineshownintheleftcolumnofFigure3.Therstfourstatesconstitutetunnelsetup.Thelasttwocomposesteadystatecommunication,wheretherequestertransmitshiddenURLsandtheresponderanswerswiththecorrespondingcontent.Wenowexplorevariousdesignalternativesanddescribethemechanismsusedforeachpartoftheprotocol.4.1TunnelSetupAnInfranetrequesterandresponderestablishatunnelbyagreeingonparameterstothehidingfunctionsgl-mandgª¦9§¨£.Therequesterandresponderexchangethesepa-rameterssecurely,therebyensuringcondentialityduringfuturemessageexchanges.Figure3showsthemessagesinvolvedinestablishingthetunnel.CommunicationwithanInfranetresponderbeginswitharequestforanHTMLpageservedbytheresponder.Thisrstrequestinitiatesthefollowingtunnelsetupproto-col:1.SetUserIDTherequestersendsanimplicitHELLOmessagetotheresponderbyrequestinganHTMLdocument,suchasindex.html.Toidentifysubsequentmessagetransmissionsfromtherequester,therespondercreatesauniqueuserIDfortherequester.ThisuserIDcouldbeexplicitlysetviaaWebcookie.However,forgreaterdefenseagainsttampering,theuserIDshouldbesetimplicitly.Asex-plainedlater,therespondermodiesthevisibleURLsonitsWebsiteforeachrequester.SuchmodicationissufcienttoidentifyrequestersbasedonwhichURLsarerequested.2.ExchangeKeyToensurecondentiality,therequesterusesaresponder-specicmodulationfunction ¢¡)£¤¡¥tosendasharedsecret,SKEY,encryptedwiththepublickeyoftheresponder.TheresponderrecoversSKEYusingitsprivatekey.3.UpdateModulationFunctionTheresponderrstselectsarequester-specicmodu-lationfunction ¢¥l£¤£¬«Q.Next,theresponderhidesthefunctioninanHTTPresponsestreamwiththesharedsecretSKEY.Therequesterrecovers ®¥l£¤£¬«fromtheHTTPre-sponsestreamusingSKEY. Thus,thetunnelsetupconsistsoftheexchangeoftwosecrets:asecretkeySKEY,andasecretmodulationfunc-tion ¥l£¬£¬«Q.SKEYensuresthatonlytherequesterisca-pableofdecodingthemessageshiddeninHTTPresponsestreams. ¥l£¬£¬«QallowstherequestertohidemessagesinHTTPrequeststreams.Thesecrecyof ¥l£¤£¬«Qprovidescondentialityforupstreammessagesbyensuringthatitishardforacensortouncoverthesurreptitiousrequests,evenifarequesterisdiscovered.InorderfortherequestertoinitiatethetransmissionofSKEY,encryptedwiththeInfranetresponder'spublickey,therequestermusthaveawayofsendingamessagetotheresponder.Thetransmissionisdoneusinganinitialmodu-lationfunction, ¯¡£¤¡¥.Thisinitialfunctionmaybeawell-knownfunction.Alternatively,therespondermaysendaninitialmodulationfunction, ¡)£¤¡¥totherequester.Topro-tectrespondercovertness,thisinitialfunctionshouldbehid-denusingaresponder-specickeyIKEY.TherequestermaylearnIKEYwiththeIPaddressandpublickeyoftherespon-der.Thismethod,whichrequirestheadditionalInitializeModulationFunctionstate,hastheadvantageofallowingresponderstoperiodicallychangemodulationschemes,butsuffersthedisadvantageofrequiringmoreHTTPmessageexchangestoestablishatunnel.Withthetunnelestablished,therequesterandrespon-derentertheTransmitRequeststate.Inthisstate,there-questeruses ®¥l£¤£¬«tohidearequestforcontentinaseriesofHTTPrequestssenttotheInfranetresponder.Whenthecovertrequestcompletes,therequesterandresponderentertheTransmitResponsestate,atwhichpointtheresponderfetchestherequestedcontentandhidesitinanHTTPre-sponsestreamusingSKEY.Whenthetransmissioniscom-plete,therequesterandresponderbothre-entertheTransmitRequeststate.4.2UpstreamCommunicationAtthemostfundamentallevel,arequestersendsames-sageupstreambysendingtheresponderavisibleHTTPre-questthatcontainsadditionalhiddeninformation.Figure4showsthedecompositionoftheupstreamhidingfunctiongl-mBhMSGjHTTPREQUESTSTREAMj ¢°k,whereMSGisthetransmittedinformation(e.g.,requestforhiddencon-tent),HTTPREQUESTSTREAMisthecovermedium,and ¢°isamodulationfunctionthathidesthemessageinavis-ibleHTTPrequeststream.Thespecicmappingfrommes-sagefragmentstovisibleHTTPrequestsdependsonthepa-rameter±.Tosendahiddenmessage,arequesterdividesitintomultiplefragments,eachofwhichtranslatestoavisi-bleHTTPrequest.Theresponderapplies ³² ´°tothere-quester'sHTTPrequeststoextractthemessagefragmentsandreassemblesthemtorecoverthehiddenmessage.Therearemanypossiblechoicesfortheupstreammod-µ¶)·¸¹v¶)ºf»¼jº¾½Q¿)ºfÀf»ºv¸µ¶·)¸¹v¶º »¼jº ÀvÁÂöQÄ)ºv¸ÅÆÆÇÉÈÊ ËjÌÊjÍÎÏ!ÐQÑjÒ¾ÓÔÕÃÖÖ×ÙØÃÚ ÛÜ ÝjÞÛÚßjàvá)âfãÃäå%æçñòójôjõ©ö÷ùøújûkü \n\r !#"$&%'()+**-,.+/ 01 230/&#x =00;46587:9; \rCDFEGHIJLKMN8O:PQ&RSTUVW X Y\rZ[\B]^^^Figure4.SequenceofHTTPrequestsandresponsesinvolvedinasingleupstreammessagetransmission.Bothpartiesmustknowthesecretmodulationfunction ¢°.ulationfunction ¢°.Eachoptionfor ¢°presentsadiffer-entdesigntradeoffbetweencovertnessandupstreamband-width.Therearemanymodulationfunctionsthatpro-videdeniabilityforanInfranetrequestercertaintypesofbasicmappingschemes,whenimplementedcorrectly,candoso.WedescribetwosuchexamplesinSec-tions4.2.1and4.2.2.Toprovidestatisticaldeniability,how-ever,requestsshouldfollowtypicalbrowsingpatternsmoreclosely.Toachievethis,weproposetherange-mappingschemeinSection4.2.3.4.2.1ImplicitMappingOneofthesimplest ¢°modulateseachbitofahiddenmes-sageasaseparateHTTPrequest.Whilethisapproachpro-videsextremelylimitedbandwidth,itoffersahighlevelofcovertnessonanygivenpagetherequestermayclickonanyoneofhalfofthelinkstospecifythenextfragment.Forexample,onecanspecifythatanyeven-numberedlinkonthepagecorrespondstoa0,whileanyodd-numberedlinkcorrespondstoa1.Ageneralizationofthisschemeusesthefunction_a`cbedgf,where_isspeciedbythe_thlinkonthelastrequestedpageandfisatmostequaltothetotalnumberoflinksonthatpage.Thismechanismmaybelesscovert,butsendshjih fßkbitsofinformationpervisibleHTTPrequest.4.2.2Dictionary-basedSchemesAnInfranetrespondercansendtherequesterastaticordy-namiccodebookthatmapsvisibleHTTPrequeststomes- sagefragments.WhileastaticmappingbetweenvisibleHTTPrequestsandURLsissimpletoimplement,there-sultingvisibleHTTPrequeststreamsmayresultinstrangebrowsingbehavior.Tocreateadynamicmapping,there-sponderusesimagesembeddedineachrequestedpagetosendupdatestothemodulationfunctionastheupstreamtransmissionprogresses.Therespondermayalsouseitslogofhiddenrequeststoprovidemostprobablecomple-tionstoanongoingmessagetransmission.Transmissionofak-bithiddenmessageusingadictionary-basedscheme,whereeachdictionaryentrycontainslbitsrequiresk+mlvisibleHTTPrequests.Thestructureofthedictionarydeterminesboththecovertnessandbandwidthofthemodulatedrequest.There-fore,thedictionarymightberepresentedasadirectedgraph,basedonthestructureoftheInfranetresponder'sWebsite.Topreservecondentialityintheeventthatacommunicationtunnelisrevealed,thedictionaryshouldbeknownonlytotherequesterandtheresponder.4.2.3Range-mappingTherequesterandrespondercommunicateviaachannelwithfargreaterbandwidthfromtherespondertothere-questerthanviceversa.BecausetheresponderservesmanyInfranetusers'requestsforhiddencontent,itcanmaintainthefrequencydistributionofhiddenmessages,n.Are-questerwantstosendamessage,URL,fromthedistributionn.ThiscommunicationmodelisessentiallytheasymmetriccommunicationmodelpresentedbyAdlerandMaggs[1].Weleveragetheirworktoproduceaniterativemodula-tionfunctionbasedonrange-mappingofthedistributionoflexicographicallyorderedURLs,n.Ineachround,there-spondersendstherequesterasetooftuplesh p¡jq¡k,wherep¡isastringinthedomainofnandq¡isthevisibleHTTPrequestthatcommunicatesp¡.p¡iscalledasplit-string.Itspeciestherangeofstringsinnthatarelexicograph-icallysmallerthanitselfandlexicographicallylargerthantheprecedingsplit-stringino.Theclientdetermineswhichlexicographicintervalcontainsthehiddenmessageandre-spondswiththesplit-stringthatidentiesthatinterval.WhilethefocusoftheAdler-Maggsprotocolistoen-ablecommunicationoveranasymmetricchannel,wearealsoconcernedwithmaintainingcovertnessandstatisticaldeniability.Inparticular,weaimtoensurethatateachstep,theprobabilitythatanInfranetrequesterselectsaparticularlinkisequaltotheprobabilitythataninnocentbrowserse-lectsthatlink.Wethereforeincludelinktraversalprobabil-ityinformationasaparametertothealgorithmforchoos-ingsplit-strings.Weextracttheseprobabilitiesfromtheserver'saccesslog.Priortocommunicatingwiththerequester,therespondercomputesthefollowinginformationof-PROCEDUREMODULATE(URL,r)ss6teuwvuyx{zwz|yu~}{~yvvuy}zy} 6vzj}{z \ry yr6ss6vu&x{ww :6|yx{wvv vw jwuy z|ywURL 8& ¢¡rand¤£¥¦¨§and©wª¡rs.t.«¦{§¬ª¬#ss6®¯uw°y±wuy}{zwz|yu¯ewyu~x{y juw} ewy²yw³z~z|yu}{uwvuyx{zuw²´}z \ry¦µrµ¶w·¸j¹r6+·¸j¹«º 8y&send¦Figure5.Pseudocodeforamodulationfunctionusingrangemapping.ine:n,thecumulativefrequencydistributionforhiddenrequests;and»,thelink-traversalproba-bilities.Specically,»isthesetofprobabilities¼¡¾½¿Àhnextrequestisforpage¼½ÂÁcurrentpageis¼¡kforallpages¼¡and¼½in_,thesetofallpagesontheresponder'sWebsite.Ineachround,thesetocontainsÃtuples,whereÃisthenumberofpagesqforwhichÀhÄqÁqcurrentkÆÅÈÇ,i.e.,thenumberofpossibilitiesfortherequester'snextvisibleHTTPrequest,giventhecurrentpageqcurrent.Thesetu-plesspecifyÃconsecutiveprobabilityintervalswithinn.ThesizeofeachprobabilityintervalÉËÊ¡isproportionaltotheconditionalprobabilityÀhÄqÁqcurrentk.Byassigningprobabilityintervalsaccordingtothenext-hopprobabilitiesforHTTPrequestsonaWebsite,range-mappingprovidesstatisticaldeniabilityfortherequesterbymakingitmorelikelythattherequesterwilltakeapaththroughthesitethatwouldbetakenbyaninnocuousWebclient.2ThesumofallÃintervalsisequaltoÌ,thesizeoftheprobabilityintervalforthepreviousiteration,orto1fortherstiteration.PseudocodeforthemodulationfunctionisshowninFig-ure5.Ineachiteration,therequesterreceivesoandselectsthesplitstringpthatspeciestherangeinwhichitsmes-sageURLlies.ItthensendsthecorrespondingvisibleHTTPrequestq.Figure6showspseudocodeforthedemodulationfunc-tion.Theresponderinterpretstherequestqcurrentasarangespecication,boundedabovebythecorrespondingsplit-stringpcurrentandbelowbysplit-stringinowhichprecedespcurrentlexicographically.Giventhisnewrange,theresponderupdatestheboundsfortherange,Í-ÎÏÐjÑBiÂÒ³ÓÔandÍÎÏÐjÑBiÒ³ÕÖ(lines12-13),andgeneratesanewsplit-stringsetoforthatrange(asshowninlines5-9andFig-ure7).ArequestercanusethisschemetomodulatethehiddenmessageURLevenifitisnotinthedomainofn.There-2Wepresenttherange-mappingmodelbasedonone-hopconditionalprobabilities.Itshouldbenotedthatalthoughthisapproachprovidestheappropriatedistributiononlinkprobabilitiesateachstep,itisnotguaran-teedtoproperlydistributemorecomplexquantitiessuchastheprobabilityofanentiresequenceoflinkchoices. PROCEDUREDEMODULATE(×¢ØÙØÚcurrentØÛ&ÜÝ-޾ߵàáâØ&Û&ÜÝ-Þ:ßÂà&)ssã´|yuw´z|wu´ :ywyu juwyx{|wuy}Fäuw j¨å+ juyz±y z|yu}{z \ry~w±yw²1if(Û&ÜÝ-޾ߵàáâ æÛ&ÜÝ-޾ߵà&)2returnÛ&ÜÝ-޾ߵàáâelsess6ç¯ye±wzuzyzyv :ywyu~w èz|y}ézuy :yzy3ê ëÈÙìÛ&ÜÝ-޾ߵà&yí¯îÙìÛ&ÜÝ-޾ߵàáâwíss6ïyzyväuvµð«uw Âñwy±yw²yyò j}{z+}{±yñwjwzuy óyv4ôáâëõÙìÛ&ÜÝ-޾ߵàáâíss6öèy èwvv{6uyyv }{uy óuy²¯6yyuw}Ú´÷#åeð«|yuy usse÷ø}éz|yu~}{uwzyy+yvv eywuy}éyz|yuLã³uyñ}{zu5ù6Úûú÷sseteuwzyz|wu~±-y6uy ñyw±yy²~y+z|wu´}{±wñyyzuw óÄwv e 6y Äzywyvssezz|wu6 jwñyyñwvz#yy uy°w±yuy}zy¯ewyuÚ6ôLëÈê#ü¨×¤ìÚÂýÚcurrentíþôáâsseÿyz wx{zyz|wu}{z \rw´wzyz|wu~ñwy±wy²yw wyz|wu´}±yñyyzuw óÄwvss ¨|y}F}z|wu´} evz}{z \rw~y z|wu´}±yñyyzuw óÄwv7´ëõÙ¨ìôísseteÂóu´z|wu6y y ~uy²³ñ&} 6vzj}{z \ryyw²¯eywuÚ8ë\n ì\ryØÚí ju6y u~z´x{w6±yzu}{±wñy}{uw°y±wuyyz+}{±wñyjwzuy óyv9ôáâëôss6teuyw²´z|wu}{uyzwyywvv ew j}Fz~z|yu juw°y±wuy}{zuw 10sendss6®¯uyxuy:óu~wuÂð juy°w±yuw}{z11receiveÚcurrentsse²wyzuwzuy óyv{w:óÄuwz|yu~}{uyvuwx{zuw²~} evz}{z \rw12Û&ÜÝ-޾ߵà&ë ý ¶ æÚcurrent13Û&ÜÝ-޾ߵàáâë! " ý # þ%$ æÛ&ÜÝ-޾ߵà& if '&æ)((otherwisess6ö±w Äz|yuw è juy²w±yx{uwzuy óyv14returnDEMODULATEì×¢Ø+*#ØÚcurrentØÛ&ÜÝ-޾ߵàáâØÛ&ÜÝ-Þ¾ßÂà&íFigure6.Pseudocodeforademodulationfunctionusingrangemapping.questerandrespondercanperformrange-mappinguntiltherangebecomestwoconsecutiveURLsinn.TheprexthatthesetwoURLssharebecomestheprex¼ofthehiddenmessage.Atthispoint,therequesterandrespondermaycontinuetherange-mappingalgorithmoverthesetofallstringsthathave¼asaprex.Sincetherequester'smessagemaybeofarbitrarylength,theremustexistanexplicitwaytostopthesearch.Oneso-lutionistoaddatuple,\r- .qend/too,where-indicatesthattherequesterisnishedsendingtherequest.Whenallsplit-stringsshareacommonprexequaltothehiddenmessage,therequestertransmitsqend.Range-mappingissimilartoarithmeticcoding,whichdividesthesizeofeachintervalinthespaceofbinarystringsaccordingtotheprobabilityofeachsymbolbeingtransmit-ted.Thebinaryentropy,01,Än/,istheexpectednumberofstring\r2min\rstring\r2max\rs\r21\rs\r22\rLexicographically\rordered strings\rv\r3min\rv\r31\rv\r2\rv\rmax\r...\r4...\rd \r5* P(r\r1\r|r\r6current\r)\r7d\r5d\r5 * P(r\r2\r|r\r6current\r)\r7C\r80\r91\r:Figure7.Oneiterationoftherangemappingdemodulationfunction.Theinitialinterval;n, ÍÎÏÐjÑBiÒ³ÓÔ/.-n, ÍÎÏÐÑiÒ³ÕÖ/=isdividedintoÃsubintervalsaccordingtoprobabilitiesofrequestinganypageontheresponder'sWebsitegiventhecurrentpageqcurrent.Therespondergeneratesthesplitstringsp´throughp�?thatcorrespondtosubintervalboundariesandreturnsthemtotherequester.bitsrequiredtomodulateamessageinn.Arithmeticcodingofabinarystringrequires0@,n/ACBtransmissions,assum-ingDbitpersymbol[31].Inourmodel,eachpagehasÃlinks.Therefore,eachvisibleHTTPrequesttransmitshji,Ã/bits,andtheexpectednumberofrequestsrequiredtomod-ulateahiddenrequestisE?FGIHKJLM� NA@B.4.3DownstreamCommunicationFigure8showsthedecompositionofthedownstreamhidingfunctionOª¦9§¨£.TherequesterreceivesahiddenmessagefromtheresponderbymakingaseriesofHTTPre-questsforimages.TheresponderappliesPtotherequestedimagesandsendstheresultingimagestotherequester.TherequestercanthenapplytheinversemodulationfunctionP²´torecoverthehiddenmessagefragment.Toensureinnocuousbrowsingpatterns,therequestershouldrequestanHTMLpageandsubsequentlyrequesttheembeddedim-agesfromthatpage(asopposedtomakingHTTPrequestsforimagesoutoftheblue).ForthemodulationfunctionP,weusetheoutguessutility[16],whichmodiesthehighfrequencycomponentsofanimageaccordingtoboththemessagebeingtransmit-tedandasecretkey.Modulationtakesplaceintwostagesndingredundantbitsintheimage(i.e.,theleastsignicantbitsofDCTcoefcientsinthecaseofJPEG),andembed-dingthemessageinsomesubsetoftheseredundantbits.Therststageisstraightforward.Thesecondstageuses QRTSIUV RIWYXZ[WY\"]TWY^\rXW UQRISTUV_RTWYXZ\rW\r^_`Ia#RIbcW_Ud"eecfhg"i[j\rki[lnmopq_r stvuwx"yy=zh{"|\r}n~\r[}| _Y=K IY#=Yn[ ¡¢c£\r¤+¥¦§¨[© ªT« ¬¯®°c±\r²+³´µ¶¸·¹º¼»½¿¾[À+ÁÂÃÄÅ[ÆYÇIÈ ÉʯËÌ ÍÎÏnÐ[ÑhÒÓ"ÔÔcÕhÖ"×\rØ[Ù×\rÚ ÛÜÝÞ_ßYà=á#ânãä"åå=æhç"è\rénê[ë\rìéè[íîï_ðYñ=òKóôõööö÷ø¼ùúYûýüþnÿ \n \r !"$#%'&)(*+, - ./0123465&#x;000;78\n9:Figure8.DownstreamcommunicationalsoconsistsofasequenceofHTTPrequestsandresponses.TheresponderhidesmessagesthatitsendstotherequesterintheHTTPresponses.Oneefcientdownstreamcommunicationmechanismusessteganographytohidedownstreammessagesinrequestedimages.thesharedsecretSKEYasaseedtoapseudorandomnum-bergeneratorthatdetermineswhichsubsetofthesebitswillcontainthemessage.Therefore,withoutknowingthesecretkey,anadversarycannotdeterminewhichbitsholdinfor-mation.Previousworkdescribesthisprocessingreaterde-tail[17].Steganographyisdesignedtohideamessageinacoverimage,wheretheadversarydoesnothaveaccesstotheorig-inalcoverandthuscannotdetectthepresenceofahiddenmessage.However,becauseaWebservertypicallyservesthesamecontenttomanydifferentusers(andeventothesameusermultipletimes),anadversarycandetecttheuseofsteganographysimplybynoticingthatthesamerequestedURLcorrespondstodifferentcontenteverytimeitisre-quested.Onesolutiontothisproblemistorequirethattheresponderneverservethesamelenametwiceforlesthatembedhiddeninformation.Forthisreason,awebcamservesasanexcellentmodefortransmittinghiddenmes-sagesdownstream,becausethelenamesandimagesthatawebcamservesregularlychangebysmallamounts.WediscussthisprobleminmoredetailinSection5.Topro-tectInfranetrequesters,Infranetrespondersembedcontentineveryimage,regardlessofwhethertheWebclientisanInfranetrequester.Therearemanyotherpossiblemodulationfunctionsforhidingdownstreammessages.OnepossibilityistoembedmessagesinHTTPresponseheadersorHTMLpages.How-ever,thisdoesnotprovidethedownstreambandwidththatisnecessarytodelivermessagestotherequesterinareason-ableamountoftime.Anotheralternativeistoembedmes-sagefragmentsinimagesusinghiddenwatermarks.Bothwatermarkingandsteganographyconcealhiddencontent;additionally,watermarksarerobusttomodicationbyanadversary.Pastworkhasinvestigatedwatermarkingtech-niquesforcompressedvideo[6].Afeasibledownstreammodulationfunctionmightusedownloadedorstreamingaudioorvideoclipstohidemessages.Notethatourdownstreammodulationschemedoesnotfundamentallydependontheuseofsteganography.Infact,itmaymakemoresensetouseadatahidingtechniquethatanadversarycannotmodifyorremovewithoutaffectingthevisiblyreturnedcontent.Forexample,ifaresponderuseslow-orderbitsofthebrightnessvaluesofanimagetoem-beddata,thecensorwillhavemoredifcultyremovingthecovertdatawithoutaffectingthevisiblecharacteristicsoftherequestedimage.Sinceweassumethatthecensordoesnotwanttoaffecttheexperienceofnormalusers,thistypeofdownstreamcommunicationmightbemoreappropriate.5SecurityAnalysisInthissection,wediscussInfranet'sabilitytohandleavarietyofattacksfromadeterminedadversarialcensor.Weareconcernedwithmaintainingdeniabilityandcovertnessinthefaceoftheseattacks,i.e.,makingithardforthecen-sortodetectrequestersandresponders.Inaddition,Infranetshouldprovidecondentiality,sothatevenifacensordis-coversanInfranetrequesterorresponder,itcannotrecoveranyofthemessagesexchanged.TheadversaryhasaccesstoalltrafcpassingbetweenitsnetworkandtheglobalInternet,especiallyallvisibleHTTPrequestsandresponses.Furthermore,theadversarycanactivelymodifyanytrafcthatpassesthroughit,aslongasthesemodicationsdonotaffectthecorrectnessoftheHTTPtransactionsthemselves.5.1DiscoveryAttacksAcensormightattempttodiscoverInfranetrequestersorrespondersbyjoiningInfranetasarequesterorarespon-der.TojoinInfranetasarequester,aparticipantmustdis-covertheIPaddressandpublickeyofaresponder.Oncetheclientjoins,allinformationexchangedwitharesponderisspecictothatrequester.Thus,byjoiningthenetworkasarequester,thecensorgainsnoadditionalinformationotherthanthatwhichmustalreadyhavebeenobtainedout-of-band.Alternatively,acensormightsetupanInfranetrespon-derinthehopethatsomeunluckyrequestersmightcon-tactit.BydeterminingwhichWebclients'visibleHTTPrequestsdemodulatetosensibleInfranetmessages,acen- HTTPRequestsHTTPResponsesNoTargetSuspiciousHTTPrequestheadersSuspiciousresponseheadersorcontentOneTargetHTTPrequestpatternsContentpatterns(e.g.,sameURL,differentimage)MultipleTargetsLinkrequestsacrossInfranetrequestersCommonpatternsinHTTPresponses(e.g.,forcommonlyrequestedforbiddenURLs)Table1.AtaxonomyofpassiveattacksonInfranet.Ifthecensorhastheabilitytotargetsuspectedusers,attacksinvolvemoresophisticatedanalysisofvisibleHTTPtrafc.sorcandistinguishinnocentWebclientsfromInfranetre-questers.Currently,werelyoneachrequestertrustingthelegitimacyofanyresponderitcontacts.Section8describesapossibledefenseagainstthisattackbyallowingforun-trustedforwarders.AcensormightmountapassiveattackinanattempttodiscoveranInfranetcommunicationtunnel.Becausethistypeofattackoftenrequirescarefultrafcanalysis,passiveattacksonInfranetaremuchmoredifculttomountthanactiveattacksbasedonlteringortamperingwithvisibleHTTPtrafc.Thetypesofattacksthatanadversarycanperformdependontheamountofstateithas,aswellaswhetherornotitistargetingoneormoreusers.Table1showsataxonomyofpassiveattacksthatacen-sorcanperformonInfranet.Potentialattacksbecomemoreseriousastheadversarytargetsmoreusers.WeakattacksinvolvedetectinganomaliesinHTTPheadersorcontent.Strongerattacksrequiremorecomplexanalysis,suchascorrelationofusers'browsingpatterns.Ifacensorobservesalltrafcthatpassesthroughitwithouttargetingusers,itcouldattempttouncoveranIn-franettunnelbydetectingsuspiciousHTTPrequestandre-sponseheaders,suchasarequestheaderwithastrangeDatevalueorgarbageintheresponseheader.Infranetdefendsagainsttheseattacksbyavoidingsuspiciousmod-icationstotheHTTPheadersandbyhidingdownstreamcontentwithsteganography.Additionally,byrequiringthatInfranetrespondersalwaysserveuniqueURLswhencon-tentchanges,Infranetguardsagainstadiscoveryattackonaresponder,wherebyacensornoticesthatslightlydifferentcontentisbeingservedfromthesameURLeachtimeitisrequested.AcensorwhotargetsasuspectedInfranetrequestercanmountstrongerattacks.AcensorcanobserveaWebuser'sbrowsingpatternsanddeterminewhetherthesepatternslooksuspicious.Sincethemodulationfunctiondeterminesthebrowsingpattern,afunctionthatselectssubsequentre-questsbasedonthestructureoftheresponder'sWebsitemighthelp,butdoesnotalwaysreectactualuserbehavior.Somepagesmightberarelyrequested,whileothersmightalwaysberequestedinsequence.Thus,itisbesttobasemodulationfunctionsoninformationfromrealaccesslogs.WhilegeneratingvisibleHTTPrequestsautomaticallyrequirestheleastworkonthepartoftheuser,thisisnottheonlyalternative.Aparticularlycautioususermightfearthatanyrequestsequencegeneratedbythesystemislikelytolookstrangeandthusarousesuspicion.Toovercomethis,thesystemcouldgivetheuseracertaindegreeofcon-troloverwhichvisiblerequestsaretransmitted.Oneex-ampleisfortherequestertoconrmeachURLwiththeuserbeforesendingit.IftheuserndstheURLstrange,hecanforcetherequestertosendadifferentURLthatcom-municatesthesamemessagefragment.Theseoverridesin-troducenoiseintotherequester'ssequence.However,therequestercanencodethemessagewithanerrorcorrectingcodethatallowsforsuchnoise.AnothersolutionwouldbetoensurethatmultipleURLsmaptoeachmessagefragmenttherequesterwantstosendtogivetheuserachoiceofwhichspecicvisibleURLtorequest.Weconjecturethatwithsufcientredundancy,auserwillfrequentlybeabletondaplausibleURLthatsendsthedesiredmessagefragment.Bytargetingmultipleusers,acensormaylearnaboutmanyInfranetusersasaresultofdiscoveringoneInfranetuser.Alternatively,acensorcouldbecomeanInfranetre-questerandcompareitsbehavioragainstothersuspectedusers.Wedefendagainstthesetypesofattacksbyusingrequester-specicsharedsecrets.5.2DisruptiveAttacksBecausealltrafcbetweenanInfranetrequesterandre-sponderpassesthroughthecensor,thecensorcandisruptInfranettunnelsbyperformingactiveattacksonHTTPtraf-c,suchasltering,transactiontampering,andsessiontampering.5.2.1FilteringAcensormayblockaccesstovariouspartsoftheInternetbasedonIPaddressorprexblock,DNSname,orport number.Additionally,censorscanblockaccesstocontentbylteringoutWebpagesthatcontaincertainkeywords.Forinstance,SaudiArabiaisreportedlytryingtoacquiresuchlteringsoftware[10].Infranet'ssuccessagainstlteringattacksdependsonthepervasivenessofInfranetrespondersthroughouttheWeb.BecauseInfranetrespondersarediscoveredout-of-band,acensorcannotrapidlylearnaboutInfranetrespondersbycrawlingtheWebwithanautomatedscript.Whileacen-sorcouldconceivablylearnaboutrespondersout-of-bandandsystematicallyblockaccesstothesemachines,theout-of-bandmechanismmakesitmoredifcultforacensortoblockaccesstoallInfranetresponders.Thewiderthede-ploymentofrespondersonWebserversaroundtheworld,themorelikelyitisthatInfranetwillsucceed.Notethatbecausetheadversarymayltertrafcbasedoncontentandportnumber,itisrelativelyeasyforthead-versarytoblockSSLbylteringSSLhandshakemessages.Thus,InfranetprovidesfarbetterdefenseagainstlteringthanasystemthatsimplyreliesonSSL.5.2.2TransactionTamperingAcensormayattempttodisruptInfranettunnelcommuni-cationbymodifyingHTTPrequestsandresponsesinwaysthatdonotaffectHTTPprotocolconformance.Forexam-ple,theadversarymaychangeeldsinHTTPrequestorresponseheaders(e.g.,changingthevalueoftheDate:eld),reordereldswithinheaders,orevenremoveoraddelds.Infranetisresistanttotheseattacksbecausethetun-nelprotocoldoesnotrelyonmodicationstotheHTTPheader.AsdescribedinSection4.1,theInfranetrequestermustpresentauniqueuseridentierwitheachHTTPrequestinordertoberecognizedacrossmultipleHTTPtransactions.ArequestercouldsenditsuserIDinaWebcookiewitheachHTTPrequest.However,ifthecensorremovescookies,wesuggestmaintainingclientstatebyembeddingtheuserID(orsometokenthatisaderivativeoftheuserID)ineachURLrequestedbytheclient.Ofcourse,topreservetherequester'sdeniability,therespondermustrewriteallembeddedlinkstoincludethisclienttoken.Thecensormaymodifythereturnedcontentitself.Forexample,itmightinsertorremoveembeddedlinksonare-questedWebpageoripbitsinrequestedimages.Linkinsertionanddeletiondoesnotaffecttunnelcommunica-tionsthatuseacodebookbecausetheclientsendsmes-sagesupstreamaccordingtothiscodebook.AttacksonimagecontentcoulddisruptthecorrectInfranetcommuni-cation.Traditionalrobustwatermarkingtechniquesdefendagainstsuchattacks.Infranetdetectsandblockssuchdis-ruptionsbyembeddingthenameoftheservedURLineachresponse.5.2.3SessionTamperingAnadversarymightattempttodisrupttunnelcommunica-tionbyinterferingwithsequencesofHTTPrequests.Acensorcouldservearequester'svisibleHTTPrequestfromitsowncacheratherthanforwardingthisrequesttotheIn-franetresponder.Topreventsuchanattack,theInfranetre-questermustensurethatitsHTTPrequestsareneverservedfromacache.OnewaytodothisistoalwaysrequestuniqueURLs.Weconsiderthisrequirementfairlyreason-able:manysitesthatservedynamiccontent(e.g.,CGI-basedpages,webcams,etc.)constantlychangetheirURLs.AnotheroptionistousethePragma:no-cachedi-rective,althoughacensoringproxywilllikelyignorethis.Alternatively,acensormightinsert,remove,orreorderHTTPrequestsandresponses.IfacensoraltersHTTPre-questpatterns,theInfranetrespondermightseeerrorsinthereceivedmessage.However,InfranetrespondersincludethenameoftheservedURLineachresponsestream,thusen-ablingtherequestertodetectsessioncorruptionandrestartthetransmission.Inthecaseofrange-mapping,upstreamtransmissionerrorswillbereectedinthesplit-stringsre-turnedbytheresponder.Therequestercanalsodefendagainsttheseattackswitherrorcorrectiontechniquesthatrecoverfromtheinsertion,deletion,andtranspositionofbits[20].6ImplementationOurimplementationofInfranetconsistsoftwocompo-nents:theInfranetrequesterandtheInfranetresponder.TherequesterfunctionsasaWebproxyandisresponsibleformodulatingaWebbrowser'srequestforhiddencontentasasequenceofvisibleHTTPrequeststotheInfranetrespon-der.TheresponderfunctionsasaWebserverextensionandisresponsiblefordemodulatingtherequester'smessagesanddeliveringrequestedcontent.Therequesterandrespon-derutilizeacommonlibrary,libinfranet,thatimple-mentscommonfunctionality,suchasmodulation,hiding,andcryptography.Inthissection,wediscussourimplemen-tationoftheInfranetrequesterandresponder,aswellasthecommonfunctionalityimplementedinlibinfranet.6.1RequesterWeimplementedtheInfranetrequesterasanasyn-chronousWebproxyinabout2,000linesofC++.Weusedlibtclfortheasynchronousevent-drivenfunctionality.TherequestersendsvisibleHTTPrequeststoanInfranetresponder,basedonaninitialURLattheresponder,there-sponder'spublickey,andoptionallyaninitialkeyIKEY.TherequesterqueuesHTTPrequestsfromtheuser'sbrowserandmodulatesthemsequentially.Iftherequester Fragment OffsetMessage Length102345678901023456789102345678912013VersionTypeZEmptyFragment LengthFigure9.Responderheaderformat.knowsaboutmorethanoneresponder,itcanservicere-questsinparallelbyusingmultipleresponders.Inourimplementation,visibleHTTPrequestsfromtherequesteraregeneratedentirelyautomatically.AsdiscussedinSection5.1,wecouldalsoallowtheusertoparticipateinlinkselectiontoprovideincreasedcovertness.6.2ResponderWeimplementedtheInfranetresponderasanApachemodule,modinfranetinabout2,000linesofC++,whichweintegratedwithApache1.3.22runningonLinux2.4.2.TheApacherequestcycleconsistsofmanyphases,includingURItranslation,content-handling,andauthoriza-tion[22].Ourmodinfranetmoduleaugmentsthecon-tenthandlerphaseoftheApacherequestloop.Therespon-derprocessesrequestsasitnormallywouldbutalsointer-pretsthemasmodulatedhiddenmessages.AnInfranetrespondermustmaintainstateforarequesteracrossmultipleHTTPtransactions.Thecurrentimplemen-tationoftheresponderusesWebcookiestomaintainclientstatebecausethismechanismwassimpletoimplement;inthefuture,weplantoimplementtheURLrewritingmech-anismoutlinedinSection5becauseofitsstrongerdefenseagainstpassivediscoveryattacks.TheresponderusestheREQUESTERTOKENcookie,whichcontainsauniqueiden-tier,toassociateHTTPrequeststoaparticularrequester.Foreachrequester,therespondermaintainsper-requesterstate,includingwhichFSMstatetherequesterisin,themodulationfunctiontherequesterisusing,thesharedse-cretSKEY,andmessagefragmentsforpendingmessages.Figure9showstheheaderthattheresponderprependstoeachmessagefragment.VersionisaD-biteldthatspecieswhichversionoftheInfranettunnelprotocoltheresponderisrunning.Typespeciesthetypeofmessagethatthepay-loadcorrespondsto(e.g.,modulationfunctionupdate,re-questedhiddencontent,etc.).ZisaD-biteldthatindicateswhethertherequestedcontentinthepayloadiscompressedwithgzip(thisisthecaseforHTMLlesbutnotimages).FragmentLengthreferstothelengthofthemessagefrag-mentinthepayloadinbytes,andFragmentOffsetspeci-estheoffsetinbyteswherethisfragmentshouldbeplacedforreassemblyofthemessage.MessageLengthspeciesthetotallengthofthemessageinbytes.Becauseupstreambandwidthisscarceandtransmittingaheadermightcre-aterecognizablemodulationpatterns,therequesterdoesnotprependaheadertoitsmessages.6.3SteganographyandCompressionUponreceivingarequest,theresponderdetermineswhetheritcanembedhiddencontentintheresponse.Cur-rently,modinfranetonlyembedsdatainJPEGimages.Iftheresponderdeterminesthatitiscapableofhidinginfor-mationintherequesteddata,itusesoutguesstoembedthehiddeninformationusingSKEY.Toreducetheamountofdatathattherespondermustsendtotherequester,therespondercompressesHTMLleswithgzip[5]beforeembeddingthemintoimages.6.4CryptographyTheInfranetrequestergeneratesthe160-bitsharedse-cretSKEYusing/dev/random.SKEYisencryptedus-ingtheRSApublickeyencryptionimplementationintheOpenSSLlibrary[15].Thisciphertextis128bytes,whichimposesalargecommunicationoverhead.However,be-causetheciphertextisafunctionofthelengthofthere-quester'spublickey,itisdifculttomakethisciphertextshorter.Oneoptiontoamelioratethiswouldbetouseanimplementationofellipticcurvecryptography[13].7PerformanceEvaluationInthissection,weexamineInfranet'sperformance.Weevaluatetheoverheadofthetunnelsetupoperationandtheperformanceofupstreamanddownstreamcommuni-cation.Finally,weestimatetheoverheadimposedbymodinfranetonnormalWebserveroperations.AllofourperformancetestswererunusingApache1.3.22withmodinfranetona1.8GHzPentium4with1GBofRAM.Forallperformancetests,werananInfranetrequesterandaPerlscriptthatemulatesauser'sbrowserfromthesamemachine.7.1TunnelSetupTunnelsetupconsistsoftwooperations:upstreamtrans-missionofSKEYencryptedwiththeresponder'spublic-key,anddownstreamtransmissionofEGFHI I'JK.Inourimplemen-tation,SKEYis160bitslongandthecorrespondingcipher-textis128bytes,proportionaltothelengthoftherespon-der'spublickey.TransmissionofEGFHI I'JKisequivalenttoasingledocumenttransmission.Thetransmissionofanini-tialmodulationfunction,ifoneisused,requiresoneaddi-tionaldownstreamtransmission. 00.10.20.30.40.50.60.70.80.91012345678910Fraction of all hidden URLsNumber of requests to transmit hidden URLIgnoring traversal probabilities (mean: 5.9)Using traversal probabilities (mean: 6.4)Figure10.NumberofvisibleHTTPrequestsrequiredtomodulatehiddenURLswithandwithoutlinktraversalprobabilitiesforrangemapping,assuming8linksperpage(LNMPO).TheexpectednumberofvisibleHTTPrequestsrequiredtomodulateamessageisindependentofwhetherthelinktraversalprobabilitiesareused.7.2UpstreamCommunicationAnimportantmeasureofupstreamcommunicationper-formanceishowmanyHTTPrequestsarerequiredtomod-ulateatypicalmessage.Wefocusourevaluationontherange-mappingschemedescribedinSection4.2.Weevaluatedtheperformanceofrange-mappingusingaWebproxytracecontaining174,100uniqueURLsfromthePaloAltoIRCache[8]proxyonJanuary27,2002.3WhenweweightURLsaccordingtopopularity,themostpopular10%ofURLsaccountforroughly90%ofthevisibleHTTPtrafc.Thisissignicant,sincemodulatingthemostpopu-lar10%ofURLsrequiresasmallnumberofvisibleHTTPrequests.Arequestercanachievestatisticaldeniabilitybypattern-ingsequencesofHTTPrequestsafterthoseofinnocuousWebclients.AsdescribedinSection4.2.3,thisisdonebyassigningsplit-stringrangesinQaccordingtothepairwiselinktraversalprobabilitiesR.Toevaluatetheeffectofus-ingthedistributionR,wemodulated1,740requestsfromQ,bothusingandignoringR,assuming8outgoinglinksperpage.Figure10showsthatassigningrangesbasedonlinktraversalprobabilitiesdoesnotaffecttheexpectednumberofvisibleHTTPrequestsrequiredtomodulateahiddenre-quest.Thisfollowsdirectlyfrompropertiesofarithmeticcodes[31].Inbothcases,overhalfofhiddenmessages3ThesetracesweremadeavailablebyNationalScienceFoundationgrantsNCR-9616602andNCR-9521745,andtheNationalLaboratoryforAppliedNetworkResearch.051015201248163264128Number of requestsNumber of possible next requests at each page90th percentile50th percentileFigure11.Themedianand90thpercentileofnumberofrequeststomodulateamessageisverysmallevenforsmallnumbersofoutgoinglinks(L)oneachpage.required4visibleHTTPrequests,andnomorethan10requestswereneededforanymessage.Therefore,usingtraversalprobabilitiestodeterminethesizeofrangesinQprovidesstatisticaldeniabilitywithouthurtingperformance.SettinglinktraversalprobabilitiestoDS'L,weevaluatedtheeffectofthenumberoflinksonapage,L,onupstreamcommunicationperformance.Figure11showsthat90%ofmessagesfromQcanbemodulatedin10visibleHTTPre-questsorfewer,evenforLassmallas4.Inthetraceweusedforourexperiments,thebinaryen-tropyofthefrequencydistributionofrequestedURLsis16.5bits.Therefore,theexpectednumberofrequestsre-quiredtotransmitaURLfromQisE T UWVXLM�NAB.Theem-piricalresultsshowninFigure11agreewiththisanalyticalresult.Toevaluatetheperformanceofrange-mappingonrealsites,wemodulatedhiddenrequestswhilevaryingLandYaccordingtothebrowsingpatternsobservedonarealWebsite.WeanalyzedtheWebaccesslogsfornms.lcs.mit.eduandpdos.lcs.mit.edutogeneratevaluesforLandYforeachpageonthesesites.WethenobservedthenumberofvisibleHTTPrequestsrequiredtotransmit1,740messagesfromQ.Resultsfromthisexperimentareshowninthetablebelow.ThenumberofrequestsrequiredtomodulateahiddenmessageisslightlyhigherthaninFig-ure11,sinceLvariesforarealWebsite.SITEZavgMEDIAN90%nms.lcs.mit.edu[\$"(pdos.lcs.mit.edu$^]_\ 5101520253035404550556001000020000300004000050000600007000080000Number of requests to retrieve data`Size of requested data (bytes)Figure12.Numberofrequestsrequiredtoretrievedataofvarioussizes.EachvisibleHTTPrequestcontainsapproximately1kBofahiddenmessage.7.3DownstreamCommunicationFigure12showsthenumberofHTTPrequeststhatanInfranetrequestermustmaketoretrievehiddenmessagesofvarioussizes.EachvisibleHTTPresponsecontainsap-proximately1kBofahiddenmessage.TheamountofdatathatcanbeembeddedinonevisibleHTTPresponsedependsontwofactorsthecompressionratioofthemes-sageandtheamountofdatathatcanbesteganographicallyembeddedintoasingleimage.Thus,dependingonthere-questeddocumentandtheimagesusedtoembedthehiddenresponse,thenumberofvisibleHTTPrequestsrequiredtosendagivenamountofhiddendatamayvary.Wemicrobenchmarkedthemainoperationsinvolvedincontentpreparation.First,weranamicrobenchmarkofoutguessinanattempttodeterminetherateatwhichitcanembeddataintoimages.Ourmeasurementsindicatethatoutguessembedsdataintoanimageatarateof20kB/sec,andthatthetimethatoutguesstakestoembeddataisproportionaltothesizeofthecoverimage.Wealsoranmicrobenchmarksongziptodetermineitscomputationalrequirements,aswellasthecompressionra-tiositachievesontypicalHTMLles.Wefetchedthein-dex.htmlpagefrom100popularWebsitesthatwese-lectedfromNielsenNetratings[14]andIRCache[8];themedianlesizefortheseleswas10kB.gzipcompressedtheseHTMLlestoasmuchas12%oftheiroriginalsize;intheworstcase,gzipcompressedtheHTMLleto90%ofitsoriginalsize.Inallcases,compressionofanHTMLlenevertookmorethanB amilliseconds.1010010001000000.10.20.30.40.50.60.70.80.91Bandwidth (kB/s)Percentage of RequestsNo InfranetInfranetFigure13.TheoverheadofrunningInfranetonWebserverperformance.Fordiskboundworkloads,anInfranetresponderperformscomparablytoanunmodiedApacheserver.7.4ServerOverheadToensureplausibledeniabilityforInfranetrequesters,Infranetrespondersalwaysembedrandomorrequesteddatainthecontenttheyserve.BecausetherespondermustmakenodistinctionbetweenInfranetrequestersandnormalWebclients,anInfranet-enabledWebserverincursadditionaloverheadinservingdatatoallclients.Therefore,todeterminetheperformanceimplicationsofrunninganInfranetresponder,wesubmittedanidenticalsequenceofrequeststoanInfranet-enabledApacheserverandanordinaryApacheserver.TherequesttracecontainsasequenceofvisibleHTTPrequeststhatweregeneratedbyusinganInfranetrequestertomodulatetherequestsinthesetof100popularWebsites.Figure13showstheadditionaloverheadofrunningIn-franet.Becausetheservermustembedeveryimagewithdata,regardlessofwhetheritisservinganInfranetrequestornot,runningInfranetincursanoticeableperformancepenalty.16%ofallrequestsservedonanInfranetresponderachieved300kB/sorless,and89%ofrequestsweretrans-ferredat1MB/sorless.Incontrast,62%ofrequestsonanormalApacheserverweredeliveredat1MB/sorgreater.Nevertheless,fordiskboundworkloads,anInfranetrespon-derperformscomparablytoaregularApacheserver.Band-widthachievedbyInfranetneverdropsbelow32%ofthatachievedbyanApacheserverrunningwithoutInfranet,andiswithin90%ofApachewithoutInfranetfor25%ofre-quests.Ourcurrentimplementationhasnotbeenoptimized,andwebelievewecanreducethisoverhead.Onewaytodosomightbetopre-fetchorcachecommonlyrequestedcen-soredcontent.Theoverheadofrunningoutguesscould Infranet\rRequester\rInfranet\rForwarder\rInfranet\rResponder\rCensor\rURL\rURL\rHidden\rcontent\rbHidden\rcontent\rb(UID, Link\rcnumber)\r(UID,\rcEncrypted\rcontent)\rbFigure14.Animprovedarchitectureseparatestheforwardinganddecodingofhiddenmessagesinbothdirections.Thisallowsapotentiallyuntrustedforwardertoservicerequestsandservehiddencontent.TheUIDservestodemultiplexrequesters.bereducedbypre-computingtheleast-signicantbitsoftheDCTforeachimageonthesite.8EnhancementsTothispoint,wehaveassumedthatInfranetrequestersoftwarecanbedistributedonaphysicalmedium,suchasaCD-ROM.However,thisdistributionmechanismisslow,providesevidenceforculpability,andismucheasierforop-pressivegovernmentstocontrolthanelectronicdistribution.Thus,afutureenhancementwouldallowclientstodown-loadtheInfranetrequestersoftwareoverInfranetitself,es-sentiallybootstrappingtheInfranetrequester.ThearchitecturewepresentedinSection3doesnotpro-tectagainstanimpersonationattackwherebyacensores-tablishesanInfranetresponderanddiscoversrequestersbyidentifyingtheWebclientsthatsendmeaningfulInfranetrequests.Figure14showsanimprovedsystemarchitec-ture,wherearequesterforwardsvisibleHTTPrequeststoatrustedresponderthroughapotentiallyuntrustedforwarder,suchthatonlytherespondercanrecoverthehiddenrequest.Respondersfetchandencryptrequestedcontentandreturnittotherequesterthroughaforwarder,whichhidestheencryptedcontentinimages.Thisschemeprovidessev-eralimprovements.First,blockingaccesstoInfranetbe-comesmoredifcult,becausearequestercancontactanyforwarder,trustedoruntrusted,togainaccess.Second,thecensorcanbecomeaforwarder,butitismuchmoredifcultforthecensortobecomeatrustedresponder.Inthecurrenttunnelcommunicationprotocol,anIn-franetrequesterandrespondertaketurnstransmittingmes-sages.ItisconceivablethataschemecouldbedevisedwherebytheHTTPrequestsusedtofetchtherequestedcon-tentcouldalsobeusedtotransmitthenexthiddenmessage,thusinterleavingtheretrievalofhiddeninformationwiththetransmissionofthenexthiddenmessage.Sincetherearemanyconceivablewaysofperformingmodulationandhiding,itislikelythattherewillbemanydifferentversionsofthetunnelcommunicationprotocol.Tunnelsetupshouldbeamendedtoincludeversionagree-ment,suchthatifsomeparticularaspectofthetunnelproto-colinagivenversionisfoundtobeinsecure,therequesterandrespondercaneasilyadapttorunadifferentversion.9ConclusionInfranetenablesuserstocircumventWebcensorshipandsurveillancebyestablishingcovertchannelswithaccessibleWebservers.Infranetrequesterscomposesecretmessagesusingsequencesofrequeststhatarehardforacensortodetect,andInfranetresponderscovertlyembeddataintheopenlyreturnedcontent.Theresultingtrafcresemblesthetrafcgeneratedbynormalbrowsing.Hence,Infranetpro-videsbothaccesstosensitivecontentandplausibledenia-bilityforusers.Infranetusesatunnelprotocolthatprovidesacovertcommunicationchannelbetweenrequestersandresponders,modulatedoverstandardHTTPtransactions.Intheup-streamdirection,InfranetrequesterssendcovertmessagestoInfranetrespondersbyassociatingadditionalsemanticstotheHTTPrequestsbeingmade.Inthedownstreamdi-rection,Infranetrespondersreturncontentbyhidingcen-soreddatainuncensoredimagesusingsteganographictech-niques.Whiledownstreamcondentialityisachievedusingasessionkey,upstreamcondentialityisachievedbycon-dentiallyexchangingamodulationfunction.Ourupstreamanddownstreamprotocolssolvetwoin-dependentproblems,andeachcanbetackledseparately.AlthoughourprotocolisoptimizedfordownloadingWebpages,itactuallyprovidesachannelforarbitrarytwo-waycommunication;forexample,Infranetcouldbeusedtocarryoutaremoteloginsession.OursecurityanalysisshowedthatInfranetcansuc-cessfullycircumventseveralsophisticatedcensoringtech-niques,rangingfromactiveattackstopassiveattackstoim-personation.OurperformanceanalysisshowedthatInfranetprovidesacceptablebandwidthforcovertWebbrowsing.Therange-mappingalgorithmforupstreamcommunicationallowstherequestertoinnocuouslytransmitahiddenre-questinanumberofvisibleHTTPrequeststhatispropor-tionaltothebinaryentropyofthehiddenrequestdistribu-tion.WebelievethatthewidespreaddeploymentofInfranetrespondersbundledwithWebserversoftwarehasthepo-tentialtoovercomevariousincreasinglyprevalentformsofcensorshipandsurveillanceontheWeb.AcknowledgmentsWethankSameerAjmaniandDaveAndersenforsev-eralhelpfuldiscussions,andFrankDabek,KevinFu,KyleJamieson,JaeyeonJung,DavidMartin,andRobertMorrisforusefulcommentsondraftsofthispaper. References[1]M.AdlerandB.Maggs.Protocolsforasymmetriccommunicationchannels.InProceedingsof39thIEEESymposiumonFoundationsofComputerScience(FOCS),PaloAlto,CA,1998.[2]Anonymizer.http://www.anonymizer.com/.[3]I.Clarke,O.Sandbert,B.Wiley,andT.Hong.Freenet:Adistributedanonymousinformationstorageandretrievalsystem.InProceedingsoftheWorkshoponDesignIssuesinAnonymityandUnobservability,Berkeley,CA,July2000.[4]R.Dingledine,M.Freedman,andD.Molnar.TheFreeHavenProject:Distributedanonymousstorageservice.InProceedingsoftheWorkshoponDesignIssuesinAnonymityandUnobservability,Berkeley,CA,July2000.[5]gzip.http://www.gzip.org/.[6]F.HartungandB.Girod.Digitalwatermarkingofrawandcom-pressedvideo.InProc.EuropeanEOS/SPIESymposiumonAd-vancedImagingandNetworkTechnologies,pages205213,Berlin,Germany,October1996.[7]A.Hintz.Fingerprintingwebsitesusingtrafcanalysis.InWorkshoponPrivacyEnhancingTechnologies,SanFrancisco,CA,April2002.[8]IRCache.http://www.ircache.net/.[9]B.W.Lampson.Anoteontheconnementproblem.Communica-tionsoftheACM,16(10):613615,October1973.[10]J.Lee.CompaniescompetetoprovideSaudiInternetveil,Novem-ber19,2001.http://www.nytimes.com/2001/11/19/technology/19SAUD.html.[11]D.MartinandA.Schulman.DeanonymizingusersoftheSafeWebanonymizingservice.InProc.11thUSENIXSecuritySymposium,SanFrancisco,CA,August2002.[12]P.Meller.EuropemovingtowardbanonInternethatespeech,November10,2001.http://www.nytimes.com/2001/11/10/technology/10CYBE.html.[13]A.J.Menezes.EllipticCurvePublicKeyCryptosystems.KluwerAcademicPublishers,Boston,MA,1993.[14]NielsenNetratings'Top25.http://pm.netratings.com/nnpm/owa/NRpublicreports.toppropertiesweekly,November25,2001.[15]OpenSSL.http://www.openssl.org/.[16]Outguess.http://www.outguess.org/.[17]N.Provos.Defendingagainststatisticalsteganalysis.InProc.10thUSENIXSecuritySymposium,Washington,D.C.,August2001.[18]M.ReiterandA.Rubin.Crowds:Anonymityforwebtrans-actions.ACMTransactionsonInformationandSystemSecurity(TISSEC),1:6692,November1998.http://www.research.att.com/projects/crowds/.[19]SafeWeb.http://www.safeweb.com/.[20]L.J.SchulmanandD.Zuckerman.Asymptoticallygoodcodescor-rectinginsertions,deletions,andtranspositions.InSymposiumonDiscreteAlgorithms,pages669674,1997.[21]SquidWebProxyCache.http://www.squid-cache.org/.[22]L.Steinetal.WritingApacheModuleswithPerlandC:TheApacheAPIandmodperl.O'ReillyandAssociates,Sebastopol,CA,March1999.[23]StunneluniversalSSLwrapper.http://www.stunnel.org/.[24]Zero-KnowledgeSystems.FreedomWebSecure.http://www.freedom.net/products/websecure/.[25]P.Syverson,M.Reed,andD.Goldschlag.Onionroutingaccesscongurations.InDARPAInformationSurvivabilityConferenceandExposition,pages3440,HiltonHeadIsland,SC,January2000.http://www.onion-router.net.[26]TheCultoftheDeadCow(cDc).Peekabooty.http://www-peek-a-booty.org.[27]TriangleBoy.http://fugu.safeweb.com/sjws/solutions/triangle_boy.html.[28]VoiceofAmerica.http://www.voa.gov/.[29]M.WaldmanandD.Mazi eres.Tangler:Acensorship-resistantpub-lishingsystembasedondocumententanglements.InProceedingsofthe8thACMConferenceonComputerandCommunicationsSecu-rity,Philadelphia,PA,November2001.[30]M.Waldman,A.Rubin,andL.Cranor.Publius:Arobust,tamper-evident,censorship-resistant,webpublishingsystem.InProc.9thUSENIXSecuritySymposium,pages5972,Denver,CO,August2000.[31]I.H.Witten,R.M.Neal,andJ.G.Cleary.Arithmeticcodingfordatacompression.CommunicationsoftheACM,30(6):520540,Febru-ary1987.