spring-epfl / lightnion Goto Github PK

View Code? Open in Web Editor NEW

119.0 119.0 3.0 8.67 MB

A light version of Tor portable to the browser

License: BSD 3-Clause "New" or "Revised" License

Makefile 0.38% Shell 2.81% HTML 10.00% JavaScript 30.60% Python 56.20%

lightnion's People

Contributors

Stargazers

Watchers

Forkers

pthevenet isabella232

lightnion's Issues

Lightnion requires python 3.6 or later

We need dict to keep insertion order due to implementation details in lightnion/cell.

For example using python 3.5 we are randomly unable to validate versions cells during negotiation, failing with traces like:

Traceback (most recent call last):
  File "examples/link.py", line 13, in <module>
    link = lnn.link.initiate(sys_argv.addr, sys_argv.port)
  File "/vagrant/lightnion/link.py", line 203, in initiate
    version = negotiate_version(peer, versions, as_initiator=True)
  File "/vagrant/lightnion/link.py", line 132, in negotiate_version
    lnn.cell.versions.send(peer, lnn.cell.versions.pack(versions))
  File "/vagrant/lightnion/cell/versions.py", line 35, in pack
    length=len(versions))
  File "/vagrant/lightnion/cell/view.py", line 559, in set
    self.finalize(truncate=True)
  File "/vagrant/lightnion/cell/view.py", line 566, in finalize
    self._view, self.raw))
RuntimeError: Invalid payload for <lightnion.cell.view.fields object at 0x7f46a55b84e0> view: b'\x00\x04\x07\x00'

…or…

Traceback (most recent call last):
  File "examples/link.py", line 13, in <module>
    link = lnn.link.initiate(sys_argv.addr, sys_argv.port)
  File "/vagrant/lightnion/link.py", line 203, in initiate
    version = negotiate_version(peer, versions, as_initiator=True)
  File "/vagrant/lightnion/link.py", line 132, in negotiate_version
    lnn.cell.versions.send(peer, lnn.cell.versions.pack(versions))
  File "/vagrant/lightnion/cell/versions.py", line 35, in pack
    length=len(versions))
  File "/vagrant/lightnion/cell/view.py", line 559, in set
    self.finalize(truncate=True)
  File "/vagrant/lightnion/cell/view.py", line 566, in finalize
    self._view, self.raw))
RuntimeError: Invalid payload for <lightnion.cell.view.fields object at 0x7f7ece53f518> view: b'\x00\x04\x07'

…or…

Traceback (most recent call last):
  File "examples/link.py", line 13, in <module>
    link = lnn.link.initiate(sys_argv.addr, sys_argv.port)
  File "/vagrant/lightnion/link.py", line 203, in initiate
    version = negotiate_version(peer, versions, as_initiator=True)
  File "/vagrant/lightnion/link.py", line 132, in negotiate_version
    lnn.cell.versions.send(peer, lnn.cell.versions.pack(versions))
  File "/vagrant/lightnion/cell/versions.py", line 35, in pack
    length=len(versions))
  File "/vagrant/lightnion/cell/view.py", line 558, in set
    self.write(*kargs, **kwargs)
  File "/vagrant/lightnion/cell/view.py", line 555, in write
    self.raw = self._view.write(self.raw, value, **kwargs)
  File "/vagrant/lightnion/cell/view.py", line 626, in raw
    offset = self._parent.offset(self._field)
  File "/vagrant/lightnion/cell/view.py", line 547, in offset
    return self._view.offset(self.raw, field)
  File "/vagrant/lightnion/cell/view.py", line 303, in offset
    return super().offset(payload, field=field)
  File "/vagrant/lightnion/cell/view.py", line 191, in offset
    width = view.width(payload)
  File "/vagrant/lightnion/cell/view.py", line 406, in width
    offset = self.offset(payload, self.quantity - 1)
  File "/vagrant/lightnion/cell/view.py", line 391, in quantity
    return self.length.cache()
  File "/vagrant/lightnion/cell/common.py", line 5, in cache
    return super().cache() // 2
  File "/vagrant/lightnion/cell/view.py", line 703, in cache
    + 'Have you called .value() of parent view yet?')
RuntimeError: Bounded value unknown at runtime: Have you called .value() of parent view yet?

…or even sending invalid versions cells to the OR and then silently hanging:

send b'\x00\x04\x00\x00\x07\x00\x04\x00\x05'
^CTraceback (most recent call last):
  File "examples/link.py", line 13, in <module>
    link = lnn.link.initiate(sys_argv.addr, sys_argv.port)
  File "/vagrant/lightnion/link.py", line 203, in initiate
    version = negotiate_version(peer, versions, as_initiator=True)
  File "/vagrant/lightnion/link.py", line 134, in negotiate_version
    vercell = lnn.cell.versions.recv(peer)
  File "/vagrant/lightnion/cell/versions.py", line 41, in recv
    answer = peer.recv(_cell.header_legacy_view.width())
  File "/usr/lib/python3.5/ssl.py", line 922, in recv
    return self.read(buflen)
  File "/usr/lib/python3.5/ssl.py", line 799, in read
    return self._sslobj.read(len, buffer)
  File "/usr/lib/python3.5/ssl.py", line 585, in read
    v = self._sslobj.read(len)
KeyboardInterrupt

Having ordered dictionaries in python is only guaranteed since python 3.7 and thus makes us rely on a pretty recent guarantee of the python language.

We still have a lot of python 3.4 and python 3.5 out there where lightnion breaks badly, either making the python 3.6+ requirement explicit or supporting python3.4+ can be a good thing.

Add libvirt as a vagrant provider

It's practical to use libvirt sometimes thanks to its support of kvm and ease of installation.

Thus this issue may be solved by providing an alternate Vagrantfile to test lightnion against debian/stretch64 (that supports libvirt as a provider).

Note that the vagrantbox we're using – ubuntu/bionic64 – is not available for libvirt.

Migrate away from BigInteger.js to either BigInt or JSBI polyfill

We have #16 scheduled to be merged that introduce consensus signature verification, and thus a need to do some nice RSA ourselves. This requires to handle big integers in Javascript, a feature exposed through the BigInt API... only available to few browsers and not even supported (yet) by Firefox. We thus need a third-party provided polyfill.

The current one in use by #16 is BigInteger.js, seems to be well maintained and even though by its author for some cryptographic applications.

However, I think it'll be sensible at some point to migrate away from this library to either use a native BigInt-based implementation… but as it may take some time to be widely supported, I'll recommend the GoogleChromeLabs polyfill (or jsbi) that is purposely written to ease the migration towards BigInt.

Note that this also can provide a more stable third-party to rely upon until we can avoid using one.

Finish documentation of Javascript client

The documentation of several parts of the Javascript client is not finished – for example src/stream.js – and is a requirement for a proper, usable library. Note that the exposed, user-friendly API must also be highlighted by inline documentation that refers to the example given – only stating that the user should only care for lnn.open and lnn.stream.tcp is not giving proper recommendations for using lightnion.

SSL connection hangs while initiating links

Running python example/link.py against a node started with ./tools/start-local-relay.sh hangs while receiving the first time:

% python examples/link.py
^CTraceback (most recent call last):
  File "examples/link.py", line 12, in <module>
    link = lnn.link.initiate(sys_argv.addr, sys_argv.port)
  File "/home/plcp/lsn/ltor/spring/lighttor/lightnion/link.py", line 193, in initiate
    version = negotiate_version(peer, versions, as_initiator=True)
  File "/home/plcp/lsn/ltor/spring/lighttor/lightnion/link.py", line 132, in negotiate_version
    vercell = lnn.cell.versions.recv(peer)
  File "/home/plcp/lsn/ltor/spring/lighttor/lightnion/cell/versions.py", line 40, in recv
    answer = peer.recv(_cell.header_legacy_view.width())
  File "/usr/lib64/python3.7/ssl.py", line 1034, in recv
    return self.read(buflen)
  File "/usr/lib64/python3.7/ssl.py", line 910, in read
    return self._sslobj.read(len)
KeyboardInterrupt

We have this the node's logs:

Nov 07 08:31:32.846 [info] tor_tls_classify_client_ciphers(): No ciphers on session

I've found [tor-commits] [tor/master] Let servers choose better ciphersuites when clients support them as an entry point while searching for tor_tls_classify_client_ciphers.

Tested with:

% tor --version
Tor version 0.3.3.9 (git-45028085ea188baf).
% python --version
Python 3.7.0
% openssl version
OpenSSL 1.1.1  11 Sep 2018
% uname -a
Linux x201 4.18.6-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 5 11:54:09 UTC 2018 x86_64 GNU/Linux

Add online Javascript client documentation and document build process

Proper documentation of the Javascript client is present across the library, however having an online version attached to the repository will be useful as readable reference for users that prefer reading convenient HTML instead of raw code.

Adding the build process using jsdoc of the HTML documentation is also a requirement to perform the aforementioned step in a proper way.

Deprecate CREATE_FAST

Tor is moving away CREATE_FAST cells: we already use ntor handshakes during channel creation, but not everywhere. We thus need to remove these and deprecate lnn.create.fast in our exposed API.

Validate router-sig-ed25519

We may be able to improve performances while relying on a more trusted implementation by validating descriptors using router-sig-ed25519 instead of the more traditional RSA signature. I've got this feeling reading #16 and I may need need to be confirmed before considering this issue.

Simple HTTP(S) request interface and UserAgents

It could be nice if we have a somewhat higher HTTP/AJAX request interface. Maybe something similar to the jquery.get interface:

lightnion.get( url, date_we_want_to_supply, success_fun, error_fun)

This function should also set a sane default for the user agent. What? Optionally make user agent configurable.

Document implementation details on the Javascript client

Few details have been given in answer of 5e29d15 and should be integrated with the documentation of the library – as GitHub comments are not a practical way of documenting the library in a long-term, resilient fashion.

This is especially interesting as most of the library have been designed to have all of its parts at least configurable and for the most part completely replaceable by a custom implementation of the appropriate handler – this will be useful only if people can hack into it with well-documented behaviors.

TL;DR: Giving more insights on the implementation details of the client will enable fellow power-users and researchers to hack their way through the code.

Timeout while expecting RELAY_END

Downloading a consensus against Tor 0.3.4.9 with python example/consensus.py timeouts with a very generic error message: RuntimeError: Timeout while expecting RELAY_END: 30.00s out of 30s.

This bug was common when we didn't send SENDME cells in an appropriate fashion, the server sending us exactly 50 cells then waiting for a SENDME cell. This was fixed and may not be related.

Found #26214 Check stream SENDME against max in the upstream changelog, however this does not appear to be related.

We receive exactly 18 cells against a directory query with compression enabled and exactly 58 cells against a directory query with compression disabled. Downgraded to Tor 0.3.4.8, we are able to receive a full consensus with compression disabled and still receive only 18 cells against a query with compression enabled. Downgraded to Tor 0.3.4.7, everything works as expected.

Migrate away from Uint8Array to ArrayBuffer

Having a native transferable type used for all data manipulations will enable us to integrate better with workers through window.postMessage and to use the SubtleCrypto API as a BufferSource.

We use Uint8Array and may prefer use ArrayBuffer – see Uint8Array.prototype.buffer.

Add proper LICENSE.txt

From what we've discussed, we are going for the BSD-3-Clause and we need to update the repository.

spring-epfl / lightnion Goto Github PK

lightnion's People

Contributors

Stargazers

Watchers

Forkers

lightnion's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs