tor-dev

tor-dev@lists.torproject.org

1 participants
3590 discussions

Pre-draft of Proposal XXX: Extended ORPort and TransportControlPort
by George Kadianakis 15 Mar '12

15 Mar '12

After discussion in tickets #4773 and #3587 this is a pre-draft of a proposal that revamps the Extended ORport, introduced in proposal 180, and specifies the new TransportControlPort. Comments are marked with '#', and there is also: https://trac.torproject.org/projects/tor/ticket/4773#comment:5 Note that this proposal is not ready for prime time. It needs more thought and lots of editing to become functional and implementable. Inlining: Filename: X Title: Extended ORPort and TransportControlPort Author: X Created: X Status: worse-than-draft-still-probably-more-thoughtful-than-sopa 1. Overview Proposal 180 defined Tor pluggable transports, a way to decouple protocol-level obfuscation from the core Tor protocol in order to better resist client-bridge censorship. This is achieved by introducing pluggable transport proxies, programs that obfuscate Tor traffic to resist DPI detection. Proposal 180 defined a way for pluggable transport proxies to communicate with local tor clients and bridges, so as to exchange traffic. This document extends this communication protocol, so that pluggable transport proxies can exchange arbitrary operational information and metadata with tor clients and bridges. 2. Motivation The communication protocol specified in Proposal 180 gives a way for transport proxies to announce the IP address of their clients to tor. Still, modern pluggable transports might have more (?) needs than this. For example: 1. Tor might want to inform pluggable transport proxies on how to rate-limit incoming or outgoing connections. 2. Server pluggable transport proxies might want to pass client information to an anti-active-probing system controlled by tor. 3. Tor might want to temporarily stop a transport proxy from obfuscating traffic. To satisfy the above use cases, there must be real-time communication between the tor process and the pluggable transport proxy. To achieve this, this proposal refactors the extended ORPort protocol specified in Proposal 180, and introduces a new port, TransportControlPort, whose sole role is the exchange of control information between transport proxies and tor. 3. The new extended ORPort protocol Server transport proxies may need to connect to the bridge and pass additional information about client connections that the bridge would ordinarily receive from the kernel's TCP stack. To do this, they connect to the "extended server port" as given in EXTENDED_SERVER_PORT, send a short amount of information, wait for a response, and then send the user traffic on that port. The extended server port protocol is as follows: COMMAND [2 bytes, big-endian] BODYLEN [2 bytes, big-endian] BODY [BODYLEN bytes] Commands sent from the transport proxy to the bridge are: [0x0000] DONE: There is no more information to give. (body ignored) [0x0001] USERADDR: an address:port string that represents the user's address. [0x0002] WANT_CONTROL: A body-less message which indicates that the transport proxy wants to use the TransportControlPort of the bridge. It SHOULD be followed by a CONTROL command from the bridge, otherwise the transport may close the connection. # will this work? Replies sent from tor to the proxy are: [0x1000] OKAY: Send the user's traffic. (body ignored) [0x1001] DENY: Tor would prefer not to get more traffic from this address for a while. (body ignored) [0x1002] CONTROL: a NUL-terminated "identifier" string, followed by a second NUL-terminated string of the <address>:<port> of the TransportControlPort. The pluggable transport proxy must use the "identifier" to access the TransportControlPort. # pass TransportControlPort <address>:<port> through env. vars? # what should parties do when they receive a command they don't # understand? should we enforce forward-compatibility with protocol # versioning or with "ignore commands you don't understand", or what? [We could also use an out-of-band signalling method to tell Tor about client addresses, but that's a historically error-prone way to go about annotating connections.] The new TransportControlPort protocol The TransportControlPort protocol is as follows: COMMAND [2 bytes, big-endian] BODYLEN [2 bytes, big-endian] BODY [BODYLEN bytes] Association commands sent from the transport proxy to the bridge are: [0x0000] ASSOCIATE: a NUL-terminated "identifier" string. See 'Association' section below. Association commands sent from the bridge to the transport proxy are: [0x1000] ASSOCIATED: Sent upon receiving a legit ASSOCIATE command from a transport proxy. (body ignored) [0x1001] NOT_ASSOCIATED: Sent after the bridge receives a non-legit ASSOCIATE command from a transport proxy. Also sent when the bridge receives a non-ASSOCIATE command from a non-associated transport proxy. Upon sending this command, the bridge SHOULD close the connection. (body ignored) Configuration commands sent from the transport proxy to the bridge: [0x0001] RATE_LIMITED: Message confirming that the rate limiting request of the bridge was carried out successfully (body ignored). See the 'Rate Limiting' section below. [0x0001] NOT_RATE_LIMITED: Message notifying that the transport proxy failed to carry out the rate limiting request of the bridge (body ignored). See the 'Rate Limiting' section below. Configuration commands sent from the bridge to the transport proxy are: [0x1002] RATE_LIMIT: Carries information on how the pluggable transport proxy should rate-limit its traffic. See the 'Rate Limiting' section below. # what should parties do when they receive a command they don't understand? 3.1. Association and identifier creation For Tor and a transport proxy to communicate using the TransportControlPort, an identifier must have already been negotiated using the 'CONTROL' command of Extended ORPort. The TransportControlPort identifier should not be predictable by a user who hasn't received a 'CONTROL' command from the Extended ORPort. For this reason, the TransportControlPort identifier should not be cryptographically-weak or deterministically created. Tor should create its identifiers by generating 16 bytes of random data and hashing them with the SHA256 cryptographic hash function. The identifier string transmitted with the 'CONTROL' command should be the hex representation of the SHA256 output. 4. Configuration commands 4.1. Rate Limiting A tor relay should be able to inform a transport proxy in real-time about its rate-limiting needs. This can be achieved by using the TransportControlPort and sending a 'RATE_LIMIT' command to the transport proxy. The body of the 'RATE_LIMIT' command should carry two integers, in NUL-terminated ASCII string format, representing the bandwidth rate and bandwidth burst in 'bytes per second', that the transport proxy must set. # better transmit format? After reading langsec.org, I prefer to avoid # length fields. Not that this format is bug-proof... When the transport proxy sets the appropriate rate limiting, it should send back a 'RATE_LIMITED' command. If it fails while setting up rate limiting, it should send back a 'NOT_RATE_LIMITED' command. After sending a 'RATE_LIMIT' command. the tor bridge might want to stop pushing data to the transport proxy, till it receives a 'RATE_LIMITED' command. If, instead, it receives a 'NOT_RATE_LIMITED' command it might want to shutdown its connections to the transport proxy. # is this realistic? 5. Security Considerations Extended ORPort or TransportControlPort do _not_ provide link confidentiality, authentication or integrity. Sensitive data, like cryptographic material, should not be transferred through them. Note that an attacker with superuser access, is able to sniff network traffic, and capture TransportControlPort identifiers and any data passed through those ports. # Is it worth adding an SSL layer (passing pub. key fpr via # env. vars?)? :/ # Talk about Incentives of tor or transport proxies to comply to the # wishes of each other. Ways to detect nonconformism. (threat # model. Should tor speak with 3v1l transport proxies in the first # place?) 6. Future In the future, we might have pluggable transports which require the _client_ transport proxy to use the TransportControlPort and exchange control information with the tor client. The current proposal doesn't yet support this, but we should not add functionality that will prevent it from being possible.

2 6

Proposal 195: TLS certificate normalization for Tor 0.2.4.x
by Nick Mathewson 12 Mar '12

12 Mar '12

Filename: 195-TLS-normalization-for-024.txt Title: TLS certificate normalization for Tor 0.2.4.x Author: Jacob Appelbaum, Gladys Shufflebottom, Nick Mathewson, Tim Wilde Created: 6-Mar-2012 Status: Draft Target: 0.2.4.x 0. Introduction The TLS (Transport Layer Security) protocol was designed for security and extensibility, not for uniformity. Because of this, it's not hard for an attacker to tell one application's use of TLS from another's. We proposes improvements to Tor's current TLS certificates to reduce the distinguishability of Tor traffic. 0.1. History This draft is based on parts of Proposal 179, by Jacob Appelbaum and Gladys Shufflebottom, but removes some already implemented parts and replaces others. 0.2. Non-Goals We do not address making TLS harder to distinguish after the handshake is done. We also do not discuss TLS improvements not related to distinguishability (such as increased key size, algorithm choice, and so on). 1. Certificate Issues Currently, Tor generates certificates according to a fixed pattern, where lifetime is fairly small, the certificate Subject DN is a single randomly generated CN, and the certificate Issuer DN is a different single randomly generated CN. We propose several ways to improve this below. 1.1. Separate initial certificate from link certificate When Tor is using the v2 or v3 link handshake (see tor-spec.txt), it currently presents an initial handshake authenticating the link key with the identity key. We propose instead that Tor should be able to present an arbitrary initial certificate (so long as its key matches the link key used in the actual TLS handshake), and then present the real certificate authenticating the link key during the Tor handshake. (That is, during the v2 handshake's renegotiation step, or in the v3 handshake's CERTS cell.) The TLS protocol and the Tor handshake protocol both allow this, and doing so will give us more freedom for the alternative certificate presentation ideas below. 1.2. Allow externally generated certificates It should be possible for a Tor relay operator to generate and provide their own certificate and secret key. This will allow a relay or bridge operator to use a certificate signed by any member of the "SSL mafia,"[*] to generate their own self-signed certificate, and so on. For compatibility, we need to require that the key be an RSA secret key, of at least 1024 bits, generated with e=65537. As a proposed interface, let's require that the certificate be stored in ${DataDir}/tls_cert/tls_certificate.crt , that the secret key be stored in ${DataDir}/tls_cert/private_tls_key.key , and that they be used instead of generating our own certificate whenever the new boolean option "ProvidedTLSCert" is set to true. (Alternative interface: Allow the cert and key cert to be stored wherever, and have the user provide their respective locations with TLSCertificateFile and TLSCertificateKeyFile options.) 1.3. Longer certificate lifetimes Tor's current certificates aren't long-lived, which makes them different from most other certificates in the wild. Typically, certificates are valid for a year, so let's use that as our default lifetime. [TODO: investigate whether "a year" for most CAs and self-signed certs have their validity dates running for a calendar year ending at the second of issue, one calendar year ending at midnight, or 86400*(365.5 +/- .5) seconds, or what.] There are two ways to approach this. We could continue our current certificate management approach where we frequently generate new certificates (albeit with longer lifetimes), or we could make a cert, store it to disk, and use it for all or most of its declared lifetime. If we continue to use fairly short lifetimes for the _true_ link certificates (the ones presented during the Tor handshake), then presenting long-lived certificates doesn't hurt us much: in the event of a link-key-only compromise, the adversary still couldn't actually impersonate a server for long.[**] Using shorter-lived certificates with long nominal lifetimes doesn't seem to buy us much. It would let us rotate link keys more frequently, but we're already getting forward secrecy from our use of diffie-hellman key agreement. Further, it would make our behavior look less like regular TLS behavior, where certificates are typically used for most of their nominal lifetime. Therefore, let's store and use certs and link keys for the full year. 1.4. Self-signed certificates with better DNs When we generate our own certificates, we currently set no DN fields other than the commonName. This behavior isn't terribly common: users of self-signed certs usually/often set other fields too. [TODO: find out frequency.] Unfortunately, it appears that no particular other set of fields or way of filling them out _is_ universal for self-signed certificates, or even particularly common. The most common schema seem to be for things most censors wouldn't mind blocking, like embedded devices. Even the default openssl schema, though common, doesn't appear to represent a terribly large fraction of self-signed websites. [TODO: get numbers here.] So the best we can do here is probably to reproduce the process that results in self-signed certificates originally: let the bridge and relay operators to pick the DN fields themselves. This is an annoying interface issue, and wants a better solution. 1.5. Better commonName values Our current certificates set the commonName to a randomly generated field like www.rmf4h4h.net. This is also a weird behavior: nearly all TLS certs used for web purposes will have a hostname that resolves to their IP. The simplest way to get a plausible commonName here would be to do a reverse lookup on our IP and try to find a good hostname. It's not clear whether this would actually work out in practice, or whether we'd just get dynamic-IP-pool hostnames everywhere blocked when they appear in certificates. Alternatively, if we are told a hostname in our Torrc (possibly in the Address field), we could try to use that. 2. TLS handshake issues 2.1. Session ID. Currently we do not send an SSL session ID, as we do not support session resumption. However, Apache (and likely other major SSL servers) do have this support, and do send a 32 byte SSLv3/TLSv1 session ID in their Server Hello cleartext. We should do the same to avoid an easy fingerprinting opportunity. It may be necessary to lie to OpenSSL to claim that we are tracking session IDs to cause it to generate them for us. (We should not actually support session resumption.) [*] "Hey buddy, it's a nice website you've got there. Sure would be a shame if somebody started poppin' up warnings on all your user's browsers, tellin' everbody that you're _insecure_..." [**] Furthermore, a link-key-only compromise isn't very realistic atm; nearly any attack that would let an adversary learn a link key would probably let the adversary learn the identity key too. The most plausible way would probably be an implementation bug in OpenSSL or something.

7 9

Torperf and #3036
by Thomas S. Benjamin 12 Mar '12

12 Mar '12

Karsten, I have some time to work on Torperf right now, and I see that there are some changes in the works (#3036). Can you suggest to me which ticket(s) could currently most use my help? --- Sincerely Yours, ---Thomas S. Benjamin

2 1

Deployability of Python software.
by Arturo Filastò 10 Mar '12

10 Mar '12

We were discussing last night with George about deployability of python application on multiple platforms. In particular how it would work out if there were to be a python port of obfsproxy and we wanted to have it deployed inside of the Tor Browser bundle. The issues that he said were raised in other discussions with Nick and Roger are mainly the following: - How do we get a good Windows binary of the Software? - How do we keep the size down to an acceptable level? - What kind of performance drawbacks would we be experiencing? - Is it even secure to do crypto in python? I will try and address these issues as they are something that I ran into also while designing AWAF (Anonymous Web Application Framework): http://wiki.globaleaks.org/index.php/Awaf and https://piratenpad.de/p/AnonymousWebApplicationFramework For packaging python software on Windows and OSX, what is generally done is shipped a precompiled python interpreter and bundle everything up with a nice bow. This technique is already quite tested in real world applications: an example that I particularly like is Tucan Manager (http://www.tucaneando.com/development.html). This application is basically a download manager written in python and gtk. The final size of the packaged software is 20MB. If you remove gtk this size goes down to around 10MB. What they are using to bundle up the application for Windows is py2exe and py2app for OSX. Another very widely used solution for packaging python applications in PyInstaller and that is probably the solution I would recommend. Quite a few open source software uses it already: http://www.pyinstaller.org/wiki/ProjectsUsingPyInstaller George also mentioned to me pypy, though I don't think pypy is ready for building shippable application just yet. The issue of size is something that we should come to an agreement on what is acceptable. What is the maximum size that we are comfortable with shipping? We are already shipping a TBB that has 25 MB of QT libraries in it, I don't think a 13 MB Python interpreter is going to be killer. With respect to performance I don't think it is particularly an issue. Python is pretty fast and if it is not fast enough for what needs to be done you can always rewrite the code in C and integrate that piece of application logic as a python binding. By talking to some of the core python developers my understanding is that there is a way of securely storing keys in memory and wiping that memory region in python. It involves using bytearray. We you override a cell in a byte array you are not simply dereferencing the pointer to the python struct, you are actually overwriting that portion of memory. I think I might write a blog post about this and illustrate what other python crypto software is using to solve this problem (PyCrypto etc.). In conclusion having a python interpreter shipped as part of Tor would allow developers of anonymity related software to integrate their "Tor add-ons" into a Tor bundle easily. I am thinking of for example making a Tor IRCD bundle, a Tor HTTPD bundle, etc. What do you think? - Art.

5 5

New IP-address for directory authority maatuska
by Linus Nordberg 29 Feb '12

29 Feb '12

Hi, The provider where maatuska, my directory authority, has been hosted for the last two years or so has had some trouble with its switches lately. I was unable to keep maatuska on the network enough to be a good participant of making a consensus. I decided to move the machine to a place where I have physical access 24x7 and can run it on a network under my control. Other directory authorities need to change its idea of where maatuska lives in order to make it part of the consensus making. Clients benefit from the same change, for downloading the consensus. Nick, Roger, can you please apply the following patch. --8<---------------cut here---------------start------------->8--- diff --git a/src/or/config.c b/src/or/config.c index d341d63..3a7bf65 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -928,7 +928,7 @@ add_default_trusted_dir_authorities(dirinfo_type_t type) "208.83.223.34:443 0AD3 FA88 4D18 F89E EA2D 89C0 1937 9E0E 7FD9 4417", "maatuska orport=80 no-v2 " "v3ident=49015F787433103580E3B66A1707A00E60F2D15B " - "213.115.239.118:443 BD6A 8292 55CB 08E6 6FBE 7D37 4836 3586 E46B 3810", + "171.25.193.9:443 BD6A 8292 55CB 08E6 6FBE 7D37 4836 3586 E46B 3810", NULL }; for (i=0; dirservers[i]; i++) { --8<---------------cut here---------------end--------------->8--- Thanks. -- Linus

2 1

Pluggable Transport through SOCKS proxy
by Arturo Filastò 29 Feb '12

29 Feb '12

Following up on the discussion at the Tor dev meeting with Nick this is the proposal for the Pluggable Transport through SOCKS proxies. You can also find it committed on github: https://github.com/hellais/torspec/commit/f0a89c8ded1971199fec6ffd0fe7e4056… Filename: xxx-pluggable-transports-through-proxy.txt Title: Pluggable Transport through SOCKS proxy Author: Arturo Filastò Created: 28 February 2012 Status: Draft Overview Tor introduced Pluggable Transports in proposal 180 Pluggable Transports for circumvention. The problem is that Tor currently cannot use a Pluggable Transport proxy and a SOCKS proxy at the same time. This has been noticed by users in #5195, where Tor would be failing saying "Unacceptable option value: You have configured more than one proxy type". Trivia This comes from a discussion that came up with Nick and I promised to write a proposal for it if I wanted to hear what he had to say. Nick spoke and I am writing this proposal. Acknowledgements Most of the credit goes to Nick Mathewson for the main idea and the rest of it goes to George Kadianakis for helping me out in writing it. Motivation After looking at some options we decided to go for this solution solution since it guarantees backwards compatibility and is not particularly costly to implement. Design overview When Tor is configured to use both a Pluggable Transport proxy and SOCKS proxy it should delegate the proxying to the pluggable transport proxy. This can be achieved by setting the environment variables for the SOCKS proxy to that specified inside of the torrc. When the pluggable transport proxy starts it will first read the environment variables and if it detects that it should be using a SOCKS proxy make all it's traffic go through it. Once the pluggable transport proxy has successfully established a connection to the SOCKS proxy it should notify Tor of it's success or failure. When both the SOCKS and the PluggableTransport directives are set Tor should set the environemnt variable start the pluggabletransport proxy and wait for it to report back on the SOCKS proxy status. If the pluggable transport reports back a failure or it does not report back at all (maybe because it is an outdated version), Tor should notify the user of the failure and exit with an error. The environment variables can also contain the credentials for accessing the proxy. Specifications: Tor Pluggable Transport communication When Tor detects a SOCKS proxy directive and a Pluggable Transport proxy directive it sets the environment variable: "TOR_PT_PROXY" -- This is the address of the proxy to be used by the pluggable transport proxy. It is in the format: <proxy_type>://<user_name?>:<password?>@<ip>:<port> ex. socks5://tor:test1234@198.51.100.1:8000 socks4a://198.51.100.2:8001 If the pluggable transport proxy detects that the TOR_PT_PROXY environment variable is set it attempts connecting to it. On successs it will write to stdout (as specified in 180-pluggable-transport.txt) PROXY true. On failure it should write PROXY-ERROR <errormessage>. If Tor does not read any PROXY line or it reads a PROXY-ERROR line and it is configured to use both SOCKS and PluggableTransport it should exit with error.

2 3

Tor and DNS
by Linus Nordberg 26 Feb '12

26 Feb '12

Hi, After some interesting discussions irl last week with knowledgeable DNS and security people (hi Jakob) I'd like to hear from people involved with DNS in Tor what current status is and what needs to be done. More specifically, what's the status of ttdnsd and TorDNSd? Are they being used? Any thoughts about having a local validating resolver? I know there's been some discussions (4zm, are you here?) about using libunbound (which could be interesting for DNSSEC support). Did that evolve into anything useful? I'm by no means a DNS expert but would love to see some discussion about this, partly because future IPv6 work will depend on changes to our DNS system. Thanks, Linus

9 30

Windows Alternative of torsocks/tsocks ?
by Catalin Patulea 18 Feb '12

18 Feb '12

[resending after subscribing to list] Hi Fabio, > On 1/22/12 11:28 AM, Roger Dingledine wrote: >> See also TorCap2: http://www.virtualventures.ca/~cat/ >> but I've never succeeded at getting a license statement out of the author. Roger, I'm sorry if I seemed uncooperative when you asked about the licensing terms of TorCap2. I can see a reference to a discussion with you back in 2006, but I no longer have copies of the actual correspondence, so I don't recall what happened. > Can you confirm whether the TorCap2 is licensed under BSD, GPL or other > opensource license? I have released TorCap2 under the LGPL 3.0 (I have updated the readme and included a license.txt in the zip files). You can use TorCap2 as-is in an application of any license. Any modifications to TorCap2 must be published under the LGPL. > at some Tor related Project we would like to use TorCap2 as a part of an > OpenSource Project whose concept is described at > https://piratenpad.de/p/AnonymousWebApplicationFramework . On a technical note, I doubt that TorCap2 is the right approach here. If you can limit yourself to support Python-only applications to start, then a SOCKS client in Python that implements the same interface as the 'socket' module seems like a much cleaner solution to me. This is now platform-independent, less complex (easier to debug), and gives the Python code the *option* between native sockets and Tor-ified sockets, under the same interface. (maybe you want to check connectivity.. or find the hosts's external IP by fetching a URL.. or talk to hosts on the local network.. etc.) Porting existing Python code would be a matter of search-replacing 'socket' with 'torsocket' (or even just 'import torsocket as socket'). Of course, with this design you would leak network traffic if you spawned a separate process, or if you used a Python native library that directly accesses the OS's socket API. But maybe it's good to start with supporting Python-only applications initially, given the complexity of Win32 API hooking.. Just my $0.02.. Catalin

3 3

Unit testing blog posts
by Esteban Manchado Velázquez 18 Feb '12

18 Feb '12

I ended up publishing it in two parts :-) Here are the URLs: http://hcoder.org/2012/02/13/unit-testing-advice-for-seasoned-hackers-12/ http://hcoder.org/2012/02/15/unit-testing-advice-for-seasoned-hackers-22/ Now I'll have a look at the coverage and see what I can do for the unit tests before I move on to Stem/chutney. -- Esteban

3 3

Fwd: Plan of attack for part (c)
by Watson Ladd 17 Feb '12

17 Feb '12

I'm forwarding the following 2 messages about work that I'm thinking about doing to the Tor code to pave the way towards multiple cryptographic methods for route extension. Feel free to comment critically on the proposed design, especially if it impacts areas you are working on or know about. If you have alternative ideas that's also good. Sincerely, Watson Ladd ---------- Forwarded message ---------- From: Robert Ransom <rransom.8774(a)gmail.com> Date: Thu, Feb 16, 2012 at 8:03 PM Subject: Fwd: Plan of attack for part (c) To: Nick Mathewson <nickm(a)torproject.org>, George Kadianakis <desnacked(a)riseup.net> Cc: Watson Ladd <watsonbladd(a)gmail.com> Forwarding to Nick and George (who has looked at the crypto code before), because I'm not going to be able to think about this much today. This sort of discussion should probably be on the tor-dev mailing list. ---------- Forwarded message ---------- From: Watson Ladd <watsonbladd(a)gmail.com> Date: Thu, 16 Feb 2012 13:15:58 -0600 Subject: Plan of attack for part (c) To: "rransom.8774" <rransom.8774(a)gmail.com> Dear Robert, I've come up with the following sketch of a plan to handle the obstacle of crypt_path_t to multiple negotiation methods. It isn't actually the problem. The problem is the crypto_dh_t * dh_handshake_state. I propose defining an enum handshake_methods_t and a handshake_state that looks like typedef struct { enum method; union { crypto_dh_t *dh_handshake; } u; } handshake_state; The extend_info_t structure will need to be modified to point to a list of similar handshake_key structures, probably in the form of a linked list. This involves modifying the functions that allocate extend_info_t's, of which thankfully there are few. Once this is done we can genericize the onion_skin functions by making new functions which essentially consist of a switch statement on the value of method. One unresolved issue is selecting the method to be used when multiple methods are available: I'll probably just take the first handshake_key and complain if it doesn't match what the handshake_state should be when processing the response. Servers are a trickier issue, but if they have a list of handshake_keys we can sort through it to find the key that matches a particular method, and rely on the new CREATE2 cell mechanism to tell us what the method is. Are there requirements for a fix that this idea doesn't meet? Any hard decisions that I've made the wrong call on? And thank you very much for taking the time to help me through working with the tor code. Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev