ISSUES

Known implementation issues with Telex
======================================

Our Telex client is a prototype - there are several known implementation
details that would allow a censor the ability to detect usage of Telex.
While we believe these prototypes are useful models for research and
experimentation, we emphasize that they may not provide the performance or
security of a more polished production implementation, and should be used
accordingly.

To emphasize and document this point, we list below several known
implementation limitations. This list is not meant to be exhaustive.

Single NotBlocked.com
---------------------
Currently, telex-client only allows a single NotBlocked.com choice.
Ideally, the client would want to choose websites that the user already
frequently visits, and have a large set to switch between. 

It is suspicious behavior if a user used to visit ~100 websites a day, and
then suddenly starts visiting only 1 of them, several hundred times a day.


Browser mimicry
---------------
A production telex-client would need to mimic the behavior of popular web
browsers in order to remain undetected. There are several sub-issues that
fall under this class; we describe two here.

It might be easier to solve these problems by pushing the telex-client
functionality into the web browser itself (perhaps as an addon), rather
than providing a second process that must behave like the web browser.

== DNS lookups ==
Our client uses libevent to perform DNS lookups of the NotBlocked domain.
Libevent appears to use 0x20-bit encoding, a known defense against DNS
Forgery. This behavior is observable to the censor, and may differ from
the popular web browsers telex-client attempts to mimic. 

Furthermore, DNS lookups from telex-client and libevent may have
observably different caching or pinning mechanisms than web browsers.

== TCP timeouts ==
Web browsers not using Telex will timeout connections that do not
succesfully send data after a certain period of time (e.g. ACK is not
recieved for sent data). Our client will ACK data from local web browsers,
even if our client does not receive an ACK from the telex-client to
"notblocked" connection. Thus, neither the browser nor telex-client will
timeout the connection.

This would allow an attacker to drop a suspected flow, and observe if the
client continues to attempt to send data (TCP retransmits) after a normal
browser would have timed the connection out. If it does, this is evidence
of a client using our telex-client instead of a web browser.


OpenSSL version
---------------
We implemented our changes to OpenSSL on the latest version, 1.0.0d.
Many browsers may use previous versions of OpenSSL, or different SSL
implementations entirely. These different versions or implementations may
provide observable differences between telex-client and a web browser,
such as differently supported or ordered cipher suites, compression
methods, or TLS extensions.


No session resumption
---------------------
Normal SSL implementations may implement TLS session resumption, a
behavior that is fairly easy to observe. Not all websites support
session resumption, however, choosing a NotBlocked site that does may
inadvertently reveal Telex usage. While OpenSSL supports session
resumption, telex-client and the Telex station do not yet support it
(though we see no practical reason preventing it from being implemented in
the future; see research paper).


Only 1 cipher suite supported
-----------------------------
We chose to only implement one cipher suite method: CBC_AES_256_SHA1_DHE.
While our demonstration NotBlocked.com (notblocked.telex.cc), running a
default Apache web server, chooses this cipher method, not all websites
will. We believe Telex could be extended to support further key exchange
and cipher suites, but until then, care must be taken to ensure that the
chosen NotBlocked will pick the expected cipher suite.


OpenSSL chuncking
-----------------
OpenSSL appears to reveal the length of data passed to the SSL_write()
function by the application. In one of our tests, fetching a 4096-byte
file over HTTP-over-TLS (4384 bytes including HTTP header) resulted in 2
Application Data Protocol TLS records, of 320 and 4128 bytes respectively.

Fetching the same file via Telex resulted in 4 Application Data Protocol
TLS records, of 32 bytes (see empty fragment), 4128 bytes, 32 bytes,
and 320 bytes (another run using telex returned 32, 2928, 32, 1520).

(each record contains a 32-byte MAC, so N packets should contain
(4384 + 32*N) bytes)


TCP congestion window
---------------------
In normal TLS, the (encrypted) HTTP request packet from the client is
ACKed by the Application Data response by the server (TCP allows packets
that contain data to also act as acknowledgements). This is due to the
congestion window of the server having grown since the start of the
connection, to a point where it will buffer multiple packets before
sending a cumulative ACK.

In our Telex station however, this congestion window has not grown - from
the Telex station perspective, it is the start of the connection, and thus
will ACK the first packet it gets (HTTP request in Application Data).


IP ID field
-----------
At the first message sent by our Telex station process (TLS Finished
message from the server), our implementation begins to use its own 
TCP/IP stack. One of the side-effects of this is that the
Identification field in the IP header is now populated by our TCP/IP
stack. Since this is normally a system-wide global that is incremented 
for each packet sent, it is possible for an adversary to observe our
transition. There are several defenses to this, including changing
our implementation to correct its IP ID per connection. For a website
under a large amount of traffic, this type of analysis is more
difficult, and thus makes such a website a natural choice for a
potential notblocked.com.


IP/TCP/SSL Options
------------------
Optional headers in the top three layers may be supported by the
NotBlocked web server, and not by our Telex station. A complete
implementation would need to detect and emulate a wide range of common
options.