Torouter OS and configuration
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.
Activity
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?
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.)
Trac:
Username: shawnmerI 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-aptI propose that we ship the following Tor Project packages and work to get them into Debian ASAP:
ttdnsdWe 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:
openntpdWe'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?
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!
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?
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.
Replying to runa:
Replying to cypherpunks:
I propose that we ship the following Tor Project packages and work to get them into Debian ASAP:
ttdnsdI 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:
openntpdWhy 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.
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?
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.
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 (closed) for the Tor 0.2.3.x and tor-fw-helper discussion.
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.8Trac:
download.php_i_v0GhXyA2Here'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.7Replying 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... :-)
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.
-
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.0Here 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.debResults:
# 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.00kAs 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.patchTrac:
Username: jrenken -
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.
Trac:
Username: 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.
Trac:
Username: gilles 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.
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.
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/).
Also worth reading: http://projects.standblue.net/docs/clockspeed.html
Trac:
Cc: N/A to tortrac@flamsmark.comReplying 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.
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.
-
Trac:
Username: zooko
Cc: tortrac@flamsmark.com to tortrac@flamsmark.com, zooko@zooko.com 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.)
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... :)
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...
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?
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.36I installed the following packages to make a mini-Tor friendly router:
openssh-server tor ntp pumpIt 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 *:sshReplying 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.
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.
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:domainI've opened a bug for discussion on the kernel issues: #3447 (closed)
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-newI 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...
This seems to be a good bug about replacing the NTP server: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593429
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 tty6That leaves us with tty1 - though I don't think we need it as we only use ttyS0 for the UART/JATG serial connection.
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.
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.
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?
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-helperout 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-helperseparately from Tor, even with 0.2.3.x.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-helperout 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-helperseparately 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.
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 -bashIn 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.
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?
Here's the ipv6 disable info: http://wiki.debian.org/DebianIPv6#In_squeeze
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.
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.
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 > ~/.armrcI configured Tor like so:
ControlPort 9051 ControlListenAddress 127.0.0.1:9051 CookieAuthentication 1I reconfigured arm like so:
root@torouter:~# cat .armrc |head # Startup options startup.cookieNow 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?
Please comment on #3453 (closed) if you've read this far...
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.
-
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.
Trac:
Username: nmeagent 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.
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.
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 (closed).
- 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 (closed). 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?
mentioned in issue #3378 (closed)
mentioned in issue #3453 (closed)