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
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. :-)
>
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
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
(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
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
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.
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 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 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
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
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 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* and *c*;
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
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 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_TOR -
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 provided
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/stegotorus.git
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 anonymity
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
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 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 encryption
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
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 get
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 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
26 matches
Mail list logo
