Tor/Iptables Question

2009-08-19 Thread Ringo
Hey Folks,

One problem I've continually run into while trying to setup a secure tor
virtual machine for browsing is that I have to allow it access to
localhost (to connect to Tor). Is there a way in iptables to say deny
localhost access to all local ports except xyz or even better say deny
user access to all local ports except xyz

Thanks for any help people can offer,

Ringo


More Secure Tor Browsing Through A Virtual Machine in Ubuntu

2009-08-19 Thread Ringo
I would appreciate any feedback people have on this. This is just an
idea and it's kind of beta, so don't use this unless you know what
you're doing. PGP key at bottom of message




More Secure Tor Browsing Through A Virtual Machine in Ubuntu

Whenever somebody uses the internet through Tor using the standard
set-up, they are assuming that the program (such as Firefox) they're
using is immune to serious remote attacks such as code execution attacks
that could allow an adversary to run commands on their system. It is
possible to use Tor without making these assumptions, thus making Tor
use safer.

The basic idea behind securing Tor browsing through a virtual machine is
to put the user's programs in a sandbox. A virtual machine is the
ultimate example of this. Even if an attacker were to be able to gain
command-line access through a vulnerability in a program such as
Firefox, they still wouldn't be able to obtain the user's IP address,
look at their file system, or gain access to any other
personally-identifiable information.

As an added benefit of running a virtual machine, you can also allow
scripts, flash, and all sorts of other nasty code to run in your browser
as even if it tries to break out it won't be able to. You should be
aware that this will break your anonymity across identities through
things like flash cookies. We'll discuss that more later as well as
steps that can be taken to prevent it.

Unfortunately, virtual machines require a lot of memory, cpu time, and
disk space. If you don't have extra of these, you might want to consider
building a chroot jail instead. If you want to install a virtual
machine, keep reading.

I'll be using Xubuntu for this guide because it's an easy distribution
for newbies to use and it's relatively lightweight. If you're dealing
with less system resources, you might want to try doing this with Damn
Small Linux or installing Fluxbox. If you get it to work, please
document how it was done so other people can lean from your experience.

Part One: Download Xubuntu
The first thing we'll have to do is grab a copy of Xubuntu. If you have
lots of spare resources, you can use Ubuntu as the instructions will be
almost identical.
You can get the 9.04 (Jaunty Jackalope) version of Xubuntu at
http://www.xubuntu.com/get#jaunty. I strongly suggest you use the
Torrents they provide at
http://mirror.anl.gov/pub/ubuntu-iso/CDs-Xubuntu/9.04/release/xubuntu-9.04-desktop-i386.iso.torrent.


Part Two: Configure Your Host System
While we're waiting for Xubuntu to download, let's set up your host
system. The first thing we'll need to do is create a user to run the
virtual machine. Go to SystemAdministrationUsers and Groups and add a
new user. You'll need to set a password for them, so make sure you write
it down when you do. Also, go to advanced and write down the user id.
I'm calling this user “torify” in my examples.
I'm assuming you already have Tor/Privoxy set up at the standard ports
(9050 and 8118) if not, please install them and remember any
non-standard configurations you have.
Let's set up our firewall so the “torify” user can only access localhost:
sudo iptables -t nat -A OUTPUT -m owner --uid-owner torify -j DNAT
--to-destination 127.0.0.1

This firewall rule will only stick around until you restart your system
(or re-connect to the network). If you want to make it persistent,
there's a guide at https://help.ubuntu.com/community/IptablesHowTo which
explains how to even if you're using the Gnome or Xcfe Network Manager.

If you have any software listening on any port (even if it's only
accessibly from localhost) then the virtual machine will be able to see
it. This is not a risk if you're browsing Tor safely in your virtual
machine but if you allow flash, java, etc. then it could become a risk.
A common open port on Linux systems is port 631, which is the CUPS
service's web interface for managing print jobs. If you open
http://localhost:631 in your web browser, you should be able to see if
it's there or not. You can temporarily disable it by going to the System
Monitor (in SystemAdministration), finding cupsd in the process list,
and killing it. This will only kill CUPS until the next system restart
(or possibly the next login).

Next, we'll install the software required to run the virtual machine.
Type the following command in the terminal (StartAccessoriesTerminal).
If your processor doesn't support virtualization, you should only
install qemu. If you don't know if your processor supports it, go ahead
and install it as you can always remove it later.
sudo aptitude install qemu kqemu-common kqemu-source

Once this is installed, you'll have to restart. Go ahead, I'll still be
here.

Now that you've got Qemu/KVM installed, let's do the final step in
configuring your system. Remember where I asked you to write down the
user id? Replace “id” in the following two commands with the id of your
“torified” user.
sudo adduser `id -un` libvirtd
sudo adduser `id -un` kvm

This allows 

Re: More Secure Tor Browsing Through A Virtual Machine in Ubuntu

2009-08-19 Thread Kyle Williams
Ringo,
So I find it funny that you write this as I am compiling a micro X11 VM for
the exact application you describe, for many of the same reason you mention.
I've been playing with this idea for quiet some time now, about a year.
I have a rough working prototype of what I would like to see, but it's about
420MB in size, based on gentoo, and to me that is way to large.
I've looked into Xbuntu and lots of others, and the solution I'm trying is
to use the Kamakazie OpenWRT build for generic x86 running just X and a web
browser application.
So trying to get Mozilla, aka Firefox, integrated into the kamakazie build
system is a nightmare.  I tried, coderman tried, and we're not going to try
anymore with it.  Mozilla code wasn't designed for this type of thing.

Three days ago coderman and I thought that chrome might be a good option.
 He downloaded the linux version, compiled and said it looked pretty
straight forward and would probably work.
So now I'm recompiling the Micro X11 VM with a kernel update, then I'll try
and add chrome into the Mix.  If all goes well, we should have something in
a few weeks.

Just so you know, I thought this was going to be much easier than it has
turned out to betheir are all kinds of incompatibility issues, bugs, and
customizations that always come up.
It has taken a very long time since initial idea to get this far and keep it
this small.  Right now the X11 VM is coming in around 11MB, that's with Tor,
kernel, X11, and the minimums needs to run.
I'm not sure how big Chrome is, but we'll see.

It'll be based on a similar build system as Tor VM.  The idea is to keep it
small in size, low in memory usage, and integrated like it's any other
application on the system, even though it's running in a VM.  The VM engine
we used in Tor VM is Qemu.  My personal goal is to try and get everything at
or below 50MB in size, but we'll see how that turns out.

If you haven't looked at Tor VM, you might want to do so.  It's a good base
to start a project like what you describe, and is what we've been working on
(quietly) for some time now. :)
https://www.torproject.org/torvm/
http://www.janusvm.com/tor_vm/


- Kyle

On Tue, Aug 18, 2009 at 11:12 PM, Ringo 2600den...@gmail.com wrote:

 I would appreciate any feedback people have on this. This is just an
 idea and it's kind of beta, so don't use this unless you know what
 you're doing. PGP key at bottom of message




 More Secure Tor Browsing Through A Virtual Machine in Ubuntu

 Whenever somebody uses the internet through Tor using the standard
 set-up, they are assuming that the program (such as Firefox) they're
 using is immune to serious remote attacks such as code execution attacks
 that could allow an adversary to run commands on their system. It is
 possible to use Tor without making these assumptions, thus making Tor
 use safer.

 The basic idea behind securing Tor browsing through a virtual machine is
 to put the user's programs in a sandbox. A virtual machine is the
 ultimate example of this. Even if an attacker were to be able to gain
 command-line access through a vulnerability in a program such as
 Firefox, they still wouldn't be able to obtain the user's IP address,
 look at their file system, or gain access to any other
 personally-identifiable information.

 As an added benefit of running a virtual machine, you can also allow
 scripts, flash, and all sorts of other nasty code to run in your browser
 as even if it tries to break out it won't be able to. You should be
 aware that this will break your anonymity across identities through
 things like flash cookies. We'll discuss that more later as well as
 steps that can be taken to prevent it.

 Unfortunately, virtual machines require a lot of memory, cpu time, and
 disk space. If you don't have extra of these, you might want to consider
 building a chroot jail instead. If you want to install a virtual
 machine, keep reading.

 I'll be using Xubuntu for this guide because it's an easy distribution
 for newbies to use and it's relatively lightweight. If you're dealing
 with less system resources, you might want to try doing this with Damn
 Small Linux or installing Fluxbox. If you get it to work, please
 document how it was done so other people can lean from your experience.

 Part One: Download Xubuntu
 The first thing we'll have to do is grab a copy of Xubuntu. If you have
 lots of spare resources, you can use Ubuntu as the instructions will be
 almost identical.
 You can get the 9.04 (Jaunty Jackalope) version of Xubuntu at
 http://www.xubuntu.com/get#jaunty. I strongly suggest you use the
 Torrents they provide at

 http://mirror.anl.gov/pub/ubuntu-iso/CDs-Xubuntu/9.04/release/xubuntu-9.04-desktop-i386.iso.torrent
 .


 Part Two: Configure Your Host System
 While we're waiting for Xubuntu to download, let's set up your host
 system. The first thing we'll need to do is create a user to run the
 virtual machine. Go to SystemAdministrationUsers and Groups and add a
 new user. 

Re: More Secure Tor Browsing Through A Virtual Machine in Ubuntu

2009-08-19 Thread Ringo
When I started working on this, I knew that projects like TorVM and
incognito existed, but I wanted to try something different. The problem
being that if an attacker is able to compromise the browser, the http
proxy, or Tor, the user could have their IP revealed, or at least that
was my understanding of it. I'm not sure what protections the current
systems have against this, but I'm guessing it's something along the
lines of a set of iptables rules that restrict certain
users/applications to localhost?

If we add that to the host of other problems that seems to come with
using Tor in a truly secure manner (updates in programs that break user
anonymity, people who want to run active scripting and remote code,
etc.), we're looking at a giant problem that can best be solved by
sandboxing the entire operating system instead of just certain
applications/users/parts of the OS.

In my model, the virtual machine can only connect (even as root) to the
host machine. I figure that anything running in a torified environment
should never need to access anything other than Tor, so I just removed
the possibility of that happening.

The problem with this model, as you state correctly is the high resource
usage and I think there's some way to bring this down but that's not
somewhere where I have a ton of experience.

I'm also working on a hidden service set-up guide using a similar model
and I did a little to lessen resource usage but much more needs to be
done. I think that for a browser vm, most consumer-grade computers can
handle a vm running damn small linux or some similar distro.

Ringo



Kyle Williams wrote:
 Ringo,
 So I find it funny that you write this as I am compiling a micro X11 VM for
 the exact application you describe, for many of the same reason you mention.
 I've been playing with this idea for quiet some time now, about a year.
 I have a rough working prototype of what I would like to see, but it's about
 420MB in size, based on gentoo, and to me that is way to large.
 I've looked into Xbuntu and lots of others, and the solution I'm trying is
 to use the Kamakazie OpenWRT build for generic x86 running just X and a web
 browser application.
 So trying to get Mozilla, aka Firefox, integrated into the kamakazie build
 system is a nightmare.  I tried, coderman tried, and we're not going to try
 anymore with it.  Mozilla code wasn't designed for this type of thing.
 
 Three days ago coderman and I thought that chrome might be a good option.
  He downloaded the linux version, compiled and said it looked pretty
 straight forward and would probably work.
 So now I'm recompiling the Micro X11 VM with a kernel update, then I'll try
 and add chrome into the Mix.  If all goes well, we should have something in
 a few weeks.
 
 Just so you know, I thought this was going to be much easier than it has
 turned out to betheir are all kinds of incompatibility issues, bugs, and
 customizations that always come up.
 It has taken a very long time since initial idea to get this far and keep it
 this small.  Right now the X11 VM is coming in around 11MB, that's with Tor,
 kernel, X11, and the minimums needs to run.
 I'm not sure how big Chrome is, but we'll see.
 
 It'll be based on a similar build system as Tor VM.  The idea is to keep it
 small in size, low in memory usage, and integrated like it's any other
 application on the system, even though it's running in a VM.  The VM engine
 we used in Tor VM is Qemu.  My personal goal is to try and get everything at
 or below 50MB in size, but we'll see how that turns out.
 
 If you haven't looked at Tor VM, you might want to do so.  It's a good base
 to start a project like what you describe, and is what we've been working on
 (quietly) for some time now. :)
 https://www.torproject.org/torvm/
 http://www.janusvm.com/tor_vm/
 
 
 - Kyle
 
 On Tue, Aug 18, 2009 at 11:12 PM, Ringo 2600den...@gmail.com wrote:
 
 I would appreciate any feedback people have on this. This is just an
 idea and it's kind of beta, so don't use this unless you know what
 you're doing. PGP key at bottom of message




 More Secure Tor Browsing Through A Virtual Machine in Ubuntu

 Whenever somebody uses the internet through Tor using the standard
 set-up, they are assuming that the program (such as Firefox) they're
 using is immune to serious remote attacks such as code execution attacks
 that could allow an adversary to run commands on their system. It is
 possible to use Tor without making these assumptions, thus making Tor
 use safer.

 The basic idea behind securing Tor browsing through a virtual machine is
 to put the user's programs in a sandbox. A virtual machine is the
 ultimate example of this. Even if an attacker were to be able to gain
 command-line access through a vulnerability in a program such as
 Firefox, they still wouldn't be able to obtain the user's IP address,
 look at their file system, or gain access to any other
 personally-identifiable information.

 As an added benefit of 

Re: Scott made me do it.

2009-08-19 Thread Karsten N.
Andrew Lewman schrieb:
 I tested a few scenarios:

The access to hidden service is important too (in my opinion). I have
good experience using privoxy with:

  forwarded-connect-retries 3

Access to hidden services with socks5 in Firefox gives sometimes a
timeout first. After 1-2 retries, the page is loaded. May be, it is
possible to configure the timeouts in firefox, may be the connect
retries of privoxy are essential? I do not know the answer. Can someone
give an advice?

For hidden services the fail count is more important than the time for load.

Karsten N.


Re: Tor/Iptables Question

2009-08-19 Thread Erilenz
* on the Wed, Aug 19, 2009 at 02:00:01AM -0400, Ringo wrote:

 One problem I've continually run into while trying to setup a secure tor
 virtual machine for browsing is that I have to allow it access to
 localhost (to connect to Tor). Is there a way in iptables to say deny
 localhost access to all local ports except xyz or even better say deny
 user access to all local ports except xyz
 
 Thanks for any help people can offer,

I prevent all users other than root from connecting to the Tor Control port 
with an
iptables rule which looks like this:

iptables -A OUTPUT -o lo -p tcp --dport 9051 -m owner ! --uid-owner root -j 
REJECT

You should be able to modify that for your own purposes.

-- 
Erilenz


Roger's HAR2009 talk on Tor performance

2009-08-19 Thread Ringo
From Tor Blog

|

Jake, Mike, Karsten, Sebastian, and I attended Hacking at Random last
week in The Netherlands. I did a talk on Tor performance challenges —
basically walking through the key pieces of the Why Tor is Slow
document that we wrote in March.

As usual with European hacking cons, they produced a really well-done
video just days after my talk. So if you want to get the highlights on
what we're doing to speed up Tor and what roadblocks remain, take a look
at the video and also the slides that come with it.

|

I just put a torrent of this up at
http://www.johntowery.com/har2009_Why_Tor_is_slow.mp4.torrent

It uses the hidden tracker and should work for Tor users and non-tor
users. It actually appears to be down right now but it'll come up
eventually. It has both the regular .onion and the tor2web url in it.

Ringo



Re: Roger's HAR2009 talk on Tor performance

2009-08-19 Thread Roger Dingledine
On Wed, Aug 19, 2009 at 05:19:20PM -0400, Ringo wrote:
 Jake, Mike, Karsten, Sebastian, and I attended Hacking at Random last
 week in The Netherlands. I did a talk on Tor performance challenges ?
 basically walking through the key pieces of the Why Tor is Slow
 document that we wrote in March.
 
 As usual with European hacking cons, they produced a really well-done
 video just days after my talk. So if you want to get the highlights on
 what we're doing to speed up Tor and what roadblocks remain, take a look
 at the video and also the slides that come with it.

Right. For those who like to see the links too, see
https://blog.torproject.org/har2009-video-tor-performance

--Roger



Re: Roger's HAR2009 talk on Tor performance

2009-08-19 Thread The Hidden Tracker
 It uses the hidden tracker and should work for Tor users and non-tor
 users. It actually appears to be down right now but it'll come up
 eventually. It has both the regular .onion and the tor2web url in it.

Yep, we're down right now. Sorry about the inconvenience. We're
expecting to be up and down for a little while while we make some
fairly comprehensive overhauls. In the mean time, publicbt.org, and
openbittorrent.com should work for you.

If anyone wants to stay in the look about our 'scheduled' downtime,
and other hidden-tracker-related goodness, @hiddentracker on twitter
has all the news.


Re: Roger's HAR2009 talk on Tor performance

2009-08-19 Thread Ringo
Well given this, I've added a few other trackers, file at the same spot:
http://www.johntowery.com/har2009_Why_Tor_is_slow.mp4.torrent

Ringo

The Hidden Tracker wrote:
 It uses the hidden tracker and should work for Tor users and non-tor
 users. It actually appears to be down right now but it'll come up
 eventually. It has both the regular .onion and the tor2web url in it.
 
 Yep, we're down right now. Sorry about the inconvenience. We're
 expecting to be up and down for a little while while we make some
 fairly comprehensive overhauls. In the mean time, publicbt.org, and
 openbittorrent.com should work for you.
 
 If anyone wants to stay in the look about our 'scheduled' downtime,
 and other hidden-tracker-related goodness, @hiddentracker on twitter
 has all the news.
 


bad exit node

2009-08-19 Thread KT
Node 446E29C6F3D47C315B78EBB1BAC62C241C9F992 [1] completely overwrites
response body [2] when UA is IE. FYI.

KT

[1] http://tinyurl.com/nxfvux
[2] http://paste.ubuntu.com/255997/


Re: Tor/Iptables Question

2009-08-19 Thread Kyle Williams
I believe if you just remove --dport, then everything (all ports) are
assumed.

On Wed, Aug 19, 2009 at 1:01 PM, Ringo 2600den...@gmail.com wrote:

 I prevent all users other than root from connecting to the Tor Control
 port with an
  iptables rule which looks like this:
 
  iptables -A OUTPUT -o lo -p tcp --dport 9051 -m owner ! --uid-owner
 root -j REJECT

 Thanks! That should work perfectly. Is there any way to make dport a
 wildcard?

 Ringo



Tor Browser Bundle 1.2.8 released

2009-08-19 Thread Andrew Lewman
Tor Browser Bundle 1.2.8 is released. The big changes are the inclusion
of statically linked openssl dlls to resolve a few geoip lookup and
functionality issues with Vidalia, and the upgrade to the new Vidalia 0.2.2.

Available at https://torproject.org/torbrowser

The full list of updates and fixes:

* update Torbutton to 1.2.2
* update Vidalia to 0.2.2
* compile OpenSSL 0.9.8k with Visual C to make dlls
* update Pidgin to 2.6.1

Full post at
https://blog.torproject.org/blog/tor-browser-bundle-128-released

-- 
Andrew Lewman
The Tor Project
pgp 0x31B0974B

Website: https://torproject.org/
Blog: https://blog.torproject.org/
Identi.ca: torproject


Re: bad exit node

2009-08-19 Thread Scott Bennett
 On Wed, 19 Aug 2009 23:54:01 +0100 KT listcli...@gmail.com wrote:
Node 446E29C6F3D47C315B78EBB1BAC62C241C9F992 [1] completely overwrites

 The above is not a valid identifier.  It appears to be missing one
character.

response body [2] when UA is IE. FYI.

KT

[1] http://tinyurl.com/nxfvux
[2] http://paste.ubuntu.com/255997/


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at cs.niu.edu  *
**
* A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army.   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**


Re: Archive crypto sigs [was: copy abuse]

2009-08-19 Thread Andrew Lewman
On 08/01/2009 02:03 PM, grarpamp wrote:

 For this and other purposes, all the files under that directory should
 also be signed with the release or other suitable key.

Good idea.  It's done.

-- 
Andrew Lewman
The Tor Project
pgp 0x31B0974B

Website: https://torproject.org/
Blog: https://blog.torproject.org/
Identi.ca: torproject


Re: Scott made me do it.

2009-08-19 Thread Scott Bennett
 Hmmm...I'm not too sure that I should be blamed for this, but
nevertheless...
 On Tue, 18 Aug 2009 23:26:44 -0400 Andrew Lewman and...@torproject.org
wrote:
A while ago there was a thread that devolved into why does Tor still
ship ancient privoxy? and why are you shipping polipo with the Tor
Browser Bundle instead of current privoxy?  For those interested, the
thread is here, http://archives.seul.org/or/talk/Jul-2009/msg00063.html.

Scott had a good argument for why we should update the bundles to the
latest privoxy, and I agree, we should.  But then I started thinking
about why we needed a proxy at all.  Almost all browsers support socks5
direct, isn't that faster than a middleman proxy?

This got me thinking about why we put polipo in the TBB, but not the
other packages.  The TBB feels faster when using Tor than using the
installed Tor, Vidalia, and Privoxy.  However, I couldn't find any
actual testing of performance of polipo vs. privoxy vs. socks5 direct.

So I did it myself, in a loose manner.

The raw data from Tamper Data as xml, proxy config files, and results in
a spreadsheet are all contained in
http://freehaven.net/~phobos/polipo-v-privoxy.tar.gz{.asc).  And yes,
the ruby script is a quick and dirty hack.

I tested a few scenarios:

1) native polipo and privoxy without using Tor.
2) polipo and privoxy forwarding to Tor localhost:9050.
3) firefox socks5 direct to Tor via localhost:9050.

The summary of results:

1) Native polipo is 54.5% faster on average than native privoxy.  This
could be due to polipo's caching, http 1.1 pipelining, and it can serve
bits as fast as they come in from the network.  Privoxy needs to load
the whole page, scan it, and then send it to the client.  Even if
privoxy filtering is disabled, it still works the same way.

2) Polipo caching shines with Tor usage.  Common images are cached, and
served from the memory cache in single-digit millisecond ranges.
Privoxy needs to wait for Tor to wholly deliver the bits.  Caching is
faster, this we know already.  However, from a user perspective, it's
just faster to load pages.

3) socks5 in Firefox 3.5.2 did better than I expected.

4) I tried testing a click to a second page to see how much polipo
caching helps people reading different pages on the same site.  It
helps, but not as much as I expected.

Caveats:  Testing under tor is highly variable.  I used the same
circuits for both the polipo and privoxy tests to minimize variability.
 However, I can't control node load and congestion.

 Thanks, Andrew, for posting these results.  They are certainly
interesting and helpful.
 To get back to your question of why we need a proxy between a browser
and tor, though, I would like to point out once again that privoxy has a
lot of good, rule-based filtering.  I especially appreciate the filters'
ability to block out well over 90% of the advertising on the web, while
leaving the viewer the options to see why an object on a page was blocked,
assuming that one can make heads or tails of the peculiar Martian dialect
in which the filter rules are written, and to go ahead and show the blocked
object anyway.
 I have not used polipo ever and therefore cannot make any intelligent
comments about its usefulness as an intermediate proxy.

Out of 23 get requests for the Torproject.org/index.html.en, 17 are for
the country flags.   Perhaps we should load these last at the bottom of
the page, or do something else to speed up the torproject page load.

 I think Kasimir's torstatus pages suffer from something quite similar.

As I was doing this, I kept thinking of other ways to do it better;

1) time requests and bits between tor, the http proxy, and the browser.
 How long does each request take to get from the browser, to the proxy,
to tor and back across each layer?  how much latency does each piece of
software add to the request and delivery?

2) automate testing and let it run on a normal tor client over weeks.
This will average out tor network variability and show typical user
experience.

3) Pick a sampling of the top 100 websites by visits worldwide and
measure their performance with the three methods, fully instrumented as
in #1.

4) Do user experience measurements.  Pay/ask/bribe people to sit in
front of a computer, video record their browsing and feedback, and ask
for a rating of each configuration (socks5, polipo, privoxy, and a placebo).

5) re-run #2 and run gcov to watch the code paths used in each piece of
software, and figure out what can be optimized for performance.

6) test various private browsing modes through tor to see which
browser is faster; firefox, safari, chromium, torfox, or torora.

7) how can we better tune polipo caching dynamically based on system ram
config?  Does having 1GB of cache provide significant benefits over the
default?

I'm sure there are lots of things wrong with my measurements, minimal
analysis, and results.

Constructive criticism is welcome.

 All of the above look good.  

Re: bad exit node

2009-08-19 Thread grarpamp
Node 446E29C6F3D47C315B78EBB1BAC62C241C9F992 [1] completely
  The above is not a valid identifier.  It appears to be missing one

I'm sure anyone interested would look up a substring in the
descriptors, tack on an A and be done with it.