Re: [tor-dev] Feedback on CollecTor web redesign

2015-10-20 Thread David Fifield 
On Tue, Oct 20, 2015 at 09:31:38PM +0200, Karsten Loesing wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi devs,
> 
> I just finished a redesign of the CollecTor website and would
> appreciate your feedback:
> 
>   https://metrics.torproject.org/index2.html

This URL is 404 for me.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

2015-10-20 Thread grarpamp 
On Sat, Oct 17, 2015 at 5:46 PM, Razvan Dragomirescu
 wrote:
> Exactly, you ask the smartcard to decrypt your traffic (and sign data if
> needed), it never tells you the key, it's a blackbox - it gets plaintext
> input and gives you encrypted (or signed) output, without ever revealing the
> key it's used. It can also generate the key internally (actually a keypair,
> it stores the private key in secure memory (protected from software _and_
> hardware attacks)) and gives you the public key so that you can publish it.
>
> Remember, smartcards are not just storage, they are tamper resistant
> embedded computers.

I misread your original intent.

Yes if you intend to patch tor to use a smartcard as a
cryptographic coprocessor offloading anything of interest
that needs signed / encrypted / decrypted to it. The card
will need to remain plugged in for tor to function. The card
will need to know to generate new keys periodically for
the functions in tor that need them... new key usage API's
will need developed between the card and tor to manage that.
OpenSSL may have card functions already but not in a way
that makes sense to abstract upper program logic of tor.
And your own use of "pin" and input to enable the card
itself should be as secure as that to be protected.

It's worth looking at the keyops per second and
streamrates per second needed by various crypto
parts of tor and determining what smartcards / expansion
cards on the market could handle which parts of that.
Cards need to support the crypto algos that tor uses
or will be moving to.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

2015-10-20 Thread grarpamp 
You mentione...

> I have Tor running on the USBArmory by InversePath (
> http://inversepath.com/usbarmory.html ) and have a microSD form factor card
> made by Swissbit (
> www.swissbit.com/products/security-products/overwiev/security-products-overview/
> ) up and running on it.

Good that USBarmory could provide even tor binaries
over a usb mass storage fs for the host to run.
Or even run the tor process and network itself as you say.

However how is "pin" on swissbit enabled?
If it goes from the host (say via ssh or keyboard or some
device or app) through usb port through armory to swissbit,
that is never secure.
If it goes from external pad through GPIO on armory
to swissbit, that will not be secure if host can in
any way snoop on armory, or can use or modify code
on the armory to do that and report the armory core / bus
data back to the host.
If swissbit card itself had external I/O for "pin" ops,
that would be secure.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Feedback on CollecTor web redesign

2015-10-20 Thread Damian Johnson 
I agree with David. I like the change, especially the table (nice
work!). Though a lot of the text is well into TL;DR territory. If the
welcome message could be half the size that would help, and the
formats have some redundancy. For instance, hidden service descriptors
and bridge pool annotations have just one sub-header so they could be
combined with their top level header.

Cheers! -Damian


On Tue, Oct 20, 2015 at 12:37 PM, David Goulet  wrote:
> On 20 Oct (21:31:38), Karsten Loesing wrote:
>> Hi devs,
>>
>> I just finished a redesign of the CollecTor website and would
>> appreciate your feedback:
>>
>>   https://metrics.torproject.org/index2.html
>
> I think you mean: https://collector.torproject.org/index2.html
>
> :)
>
> I like it. There is quite a bit of text and information pass the Data
> Formats section but what I really enjoy now (from which I got annoyed
> from the original design) is the two buttons for recent/ and archive/
> descriptors. Way easier to get then before where I had to go in a
> subsection and then click recent/ in the middle of the paragraph.
>
> Cheers!
> David
>
>>
>> For reference, the old CollecTor website is still available here:
>>
>>   https://metrics.torproject.org/index.html
>>
>>   https://metrics.torproject.org/formats.html
>>
>> Let me add that I'm not a web designer, and let me prove that
>> statement by telling you that all HTML on that website was
>> written using vim.  I'm more than happy to accept patches or
>> suggestions, though I'll likely ask you to explain them to me.
>>
>> Thanks!
>>
>> All the best,
>> Karsten
>> ___
>> tor-dev mailing list
>> tor-dev@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Feedback on CollecTor web redesign

2015-10-20 Thread Damian Johnson 
> I agree with David. I like the change, especially the table (nice
> work!). Though a lot of the text is well into TL;DR territory. If the
> welcome message could be half the size that would help, and the
> formats have some redundancy. For instance, hidden service descriptors
> and bridge pool annotations have just one sub-header so they could be
> combined with their top level header.

Hmmm, now that I think about this some more I wonder if the two of us
should do some collaboration on this. Stem's descriptor page and
CollecTor both provide differing general information...

Stem - https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html

  * What is a descriptor?
  * Where do descriptors come from?
  * Brief summary of the most important descriptor types
  * Library comparison we're working on

CollecTor - https://collector.torproject.org/index2.html

  * Detailed listing of all descriptor types
  * Reference users on where to get 'em

Perhaps we should combine parts of both for a "New to descriptors?
Lets give you a very simple, short description of them". Your table
would be perfect for that.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

2015-10-20 Thread grarpamp 
On Tue, Oct 20, 2015 at 3:05 PM, Ivan Markin  wrote:
> No, I will be secure. An adversary could sniff your PIN and sign
> whatever they want to, true. But revealing the PIN != revealing the key.
> In this case your identity key is still safe even if your PIN is
> "compromised".

Yes the private key may be safe, but the smartcard may be stolen or
removed from your sphere of access and reutilized with the sniffed
pin, thus your onion or relay or node is no longer under your control,
which was the point of the project. The enablement of the smartcard
needs to be out of band, or use some strong one way challenge
response like pki/totp/hotp/skey/opie.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Effect of padding on end to end correlation false positive rate

2015-10-20 Thread grarpamp 
On Fri, Oct 16, 2015 at 3:22 PM, s7r  wrote:
> I am describing something like a Sybil attack where the adversary runs
> relays, gets lucky and is selected in a certain position of a certain

> Does this change with padding? If yes, how?
> [1]: https://blog.torproject.org/blog/traffic-correlation-using-netflows

My thought was solely restricted to analysis of network
traffic by *passive* adversary... not involving any collusion
by actives over circuits they can see inside or pump within
any given onion layer, though clocked and checked network
fill by all proper nodes would inhibit pumping by actives.
I talked on list with someone at briarproject and wherever
else on idea of filling the network with traffic vs the passives.
Apologize for not making time to review Mike's proposal
or develop further talk yet. Someone will review / integrate
fill padding of network with regard anonbib, Mike's, etc I'm sure,
as it is clearly (to me at least) a weakness of non-filled
non-store-and-forward networks vs the passives which we
all know and love.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] adding smartcard support to Tor

2015-10-20 Thread Razvan Dragomirescu 
Yes, that's precisely the point - if the card is stolen, the service is
stolen with it. I'm not trying to prevent that, I'm trying to _tie_ the
service to the card - whoever has the card runs the service. If you see
that the card is gone, you know your service is gone too. If the card is
still there, your service keys are safe.

Razvan

On Tue, Oct 20, 2015 at 10:59 PM, grarpamp  wrote:

> On Tue, Oct 20, 2015 at 3:05 PM, Ivan Markin  wrote:
> > No, I will be secure. An adversary could sniff your PIN and sign
> > whatever they want to, true. But revealing the PIN != revealing the key.
> > In this case your identity key is still safe even if your PIN is
> > "compromised".
>
> Yes the private key may be safe, but the smartcard may be stolen or
> removed from your sphere of access and reutilized with the sniffed
> pin, thus your onion or relay or node is no longer under your control,
> which was the point of the project. The enablement of the smartcard
> needs to be out of band, or use some strong one way challenge
> response like pki/totp/hotp/skey/opie.
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Feedback on CollecTor web redesign

2015-10-20 Thread Karsten Loesing 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 20/10/15 21:36, David Fifield wrote:
> On Tue, Oct 20, 2015 at 09:31:38PM +0200, Karsten Loesing wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> Hi devs,
>> 
>> I just finished a redesign of the CollecTor website and would 
>> appreciate your feedback:
>> 
>> https://metrics.torproject.org/index2.html
> 
> This URL is 404 for me.

Bah, sorry!  Let me try again and give you all new and old URLs:

New CollecTor website:

  https://collector.torproject.org/index2.html

Old CollecTor website:

  https://collector.torproject.org/index.html

  https://collector.torproject.org/formats.html

All the best,
Karsten

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJWJpoHAAoJEJD5dJfVqbCrs3MH/RPlYJX5os7jURjgNElDgUdS
wCGYwumkkslzbPrVqQqSOgGisELBN7BPmU2NqP1h/R2fKaDqEt36fIYRLnU9SSuv
aIpCTd98eGMfBgm+2loGGMr5TOHEZZ3uae4KJwBR8b1AFpZebO4BZKK34lQtpRTB
P/Zx9qKdiB/dVA+uk+wXRbO0tW6N/5jYxGfnFNMCIgeyUipMq9+cuvhtfG7yRJIE
mmqiiZq2tBeKliE/OW5pnaDhuL9BR53lPVyIOfAUgEtcKDcvSht86gBSOzr0Vyrp
ippAVp8Cw+x+3UrZeWhbEuFYqyldpUAwNp8VUUDwCw4Dr7QhbJQ1HihRpfDJmAY=
=eySE
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Load Balancing in 2.7 series - incompatible with OnionBalance ?

2015-10-20 Thread Alec Muffett 
So I’ve just had a conversation with dgoulet on IRC, which I will reformat and 
subedit here as a conversation regarding OnionBalance and issues in 2.6 and 2.7 
when a recently rebooted HS publishes a fresh descriptor:

[…]

alecm: consider OnionBalance which - being a bunch of daemons on a bunch of 
servers - will be a lot more prone to intermittent failures of 1+ daemons 
yielding a lot of republishing

alecm: we tend to move services around, and daemons will be killed in one place 
and resurrected elsewhere, and then we'll have to bundle up a new descriptor 
and ship it out

dgoulet: hrm so with that new 027 cache behavior, as long as the IP are usable, 
the descriptor will be kept, if they all become unusable, a new descriptor 
fetch is triggered and then those IPs will be tried

alecm: There's a mandatory refresh [of the descriptor] after N minutes?

dgoulet: we'll retry 3 times and after that all HSDir are in timeout for 15 
minutes (I think, I'll have to validate) before retrying any HSDirs

alecm: I wonder if descriptors should publish a recommended TTL - [number of 
seconds to live before refresh]

dgoulet: yeah we have an idea for a "revision-counter" in the descriptor being 
incremented at each new version for the 24 hours period

dgoulet: a TTL could be useful for load balancing though!

alecm: so, here's a scenario: imagine that we run 10 daemons,

alecm: call these daemons: A B C D E F G H I J - they all have random onion 
addresses

alecm: we steal one IP from each daemon, and bundle the 10 stolen IPs together 
to make an onionbalance site descriptor and publish it

alecm: people pull that descriptor, it's quite popular

alecm: we then lose power in a datacentre, which takes out half of our onions - 
say, A through E

alecm: we reboot the datacentre and restart A-E merely 10 minutes later

alecm: everyone who has already loaded our onionbalance site descriptor tests A 
B C D E and finds them all dead, because the old IPs for A-E are invalid

alecm: so they all move to F G H I J - which get overloaded even though (new) A 
B C D E are back up

alecm: and this persists for up to 244, even though the outage was only 10 
minutes

alecm: net result: large chunks of the world (anyone with an old descriptor + 
anyone randomly choosing F-J) have a shitty experience, which is not what 
high-availability is all about :-)

dgoulet: that will be what's going to happen - having a TTL in the desc. would 
help here indeed, I see the issue

dgoulet: TTL would be one thing to add, here we could also add a mechanism for 
a client retrying IPs that failed in the situation where some of the IPs are 
still working, or making client balance themself randomly could be also an idea

dgoulet: definitely there is some content here for tor-dev - I don't have a 
good answer but it should definitely be addressed

alecm: proper random selection of IP would be beneficial for load-balancing; 
not perfect, but in the long run, helpful

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Load Balancing in 2.7 series - incompatible with OnionBalance ?

2015-10-20 Thread Alec Muffett 
typo:

> alecm: and this persists for up to 24h, even though the outage was only 10 
> minutes

Also, I neglected to observe that linear polling of A-E seeking a descriptor 
suggests A will be hammered whilst J is nearly idle.

Some entropy in IP selection would be a good thing.

-a

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev