<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Greetings,<br>
    <br>
    A while ago the Tor project rolled out Obfsproxy as
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    a Browser Bundle [1], for users behind firewalls filtering SSL or
    detecting other characteristics of a Tor connection, to help them
    access bridges.<br>
    <br>
    In our recent work, SkypeMorph [2], we have tried to use Skype video
    communications as our target protocol for protocol obfuscation.
    SkypeMorph functionality is similar to Obfsproxy, but the connection
    between the bridge and the client looks like a Skype video call (the
    details of how we do this is discussed in the technical report).<br>
    <br>
    We also have an open-source proof-of-concept impelmenation of the
    SkypeMorph available at: [3]<br>
    <br>
    <br>
    Notes:<br>
    1- At the moment our code relies on SkypeKit SDK
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    [4] (a paid Skype SDK which you can get for around US$ 5) for Skype
    functionalities (the README file in the package explains how one can
    obtain SkypeKit). However, it can be easily ported to Skype public
    API [5], so users would not have to pay for it.<br>
    <br>
    2- SkypeMorph and pluggable transports: Although our code can
    potentially be used as a pluggable transport, there is a minor
    difficulty with the pluggable transport framework that needs to be
    addressed before it can host our code. As mentioned above, our code
    uses Skype network for basic login stuff, so it takes a little bit
    more time than what Tor expect from a typical transport (like
    Obfsproxy), so the Tor client gives up building circuits after a
    while. We are aware of ORControllers tricks to solve the problem,
    but it does not seem to be the right way to do it and it would be
    awesome if the pluggable transport were able to tell Tor that it's
    working on setting up the connection, and that Tor<br>
    shouldn't give up on it until it says it's ready. I am sure other
    transports could also benefit from this.<br>
    <br>
    Hooman<br>
    <br>
    <br>
    <br>
    [1]:<a moz-do-not-send="true"
href="https://blog.torproject.org/blog/obfsproxy-next-step-censorship-arms-race">https://blog.torproject.org/blog/obfsproxy-next-step-censorship-arms-race</a><br>
    [2]:<a moz-do-not-send="true" class="moz-txt-link-freetext"
      href="http://cacr.uwaterloo.ca/techreports/2012/cacr2012-08.pdf">http://cacr.uwaterloo.ca/techreports/2012/cacr2012-08.pdf</a><br>
    [3]:<a moz-do-not-send="true" class="moz-txt-link-freetext"
      href="http://crysp.uwaterloo.ca/software/">http://crysp.uwaterloo.ca/software/</a><br>
    [4]:<a moz-do-not-send="true"
      href="http://developer.skype.com/public/skypekit">http://developer.skype.com/public/skypekit</a><br>
    [5]:<a moz-do-not-send="true"
      href="http://developer.skype.com/public-api-reference">http://developer.skype.com/public-api-reference</a><br>
    <br>
  </body>
</html>