Opened 6 years ago

Closed 6 years ago

#3374 closed task (fixed)

Torouter OS and configuration

Reported by: runa Owned by: runa
Priority: Medium Milestone:
Component: Archived/Torouter Version:
Severity: Keywords:
Cc: tortrac@…, zooko@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We need to come up with a list of requirements for the OS and the Torouter config (with the DreamPlug in mind). In an email to tor-dev, Jake suggests that we:

  • Re-flash devices to have Debian or a modern Ubuntu.
  • Lock down the device, except with Tor and OpenSSH as listening services.
  • A few stock configuration files.
  • Time syncing (clockskew for example).
  • Randomly generated password that we uniquely key for each device.
  • Non-exit relay by default.
  • Ship 0.2.3.x with tor-fw-helper enabled by default.

Child Tickets

Attachments (1)

download.php?i=v0GhXyA2 (12.5 KB) - added by rransom 6 years ago.
v0GhXyA2

Download all attachments as: .zip

Change History (77)

comment:1 Changed 6 years ago by runa

We should also look into the following:

  • Stripping down Excito's B3 interface and use this on the DreamPlug.
  • Debian or Ubuntu; are there any good reasons to pick one over the other?
  • NTP, OpenSSH with key authentication (and perhaps fail2ban or similar), password authentication and a web interface.
  • Do we want to include a Tor wifi network? And if so, should it be enabled by default?

comment:2 Changed 6 years ago by shawnmer

Possibly consider:

  • Via web interface can assign specific client IP/MAC to always/never use TOR network
  • Ability to define specific IP/websites that will always/never go thru the TOR network
  • Optional client capture portal/splash page to:
    • Allow clients to choose yes/no for TOR network
    • Provide link to TOR project, FAQ, etc.
    • Provide a means for TOR router admin to add text(disclaimer, welcome, etc.)

comment:3 Changed 6 years ago by runa

We cannot strip down and use the Excito B3 web interface on the DreamPlug because not all of it is free software. We'll have to come up with something else.

comment:4 in reply to:  3 Changed 6 years ago by cypherpunks

Replying to runa:

We cannot strip down and use the Excito B3 web interface on the DreamPlug because not all of it is free software. We'll have to come up with something else.

That seems rather lame of them. Why are they not releasing it as free software?

comment:5 Changed 6 years ago by runa

I guess they want to keep a small part of the interface closed as a company asset.

comment:6 Changed 6 years ago by cypherpunks

I propose that we ship the following debian packages:

http://packages.debian.org/squeeze/denyhosts
http://packages.debian.org/squeeze/openssh-server
http://packages.debian.org/squeeze/cron-apt

I propose that we ship the following Tor Project packages and work to get them into Debian ASAP:

ttdnsd

We need to package a few things for this process to work.

clockspeed needs to be packaged:
http://cr.yp.to/clockspeed.html
http://thedjbway.b0llix.net/clocksd/index.html

We'd need to install daemontools for clockspeed and this is already supported on Debian.

An alternative that I trust less is OpenNTPD but it is already packaged:

openntpd

We'll also need the most recent 0.2.3.x Tor release as a Debian package, specifically we need to build it with tor-fw-helper. This means that we need to package the upnp and natpmp shared libraries.

What other packages do we need to build? What other packages do we need to install?

comment:7 in reply to:  5 ; Changed 6 years ago by cypherpunks

Replying to runa:

I guess they want to keep a small part of the interface closed as a company asset.

Has anyone asked them to make it Free Software? It seems like a bad choice as now the Freedom Box has to re-create a project for the community and eventually their software will simply not be used by anyone. It seems like a much better thing to make it the best web interface around and everyone wins. Especially Excito!

comment:8 Changed 6 years ago by cypherpunks

I think that it would also be nice to ship ufw enabled by default:

http://packages.debian.org/squeeze/ufw

comment:9 in reply to:  6 ; Changed 6 years ago by runa

Replying to cypherpunks:

I propose that we ship the following debian packages:

http://packages.debian.org/squeeze/denyhosts
http://packages.debian.org/squeeze/openssh-server
http://packages.debian.org/squeeze/cron-apt

Sure, looks good.

I propose that we ship the following Tor Project packages and work to get them into Debian ASAP:

ttdnsd

I see that some work has already been done to package this for Debian (there's a Debian directory in the ttdnsd.git repository). What's the status of that?

Also, I believe that tsocks (which ttdnsd depends on) is out of date and that we should use torsocks instead. Thoughts?

We need to package a few things for this process to work.

clockspeed needs to be packaged:
http://cr.yp.to/clockspeed.html
http://thedjbway.b0llix.net/clocksd/index.html

We'd need to install daemontools for clockspeed and this is already supported on Debian.

An alternative that I trust less is OpenNTPD but it is already packaged:

openntpd

Why do you trust it less?

We'll also need the most recent 0.2.3.x Tor release as a Debian package, specifically we need to build it with tor-fw-helper. This means that we need to package the upnp and natpmp shared libraries.

I assume weasel is the person to ask regarding Debian packages for 0.2.3.x. Do you want to package upnp and natpmp?

comment:10 in reply to:  7 Changed 6 years ago by runa

Replying to cypherpunks:

Replying to runa:

I guess they want to keep a small part of the interface closed as a company asset.

Has anyone asked them to make it Free Software? It seems like a bad choice as now the Freedom Box has to re-create a project for the community and eventually their software will simply not be used by anyone. It seems like a much better thing to make it the best web interface around and everyone wins. Especially Excito!

I'm way ahead of you there. I believe there is an ongoing discussion, and a bunch of people who need convincing. I agree that it's sad to see the Freedom Box (and possibly us) re-create something that already exists, but I don't think that having a Freedom Box will mean that people will no longer want Excito's product.

comment:11 in reply to:  9 ; Changed 6 years ago by rransom

Replying to runa:

Replying to cypherpunks:

I propose that we ship the following Tor Project packages and work to get them into Debian ASAP:

ttdnsd

I see that some work has already been done to package this for Debian (there's a Debian directory in the ttdnsd.git repository). What's the status of that?

Also, I believe that tsocks (which ttdnsd depends on) is out of date and that we should use torsocks instead. Thoughts?

Yes, we should use torsocks instead of tsocks if we configure any software to act as a Tor client. But ttdnsd is only useful for a client configuration -- its main use is as a fallback DNS server for DNS requests that Tor cannot handle, as part of a Tor transparent proxy configuration.

We need to package a few things for this process to work.

clockspeed needs to be packaged:
http://cr.yp.to/clockspeed.html
http://thedjbway.b0llix.net/clocksd/index.html

We'd need to install daemontools for clockspeed and this is already supported on Debian.

An alternative that I trust less is OpenNTPD but it is already packaged:

openntpd

Why do you trust it less?

clockspeed was written by DJB, and is very unlikely to have security holes. clockspeed also appears to use less frequent network queries than NTP clients would, although it might not behave properly on a computer with CPU frequency scaling.

comment:12 in reply to:  11 ; Changed 6 years ago by runa

Replying to rransom:

Replying to runa:

Replying to cypherpunks:

I propose that we ship the following Tor Project packages and work to get them into Debian ASAP:

ttdnsd

I see that some work has already been done to package this for Debian (there's a Debian directory in the ttdnsd.git repository). What's the status of that?

Also, I believe that tsocks (which ttdnsd depends on) is out of date and that we should use torsocks instead. Thoughts?

Yes, we should use torsocks instead of tsocks if we configure any software to act as a Tor client. But ttdnsd is only useful for a client configuration -- its main use is as a fallback DNS server for DNS requests that Tor cannot handle, as part of a Tor transparent proxy configuration.

So, if ttdnsd is only useful for a client configuration, do we really need it right now? We're only shipping bridge-by-default plugs to begin with, and users can choose to set them up as relays if they want to.

We need to package a few things for this process to work.

clockspeed needs to be packaged:
http://cr.yp.to/clockspeed.html
http://thedjbway.b0llix.net/clocksd/index.html

We'd need to install daemontools for clockspeed and this is already supported on Debian.

An alternative that I trust less is OpenNTPD but it is already packaged:

openntpd

Why do you trust it less?

clockspeed was written by DJB, and is very unlikely to have security holes. clockspeed also appears to use less frequent network queries than NTP clients would, although it might not behave properly on a computer with CPU frequency scaling.

Ok, guess we can add this to the list of software to package as well. Who wants to give it a go?

comment:13 in reply to:  12 ; Changed 6 years ago by rransom

Replying to runa:

Replying to rransom:

Replying to runa:

Replying to cypherpunks:

So, if ttdnsd is only useful for a client configuration, do we really need it right now? We're only shipping bridge-by-default plugs to begin with, and users can choose to set them up as relays if they want to.

We don't need it.

comment:14 in reply to:  6 Changed 6 years ago by runa

Replying to cypherpunks:

We'll also need the most recent 0.2.3.x Tor release as a Debian package, specifically we need to build it with tor-fw-helper. This means that we need to package the upnp and natpmp shared libraries.

I created #3378 for the Tor 0.2.3.x and tor-fw-helper discussion.

comment:15 Changed 6 years ago by cypherpunks

Thanks to https://twitter.com/#!/jrenken for posting this: http://pastebin.com/v0GhXyA2

Here's a reality check for OpenSSL on the DreamPlug (from that pastebin):

# uname -a
Linux dreamplug 2.6.33.6 #1 PREEMPT Tue Feb 8 03:18:41 EST 2011 armv5tel GNU/Linux

# cat /etc/apt/sources.list
deb http://http.us.debian.org/debian squeeze main contrib non-free
deb http://http.us.debian.org/debian squeeze-updates main contrib non-free
deb http://security.debian.org squeeze/updates main contrib non-free

# cat /proc/cpuinfo
Processor       : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1192.75
Features        : swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Hardware        : Marvell GuruPlug Reference Board
Revision        : 0000
Serial          : 0000000000000000

# cat /proc/meminfo
MemTotal:         513780 kB
MemFree:          370548 kB
Buffers:           11624 kB
Cached:           106484 kB
SwapCached:            0 kB
Active:            98364 kB
Inactive:          31096 kB
Active(anon):      38656 kB
Inactive(anon):      628 kB
Active(file):      59708 kB
Inactive(file):    30468 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         11368 kB
Mapped:             7868 kB
Shmem:             27932 kB
Slab:               6448 kB
SReclaimable:       3516 kB
SUnreclaim:         2932 kB
KernelStack:        1088 kB
PageTables:          580 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      256888 kB
Committed_AS:      94752 kB
VmallocTotal:     491520 kB
VmallocUsed:        3056 kB
VmallocChunk:     487872 kB

# openssl speed
Doing md2 for 3s on 16 size blocks: 122476 md2's in 2.99s
Doing md2 for 3s on 64 size blocks: 67694 md2's in 3.00s
Doing md2 for 3s on 256 size blocks: 24261 md2's in 3.00s
Doing md2 for 3s on 1024 size blocks: 6810 md2's in 3.00s
Doing md2 for 3s on 8192 size blocks: 882 md2's in 3.00s
Doing md4 for 3s on 16 size blocks: 770980 md4's in 2.99s
Doing md4 for 3s on 64 size blocks: 694521 md4's in 3.00s
Doing md4 for 3s on 256 size blocks: 514645 md4's in 3.00s
Doing md4 for 3s on 1024 size blocks: 251637 md4's in 3.00s
Doing md4 for 3s on 8192 size blocks: 43600 md4's in 3.00s
Doing md5 for 3s on 16 size blocks: 623897 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 548525 md5's in 2.99s
Doing md5 for 3s on 256 size blocks: 396362 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 188326 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 31974 md5's in 3.00s
Doing hmac(md5) for 3s on 16 size blocks: 803103 hmac(md5)'s in 3.00s
Doing hmac(md5) for 3s on 64 size blocks: 679630 hmac(md5)'s in 2.99s
Doing hmac(md5) for 3s on 256 size blocks: 461056 hmac(md5)'s in 3.00s
Doing hmac(md5) for 3s on 1024 size blocks: 202498 hmac(md5)'s in 3.00s
Doing hmac(md5) for 3s on 8192 size blocks: 32456 hmac(md5)'s in 3.00s
Doing sha1 for 3s on 16 size blocks: 562151 sha1's in 3.00s
Doing sha1 for 3s on 64 size blocks: 445183 sha1's in 3.00s
Doing sha1 for 3s on 256 size blocks: 267571 sha1's in 2.99s
Doing sha1 for 3s on 1024 size blocks: 103395 sha1's in 3.00s
Doing sha1 for 3s on 8192 size blocks: 15233 sha1's in 3.00s
Doing sha256 for 3s on 16 size blocks: 481544 sha256's in 3.00s
Doing sha256 for 3s on 64 size blocks: 285020 sha256's in 3.00s
Doing sha256 for 3s on 256 size blocks: 127673 sha256's in 2.99s
Doing sha256 for 3s on 1024 size blocks: 39795 sha256's in 3.00s
Doing sha256 for 3s on 8192 size blocks: 5349 sha256's in 2.99s
Doing sha512 for 3s on 16 size blocks: 59554 sha512's in 3.00s
Doing sha512 for 3s on 64 size blocks: 59654 sha512's in 3.00s
Doing sha512 for 3s on 256 size blocks: 21005 sha512's in 3.00s
Doing sha512 for 3s on 1024 size blocks: 7198 sha512's in 3.00s
Doing sha512 for 3s on 8192 size blocks: 1028 sha512's in 2.99s
Doing rmd160 for 3s on 16 size blocks: 466774 rmd160's in 3.00s
Doing rmd160 for 3s on 64 size blocks: 361227 rmd160's in 3.00s
Doing rmd160 for 3s on 256 size blocks: 212312 rmd160's in 3.00s
Doing rmd160 for 3s on 1024 size blocks: 80270 rmd160's in 3.00s
Doing rmd160 for 3s on 8192 size blocks: 11790 rmd160's in 3.00s
Doing rc4 for 3s on 16 size blocks: 6937708 rc4's in 2.99s
Doing rc4 for 3s on 64 size blocks: 1951308 rc4's in 3.00s
Doing rc4 for 3s on 256 size blocks: 503975 rc4's in 3.00s
Doing rc4 for 3s on 1024 size blocks: 127099 rc4's in 3.00s
Doing rc4 for 3s on 8192 size blocks: 15917 rc4's in 3.00s
Doing des cbc for 3s on 16 size blocks: 1495004 des cbc's in 3.00s
Doing des cbc for 3s on 64 size blocks: 405724 des cbc's in 2.99s
Doing des cbc for 3s on 256 size blocks: 103738 des cbc's in 3.00s
Doing des cbc for 3s on 1024 size blocks: 26077 des cbc's in 3.00s
Doing des cbc for 3s on 8192 size blocks: 3264 des cbc's in 3.00s
Doing des ede3 for 3s on 16 size blocks: 568073 des ede3's in 3.00s
Doing des ede3 for 3s on 64 size blocks: 146383 des ede3's in 3.00s
Doing des ede3 for 3s on 256 size blocks: 36872 des ede3's in 3.00s
Doing des ede3 for 3s on 1024 size blocks: 9238 des ede3's in 2.99s
Doing des ede3 for 3s on 8192 size blocks: 1155 des ede3's in 3.00s
Doing aes-128 cbc for 3s on 16 size blocks: 1692575 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 465134 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 256 size blocks: 119350 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 1024 size blocks: 30028 aes-128 cbc's in 2.99s
Doing aes-128 cbc for 3s on 8192 size blocks: 3759 aes-128 cbc's in 3.00s
Doing aes-192 cbc for 3s on 16 size blocks: 1466123 aes-192 cbc's in 3.00s
Doing aes-192 cbc for 3s on 64 size blocks: 400505 aes-192 cbc's in 3.00s
Doing aes-192 cbc for 3s on 256 size blocks: 102296 aes-192 cbc's in 3.00s
Doing aes-192 cbc for 3s on 1024 size blocks: 25720 aes-192 cbc's in 3.00s
Doing aes-192 cbc for 3s on 8192 size blocks: 3217 aes-192 cbc's in 3.00s
Doing aes-256 cbc for 3s on 16 size blocks: 1309990 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 64 size blocks: 351233 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 256 size blocks: 89520 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 22480 aes-256 cbc's in 3.01s
Doing aes-256 cbc for 3s on 8192 size blocks: 2812 aes-256 cbc's in 3.00s
Doing aes-128 ige for 3s on 16 size blocks: 1681216 aes-128 ige's in 3.00s
Doing aes-128 ige for 3s on 64 size blocks: 473351 aes-128 ige's in 2.99s
Doing aes-128 ige for 3s on 256 size blocks: 122480 aes-128 ige's in 3.00s
Doing aes-128 ige for 3s on 1024 size blocks: 30893 aes-128 ige's in 3.00s
Doing aes-128 ige for 3s on 8192 size blocks: 3826 aes-128 ige's in 3.00s
Doing aes-192 ige for 3s on 16 size blocks: 1466402 aes-192 ige's in 3.00s
Doing aes-192 ige for 3s on 64 size blocks: 412688 aes-192 ige's in 3.00s
Doing aes-192 ige for 3s on 256 size blocks: 107345 aes-192 ige's in 3.00s
Doing aes-192 ige for 3s on 1024 size blocks: 27087 aes-192 ige's in 2.99s
Doing aes-192 ige for 3s on 8192 size blocks: 3362 aes-192 ige's in 3.00s
Doing aes-256 ige for 3s on 16 size blocks: 1298774 aes-256 ige's in 3.00s
Doing aes-256 ige for 3s on 64 size blocks: 360722 aes-256 ige's in 3.00s
Doing aes-256 ige for 3s on 256 size blocks: 93316 aes-256 ige's in 2.99s
Doing aes-256 ige for 3s on 1024 size blocks: 23534 aes-256 ige's in 3.00s
Doing aes-256 ige for 3s on 8192 size blocks: 2922 aes-256 ige's in 3.00s
Doing rc2 cbc for 3s on 16 size blocks: 1716926 rc2 cbc's in 3.00s
Doing rc2 cbc for 3s on 64 size blocks: 459696 rc2 cbc's in 3.00s
Doing rc2 cbc for 3s on 256 size blocks: 117055 rc2 cbc's in 3.00s
Doing rc2 cbc for 3s on 1024 size blocks: 29390 rc2 cbc's in 2.99s
Doing rc2 cbc for 3s on 8192 size blocks: 3679 rc2 cbc's in 3.00s
Doing blowfish cbc for 3s on 16 size blocks: 2918873 blowfish cbc's in 3.00s
Doing blowfish cbc for 3s on 64 size blocks: 856041 blowfish cbc's in 3.00s
Doing blowfish cbc for 3s on 256 size blocks: 223821 blowfish cbc's in 3.00s
Doing blowfish cbc for 3s on 1024 size blocks: 56612 blowfish cbc's in 3.00s
Doing blowfish cbc for 3s on 8192 size blocks: 7095 blowfish cbc's in 2.99s
Doing cast cbc for 3s on 16 size blocks: 2913689 cast cbc's in 3.00s
Doing cast cbc for 3s on 64 size blocks: 862679 cast cbc's in 3.00s
Doing cast cbc for 3s on 256 size blocks: 226385 cast cbc's in 3.00s
Doing cast cbc for 3s on 1024 size blocks: 57288 cast cbc's in 3.00s
Doing cast cbc for 3s on 8192 size blocks: 7184 cast cbc's in 3.00s
Doing 512 bit private rsa's for 10s: 3579 512 bit private RSA's in 9.99s
Doing 512 bit public rsa's for 10s: 44964 512 bit public RSA's in 10.00s
Doing 1024 bit private rsa's for 10s: 792 1024 bit private RSA's in 10.00s
Doing 1024 bit public rsa's for 10s: 17367 1024 bit public RSA's in 10.00s
Doing 2048 bit private rsa's for 10s: 145 2048 bit private RSA's in 10.00s
Doing 2048 bit public rsa's for 10s: 5642 2048 bit public RSA's in 10.00s
Doing 4096 bit private rsa's for 10s: 24 4096 bit private RSA's in 10.26s
Doing 4096 bit public rsa's for 10s: 1685 4096 bit public RSA's in 9.99s
Doing 512 bit sign dsa's for 10s: 4424 512 bit DSA signs in 10.00s
Doing 512 bit verify dsa's for 10s: 3947 512 bit DSA verify in 9.99s
Doing 1024 bit sign dsa's for 10s: 1742 1024 bit DSA signs in 10.01s
Doing 1024 bit verify dsa's for 10s: 1462 1024 bit DSA verify in 9.99s
Doing 2048 bit sign dsa's for 10s: 569 2048 bit DSA signs in 10.00s
Doing 2048 bit verify dsa's for 10s: 488 2048 bit DSA verify in 10.01s
OpenSSL 0.9.8o 01 Jun 2010
built on: Thu Feb 10 21:19:23 UTC 2011
options:bn(64,32) md2(int) rc4(ptr,int) des(idx,risc1,4,long) aes(partial) blowfish(idx) 
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -Wa,--noexecstack -g -Wall
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md2                655.39k     1444.14k     2070.27k     2324.48k     2408.45k
mdc2                 0.00         0.00         0.00         0.00         0.00 
md4               4125.65k    14816.45k    43916.37k    85892.10k   119057.07k
md5               3327.45k    11741.00k    33822.89k    64281.94k    87310.34k
hmac(md5)         4283.22k    14547.26k    39343.45k    69119.32k    88626.52k
sha1              2998.14k     9497.24k    22909.09k    35292.16k    41596.25k
rmd160            2489.46k     7706.18k    18117.29k    27398.83k    32194.56k
rc4              37124.86k    41627.90k    43005.87k    43383.13k    43464.02k
des cbc           7973.35k     8684.39k     8852.31k     8900.95k     8912.90k
des ede3          3029.72k     3122.84k     3146.41k     3163.78k     3153.92k
idea cbc             0.00         0.00         0.00         0.00         0.00 
seed cbc             0.00         0.00         0.00         0.00         0.00 
rc2 cbc           9156.94k     9806.85k     9988.69k    10065.34k    10046.12k
rc5-32/12 cbc        0.00         0.00         0.00         0.00         0.00 
blowfish cbc     15567.32k    18262.21k    19099.39k    19323.56k    19438.88k
cast cbc         15539.67k    18403.82k    19318.19k    19554.30k    19617.11k
aes-128 cbc       9027.07k     9922.86k    10184.53k    10283.84k    10264.58k
aes-192 cbc       7819.32k     8544.11k     8729.26k     8779.09k     8784.55k
aes-256 cbc       7009.98k     7492.97k     7639.04k     7647.68k     7678.63k
camellia-128 cbc        0.00         0.00         0.00         0.00         0.00 
camellia-192 cbc        0.00         0.00         0.00         0.00         0.00 
camellia-256 cbc        0.00         0.00         0.00         0.00         0.00 
sha256            2568.23k     6080.43k    10931.20k    13583.36k    14655.19k
sha512             317.62k     1272.62k     1792.43k     2456.92k     2816.51k
aes-128 ige       8966.49k    10131.93k    10451.63k    10544.81k    10447.53k
aes-192 ige       7820.81k     8804.01k     9160.11k     9276.62k     9180.50k
aes-256 ige       6926.79k     7695.40k     7989.60k     8032.94k     7979.01k
                  sign    verify    sign/s verify/s
rsa  512 bits 0.002791s 0.000222s    358.3   4496.4
rsa 1024 bits 0.012626s 0.000576s     79.2   1736.7
rsa 2048 bits 0.068966s 0.001772s     14.5    564.2
rsa 4096 bits 0.427500s 0.005929s      2.3    168.7
                  sign    verify    sign/s verify/s
dsa  512 bits 0.002260s 0.002531s    442.4    395.1
dsa 1024 bits 0.005746s 0.006833s    174.0    146.3
dsa 2048 bits 0.017575s 0.020512s     56.9     48.8

Changed 6 years ago by rransom

Attachment: download.php?i=v0GhXyA2 added

v0GhXyA2

comment:16 Changed 6 years ago by cypherpunks

Here's the OpenSSL speed tests for a dockstar from Amir Hassan and peppi:

Linux debian 2.6.32-5-kirkwood #1 Fri Nov 26 07:01:06 UTC 2010 armv5tel GNU/Linux

OpenSSL 0.9.8o 01 Jun 2010

Processor       : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1192.75
Features        : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Hardware        : Marvell SheevaPlug Reference Board
Revision        : 0000
Serial          : 0000000000000000
                                                                                                         
Doing md2 for 3s on 16 size blocks: 122177 md2's in 2.99s
Doing md2 for 3s on 64 size blocks: 67309 md2's in 2.99s
Doing md2 for 3s on 256 size blocks: 24139 md2's in 2.98s
Doing md2 for 3s on 1024 size blocks: 6773 md2's in 2.98s
Doing md2 for 3s on 8192 size blocks: 879 md2's in 2.99s
Doing md4 for 3s on 16 size blocks: 772402 md4's in 2.98s
Doing md4 for 3s on 64 size blocks: 699053 md4's in 2.98s
Doing md4 for 3s on 256 size blocks: 512758 md4's in 2.99s
Doing md4 for 3s on 1024 size blocks: 250542 md4's in 2.99s
Doing md4 for 3s on 8192 size blocks: 43327 md4's in 2.98s
Doing md5 for 3s on 16 size blocks: 620664 md5's in 2.98s
Doing md5 for 3s on 64 size blocks: 545206 md5's in 2.98s
Doing md5 for 3s on 256 size blocks: 394470 md5's in 2.99s
Doing md5 for 3s on 1024 size blocks: 187136 md5's in 2.98s
Doing md5 for 3s on 8192 size blocks: 31812 md5's in 2.99s
Doing hmac(md5) for 3s on 16 size blocks: 798071 hmac(md5)'s in 2.98s
Doing hmac(md5) for 3s on 64 size blocks: 676771 hmac(md5)'s in 2.98s
Doing hmac(md5) for 3s on 256 size blocks: 458451 hmac(md5)'s in 2.99s
Doing hmac(md5) for 3s on 1024 size blocks: 201363 hmac(md5)'s in 2.98s
Doing hmac(md5) for 3s on 8192 size blocks: 32240 hmac(md5)'s in 2.98s
Doing sha1 for 3s on 16 size blocks: 560042 sha1's in 2.99s
Doing sha1 for 3s on 64 size blocks: 442665 sha1's in 2.98s
Doing sha1 for 3s on 256 size blocks: 266022 sha1's in 2.98s
Doing sha1 for 3s on 1024 size blocks: 102762 sha1's in 2.99s
Doing sha1 for 3s on 8192 size blocks: 15151 sha1's in 2.98s
Doing sha256 for 3s on 16 size blocks: 478504 sha256's in 2.99s
Doing sha256 for 3s on 64 size blocks: 283335 sha256's in 2.98s
Doing sha256 for 3s on 256 size blocks: 126467 sha256's in 2.98s
Doing sha256 for 3s on 1024 size blocks: 39696 sha256's in 2.99s
Doing sha256 for 3s on 8192 size blocks: 5311 sha256's in 2.98s
Doing sha512 for 3s on 16 size blocks: 59224 sha512's in 2.98s
Doing sha512 for 3s on 64 size blocks: 59310 sha512's in 2.99s
Doing sha512 for 3s on 256 size blocks: 20944 sha512's in 2.98s
Doing sha512 for 3s on 1024 size blocks: 7160 sha512's in 2.99s
Doing sha512 for 3s on 8192 size blocks: 1026 sha512's in 2.98s
Doing rmd160 for 3s on 16 size blocks: 464393 rmd160's in 2.98s
Doing rmd160 for 3s on 64 size blocks: 359829 rmd160's in 2.99s
Doing rmd160 for 3s on 256 size blocks: 210947 rmd160's in 2.98s
Doing rmd160 for 3s on 1024 size blocks: 79798 rmd160's in 2.99s
Doing rmd160 for 3s on 8192 size blocks: 11718 rmd160's in 2.98s
Doing rc4 for 3s on 16 size blocks: 6931021 rc4's in 2.99s
Doing rc4 for 3s on 64 size blocks: 1940181 rc4's in 2.98s
Doing rc4 for 3s on 256 size blocks: 501667 rc4's in 2.98s
Doing rc4 for 3s on 1024 size blocks: 126375 rc4's in 2.99s
Doing rc4 for 3s on 8192 size blocks: 15857 rc4's in 2.98s
Doing des cbc for 3s on 16 size blocks: 1487355 des cbc's in 2.99s
Doing des cbc for 3s on 64 size blocks: 403676 des cbc's in 2.98s
Doing des cbc for 3s on 256 size blocks: 103168 des cbc's in 2.98s
Doing des cbc for 3s on 1024 size blocks: 25985 des cbc's in 2.99s
Doing des cbc for 3s on 8192 size blocks: 3248 des cbc's in 2.98s
Doing des ede3 for 3s on 16 size blocks: 564992 des ede3's in 2.98s
Doing des ede3 for 3s on 64 size blocks: 145555 des ede3's in 2.99s
Doing des ede3 for 3s on 256 size blocks: 36743 des ede3's in 2.99s
Doing des ede3 for 3s on 1024 size blocks: 9185 des ede3's in 2.98s
Doing des ede3 for 3s on 8192 size blocks: 1148 des ede3's in 2.98s
Doing aes-128 cbc for 3s on 16 size blocks: 1675355 aes-128 cbc's in 2.98s
Doing aes-128 cbc for 3s on 64 size blocks: 464861 aes-128 cbc's in 2.99s
Doing aes-128 cbc for 3s on 256 size blocks: 118735 aes-128 cbc's in 2.98s
Doing aes-128 cbc for 3s on 1024 size blocks: 29870 aes-128 cbc's in 2.99s
Doing aes-128 cbc for 3s on 8192 size blocks: 3737 aes-128 cbc's in 2.98s
Doing aes-192 cbc for 3s on 16 size blocks: 1452411 aes-192 cbc's in 2.99s
Doing aes-192 cbc for 3s on 64 size blocks: 397840 aes-192 cbc's in 2.98s
Doing aes-192 cbc for 3s on 256 size blocks: 101720 aes-192 cbc's in 2.98s
Doing aes-192 cbc for 3s on 1024 size blocks: 25589 aes-192 cbc's in 2.98s
Doing aes-192 cbc for 3s on 8192 size blocks: 3205 aes-192 cbc's in 2.99s
Doing aes-256 cbc for 3s on 16 size blocks: 1293201 aes-256 cbc's in 2.98s
Doing aes-256 cbc for 3s on 64 size blocks: 349266 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 256 size blocks: 88996 aes-256 cbc's in 2.98s
Doing aes-256 cbc for 3s on 1024 size blocks: 22382 aes-256 cbc's in 2.98s
Doing aes-256 cbc for 3s on 8192 size blocks: 2795 aes-256 cbc's in 2.98s
Doing aes-128 ige for 3s on 16 size blocks: 1682713 aes-128 ige's in 2.99s
Doing aes-128 ige for 3s on 64 size blocks: 483348 aes-128 ige's in 2.98s
Doing aes-128 ige for 3s on 256 size blocks: 126069 aes-128 ige's in 2.99s
Doing aes-128 ige for 3s on 1024 size blocks: 31773 aes-128 ige's in 2.98s
Doing aes-128 ige for 3s on 8192 size blocks: 3936 aes-128 ige's in 2.98s
Doing aes-192 ige for 3s on 16 size blocks: 1457504 aes-192 ige's in 2.99s
Doing aes-192 ige for 3s on 64 size blocks: 404649 aes-192 ige's in 2.98s
Doing aes-192 ige for 3s on 256 size blocks: 104090 aes-192 ige's in 2.99s
Doing aes-192 ige for 3s on 1024 size blocks: 26197 aes-192 ige's in 2.98s
Doing aes-192 ige for 3s on 8192 size blocks: 3247 aes-192 ige's in 2.98s
Doing aes-256 ige for 3s on 16 size blocks: 1294330 aes-256 ige's in 2.99s
Doing aes-256 ige for 3s on 64 size blocks: 358609 aes-256 ige's in 2.98s
Doing aes-256 ige for 3s on 256 size blocks: 92778 aes-256 ige's in 2.99s
Doing aes-256 ige for 3s on 1024 size blocks: 23399 aes-256 ige's in 2.98s
Doing aes-256 ige for 3s on 8192 size blocks: 2914 aes-256 ige's in 2.99s
Doing rc2 cbc for 3s on 16 size blocks: 1709112 rc2 cbc's in 2.98s
Doing rc2 cbc for 3s on 64 size blocks: 457203 rc2 cbc's in 2.98s
Doing rc2 cbc for 3s on 256 size blocks: 116401 rc2 cbc's in 2.99s
Doing rc2 cbc for 3s on 1024 size blocks: 29288 rc2 cbc's in 2.98s
Doing rc2 cbc for 3s on 8192 size blocks: 3657 rc2 cbc's in 2.98s
Doing blowfish cbc for 3s on 16 size blocks: 2879802 blowfish cbc's in 2.99s
Doing blowfish cbc for 3s on 64 size blocks: 850548 blowfish cbc's in 2.98s
Doing blowfish cbc for 3s on 256 size blocks: 222929 blowfish cbc's in 2.99s
Doing blowfish cbc for 3s on 1024 size blocks: 56225 blowfish cbc's in 2.97s
Doing blowfish cbc for 3s on 8192 size blocks: 7054 blowfish cbc's in 2.98s
Doing cast cbc for 3s on 16 size blocks: 2895539 cast cbc's in 3.00s
Doing cast cbc for 3s on 64 size blocks: 858725 cast cbc's in 2.97s
Doing cast cbc for 3s on 256 size blocks: 225092 cast cbc's in 2.99s
Doing cast cbc for 3s on 1024 size blocks: 57026 cast cbc's in 2.99s
Doing cast cbc for 3s on 8192 size blocks: 7155 cast cbc's in 2.99s
Doing 512 bit private rsa's for 10s: 3555 512 bit private RSA's in 9.94s
Doing 512 bit public rsa's for 10s: 44705 512 bit public RSA's in 9.95s
Doing 1024 bit private rsa's for 10s: 788 1024 bit private RSA's in 9.95s
Doing 1024 bit public rsa's for 10s: 17266 1024 bit public RSA's in 9.95s
Doing 2048 bit private rsa's for 10s: 144 2048 bit private RSA's in 9.98s
Doing 2048 bit public rsa's for 10s: 5620 2048 bit public RSA's in 9.95s
Doing 4096 bit private rsa's for 10s: 24 4096 bit private RSA's in 10.28s
Doing 4096 bit public rsa's for 10s: 1675 4096 bit public RSA's in 9.95s
Doing 512 bit sign dsa's for 10s: 4398 512 bit DSA signs in 9.93s
Doing 512 bit verify dsa's for 10s: 3950 512 bit DSA verify in 9.95s
Doing 1024 bit sign dsa's for 10s: 1732 1024 bit DSA signs in 9.94s
Doing 1024 bit verify dsa's for 10s: 1482 1024 bit DSA verify in 9.95s
Doing 2048 bit sign dsa's for 10s: 566 2048 bit DSA signs in 9.97s
Doing 2048 bit verify dsa's for 10s: 474 2048 bit DSA verify in 9.94s
OpenSSL 0.9.8o 01 Jun 2010
built on: Tue Nov 16 21:03:01 UTC 2010
options:bn(64,32) md2(int) rc4(ptr,int) des(idx,risc1,4,long) aes(partial) blowfish(idx) 
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -Wa,--noexecstack -g -Wall
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md2                653.79k     1440.73k     2073.69k     2327.37k     2408.28k
mdc2                 0.00         0.00         0.00         0.00         0.00 
md4               4147.12k    15013.22k    43901.69k    85804.35k   119105.63k
md5               3332.42k    11709.12k    33774.02k    64304.45k    87158.50k
hmac(md5)         4284.94k    14534.68k    39251.99k    69193.19k    88627.54k
sha1              2996.88k     9506.90k    22852.90k    35193.41k    41650.00k
rmd160            2493.39k     7702.03k    18121.62k    27328.81k    32212.70k
rc4              37089.08k    41668.32k    43096.23k    43280.27k    43590.79k
des cbc           7959.09k     8669.55k     8862.75k     8899.21k     8928.73k
des ede3          3033.51k     3115.56k     3145.89k     3156.19k     3155.84k
idea cbc             0.00         0.00         0.00         0.00         0.00 
seed cbc             0.00         0.00         0.00         0.00         0.00 
rc2 cbc           9176.44k     9819.12k     9966.11k    10064.06k    10053.07k
rc5-32/12 cbc        0.00         0.00         0.00         0.00         0.00 
blowfish cbc     15410.31k    18266.80k    19086.90k    19385.32k    19391.40k
cast cbc         15442.87k    18504.51k    19272.09k    19529.97k    19603.26k
aes-128 cbc       8995.19k     9950.20k    10200.05k    10229.73k    10272.99k
aes-192 cbc       7772.10k     8544.21k     8738.36k     8793.00k     8781.06k
aes-256 cbc       6943.36k     7475.93k     7645.29k     7691.00k     7683.44k
camellia-128 cbc        0.00         0.00         0.00         0.00         0.00 
camellia-192 cbc        0.00         0.00         0.00         0.00         0.00 
camellia-256 cbc        0.00         0.00         0.00         0.00         0.00 
sha256            2560.56k     6085.05k    10864.28k    13594.88k    14599.90k
sha512             317.98k     1269.51k     1799.22k     2452.12k     2820.47k
aes-128 ige       9004.48k    10380.63k    10793.87k    10917.97k    10820.04k
aes-192 ige       7799.35k     8690.45k     8912.05k     9001.92k     8925.98k
aes-256 ige       6926.18k     7701.67k     7943.53k     8040.46k     7983.78k
                  sign    verify    sign/s verify/s
rsa  512 bits 0.002796s 0.000223s    357.6   4493.0
rsa 1024 bits 0.012627s 0.000576s     79.2   1735.3
rsa 2048 bits 0.069306s 0.001770s     14.4    564.8
rsa 4096 bits 0.428333s 0.005940s      2.3    168.3
                  sign    verify    sign/s verify/s
dsa  512 bits 0.002258s 0.002519s    442.9    397.0
dsa 1024 bits 0.005739s 0.006714s    174.2    148.9
dsa 2048 bits 0.017615s 0.020970s     56.8     47.7

comment:17 in reply to:  9 ; Changed 6 years ago by cypherpunks

Replying to runa:

Replying to cypherpunks:

I propose that we ship the following debian packages:

http://packages.debian.org/squeeze/denyhosts
http://packages.debian.org/squeeze/openssh-server
http://packages.debian.org/squeeze/cron-apt

Sure, looks good.

I propose that we ship the following Tor Project packages and work to get them into Debian ASAP:

ttdnsd

I see that some work has already been done to package this for Debian (there's a Debian directory in the ttdnsd.git repository). What's the status of that?

We have packages for ttdnsd in deb.torproject.org; they're not uploaded to Debian.

Also, I believe that tsocks (which ttdnsd depends on) is out of date and that we should use torsocks instead. Thoughts?

Yes, torsocks is safe, tsocks is not.

We need to package a few things for this process to work.

clockspeed needs to be packaged:
http://cr.yp.to/clockspeed.html
http://thedjbway.b0llix.net/clocksd/index.html

We'd need to install daemontools for clockspeed and this is already supported on Debian.

An alternative that I trust less is OpenNTPD but it is already packaged:

openntpd

Why do you trust it less?

djb wrote one, who the hell knows about the other? :-) We absolutely must not use ISC software whatever we do.

We'll also need the most recent 0.2.3.x Tor release as a Debian package, specifically we need to build it with tor-fw-helper. This means that we need to package the upnp and natpmp shared libraries.

I assume weasel is the person to ask regarding Debian packages for 0.2.3.x. Do you want to package upnp and natpmp?

Want is a curious way to phrase it... :-)

comment:18 in reply to:  13 Changed 6 years ago by cypherpunks

Replying to rransom:

Replying to runa:

Replying to rransom:

Replying to runa:

Replying to cypherpunks:

So, if ttdnsd is only useful for a client configuration, do we really need it right now? We're only shipping bridge-by-default plugs to begin with, and users can choose to set them up as relays if they want to.

We don't need it.

I think it's fine to include it as we're basically not doing anything more than installing it.

comment:19 in reply to:  15 Changed 6 years ago by jrenken

Replying to cypherpunks:

Thanks to https://twitter.com/#!/jrenken for posting this: http://pastebin.com/v0GhXyA2

Here's a reality check for OpenSSL on the DreamPlug (from that pastebin):

Turns out there's hardware crypto acceleration on the DreamPlug's Marvell Kirkwood processor, via the mv_cesa Linux kernel module, but it's not supported by OpenSSL without some patches. I updated my Pastebin with the info below, having set it up thanks to the following posts:

http://www.altechnative.net/?p=174
http://www.newit.co.uk/forum/index.php?action=printpage;topic=2030.0

Here are the steps to make it work:

Assumptions and prerequisites:

- DreamPlug
- Debian Squeeze system
- GlobalScale stock (or other replacement-worthy) kernel
- build-essential, bzip2, devscripts, fakeroot & wget packages
- Boot partition (probably /dev/sda1) mounted on /boot
- Plenty of free space for sources

To get to this point, see: http://code.google.com/p/dreamplug/downloads/list

Run as root (n.b. you are trusting plugapps.com):

wget --directory-prefix=/usr/src http://download.gna.org/cryptodev-linux/cryptodev-linux-1.0.tar.gz
wget --directory-prefix=/usr/src http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.38.7.tar.bz2
wget --directory-prefix=/usr/src http://plugapps.com/mirror/with-linux/2.6.38/2.6.38.7/sheeva-2.6.38.7-Modules.tar.gz
wget --directory-prefix=/boot http://plugapps.com/mirror/with-linux/2.6.38/2.6.38.7/dream-2.6.38.7-uImage
wget --directory-prefix=/boot http://plugapps.com/mirror/with-linux/2.6.38/2.6.38.7/dream-2.6.38.7.config
wget --directory-prefix=/boot http://plugapps.com/mirror/with-linux/2.6.38/2.6.38.7/sheeva-2.6.38.7-System.map
tar -C / -x -v -z --no-same-owner --no-same-permissions -f /usr/src/sheeva-2.6.38.7-Modules.tar.gz
depmod -eF /boot/sheeva-2.6.38.7-System.map 2.6.38.7
tar -C /usr/src -x -v -j --no-same-owner --no-same-permissions -f /usr/src/linux-2.6.38.7.tar.bz2
cp /boot/dream-2.6.38.7.config /usr/src/linux-2.6.38.7/.config
tar -C /usr/src -x -v -z --no-same-owner --no-same-permissions -f /usr/src/cryptodev-linux-1.0.tar.gz

Reboot. In U-Boot, from the serial/JTAG console:

setenv mainlineLinux yes
setenv arcNumber 2659
printenv

Use `setenv _ENV_ _VALUE_` to change "uImage" to "dream-2.6.38.7-uImage". Now:

saveenv
reset

Let the system boot. Now, as root:

make -C /usr/src/linux-2.6.38.7 oldconfig
make -C /usr/src/linux-2.6.38.7 prepare
make -C /usr/src/linux-2.6.38.7

Watch for this output, near the top, and hit ^C once you've seen the second line:
  HOSTLD  scripts/mod/modpost
  HOSTCC  scripts/kallsyms
(All you need from this potentially lengthy `make` is modpost.) Continue:

rm /lib/modules/2.6.38.7/build
rm /lib/modules/2.6.38.7/source
ln -s /usr/src/linux-2.6.38.7 /lib/modules/2.6.38.7/build
ln -s /usr/src/linux-2.6.38.7 /lib/modules/2.6.38.7/source
make -C /usr/src/cryptodev-linux-1.0 install
depmod -eF /boot/sheeva-2.6.38.7-System.map 2.6.38.7
modprobe cryptodev

apt-get source openssl
apt-get build-dep openssl
sed -i '/^CONFARGS/s|$| -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DHASH_MAX_LEN=64|' /usr/src/openssl-0.9.8o/debian/rules
sed -i '1i\\' /usr/src/openssl-0.9.8o/debian/changelog
sed -i '1i\ -- James Renken <jrenken@sandwich.net>  Sat, 11 Jun 2011 01:13:00 -0400' /usr/src/openssl-0.9.8o/debian/changelog
sed -i '1i\\' /usr/src/openssl-0.9.8o/debian/changelog
sed -i '1i\ \ * Patched rules to compile with CRYPTODEV options' /usr/src/openssl-0.9.8o/debian/changelog
sed -i '1i\\' /usr/src/openssl-0.9.8o/debian/changelog
sed -i '1iopenssl (0.9.8o-4squeeze1+cryptodev) stable; urgency=low' /usr/src/openssl-0.9.8o/debian/changelog
cd /usr/src/openssl-0.9.8o ; debuild -us -uc -b
dpkg -i /usr/src/libssl0.9.8_0.9.8o-4squeeze1+cryptodev_armel.deb /usr/src/openssl_0.9.8o-4squeeze1+cryptodev_armel.deb

Results:

# uname -a
Linux dreamplug 2.6.38.7 #1 PREEMPT Sun May 22 00:23:53 MDT 2011 armv5tel GNU/Linux

# openssl engine
(dynamic) Dynamic engine loading support
(cryptodev) BSD cryptodev engine

# openssl speed -evp aes-128-cbc -engine cryptodev
engine "cryptodev" set.
Doing aes-128-cbc for 3s on 16 size blocks: 81432 aes-128-cbc's in 0.16s
Doing aes-128-cbc for 3s on 64 size blocks: 79173 aes-128-cbc's in 0.03s
Doing aes-128-cbc for 3s on 256 size blocks: 66949 aes-128-cbc's in 0.08s
Doing aes-128-cbc for 3s on 1024 size blocks: 40495 aes-128-cbc's in 0.03s
Doing aes-128-cbc for 3s on 8192 size blocks: 8300 aes-128-cbc's in 0.01s
OpenSSL 0.9.8o 01 Jun 2010
built on: Sat Jun 11 05:44:31 UTC 2011
options:bn(64,32) md2(int) rc4(ptr,int) des(idx,risc1,4,long) aes(partial) blowfish(idx) 
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DHASH_MAX_LEN=64 -DL_ENDIAN -DTERMIO -O2 -Wa,--noexecstack -g -Wall
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc       8143.20k   168902.40k   214236.80k  1382229.33k  6799360.00k

As of 0.9.8o in Debian Squeeze, OpenSSL doesn't include /dev/crypto acceleration support for AES192 or AES256 CBC, nor for SHA digests. There are some older patches for this, but they don't apply cleanly to this version.

http://repo.or.cz/w/cryptodev-linux.git/blob/HEAD:/extras/openssl-0.9.8l-cryptodev-aes256.patch
http://people.freebsd.org/~pjd/patches/eng_cryptodev.c.patch

comment:20 in reply to:  11 ; Changed 6 years ago by gilles

Replying to rransom:

An alternative that I trust less is OpenNTPD but it is already packaged:

openntpd

Why do you trust it less?

clockspeed was written by DJB, and is very unlikely to have security holes. clockspeed also appears to use less frequent network queries than NTP clients would, although it might not behave properly on a computer with CPU frequency scaling.

Just to set the record straight OpenNTPD is written by the same people who write OpenSSH (which you seem to trust). I may have misunderstood your comment about clockspeed but it seemed to imply OpenNTPD was less trustable *just* because DJB didn't write it, that seems a bit irrational. OpenNTPD has privileges separation, runs chrooted under an unprivileged user, has a secure design and no bad security history.

comment:21 in reply to:  17 ; Changed 6 years ago by gilles

Replying to cypherpunks:

An alternative that I trust less is OpenNTPD but it is already packaged:

openntpd

Why do you trust it less?

djb wrote one, who the hell knows about the other? :-) We absolutely must not use ISC software whatever we do.

The software is not written by ISC but by OpenBSD ... it just happens to be distributed under the ISC license which is even shorter than the BSD license.

comment:22 in reply to:  21 Changed 6 years ago by cypherpunks

Replying to gilles:

Replying to cypherpunks:

An alternative that I trust less is OpenNTPD but it is already packaged:

openntpd

Why do you trust it less?

djb wrote one, who the hell knows about the other? :-) We absolutely must not use ISC software whatever we do.

The software is not written by ISC but by OpenBSD ... it just happens to be distributed under the ISC license which is even shorter than the BSD license.

Actually, ISC software is written by ISC. I stated that we absolutely must not use ISC software; I was not saying that OpenNTPD was ISC software.

comment:23 in reply to:  20 Changed 6 years ago by cypherpunks

Replying to gilles:

Replying to rransom:

An alternative that I trust less is OpenNTPD but it is already packaged:

openntpd

Why do you trust it less?

clockspeed was written by DJB, and is very unlikely to have security holes. clockspeed also appears to use less frequent network queries than NTP clients would, although it might not behave properly on a computer with CPU frequency scaling.

Yep. Also, I think is probably better for an embedded client.

Just to set the record straight OpenNTPD is written by the same people who write OpenSSH (which you seem to trust). I may have misunderstood your comment about clockspeed but it seemed to imply OpenNTPD was less trustable *just* because DJB didn't write it, that seems a bit irrational. OpenNTPD has privileges separation, runs chrooted under an unprivileged user, has a secure design and no bad security history.

I trust OpenSSH within a very small window of attack surface. It is not perfect software and no person other than djb can even come close to writing near-perfect network security software. See qmail for an example.

OpenNTPD does have privilege separation, run with a chroot, run as a non-root user, and so on. I use it on some systems. I would still feel safer using djb software based on his total history of software development, I don't really think the history of OpenBSD or OpenSSH is as taint free as his. I don't think that's irrational.

With that said, I think OpenNTPD is probably fine, my personal preference would be to use djb's code if I did not have time to analysis or audit *either* of them.

comment:24 Changed 6 years ago by cypherpunks

In an ideal world, I'd like to find a dhcp client and server written in python, rather than the C implementation that ships with Debian. More ISC code, more attack surface...

comment:25 Changed 6 years ago by cypherpunks

This looks like a well tested python dhcpd that can store leases in SQLite:
http://code.google.com/p/staticdhcpd/

That seems promising and not dead code like Anemon (http://anemon.org/wiki/).

comment:26 Changed 6 years ago by cypherpunks

Anemon claims to have a python dhcp client but it doesn't really seem like a very lively project at this time.

comment:28 Changed 6 years ago by StrangeCharm

Cc: tortrac@… added

comment:29 in reply to:  17 ; Changed 6 years ago by runa

Replying to cypherpunks:

Replying to runa:

Replying to cypherpunks:

I propose that we ship the following debian packages:

http://packages.debian.org/squeeze/denyhosts
http://packages.debian.org/squeeze/openssh-server
http://packages.debian.org/squeeze/cron-apt

Sure, looks good.

I propose that we ship the following Tor Project packages and work to get them into Debian ASAP:

ttdnsd

I see that some work has already been done to package this for Debian (there's a Debian directory in the ttdnsd.git repository). What's the status of that?

We have packages for ttdnsd in deb.torproject.org; they're not uploaded to Debian.

Why not?

Also, I believe that tsocks (which ttdnsd depends on) is out of date and that we should use torsocks instead. Thoughts?

Yes, torsocks is safe, tsocks is not.

In that case, shouldn't ttdnsd be updated to use torsocks instead of tsocks?

We need to package a few things for this process to work.

clockspeed needs to be packaged:
http://cr.yp.to/clockspeed.html
http://thedjbway.b0llix.net/clocksd/index.html

We'd need to install daemontools for clockspeed and this is already supported on Debian.

An alternative that I trust less is OpenNTPD but it is already packaged:

openntpd

Why do you trust it less?

djb wrote one, who the hell knows about the other? :-) We absolutely must not use ISC software whatever we do.

Seems like I missed out on something; why can't we use ISC software (and what, on a standard Debian system, classifies as ISC software)?

We'll also need the most recent 0.2.3.x Tor release as a Debian package, specifically we need to build it with tor-fw-helper. This means that we need to package the upnp and natpmp shared libraries.

I assume weasel is the person to ask regarding Debian packages for 0.2.3.x. Do you want to package upnp and natpmp?

Want is a curious way to phrase it... :-)

I wonder if we should wait with shipping 0.2.3.x until it can be considered stable. The purpose of the Torouter is to provide a (cheap) consumer-level Internet router that is a tor bridge. Shipping with software that cannot be considered stable and/or hasn't been tested in the wild may not be a good idea.

comment:30 in reply to:  29 ; Changed 6 years ago by cypherpunks

Replying to runa:

Replying to cypherpunks:

Replying to runa:

Replying to cypherpunks:

I propose that we ship the following debian packages:

http://packages.debian.org/squeeze/denyhosts
http://packages.debian.org/squeeze/openssh-server
http://packages.debian.org/squeeze/cron-apt

Sure, looks good.

I propose that we ship the following Tor Project packages and work to get them into Debian ASAP:

ttdnsd

I see that some work has already been done to package this for Debian (there's a Debian directory in the ttdnsd.git repository). What's the status of that?

We have packages for ttdnsd in deb.torproject.org; they're not uploaded to Debian.

Why not?

I cannot upload on my own. The next version of ttdnsd will be uploading by me to deb.torproject.org and I'll ask helix or weasel to sponsor it.

Also, I believe that tsocks (which ttdnsd depends on) is out of date and that we should use torsocks instead. Thoughts?

Yes, torsocks is safe, tsocks is not.

In that case, shouldn't ttdnsd be updated to use torsocks instead of tsocks?

There has been a bit of work on this - it's not really necessary though, ttdnsd is one of the rare safe cases with tsocks.

We need to package a few things for this process to work.

clockspeed needs to be packaged:
http://cr.yp.to/clockspeed.html
http://thedjbway.b0llix.net/clocksd/index.html

We'd need to install daemontools for clockspeed and this is already supported on Debian.

An alternative that I trust less is OpenNTPD but it is already packaged:

openntpd

Why do you trust it less?

djb wrote one, who the hell knows about the other? :-) We absolutely must not use ISC software whatever we do.

Seems like I missed out on something; why can't we use ISC software (and what, on a standard Debian system, classifies as ISC software)?

ISC is a group of people that write software. They have the worst security track record of any group, probably ever. One of the authors in fact has the most security bugs ever for a single person. It is typically written without security in mind from the start and generally the purpose is to get something working. It's good for getting a protocol adopted but it's not good for anything we want to do. For example, not getting owned. :)

We'll also need the most recent 0.2.3.x Tor release as a Debian package, specifically we need to build it with tor-fw-helper. This means that we need to package the upnp and natpmp shared libraries.

I assume weasel is the person to ask regarding Debian packages for 0.2.3.x. Do you want to package upnp and natpmp?

Want is a curious way to phrase it... :-)

I wonder if we should wait with shipping 0.2.3.x until it can be considered stable. The purpose of the Torouter is to provide a (cheap) consumer-level Internet router that is a tor bridge. Shipping with software that cannot be considered stable and/or hasn't been tested in the wild may not be a good idea.

I think we've waited long enough and testing with 0.2.3.x should be fine. We're doing releases of it, we should consider it experimental which is of course the goal of the Torouter; it is an experiment. If we find it non-functional or that it is breaking, we should fix it. We need a UPnP and NATPMP client for these devices to work easily.

comment:31 Changed 6 years ago by zooko

Cc: zooko@… added

comment:32 in reply to:  30 ; Changed 6 years ago by rransom

Replying to cypherpunks:

Replying to runa:

I wonder if we should wait with shipping 0.2.3.x until it can be considered stable. The purpose of the Torouter is to provide a (cheap) consumer-level Internet router that is a tor bridge. Shipping with software that cannot be considered stable and/or hasn't been tested in the wild may not be a good idea.

I think we've waited long enough and testing with 0.2.3.x should be fine. We're doing releases of it, we should consider it experimental which is of course the goal of the Torouter; it is an experiment. If we find it non-functional or that it is breaking, we should fix it. We need a UPnP and NATPMP client for these devices to work easily.

Why do these devices need UPnP and NAT-PMP client support? It is very unlikely that any ISP which does not allow its customers to listen for TCP connections without a UPnP or NAT-PMP request would allow its customers to listen for them with such a request.

An UPnP or NAT-PMP server is more likely to be useful, but would need to be turned off by default.

We might need to deploy Tor 0.2.3.x on these devices anyway, if we go ahead with the plan in proposal 180 of requiring protocol obfuscators to interact with Tor, but deploying obfuscators on Torouter would require a software update anyway -- we currently have no protocol obfuscators that would remain unblocked for more than a day against a slightly competent attacker.

(By ‘slightly competent attacker’, I mean someone capable of checking a single box on the configuration panel of a typical censoring proxy device.)

comment:33 in reply to:  30 ; Changed 6 years ago by runa

Replying to cypherpunks:

Replying to runa:

I wonder if we should wait with shipping 0.2.3.x until it can be considered stable. The purpose of the Torouter is to provide a (cheap) consumer-level Internet router that is a tor bridge. Shipping with software that cannot be considered stable and/or hasn't been tested in the wild may not be a good idea.

I think we've waited long enough and testing with 0.2.3.x should be fine. We're doing releases of it, we should consider it experimental which is of course the goal of the Torouter; it is an experiment. If we find it non-functional or that it is breaking, we should fix it. We need a UPnP and NATPMP client for these devices to work easily.

As far as I know, Tor 0.2.3.x breaks every few days and shipping 0.2.2.x is much saner. The Torouter is an experiment in getting non-tech users to run bridges. I don't see how we need to complicate that with shipping an experimental version of Tor. There are enough people out there who can help test 0.2.3.x when it's ready for testing in the wild. And at some point we can also include it on the Torouter. I just don't think now is a good time. if anyone wants to want to convince me otherwise, go for it... :)

comment:34 in reply to:  32 Changed 6 years ago by ioerror

Replying to rransom:

Replying to cypherpunks:

Replying to runa:

I wonder if we should wait with shipping 0.2.3.x until it can be considered stable. The purpose of the Torouter is to provide a (cheap) consumer-level Internet router that is a tor bridge. Shipping with software that cannot be considered stable and/or hasn't been tested in the wild may not be a good idea.

I think we've waited long enough and testing with 0.2.3.x should be fine. We're doing releases of it, we should consider it experimental which is of course the goal of the Torouter; it is an experiment. If we find it non-functional or that it is breaking, we should fix it. We need a UPnP and NATPMP client for these devices to work easily.

Why do these devices need UPnP and NAT-PMP client support? It is very unlikely that any ISP which does not allow its customers to listen for TCP connections without a UPnP or NAT-PMP request would allow its customers to listen for them with such a request.

Huh? Every home router on the planet seems to have either NAT-PMP or UPnP support. Every Apple device has NAT-PMP on by default and it's the *only* way to map a port through their NAT devices. This is about punching holes in a NAT, it's not about binding to a port when you have a public IP address. I really doubt these boxes will have a public IP very often.

An UPnP or NAT-PMP server is more likely to be useful, but would need to be turned off by default.

Huh? Why?

We might need to deploy Tor 0.2.3.x on these devices anyway, if we go ahead with the plan in proposal 180 of requiring protocol obfuscators to interact with Tor, but deploying obfuscators on Torouter would require a software update anyway -- we currently have no protocol obfuscators that would remain unblocked for more than a day against a slightly competent attacker.

Indeed.

(By ‘slightly competent attacker’, I mean someone capable of checking a single box on the configuration panel of a typical censoring proxy device.)

Yeah, the bar is really low...

comment:35 in reply to:  33 ; Changed 6 years ago by ioerror

Replying to runa:

As far as I know, Tor 0.2.3.x breaks every few days and shipping 0.2.2.x is much saner. The Torouter is an experiment in getting non-tech users to run bridges. I don't see how we need to complicate that with shipping an experimental version of Tor. There are enough people out there who can help test 0.2.3.x when it's ready for testing in the wild. And at some point we can also include it on the Torouter. I just don't think now is a good time. if anyone wants to want to convince me otherwise, go for it... :)

How do you propose that we open ports in a NAT device without tor-fw-helper?

comment:36 Changed 6 years ago by ioerror

For various reasons - I've setup Debian Squeeze on my DreamPlug with a few stock packages just to get it running. I'm happy to say that Tor seems to function!

root@holoscanner:~# tor-resolve torproject.org
86.59.30.36

I installed the following packages to make a mini-Tor friendly router:

openssh-server
tor
ntp
pump

It looks like so:

root@holoscanner:~# lsof -ni
COMMAND   PID       USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
tor      9764 debian-tor    7u  IPv4   8521      0t0  TCP 127.0.0.1:9050 (LISTEN)
ntpd    10235        ntp   16u  IPv4   9356      0t0  UDP *:ntp 
ntpd    10235        ntp   17u  IPv4   9361      0t0  UDP 127.0.0.1:ntp 
ntpd    10235        ntp   18u  IPv4   9363      0t0  UDP 10.0.2.111:ntp 
pump    10281       root    0u  IPv4   9698      0t0  TCP *:bootpc (LISTEN)
sshd    10323       root    3u  IPv4   9807      0t0  TCP *:ssh

comment:37 Changed 6 years ago by ioerror

I also added this to my torrc:

AvoidDiskWrites 1

comment:38 Changed 6 years ago by ioerror

I've also installed cron-apt to ensure that packages are updated without the user; we already trust the package manager upstream and this at keeps users patched.

comment:39 in reply to:  35 ; Changed 6 years ago by runa

Replying to ioerror:

Replying to runa:

As far as I know, Tor 0.2.3.x breaks every few days and shipping 0.2.2.x is much saner. The Torouter is an experiment in getting non-tech users to run bridges. I don't see how we need to complicate that with shipping an experimental version of Tor. There are enough people out there who can help test 0.2.3.x when it's ready for testing in the wild. And at some point we can also include it on the Torouter. I just don't think now is a good time. if anyone wants to want to convince me otherwise, go for it... :)

How do you propose that we open ports in a NAT device without tor-fw-helper?

Users will have to open ports in their NAT devices manually, which is what they have done so far (and will have to do with the B3 as well). I think it would be great to ship with tor-fw-helper, but I am worried that 0.2.3 is too unstable for non-tech users.

comment:40 in reply to:  39 Changed 6 years ago by ioerror

Replying to runa:

Replying to ioerror:

How do you propose that we open ports in a NAT device without tor-fw-helper?

Users will have to open ports in their NAT devices manually, which is what they have done so far (and will have to do with the B3 as well). I think it would be great to ship with tor-fw-helper, but I am worried that 0.2.3 is too unstable for non-tech users.

I think these concerns are unfounded and I see no technical reason to not use 0.2.3.x and at least one major technical reason to do so.

What makes it unstable? I've never crashed a 0.2.3.x Tor relay or bridge.

comment:41 Changed 6 years ago by ioerror

I've now setup a Torouter that is pretty functional. I'll try to outline this at a high level and then show some service details that will make for interesting discussion.

The Torouter I'm using is a DreamPlug with no modifications other than a stock Debian install - at the moment, I'm using the Marvell/DreamPlug stock kernel because it's a PITA to change it. I'm hopeful to change the kernel and to integrate grsec into the mix in the very near future. I need a different ticket for this work and will update this ticket when I have it. That will take a lot of work, I suspect.

The router has two ethernet ports - the first one at the top of the device is eth0 and the second one near the bottom of the device is eth1. eth0 may be plugged into any network that connects to the internet. eth1 may be plugged into a switch or directly into another computer.

When eth0 is brought up, tor (0.2.3.x) is started and configured as a bridge. Tor attempts to automatically punch a hole in any upstream NAT device with tor-fw-helper and does so with the NAT-PMP and UPnP client protocols. Additionally, when eth0 is brought up, uap0 is brought up as a wireless access point.

uap0 shares a normal 802.11 wireless network in infrastructure mode with the ESSID of "torproject" - It is an open wireless network that provides dhcp for any client that joins the network. It performs DNS resolution with Tor's DNSPort and all traffic is transparently routed to the internet through the Tor client on the Torouter itself. This network drops all non-TCP traffic and provides Tor access for devices such as the Chrome CR-48 or phones that do not yet support a native Tor client.

eth1 provides normal internet access - it acts as a NAT behind eth0, it forwards packets, it offers dns resolution and of course dhcp service. A client or up to 244 clients (according to the current dhcp configuration) merely needs to plug into a switch fabric or directly into the Torouter to receive internet service.

This setup seems to satisify nearly every requirement I've heard as something we'd desire. This device may be used as a home router (via eth1 and the NAT), a wifi access point, a Tor bridge and even a Tor relay if reconfigured. It requires no setup by the user and automatically enables all of these features by merely plugging into a single internet enabled ethernet cord and providing power.

The specific services may need to be reconfigured or even re-written. However their specific purpose seems to be well defined - we simply need to think about the security boundaries and the scope of each thing we enable.

Here's a list of services listening at the moment:

root@torouter:~# lsof -ni
COMMAND  PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pump     962        root    0u  IPv4   1473      0t0  TCP *:bootpc (LISTEN)
udhcpd  1016        root    5u  IPv4   1539      0t0  UDP *:bootps 
exim4   1405 Debian-exim    3u  IPv4   1845      0t0  TCP 127.0.0.1:smtp (LISTEN)
exim4   1405 Debian-exim    4u  IPv6   1846      0t0  TCP [::1]:smtp (LISTEN)
ntpd    1421         ntp   16u  IPv4   1877      0t0  UDP *:ntp 
ntpd    1421         ntp   17u  IPv6   1879      0t0  UDP *:ntp 
ntpd    1421         ntp   18u  IPv4   1889      0t0  UDP 127.0.0.1:ntp 
ntpd    1421         ntp   19u  IPv4   1891      0t0  UDP 10.0.2.102:ntp 
ntpd    1421         ntp   20u  IPv4   1893      0t0  UDP 172.16.23.1:ntp 
ntpd    1421         ntp   21u  IPv6   1895      0t0  UDP [::1]:ntp 
ntpd    1421         ntp   22u  IPv6   2006      0t0  UDP [fe80::f2ad:4eff:fe00:7aab]:ntp 
ntpd    1421         ntp   23u  IPv4   2927      0t0  UDP 10.23.42.1:ntp 
ntpd    1421         ntp   24u  IPv6   2929      0t0  UDP [fe80::f2ad:4eff:fe00:7aac]:ntp 
tor     1436  debian-tor    7u  IPv4   1942      0t0  TCP *:9001 (LISTEN)
tor     1436  debian-tor    8u  IPv4   1943      0t0  TCP 127.0.0.1:9050 (LISTEN)
tor     1436  debian-tor    9u  IPv4   1944      0t0  TCP 172.16.23.1:9040 (LISTEN)
tor     1436  debian-tor   10u  IPv4   1945      0t0  UDP 172.16.23.1:domain 
tor     1436  debian-tor   14u  IPv4   2012      0t0  UDP 10.0.2.102:53980->216.39.139.193:domain 
tor     1436  debian-tor   15u  IPv4   2013      0t0  UDP 10.0.2.102:33898->8.8.8.8:domain 
tor     1436  debian-tor   18u  IPv4   2105      0t0  TCP 10.0.2.102:52788->149.9.0.59:9001 (ESTABLISHED)
tor     1436  debian-tor   19u  IPv4   2106      0t0  TCP 10.0.2.102:59918->38.229.70.42:www (ESTABLISHED)
sshd    1460        root    3r  IPv4   2045      0t0  TCP 10.0.2.102:ssh->10.0.2.110:52163 (ESTABLISHED)
sshd    1549        root    3r  IPv4   2315      0t0  TCP 10.0.2.102:ssh->10.0.2.110:48684 (ESTABLISHED)
sshd    1971        root    3u  IPv4   3254      0t0  TCP *:ssh (LISTEN)
sshd    1971        root    4u  IPv6   3256      0t0  TCP *:ssh (LISTEN)
dnsmasq 2318     dnsmasq    5u  IPv4   7844      0t0  UDP *:bootps 
dnsmasq 2318     dnsmasq    6u  IPv6   7852      0t0  TCP [fe80::f2ad:4eff:fe00:7aac]:domain (LISTEN)
dnsmasq 2318     dnsmasq    7u  IPv6   7853      0t0  UDP [fe80::f2ad:4eff:fe00:7aac]:domain 
dnsmasq 2318     dnsmasq    8u  IPv6   7854      0t0  TCP [::1]:domain (LISTEN)
dnsmasq 2318     dnsmasq    9u  IPv6   7855      0t0  UDP [::1]:domain 
dnsmasq 2318     dnsmasq   10u  IPv4   7856      0t0  TCP 10.23.42.1:domain (LISTEN)
dnsmasq 2318     dnsmasq   11u  IPv4   7857      0t0  UDP 10.23.42.1:domain 
dnsmasq 2318     dnsmasq   12u  IPv4   7858      0t0  TCP 127.0.0.1:domain (LISTEN)
dnsmasq 2318     dnsmasq   13u  IPv4   7859      0t0  UDP 127.0.0.1:domain 

comment:42 Changed 6 years ago by ioerror

I've opened a bug for discussion on the kernel issues: #3447

comment:43 Changed 6 years ago by ioerror

Here's a list of all the processes running in the above mentioned configuration:

root@torouter:~# ps auxwwww
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1   2016   696 ?        Ss   Jun21   0:01 init [2]  
root         2  0.0  0.0      0     0 ?        S    Jun21   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    Jun21   0:00 [ksoftirqd/0]
root         4  0.0  0.0      0     0 ?        S    Jun21   0:00 [watchdog/0]
root         5  0.0  0.0      0     0 ?        S    Jun21   0:00 [events/0]
root         6  0.0  0.0      0     0 ?        S    Jun21   0:00 [khelper]
root         9  0.0  0.0      0     0 ?        S    Jun21   0:00 [async/mgr]
root       132  0.0  0.0      0     0 ?        S    Jun21   0:00 [sync_supers]
root       134  0.0  0.0      0     0 ?        S    Jun21   0:00 [bdi-default]
root       136  0.0  0.0      0     0 ?        S    Jun21   0:00 [kblockd/0]
root       142  0.0  0.0      0     0 ?        S    Jun21   0:00 [ata/0]
root       143  0.0  0.0      0     0 ?        S    Jun21   0:00 [ata_aux]
root       147  0.0  0.0      0     0 ?        S    Jun21   0:00 [ksuspend_usbd]
root       152  0.0  0.0      0     0 ?        S    Jun21   0:00 [khubd]
root       155  0.0  0.0      0     0 ?        S    Jun21   0:00 [kseriod]
root       158  0.0  0.0      0     0 ?        S    Jun21   0:00 [kmmcd]
root       168  0.0  0.0      0     0 ?        S    Jun21   0:00 [cfg80211]
root       179  0.0  0.0      0     0 ?        S    Jun21   0:00 [rpciod/0]
root       187  0.0  0.0      0     0 ?        S    Jun21   0:00 [khungtaskd]
root       188  0.0  0.0      0     0 ?        S    Jun21   0:00 [kswapd0]
root       233  0.0  0.0      0     0 ?        S    Jun21   0:00 [aio/0]
root       246  0.0  0.0      0     0 ?        S    Jun21   0:00 [nfsiod]
root       254  0.0  0.0      0     0 ?        S    Jun21   0:00 [jfsIO]
root       255  0.0  0.0      0     0 ?        S    Jun21   0:00 [jfsCommit]
root       256  0.0  0.0      0     0 ?        S    Jun21   0:00 [jfsSync]
root       257  0.0  0.0      0     0 ?        S    Jun21   0:00 [crypto/0]
root       432  0.0  0.0      0     0 ?        S    Jun21   0:00 [mtdblockd]
root       439  0.0  0.0      0     0 ?        S    Jun21   0:00 [orion_spi]
root       529  0.0  0.0      0     0 ?        S    Jun21   0:00 [usbhid_resumer]
root       544  0.0  0.0      0     0 ?        S    Jun21   0:00 [scsi_eh_0]
root       545  0.0  0.0      0     0 ?        S    Jun21   0:00 [usb-storage]
root       577  0.0  0.0      0     0 ?        S    Jun21   0:00 [flush-8:0]
root       578  0.0  0.0      0     0 ?        S    Jun21   0:00 [kjournald]
root       619  0.0  0.1   2300   692 ?        S<s  Jun21   0:00 udevd --daemon
root       653  0.0  0.0      0     0 ?        S    Jun21   0:00 [mv_crypto]
root       701  0.0  0.1   2296   628 ?        S<   Jun21   0:00 udevd --daemon
root       710  0.0  0.1   2296   616 ?        S<   Jun21   0:00 udevd --daemon
root       724  0.0  0.0      0     0 ?        S    Jun21   0:00 [scsi_eh_1]
root       738  0.0  0.0      0     0 ?        S    Jun21   0:00 [bluetooth]
root       759  0.0  0.0      0     0 ?        S    Jun21   0:00 [uap_main_servic]
root       760  0.0  0.0      0     0 ?        S    Jun21   0:00 [ksdioirqd/mmc0]
root       962  0.0  0.1   1924   604 ?        Ss   Jun21   0:00 pump -i eth0
root      1016  0.0  0.0   2736   480 ?        Ss   Jun21   0:00 /usr/sbin/udhcpd
daemon    1109  0.0  0.0   2260   424 ?        Ss   Jun21   0:00 /usr/sbin/atd
root      1153  0.0  0.1   2416   872 ?        Ss   Jun21   0:00 /usr/sbin/cron
105       1158  0.0  0.1   2776   980 ?        Ss   Jun21   0:00 /usr/bin/dbus-daemon --system
102       1405  0.0  0.1   7268   948 ?        Ss   Jun21   0:00 /usr/sbin/exim4 -bd -q30m
ntp       1421  0.0  0.3   5368  1948 ?        Ss   Jun21   0:03 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 104:106
103       1436  0.2  7.2  48956 37308 ?        Sl   Jun21   2:35 /usr/local/bin/tor
root      1447  0.0  0.1   1640   528 tty1     Ss+  Jun21   0:00 /sbin/getty 38400 tty1
root      1448  0.0  0.1   1640   528 tty2     Ss+  Jun21   0:00 /sbin/getty 38400 tty2
root      1449  0.0  0.1   1640   528 tty3     Ss+  Jun21   0:00 /sbin/getty 38400 tty3
root      1450  0.0  0.1   1640   528 tty4     Ss+  Jun21   0:00 /sbin/getty 38400 tty4
root      1451  0.0  0.1   1640   528 tty5     Ss+  Jun21   0:00 /sbin/getty 38400 tty5
root      1452  0.0  0.1   1640   528 tty6     Ss+  Jun21   0:00 /sbin/getty 38400 tty6
root      1453  0.0  0.2   3096  1268 ttyS0    Ss   Jun21   0:00 /bin/login --     
root      1454  0.0  0.3   3228  1820 ttyS0    S+   Jun21   0:00 -bash
root      1460  0.0  0.5   8968  2792 ?        Ss   Jun21   0:00 sshd: root@pts/0 
root      1462  0.0  0.3   3152  1708 pts/0    Ss   Jun21   0:00 -bash
root      1549  0.0  0.5   8968  2792 ?        Ss   Jun21   0:00 sshd: root@pts/1 
root      1551  0.0  0.3   3144  1704 pts/1    Ss+  Jun21   0:00 -bash
root      1971  0.0  0.1   5820   976 ?        Ss   Jun21   0:00 /usr/sbin/sshd
dnsmasq   2318  0.0  0.1   2748   872 ?        S    Jun21   0:00 /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new

I suspect we can lower a lot of overhead with simple things such as re-configuring getty to only listen on the tty devices we actually use, removing dbus if we don't need it, removing exim4 and likely by choosing a single dhcp server, rather than running two. I think that http://code.google.com/p/staticdhcpd/ is probably a good bet...

comment:44 Changed 6 years ago by ioerror

I'm also not very keen on the number of services that are running as root but I'm not sure of the best way to change these things without upsetting the Debian ecosystem...

comment:45 Changed 6 years ago by ioerror

This seems to be a good bug about replacing the NTP server:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593429

comment:46 Changed 6 years ago by ioerror

If we use dnsmasq for anything long term, it's worth noting the following:

09:45 < rransom> Does it use random UDP ports for its DNS client functionality?
...
09:47 < ioerror_>    now uses a new, randomly selected, port for each query.

comment:47 Changed 6 years ago by ioerror

I removed dbus and Exim4 - I've noticed no adverse issues.

comment:48 Changed 6 years ago by ioerror

I also reconfigured /etc/inittab to remove the following lines:

2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

That leaves us with tty1 - though I don't think we need it as we only use ttyS0 for the UART/JATG serial connection.

comment:49 Changed 6 years ago by ioerror

I also removed udhcpd as it runs as root and generally doesn't seem to be everything that we'd like in a dhcpd while we evaluate the python solution.

comment:50 Changed 6 years ago by ioerror

When I removed exim4, I removed:

exim4-base exim4-config exim4-daemon-light

comment:51 in reply to:  41 Changed 6 years ago by rransom

Replying to ioerror:

The router has two ethernet ports - the first one at the top of the device is eth0 and the second one near the bottom of the device is eth1. eth0 may be plugged into any network that connects to the internet. eth1 may be plugged into a switch or directly into another computer.

This is a minor issue, but I would suggest putting the LAN side on ‘top’ of the device and the WAN side on the ‘bottom’, unless the Dreamplug ships with “LAN” and “WAN” (or similar) markings. In either case, ensuring that the two Ethernet ports are clearly labeled is more important.

comment:52 in reply to:  48 Changed 6 years ago by runa

Replying to ioerror:

I also reconfigured /etc/inittab to remove the following lines:

2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

That leaves us with tty1 - though I don't think we need it as we only use ttyS0 for the UART/JATG serial connection.

You're right, we don't need tty1.

comment:53 in reply to:  49 Changed 6 years ago by runa

Replying to ioerror:

I also removed udhcpd as it runs as root and generally doesn't seem to be everything that we'd like in a dhcpd while we evaluate the python solution.

I still don't understand why we can't use the one that ships with Debian. I've asked earlier in this thread somewhere, but can't see an answer. I believe it has something to do with ISC software?

comment:54 in reply to:  50 Changed 6 years ago by runa

Replying to ioerror:

When I removed exim4, I removed:

exim4-base exim4-config exim4-daemon-light

You might want to take a look through dpkg --get-selections and see if there are more packages worth taking out.

comment:55 Changed 6 years ago by rransom

We will need to ship a NAT-punching tool in the Torouter after all -- home Internet modems with built-in NAT functionality are far more common than I thought. But I still think shipping 0.2.3.x is not going to be a good idea for the next few months, so we should consider splitting tor-fw-helper out of the Tor source tree and shipping it as a completely separate package.

We may need to have a script (other than Tor) automatically select a good port for the Tor bridge, in case the user is running something else (e.g. Skype) that grabs port 443. I think that also argues for using tor-fw-helper separately from Tor, even with 0.2.3.x.

comment:56 in reply to:  55 Changed 6 years ago by ioerror

Replying to rransom:

We will need to ship a NAT-punching tool in the Torouter after all -- home Internet modems with built-in NAT functionality are far more common than I thought. But I still think shipping 0.2.3.x is not going to be a good idea for the next few months, so we should consider splitting tor-fw-helper out of the Tor source tree and shipping it as a completely separate package.

This is possible and this is what I meant when I suggested back-porting tor-fw-helper itself on irc. Perhaps this was confusing because tor-fw-helper also has the hooks inside of Tor that launch it? If we just back-port the tool itself, it's really quite standalone, I think.

We may need to have a script (other than Tor) automatically select a good port for the Tor bridge, in case the user is running something else (e.g. Skype) that grabs port 443. I think that also argues for using tor-fw-helper separately from Tor, even with 0.2.3.x.

Arma describes this as 'the real ORPort auto' - that is - something that randomly chooses a port, tests if it's open, launches tor-fw-helper, confirms that everything is working and so on.

comment:57 Changed 6 years ago by ioerror

Here's my current config that nearly runs all services without root:

COMMAND  PID       USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pump     959       root    0u  IPv4   1425      0t0  TCP *:bootpc (LISTEN)
dnsmasq 1044    dnsmasq    5u  IPv4   1514      0t0  UDP *:bootps 
dnsmasq 1044    dnsmasq    6u  IPv4   1520      0t0  TCP 172.16.23.1:domain (LISTEN)
dnsmasq 1044    dnsmasq    7u  IPv4   1521      0t0  UDP 172.16.23.1:domain 
dnsmasq 1044    dnsmasq    8u  IPv4   1522      0t0  TCP 10.23.42.1:domain (LISTEN)
dnsmasq 1044    dnsmasq    9u  IPv4   1523      0t0  UDP 10.23.42.1:domain 
dnsmasq 1044    dnsmasq   10u  IPv4   1524      0t0  TCP 127.0.0.1:domain (LISTEN)
dnsmasq 1044    dnsmasq   11u  IPv4   1525      0t0  UDP 127.0.0.1:domain 
ntpd    1177        ntp   16u  IPv4   1669      0t0  UDP *:ntp 
ntpd    1177        ntp   17u  IPv6   1671      0t0  UDP *:ntp 
ntpd    1177        ntp   18u  IPv4   1682      0t0  UDP 127.0.0.1:ntp 
ntpd    1177        ntp   19u  IPv4   1684      0t0  UDP 10.0.2.102:ntp 
ntpd    1177        ntp   20u  IPv4   1686      0t0  UDP 10.23.42.1:ntp 
ntpd    1177        ntp   21u  IPv4   1688      0t0  UDP 172.16.23.1:ntp 
ntpd    1177        ntp   22u  IPv6   1690      0t0  UDP [::1]:ntp 
ntpd    1177        ntp   23u  IPv6   1767      0t0  UDP [fe80::f2ad:4eff:fe00:7aac]:ntp 
ntpd    1177        ntp   24u  IPv6   1769      0t0  UDP [fe80::f2ad:4eff:fe00:7aab]:ntp 
sshd    1188       root    3u  IPv4   1715      0t0  TCP *:ssh (LISTEN)
sshd    1188       root    4u  IPv6   1717      0t0  TCP *:ssh (LISTEN)
tor     1194 debian-tor    7u  IPv4   1726      0t0  TCP *:9001 (LISTEN)
tor     1194 debian-tor    8u  IPv4   1727      0t0  TCP 127.0.0.1:9050 (LISTEN)
tor     1194 debian-tor    9u  IPv4   1728      0t0  TCP 172.16.23.1:9040 (LISTEN)
tor     1194 debian-tor   10u  IPv4   1729      0t0  UDP 172.16.23.1:domain 
tor     1194 debian-tor   14u  IPv4   1749      0t0  UDP 10.0.2.102:49953->216.39.139.193:domain 
tor     1194 debian-tor   15u  IPv4   1750      0t0  UDP 10.0.2.102:58581->8.8.8.8:domain 
tor     1194 debian-tor   17u  IPv4   5566      0t0  TCP 10.0.2.102:9001->82.94.251.203:51473 (ESTABLISHED)
tor     1194 debian-tor   18u  IPv4   1816      0t0  TCP 10.0.2.102:34650->184.105.231.11:https (ESTABLISHED)
tor     1194 debian-tor   19u  IPv4   1817      0t0  TCP 10.0.2.102:60306->149.9.0.59:9001 (ESTABLISHED)
tor     1194 debian-tor   20u  IPv4   1818      0t0  TCP 10.0.2.102:58241->38.229.70.42:www (ESTABLISHED)
sshd    1207       root    3r  IPv4   1789      0t0  TCP 10.0.2.102:ssh->10.0.2.110:49818 (ESTABLISHED)

And here's my process list:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1   2016   696 ?        Ss   06:39   0:01 init [2]  
root         2  0.0  0.0      0     0 ?        S    06:39   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    06:39   0:00 [ksoftirqd/0]
root         4  0.0  0.0      0     0 ?        S    06:39   0:00 [watchdog/0]
root         5  0.0  0.0      0     0 ?        S    06:39   0:00 [events/0]
root         6  0.0  0.0      0     0 ?        S    06:39   0:00 [khelper]
root         9  0.0  0.0      0     0 ?        S    06:39   0:00 [async/mgr]
root       132  0.0  0.0      0     0 ?        S    06:39   0:00 [sync_supers]
root       134  0.0  0.0      0     0 ?        S    06:39   0:00 [bdi-default]
root       136  0.0  0.0      0     0 ?        S    06:39   0:00 [kblockd/0]
root       142  0.0  0.0      0     0 ?        S    06:39   0:00 [ata/0]
root       143  0.0  0.0      0     0 ?        S    06:39   0:00 [ata_aux]
root       147  0.0  0.0      0     0 ?        S    06:39   0:00 [ksuspend_usbd]
root       152  0.0  0.0      0     0 ?        S    06:39   0:00 [khubd]
root       155  0.0  0.0      0     0 ?        S    06:39   0:00 [kseriod]
root       158  0.0  0.0      0     0 ?        S    06:39   0:00 [kmmcd]
root       168  0.0  0.0      0     0 ?        S    06:39   0:00 [cfg80211]
root       179  0.0  0.0      0     0 ?        S    06:39   0:00 [rpciod/0]
root       187  0.0  0.0      0     0 ?        S    06:39   0:00 [khungtaskd]
root       188  0.0  0.0      0     0 ?        S    06:39   0:00 [kswapd0]
root       233  0.0  0.0      0     0 ?        S    06:39   0:00 [aio/0]
root       246  0.0  0.0      0     0 ?        S    06:39   0:00 [nfsiod]
root       254  0.0  0.0      0     0 ?        S    06:39   0:00 [jfsIO]
root       255  0.0  0.0      0     0 ?        S    06:39   0:00 [jfsCommit]
root       256  0.0  0.0      0     0 ?        S    06:39   0:00 [jfsSync]
root       257  0.0  0.0      0     0 ?        S    06:39   0:00 [crypto/0]
root       432  0.0  0.0      0     0 ?        S    06:39   0:00 [mtdblockd]
root       439  0.0  0.0      0     0 ?        S    06:39   0:00 [orion_spi]
root       529  0.0  0.0      0     0 ?        S    06:39   0:00 [usbhid_resumer]
root       544  0.0  0.0      0     0 ?        S    06:39   0:00 [scsi_eh_0]
root       545  0.0  0.0      0     0 ?        S    06:39   0:00 [usb-storage]
root       577  0.0  0.0      0     0 ?        S    06:39   0:00 [flush-8:0]
root       578  0.0  0.0      0     0 ?        S    06:39   0:00 [kjournald]
root       619  0.0  0.1   2300   688 ?        S<s  06:39   0:00 udevd --daemon
root       658  0.0  0.0      0     0 ?        S    06:39   0:00 [mv_crypto]
root       707  0.0  0.1   2296   616 ?        S<   06:39   0:00 udevd --daemon
root       708  0.0  0.1   2296   604 ?        S<   06:39   0:00 udevd --daemon
root       727  0.0  0.0      0     0 ?        S    06:39   0:00 [scsi_eh_1]
root       735  0.0  0.0      0     0 ?        S    06:39   0:00 [bluetooth]
root       756  0.0  0.0      0     0 ?        S    06:39   0:00 [uap_main_servic]
root       757  0.0  0.0      0     0 ?        S    06:39   0:00 [ksdioirqd/mmc0]
root       959  0.0  0.1   1924   604 ?        Ss   06:39   0:00 pump -i eth0
dnsmasq   1044  0.0  0.1   2748   876 ?        S    06:39   0:00 /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-d
daemon    1117  0.0  0.0   2260   424 ?        Ss   06:40   0:00 /usr/sbin/atd
root      1164  0.0  0.1   2416   872 ?        Ss   06:40   0:00 /usr/sbin/cron
ntp       1177  0.0  0.3   5368  1948 ?        Ss   06:40   0:02 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 104:106
root      1188  0.0  0.1   5820   976 ?        Ss   06:40   0:00 /usr/sbin/sshd
103       1194  0.4  8.8  57308 45660 ?        Sl   06:40   2:41 /usr/local/bin/tor
root      1204  0.0  0.1   1640   528 tty1     Ss+  06:40   0:00 /sbin/getty 38400 tty1
root      1205  0.0  0.1   1640   532 ttyS0    Ss+  06:40   0:00 /sbin/getty -L ttyS0 115200 linux
root      1207  0.0  0.5   9044  2880 ?        Ss   06:40   0:00 sshd: root@pts/0 
root      1210  0.0  0.3   3140  1704 pts/0    Ss   06:40   0:00 -bash

comment:58 Changed 6 years ago by ioerror

In an ideal world, I'd suggest we may want to investigate finding a way for pump to drop privs or to replace pump with something written in a safe language. Additionally, I'd like to configure OpenSSH to only listen on eth1 - this means that there would only be three services on eth0 - a dhcp client, the ntp client, and Tor itself.

I'd like to replace the ntp client with openntpd as there appears to be no safe python ntp client. This is a pretty good example of what we'd need in python for ntp:
http://code.activestate.com/recipes/117211-simple-very-sntp-client/

So all in all, I think we could probably replace both the ntp client and the dhcp client with something safe but it wouldn't be well tested for a while, obviously.

comment:59 Changed 6 years ago by ioerror

What do we want to do about ipv6? It seems like we should probably disable it on uap0 - I'm unclear on what we should do about eth0 or eth1.

The ipv6 code is rumored to have lots of security concerns, I've seen a bit and I think more is likely. Should we care about ipv6 in our very first tests? Will we have any ipv6 testing users out of the box in our first round?

comment:60 Changed 6 years ago by ioerror

Here's the ipv6 disable info: http://wiki.debian.org/DebianIPv6#In_squeeze

comment:61 in reply to:  59 ; Changed 6 years ago by runa

Replying to ioerror:

What do we want to do about ipv6? It seems like we should probably disable it on uap0 - I'm unclear on what we should do about eth0 or eth1.

The ipv6 code is rumored to have lots of security concerns, I've seen a bit and I think more is likely. Should we care about ipv6 in our very first tests? Will we have any ipv6 testing users out of the box in our first round?

I say we ignore ipv6 for the first round of testing. We can always include it later on, in v2 of the Torouter or something.

comment:62 in reply to:  61 Changed 6 years ago by ioerror

Replying to runa:

I say we ignore ipv6 for the first round of testing. We can always include it later on, in v2 of the Torouter or something.

It is on by default - does that mean we should disable it?

comment:63 Changed 6 years ago by ioerror

Roger points out that Mike once had some good QoS scripts - what better place to use them? Where are they these days?

comment:64 in reply to:  63 ; Changed 6 years ago by rransom

Replying to ioerror:

Roger points out that Mike once had some good QoS scripts - what better place to use them? Where are they these days?

Would those scripts result in QoS markings on the bridge's TCP packets?

comment:65 in reply to:  64 Changed 6 years ago by ioerror

Replying to rransom:

Replying to ioerror:

Roger points out that Mike once had some good QoS scripts - what better place to use them? Where are they these days?

Would those scripts result in QoS markings on the bridge's TCP packets?

Not as far as I understand them - it would simply ensure that the bridge packets are de-prioritized from other tcp traffic, say on the NAT via eth1 -> eth0.

comment:66 Changed 6 years ago by ioerror

I did disable ipv6 like so:

echo net.ipv6.conf.all.disable_ipv6=1 > /etc/sysctl.d/disableipv6.conf

I added AddressFamily inet to sshd_config.

comment:67 Changed 6 years ago by ioerror

I was thinking and talking with atagar, I realized that we have a good Tor UI for torouter that we hadn't discussed, tor-arm!

apt-get install tor-arm
zcat /usr/share/doc/tor-arm/armrc.sample.gz > ~/.armrc

I configured Tor like so:

ControlPort 9051
ControlListenAddress 127.0.0.1:9051
CookieAuthentication 1

I reconfigured arm like so:

root@torouter:~# cat .armrc |head
# Startup options
startup.cookie

Now I have a Tor controller on the Torouter that could easily be started at boot time in a screen session. A user could login to the machine and attach to the shared screen to see the current stats - this would make it easy to view stats and to configure it.

Thoughts atagar?

comment:68 Changed 6 years ago by ioerror

Please comment on #3453 if you've read this far...

comment:69 Changed 6 years ago by ioerror

For ipv6, I also did this:

root@torouter:~# cat /etc/hosts
127.0.0.1	localhost

comment:70 Changed 6 years ago by atagar

Great, I'll be looking into the deb installer changes we discussed on irc after this release and if there's anything else I can do to better accommodate the torouter then let me know. :)

Btw, a "startup.cookie" option shouldn't be required unless this is a very old version of arm. It uses the PROTOCOLINFO response to automatically detect that it needs to do cookie auth.

comment:71 in reply to:  41 ; Changed 6 years ago by nmeagent

Replying to ioerror:

Two quick ideas/comments to consider:

(1) Random plausible MAC address(es) for eth0 at least and possibly the other interfaces prior to bringing them up. By plausible I mean chosen from a set of MAC blocks for existing router-esque devices by common vendors that wouldn't be out of the ordinary on the target networks. It likely isn't trivial to compile a complete list of such, but a sampling of MACs by off-the-shelf devices might do initially.

(2) It might be safer to set a default ESSID that is more innocuous than 'torproject'. Informed local 'authorities' may keep an eye out for this ESSID by various means and its presence could draw unwanted attention and possibly place the user(s) in danger (depending on the severity of the local situation). You could select a default ESSID based on the random MAC from (1), e.g. 'Linksys' if you happened to end up in the appropriate Linksys block of MACs. That's probably more work than it's worth, however, so may be best to instead select something ridiculously general like 'router' and let the user change it if they like.

comment:72 Changed 6 years ago by ioerror

Ok, I'm convinced that pump is probably not such a hot dhcp client. I guess I'll report the bug and report back with a CVE...

comment:73 in reply to:  71 ; Changed 6 years ago by rransom

Replying to nmeagent:

Replying to ioerror:

Two quick ideas/comments to consider:

(1) Random plausible MAC address(es) for eth0 at least and possibly the other interfaces prior to bringing them up. By plausible I mean chosen from a set of MAC blocks for existing router-esque devices by common vendors that wouldn't be out of the ordinary on the target networks. It likely isn't trivial to compile a complete list of such, but a sampling of MACs by off-the-shelf devices might do initially.

(2) It might be safer to set a default ESSID that is more innocuous than 'torproject'. Informed local 'authorities' may keep an eye out for this ESSID by various means and its presence could draw unwanted attention and possibly place the user(s) in danger (depending on the severity of the local situation). You could select a default ESSID based on the random MAC from (1), e.g. 'Linksys' if you happened to end up in the appropriate Linksys block of MACs. That's probably more work than it's worth, however, so may be best to instead select something ridiculously general like 'router' and let the user change it if they like.

The Torouter is intended to be deployed in countries that do not censor the Internet.

comment:74 in reply to:  73 Changed 6 years ago by ioerror

Replying to rransom:

The Torouter is intended to be deployed in countries that do not censor the Internet.

That is not entirely true. There are lots of countries where internet censorship is prevalent and we hope to have users deploy Torouters - the US for example, Denmark, Ireland, Egypt, and so on.

comment:75 Changed 6 years ago by ioerror

Some possible questions worth asking - originally from the wiki but in need of real discussion:

  • How can we fix Tor to work on systems with limited disk space? See #2334.
  • Do we want one Tor process for bridging and one for the transparent Tor wifi network? Please see: doc/Torouter/OpenWRT_setup_notes
  • Do we want one hardware platform or a more generic ready to use image for many systems?
  • What is the perfect price point?
  • Do we want to make it easy to use the router as a private bridge?
  • What kind of watchdog process is suitable for ensuring that Tor doesn't fail or that the router works well
  • Do we want to ensure that we gather statistics for Karsten? (If we're planning to deploy lots of these bridges, then we should. -KL)
    • To that end, do we want to ensure that we ship a GeoIP file. The current OpenWRT build does not do this.
  • How do we ensure our users' privacy in terms of encryption from computer to router?
  • What is the best way to set the clock and keep it synced with a time server on OpenWRT?
  • Web UI? Have a basic UI for OpenWRT at #2370. Should we provide a "Setup Wizard" of some sort? And what should this wizard handle in addition to the torrc basics: adding essid, adding firewall zones, dhcp for essid?

comment:76 Changed 6 years ago by ioerror

Resolution: fixed
Status: newclosed

I believe that we have a good idea about what this system is able to do.

Note: See TracTickets for help on using tickets.