I'm trying to establish an HTTPS connection to a Tor resourse, for example https://3g2upl4pq6kufc4m.onion. Connection fails while performing the TLS handshake. Meanwhile HTTPS connection to common websites is ok. It looks like Tor router rejects RELAY_DATA cell with incorrect encrypted payload.

mini-tor.exe -vvv "https://check.torproject.org/"
[17:10:38.524] Fetching consensus...
[17:10:38.607] Consensus fetched...
[17:10:38.608] Connecting to node #1: 'okamoto' (216.24.242.34:443)
[17:10:39.330] tor_socket::send_versions()
[17:10:39.331] tor_socket::recv_versions()
[17:10:39.553] tor_socket::recv_certificates()
[17:10:39.553] tor_socket::recv_net_info()
[17:10:39.554] tor_socket::send_net_info()
[17:10:39.554] consensus::download_from_random_authority() [path: http://109.201.133.100:80/tor/server/fp/c7d67c945ae18a7f53299e30a284e0e3bc9e4309]
[17:10:39.729] circuit::create_ntor() [or: okamoto, state: creating]
[17:10:40.034] tor_socket::recv_cell() [circuit: 1 (MSB set), command: 4]
[17:10:40.035] circuit::destroy()
[17:10:40.036] tor_socket::remove_circuit() [circuit: 1]
[17:10:40.036] circuit::create_ntor() [or: okamoto, state: destroyed]
[17:10:40.036] Error while creating circuit!
[17:10:40.037] Connecting to node #1: 'DobbyIsFree' (178.211.45.18:443)
[17:10:40.364] tor_socket::send_versions()
[17:10:40.365] tor_socket::recv_versions()
[17:10:40.476] tor_socket::recv_certificates()
[17:10:40.476] tor_socket::recv_net_info()
[17:10:40.477] tor_socket::send_net_info()
[17:10:40.478] consensus::download_from_random_authority() [path: http://43.251.159.144:80/tor/server/fp/39bc283d9734073a13be346acd4091c0fa505ca4]
[17:10:41.015] circuit::create_ntor() [or: DobbyIsFree, state: creating]
[17:10:41.125] tor_socket::recv_cell() [circuit: 2 (MSB set), command: 4]
[17:10:41.125] circuit::destroy()
[17:10:41.126] tor_socket::remove_circuit() [circuit: 2]
[17:10:41.126] circuit::create_ntor() [or: DobbyIsFree, state: destroyed]
[17:10:41.126] Error while creating circuit!
[17:10:41.127] Connecting to node #1: 'tordebain4' (95.217.3.165:443)

I've checked 0.1.29, 0.1.28

There appears to be no documentation on how to use the "lib" branch of Mini-Tor. I've tried compiling it into my messaging app several different ways, and I always seem to get different compilation errors. Can you please provide a guide on building your software into a static .lib, and how it's intended to be included into other C++ files?

Anyone managed to get this to work with v3 services ?
Always getting "Hidden service descriptor is invalid..." on whatever .onion v3 address I try.
I checked them in tor browser they work fine.

using visual studio 2019 i'm make project as dll. when running dll repeat
connect_again:
while (tor.get_hop_count() < hops)
{
//
// first hop.
//
if (tor.get_hop_count() == 0)
tested windows 10. exe build works fine. Please, help me make dll

I don't know how to describe it since I'm not so good with English, but watch this:

mini::tor::tor_client tor;
content = tor.http_get(
      mini::net::uri("http://a.onion"));
...
content = tor.http_get(
      mini::net::uri("http://b.onion"));

You will never get to access the second hidden service, here's my pseudo-log:

[22:25:35.719] Accessing 'http://a.onion/index.htm'
[22:25:35.719] Creating onion stream...
[22:25:54.670] hidden_service() [a.onion]
[22:25:54.675] circuit::rendezvous_establish() [circuit: 2147483649, state: establishing]
...
[22:25:58.795]  Connected...
...
[22:26:04.894] circuit::handle_relay_end_cell() [stream: 2, reason: 6]
[22:26:04.898] Response received...
...
[22:26:04.899] Accessing 'http://b.onion/index.php'
[22:26:04.903] Creating onion stream...
[22:26:13.543] hidden_service() [b.onion]
[22:26:13.549] circuit::rendezvous_establish() [circuit: 2147483649, state: establishing]
[22:26:13.549] tor_socket::send_cell() [circuit: 1 (MSB set), stream: 0, command: 3, relay_command: 33]
...
[22:29:21.384] circuit::rendezvous_establish() [circuit: 6, is_rendezvous_established() == false] # timeout
[22:29:21.389] Error while creating the onion stream

The addresses/domain name are aliased for demonstration purposes only.

As you shall see, the second rendezvous establishment was never received, it keeps stucked at RELAY_COMMAND_ESTABLISH_RENDEZVOUS...The only workaround is to create another Tor circuit, but to which I think is inefficient.

I wonder if I could know the call stack of circuit::create_onion_stream. Oh and by the way would you accept the pull request if I used inconsistent formating?

is it possible via this lib to make a persistent connection to some onion address? if possible, can you provide some example? thans

in <string_ref.h> std::char_traits moved from <iosfwd> to <string>.
Solution:

//#include <iosfwd> // std::char_traits
#include <string> // std::char_traits

always show this error. Windows 7 32bit vm.

When reading your code I noticed for circuit IDs you simply increment an int:

5.1.1. Choosing circuit IDs in create cells

   The CircID for a CREATE/CREATE2 cell is an arbitrarily chosen
   nonzero integer, selected by the node (OP or OR) that sends the
   CREATE/CREATE2 cell.  In link protocol 3 or lower, CircIDs are 2
   bytes long; in protocol 4 or higher, CircIDs are 4 bytes long.

When using an incrementing number, if the circuit ID is already in use, guard relays respond with RELAY_CONNECTED when performing the NTOR handshake instead of RELAY_RESOLVE (NTOR server handshake reply), this will cause issues.

I think it would be a good idea to make circuit IDs a random int with a maximum value of 2^31 (max C int value range for 4 bytes). Or am I missing something here?

tor.exe -vvv "https://check.torproject.org/"

[19:40:51.413]Fetching consensus...
[19:40:51.525] Consensus fetched...
[19:40:51.529] Connecting to node #1: 'freja' (194.88.143.66:443)
[19:40:51.892] tor_socket::send_versions()
[19:40:51.893] tor_socket::recv_versions()
[19:40:51.994] tor_socket::recv_certificates()
[19:40:51.995] tor_socket::recv_net_info()
[19:40:51.995] tor_socket::send_net_info()
[19:40:51.996] consensus::download_from_random_authority() [path: http://190.216.2.136:80/tor/server/fp/3755325d6537360757a31785ed2e32144ab97266]
[19:40:52.637] circuit::create_ntor() [or: freja, state: creating]
[19:40:53.378] tor_socket::recv_cell() [circuit: 1 (MSB set), command: 4]
[19:40:53.378] circuit::destroy()
[19:40:53.379] tor_socket::remove_circuit() [circuit: 1]
[19:40:53.380] circuit::create_ntor() [or: freja, state: destroyed]
[19:40:53.380] Error while creating circuit!
[19:40:53.381] Connecting to node #1: 'twilight' (155.254.49.178:443)
[19:40:54.120] tor_socket::send_versions()
[19:40:54.121] tor_socket::recv_versions()
[19:40:54.350] tor_socket::recv_certificates()
[19:40:54.351] tor_socket::recv_net_info()
[19:40:54.351] tor_socket::send_net_info()
[19:40:54.353] consensus::download_from_random_authority() [path: http://62.210.5.240:80/tor/server/fp/9fc2673bb2704c2aab851f8334938565df1d0819]
[19:40:54.528] circuit::create_ntor() [or: twilight, state: creating]
[19:40:55.064] tor_socket::recv_cell() [circuit: 2 (MSB set), command: 4]
[19:40:55.065] circuit::destroy()
[19:40:55.066] tor_socket::remove_circuit() [circuit: 2]
[19:40:55.066] circuit::create_ntor() [or: twilight, state: destroyed]
[19:40:55.066] Error while creating circuit!
[19:40:55.067] Connecting to node #1: 'tor1philslab' (78.47.226.12:443)
[19:40:55.424] tor_socket::send_versions()
[19:40:55.425] tor_socket::recv_versions()
[19:40:55.531] tor_socket::recv_certificates()
[19:40:55.532] tor_socket::recv_net_info()
[19:40:55.532] tor_socket::send_net_info()
[19:40:55.533] consensus::download_from_random_authority() [path: http://80.127.117.180:80/tor/server/fp/0c93559d6d7e95b41561424345b0b176fbe66f00]
[19:40:55.770] circuit::create_ntor() [or: tor1philslab, state: creating]
[19:40:55.964] tor_socket::recv_cell() [circuit: 3 (MSB set), command: 4]
[19:40:55.965] circuit::destroy()
[19:40:55.967] tor_socket::remove_circuit() [circuit: 3]
[19:40:55.968] circuit::create_ntor() [or: tor1philslab, state: destroyed]
[19:40:55.968] Error while creating circuit!
[19:40:55.969] Connecting to node #1: 'TykRelay01' (85.235.250.88:443)
[19:40:56.270] tor_socket::send_versions()
[19:40:56.271] tor_socket::recv_versions()
[19:40:56.362] tor_socket::recv_certificates()
[19:40:56.362] tor_socket::recv_net_info()
[19:40:56.363] tor_socket::send_net_info()
[19:40:56.365] consensus::download_from_random_authority() [path: http://149.56.12.78:80/tor/server/fp/72b2b12a3f60408bdbc98c6df53988d3a0b3f0ee]
[19:40:56.793] circuit::create_ntor() [or: TykRelay01, state: creating]
[19:40:57.934] tor_socket::recv_cell() [circuit: 4 (MSB set), command: 4]
[19:40:57.935] circuit::destroy()
[19:40:57.935] tor_socket::remove_circuit() [circuit: 4]
[19:40:57.936] circuit::create_ntor() [or: TykRelay01, state: destroyed]
[19:40:57.937] Error while creating circuit!
[19:40:57.937] Connecting to node #1: 'Wapiti' (69.30.218.186:443)
[19:40:58.573] tor_socket::send_versions()
[19:40:58.573] tor_socket::recv_versions()
[19:40:58.784] tor_socket::recv_certificates()
[19:40:58.784] tor_socket::recv_net_info()
[19:40:58.785] tor_socket::send_net_info()
[19:40:58.786] consensus::download_from_random_authority() [path: http://46.165.250.224:80/tor/server/fp/ccc250de86f0b0da7f15993ddd01101ac96259d0]
[19:40:58.965] circuit::create_ntor() [or: Wapiti, state: creating]
[19:41:01.318] tor_socket::recv_cell() [circuit: 5 (MSB set), command: 4]
[19:41:01.319] circuit::destroy()
[19:41:01.320] tor_socket::remove_circuit() [circuit: 5]
[19:41:01.321] circuit::create_ntor() [or: Wapiti, state: destroyed]
[19:41:01.321] Error while creating circuit!
[19:41:01.322] Connecting to node #1: 'janitormentor' (91.219.238.221:443)
[19:41:01.751] tor_socket::send_versions()
[19:41:01.751] tor_socket::recv_versions()
[19:41:01.887] tor_socket::recv_certificates()
[19:41:01.888] tor_socket::recv_net_info()
[19:41:01.889] tor_socket::send_net_info()
[19:41:01.890] consensus::download_from_random_authority() [path: http://89.34.237.230:80/tor/server/fp/64a8837a97af71775c84de0eda94552aaedc424f]
[19:41:02.141] circuit::create_ntor() [or: janitormentor, state: creating]
[19:41:03.008] tor_socket::recv_cell() [circuit: 6 (MSB set), command: 4]
[19:41:03.010] circuit::destroy()
[19:41:03.011] tor_socket::remove_circuit() [circuit: 6]
[19:41:03.012] circuit::create_ntor() [or: janitormentor, state: destroyed]
[19:41:03.012] Error while creating circuit!
[19:41:03.013] Connecting to node #1: 'thedoctor' (192.44.30.40:443)
[19:41:03.341] tor_socket::send_versions()
[19:41:03.343] tor_socket::recv_versions()
[19:41:03.436] tor_socket::recv_certificates()
[19:41:03.437] tor_socket::recv_net_info()
[19:41:03.437] tor_socket::send_net_info()
[19:41:03.438] consensus::download_from_random_authority() [path: http://91.219.237.244:80/tor/server/fp/20386d9a32becbe602375e015fc70117955653f1]
[19:41:03.856] circuit::create_ntor() [or: thedoctor, state: creating]
[19:41:05.054] tor_socket::recv_cell() [circuit: 7 (MSB set), command: 4]
[19:41:05.055] circuit::destroy()
[19:41:05.055] tor_socket::remove_circuit() [circuit: 7]
[19:41:05.056] circuit::create_ntor() [or: thedoctor, state: destroyed]
[19:41:05.057] Error while creating circuit!
[19:41:05.057] Connecting to node #1: 'rickpotion9' (64.137.178.43:443)
[19:41:05.648] tor_socket::send_versions()
[19:41:05.649] tor_socket::recv_versions()
[19:41:05.826] tor_socket::recv_certificates()
[19:41:05.826] tor_socket::recv_net_info()
[19:41:05.827] tor_socket::send_net_info()
[19:41:05.828] consensus::download_from_random_authority() [path: http://188.40.248.57:80/tor/server/fp/f4e0813eb58705fcbb76417824d8a36df1f36453]
[19:41:06.017] circuit::create_ntor() [or: rickpotion9, state: creating]
[19:41:06.878] tor_socket::recv_cell() [circuit: 8 (MSB set), command: 4]
[19:41:06.878] circuit::destroy()
[19:41:06.879] tor_socket::remove_circuit() [circuit: 8]
[19:41:06.879] circuit::create_ntor() [or: rickpotion9, state: destroyed]
[19:41:06.880] Error while creating circuit!
[19:41:06.881] Connecting to node #1: 'RandomRelayNode' (84.249.11.195:443)
[19:41:07.133] tor_socket::send_versions()
[19:41:07.134] tor_socket::recv_versions()
[19:41:07.134] tor_socket::recv_certificates()
[19:41:07.135] tor_socket::recv_net_info()
[19:41:07.135] tor_socket::send_net_info()
[19:41:07.136] consensus::download_from_random_authority() [path: http://95.141.44.66:80/tor/server/fp/8dfd694d9089b250044457ee9ebfcf6402df3361]
[19:41:07.137] tor_socket::recv_cell_loop() !! received invalid cell, closing stream
[19:41:07.138] circuit::destroy()
[19:41:07.138] tor_socket::remove_circuit() [circuit: 9]
[19:41:08.295] circuit::create_ntor() [or: RandomRelayNode, state: creating]
[19:41:08.296] circuit::create_ntor() [or: RandomRelayNode, state: destroyed]
[19:41:08.296] Error while creating circuit!
[19:41:08.297] Connecting to node #1: 'Jarvis' (85.17.164.172:443)
[19:41:08.592] tor_socket::send_versions()
[19:41:08.593] tor_socket::recv_versions()

Look at this https://github.com/wbenny/mini-tor/blob/master/mini/crt/crt0.cpp#L140

void
create_argc_and_argv(
  void
  )
{
  wchar_t** argvW = CommandLineToArgvW(GetCommandLineW(), &__argc);

  __argv = (char**)malloc(__argc); // <<< here
  for (int i = 0; i < __argc; i++)
  {
    size_t argv_size = wcslen(argvW[i]) + 1;

    __argv[i] = (char*)malloc(argv_size);
    wcstombs(__argv[i], argvW[i], argv_size);
  }

  LocalFree(argvW);
}

Hi wbenny. Thank you for implementing a Tor client that is more Windows oriented. I'd like to use your code in a messaging app I'm developing, and would like to use mini-tor as a communication transport. Is there a way to compile your software into a static library for use in a C++ app? Thanks for the guidance

1. _recv_cell_loop_thread is started to run function _recv_cell_loop. But when a received cell is invalid. _recv_cell_loop calls close(). Because the state cannot be closing, so it would call _recv_cell_loop_thread.join and _recv_cell_loop_thread.reset.

   Is it a bug? Maybe line 447 of tor_socket.cpp should be removed?

2. At circuit::create_stream, when tor_stream is not ready, it is destroyed otherwhere, but it is not deleted. Would it be a memory leak?

3. At circuit::send_relay_end_cell, it set_state to destroyed and removes the stream from _stream_map. At circuit::handle_relay_end_cell, it does these again. set_state seems thread-safe, but _stream_map seems not. Would it cause a problem?

The client will not be able to parse the crypto state, it is filled with completely garbage data:

[20:42:52.817] Fetching consensus...
[20:42:53.224] Consensus fetched...
[20:42:53.226] Connecting to node #1: 'Unnamed' (178.249.167.2:443)
[20:42:55.152] circuit::handle_created2_cell() extend node [ <corrupted sequences> ] has invalid crypto state
[20:42:55.153] circuit::create_ntor() [or: Unnamed, state: destroyed]
[20:42:55.153] Error while creating circuit!
[20:42:55.154] Connecting to node #1: 'noiseexit01b' (173.254.216.67:443)
[20:42:56.436] circuit::handle_created2_cell() extend node [ ░≥╞e2� ] has invalid crypto state
[20:42:56.437] circuit::create_ntor() [or: noiseexit01b, state: destroyed]
[20:42:56.438] Error while creating circuit!
[20:42:56.439] Connecting to node #1: 'VivaLuxxx' (91.121.224.10:443)

And it seems like we have an access violation on the crypto operations:

Exception thrown at 0x00007FFD5D3816B1 (cryptsp.dll) in <REDACTED>.exe: 0xC0000005: Access violation reading location 0x0000000000000058.
Exception thrown at 0x00007FFD5D382474 (cryptsp.dll) in <REDACTED>.exe: 0xC0000005: Access violation reading location 0x0000000000000058.
Exception thrown at 0x00007FFD5D382474 (cryptsp.dll) in <REDACTED>.exe: 0xC0000005: Access violation reading location 0x0000000000000058.
Exception thrown at 0x00007FFD5D3816B1 (cryptsp.dll) in <REDACTED>.exe: 0xC0000005: Access violation reading location 0x0000000000000058.
Exception thrown at 0x00007FFD5D382474 (cryptsp.dll) in <REDACTED>.exe: 0xC0000005: Access violation reading location 0x0000000000000058.
Exception thrown at 0x00007FFD5D382474 (cryptsp.dll) in <REDACTED>.exe: 0xC0000005: Access violation reading location 0x0000000000000058.
The thread 0x2f70 has exited with code 0 (0x0).

where is opaqued for the application of my own deed; this is universal to the POC program as well. Notice cryptsp.dll here as well that it shed some light to that it is definitely pointing to problems with the crypto facility.

This seems problematic...I don't know why is it happening, and all I got to do was switch to CryptoAPI version of HMAC.

#ifndef MINI_CRYPTO_HMAC_NAMESPACE
#define MINI_CRYPTO_HMAC_NAMESPACE        capi   // [capi, cng]
#endif

then I got the problem reproduced.

The program runs perfectly fine with CryptoNG aka BCrypt. It has been thoroughly tested with different combination of crypto config.

Hey,
first of all thank you for your work.
I've discovered that if host is unreachable it still hangs at mini/tor/tor_socket.cpp#L300.
I tried to just replace this line with tor_socket::close which can produce another loop at /mini/tor/tor_socket.cpp#L96.

You set tor_socket::state::ready here, but also check just in the next loop if tor_socket::_state equals tor_socket::state::ready::closing so it cant reach break;.

Call stack:
-> mini-tor.exe!mini::threading::thread::join(int timeout) Line 118
-> mini-tor.exe!mini::tor::tor_socket::set_state(mini::tor::tor_socket::state new_state) Line 306
-> mini-tor.exe!mini::tor::tor_socket::connect(mini::tor::onion_router * or) Line 53
-> mini-tor.exe!tor_client::extend_to(mini::tor::onion_router * onion_router) Line 65
-> mini-tor.exe!tor_client::extend_to_random(mini::flags flags, mini::collections::list<unsigned short,mini::allocator > or_ports) Line 47
-> mini-tor.exe!main(int argc, char * * argv) Line 259

Best Regards

When calling circuit::create_stream() to connect to a host that is currently unreachable, the function hangs indefinitely.

I think this happens because on mini/tor/circuit.cpp:114 there is an infinite wait until state equals state::ready, which may never happen.

I guess a possible fix is to wait with a proper timeout, and abort circuit creation returning an error value in case such timeout is reached. A timeout parameter could be added in circuit::wait_for_state() to do so.

By the way, I think locked_value::wait_for_value() is also broken when you call it with a non-infinite timeout value. My guess is that sometimes the variable remaining_timeout underflows and therefore issues an absurdly long wait.

Let me know if you want me to help in any way
Best regards