On Tue, 24 Jan 2017 12:40:00 +, segfault wrote:
...
> While the addresses are definitely too long to be fun to type, there are
> still use cases where the addresses will be typed.
For those cases you could print them with half-spaces or similar.
You can even type them but need to remove them b
On Fri, 17 Mar 2017 18:12:11 +, Jaskaran Singh wrote:
...
> Currently, guard relays and bridges maintains a list of IP addresses of
> the devices that connect to it for various reasons such as for use by
> the bridge to check which country has them blocked. This is dangerous
> because if any of
On Tue, 21 Mar 2017 16:06:59 +, Jaskaran Singh wrote:
...
> > On the other hand side you can indeed keep the filter rather small
> > because one bridge doesn't get that many collisions, and you don't
> > need to make it anywhere as big as to avoid collision with 2^32 entries.
> > Could also be
On Tue, 28 Mar 2017 13:24:15 +, samir menon wrote:
...
> IPv6 also solves this (128 bits), but there again, the solution is just to
> hash the IP's before storing them
No even that. Once you forget the salt the stored-so-far addresses
become useless for you, too. So instead of storing current
On Sun, 13 Aug 2017 17:06:20 +, Ryan Carboni wrote:
> https://tools.ietf.org/html/rfc3986#section-3
> By placing the scheme within the authority as a tld while using the same
> authority as the HTTP specification, this probably breaks RFC 3986 and
> maybe others.
RFC7686 deals with that.
Andr
On Sat, 14 Oct 2017 15:12:05 +, dawuud wrote:
>
> That sounds terrabad. Can we finally set fire to tor2web? It was
> never a good idea.
Why? There is exactly nothing that would stop google from actually
indexing .onion domains (it knows about), like it now is with
onion.to, even thought that
(Earlier reply has somehow vanished...)
On Mon, 08 Jan 2018 00:49:16 +, teor wrote:
...
> When there are multiple supported tor versions, which one should be stable?
> At the moment, we support 0.2.5 and 0.2.9 as long-term support, and 0.3.0 and
> 0.3.1 as regular releases.
The newest/highest
On Wed, 24 Jan 2018 10:42:42 +, Nick Mathewson wrote:
...
> > Can we maintain an "alpha" branch with the latest Tor alpha,
> > and a "stable" branch with the latest Tor stable?
>
> Hm. I'm not strictly opposed to the idea, but I'd like to think about
> how it would work. The history of such br
On Mon, 24 Sep 2018 11:57:48 +, David Fifield wrote:
> I have to admit that I don't fully understand the apparent enthusiasm
> for encrypted SNI from groups that formerly were not excited about
> domain fronting.
It's simply wrong to use different names in SNI and the host header. :-)
> custo
On Mon, 24 Sep 2018 20:23:58 +, David Fifield wrote:
...
> "encrypted SNI" part. But it's possible to do better: if you're willing
> to abandon HTTP/1.1 compatibility and require HTTP/2, you can use the
> "server push" feature to implement a serialization that's much more
> efficient than the c
On Wed, 03 Oct 2018 19:01:21 +, David Fifield wrote:
...
> And for that matter, why not a plain old HTTP CONNECT proxy?
Because the typical load balancer/forwarder would have to
decide whether to forward that CONNECT or do it itself,
and some other. CONNECT with a Host: header - I'm not
sure t
On Thu, 23 Aug 2012 19:03:06 +, tagnaq wrote:
...
> Why?
> This would reduce the configuration effort required when adding a new
> relay to *two* relays regardless of how many relays are in your family.
True, but: If one relay disappears for a while then the family may
break into two if it was
On Thu, 16 Aug 2012 22:45:47 +, Linus Nordberg wrote:
...
> The roadmaps/Tor/IPv6 [1] wiki page has been started with the goal of
> communicating the status of the work with Tor on IPv6.
Hmm, is there any thought of allowing IPv6 addresses for accessing
hidden services? Or do you expect it to
On Mon, 27 Aug 2012 09:13:37 +, Linus Nordberg wrote:
...
> I think that we should allow IPv6 addresses in the HiddenServicePort
Turns out it already does (tor_addr_port_lookup()). Seems that changing
the parsing & processing for IPv6 'bridge' already did the trick.
Tested with ::1 only, have
On Sun, 04 Nov 2012 18:31:51 +, Roger Dingledine wrote:
...
> The circuit-level flow control, or something like it, is needed
> because different users are competing for the same resources. But the
> stream-level flow control has a different threat model, since all the
> streams belong
On Mon, 05 Nov 2012 02:01:21 +, Roger Dingledine wrote:
> On Mon, Nov 05, 2012 at 06:57:48AM +0100, Andreas Krey wrote:
> > With no per-stream window a single stalled stream would
> > block the circuit forever.
>
> Wait, what?
>
> Can you define 'stalled'
On Tue, 06 Nov 2012 11:51:10 +, Julian Yon wrote:
> On Tue, 6 Nov 2012 01:06:56 -0500
> Roger Dingledine wrote:
>
> > If we ripped out stream-level sendmes, then as you say, we'd have to
> > choose between "queue all the data for the stream, no matter how big
> > it gets" and "tell the whole
On Thu, 13 Dec 2012 16:22:09 +, Angus Gardner wrote:
...
> Recently I have been noticing, in netstat output, a high level of
> established but idle TCP connections to other tor-hosts.
>
> (Out of 96 ESTABLISHED connections there are 90 with Recv-Q & Send-Q of 0.)
That pretty normal. Recv-Q ge
On Sat, 09 Feb 2013 14:27:33 +, Damian Johnson wrote:
...
> I cringe a bit to suggest it, but maybe a mapping in a mapping?
>
> CELL_STATS PCircID=8 PConnID=47110 PAdded=created:1,relay:1
> PRemoved=created:1,relay:1
You can as well go wild and use recursive syntax:
CELL_STATS PCircID=8 P
On Tue, 02 Jul 2013 23:42:20 +, Ximin Luo wrote:
...
> What sort of PKI are you using to verify the pubkey claimed by either side, to
> prevent MitM?
What for? The authentication happens in the next step,
within the OR/bridge protocol. In this case we just have
an additional layer of encryptio
On Sat, 27 Jul 2013 09:52:52 +, Tom Ritter wrote:
...
> I've always thought with SSH-based obsproxies, that you could
> distribute the SSH private key to connect to the server with the
> bridge IP address:port.
I couldn't quite avoid the reflexive cringe at 'distribute private key'. :-)
...
>
On Tue, 10 Sep 2013 14:17:12 +, George Kadianakis wrote:
> Hey Yawning (and tor-dev),
>
> a topic that we will soon need to consider seriously is rate limiting
> of pluggable transports. For example, Obfsproxy at the moment does not
> understand rate limiting and will happily read and write as
On Fri, 10 Jan 2014 00:19:32 +, Jim Rucker wrote:
> This is an attempt at security though obscurity,
I think you mean 'nondiscoverability through obscurity';
transport security would be in a different layer. What is
tunneled in an obscure way is still the regular tor
protocol which provide enc
On Wed, 15 Jan 2014 21:16:20 +, Jim Rucker wrote:
> There was a story in the news recently of a Harvard student who used Tor to
> send a bomb threat to Harvard in order to cancel classes so he wouldn't
> have to take a test. He was apprehended within a day, which puts into
> question the anonym
On Tue, 01 Apr 2014 12:02:23 +, Zack Weinberg wrote:
...
> That's not the issue; the issue is that I am unaware of any good way to
> tell git to pull or push *all* branches that exist in a particular
> remote. Your example
>
> > [remote "origin"]
> > url = g...@github.com:zackw/stegot
On Wed, 17 Sep 2014 21:05:39 +, Tom Ritter wrote:
...
> A horrible idea Isis and I came up with was standing up two or more
> tor servers with the same keys, on an anycast-ed IP address.
I don't think anycasted IPs work well with TCP, considering route flapping.
Andreas
--
"Totally trivial.
On Tue, 11 Nov 2014 15:07:38 +, Mohiuddin Ebna Kawsar wrote:
> Hi,
>
> I want to develop extension(intrusion detection) for tor. for that i have
> to extract TCP and IP header from packet.
> I need to know where and how tor handle packet(TCP/IP).
Nowhere. tor works with tcp connections provid
On Wed, 25 Feb 2015 05:06:37 +, carlo von lynX wrote:
> the advantages of that aren't obvious to me. why would i need to
> make every networking app hold the hand of its router to let it
> know it's still needed?
You answer your question yourself:
> tor is on its way to becoming an AF_TO
On Wed, 25 Feb 2015 13:51:59 +, carlo von lynX wrote:
...
> What is useful here is if I can use existing $app with existing
> tor router and just have a shell script drop the glue instructions
> into the tor unix socket.
One way to do that would be to tie the hidden service to the existence
of
On Fri, 13 Mar 2015 00:00:36 +, Damian Johnson wrote:
...
> And on a side note, damn naming things is hard...
Indeed. You mostly need invented names to avoid the google trap,
like git didn't, and thalys did.
'sethor' came to mind, and it contains 'tor' in a non-roger-invoking
way. :-) (But ap
On Tue, 11 Aug 2015 13:44:48 +, Virgil Griffith wrote:
> I mean the median.
>
> >From Wikipedia...
>
> For example, if *a* < *b* < *c*, then the median of the list {*a*, *b*, *c*}
> is *b*, and, if *a* < *b* < *c* < *d*, then the median of the list {*a*, *b*
> , *c*, *d*} is the mean of *b* a
On Sun, 30 Aug 2015 23:24:07 +, Michael McConville wrote:
> Mansour Moufid wrote:
> > Michael McConville wrote:
...
> > > error:
> > > - if (x509) {
> > > -X509_free(x509);
> > > -x509 = NULL;
> > > - }
...
> > But you did find some places they forgot to assign NULL after free.
>
>
On Wed, 30 Sep 2015 17:12:53 +, Tim Wilson-Brown - teor wrote:
...
> Are there any use cases that:
> * need NAT punching,
> * don???t need service location anonymity, and
> * would benefit from lower latency?
Of course. All the cases where you set up a hidden service
exactly because your host
33 matches
Mail list logo