Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] [was Secure hosted mail, now: AutonomyCentral by Valeso]

R. P. Ruiz r.p.ruiz at
Mon Mar 5 19:23:15 PST 2012


Finally, I actually slept a bit this weekend for first time in a month.  Huzzah!

First clarification: It's now officially AutonomyCentral by Valeso ( - VaultletSuite 2 Go by VaultletSoft is now in EOL mode.  That's how I'll refer to it from here on out.

Having said that, it's on to my comments inline below.  Sorry so verbose, but Jacob's raised quite a few issues, and I feel it's important to address as many as I can before punching out for the night.



R. P. Ruiz - President, Valeso
Cell [+1.202.409.4959] Web []
Free secure AutonomyCentral support forums []
Note: I check my email infrequently. Need a quick(er) response?  Call!

> ---------------- Original Message ----------------
> From: jacob at
> To: rguerra at
> Cc: liberationtech at
> Cc: r.p.ruiz at
> Sent: 2/25/12 5:19 PM
> Subject: was Secure hosted mail, now: VaultletSoft
> On 02/25/2012 10:06 AM, Robert Guerra wrote:
> > John,

...BIG SNIP...

> > Would be great to get people's comments on this..
> I've met the author and he's a nice guy. However, I wouldn't suggest
> that people use Vaultletsoft or Autonomy Central or whatever it is
> called these days.
> Some comments on why I'm not a fan:
> It's not Free Software, it's not even Open Source software.

The basic version's free for personal, non-profit and educational use - if you want more features, then you can pay.  Crazy concept that: paying for something that takes incredible amounts of time, attention and energy to do!

The crypto's open source, which is basically object wrappers for the Bouncy Castle java crypto library.

> You have to use (!) their software to receive a copy of the source for
> the software. That's a turtles all the way down security approach if
> I've ever seen one!

Nah, all I want is a digital sig for the agreement, something that VaultletMail does quite nicely.

If you had contacted me first I'd have said that you could sign w/ your GPG key if you were so inclined.  Gods know how many other people have contacted me about various and sundry issues related to the design, implementation, technology, cost, freebies, etc. 

In this case, I figure you were probably too busy to drop me a line to say something along the lines of "Hey Mr. Valeso, what's up w/ that goofus peer-review license?" - Don't sweat it though, because I understand:  The busier I get, the harder I prune the work tree and fall back even harder on rules-of-thumb instead of taking on people and issues on a case-by-case basis.

> To make matters worse anyone reading the source has to agree to some
> license about peer review that includes this gem of a gag attempt:
> "You agree that you will not post any information about any bug,
> problem, deficiency, or weakness in the VaultletSuite Client software on
> any web site or electronic bulletin board, or otherwise disclose or
> provide any such information to anyone else, unless you have first
> reported it to VaultletSoft Inc. and until at least 30 days after
> VaultletSoft Inc. sends its email acknowledgement to you."

...You silly inflamatory goose, it's not a *gem* - it's just a simple attempt/request (albeit disguised in legalese) that I be informed of any problems so that I might fix them before they're made public.  That mischaracterization is one example of the hyperbole that I mentioned earlier.  Well written to be sure, but it doesn't really make me want to engage in a public conversation in which I'm taken to task first and then expected to defend myself after the fact.

W/ regards to the 30 day window, I wouldn't be the first person to ask for this courtesy, nor would I be the first person or org to actually be granted a stay on public announcements so that a proper patch could be put in place.  Further, and believe it or not, I personally think that you'd be in your rights (ethically) to blow the whistle loudly and vociferously if I couldn't get a patch out w/in 30 days.  That's an eternity in security years.

It did occur to me while going for a long swim this week that I could probably add something to that effect and shorten the reprieve to 14 days. Not that it would make much difference to you Jacob, but it still would be an attempt to better explain my motivation.  If there's one thing that bugs the shite out of me, it's being misjudged and/or misunderstood.  Especially in public, that just amps up the animus (or the appearance/perception thereof), something I can definitely live w/o.  

Anyway, I know that even w/ the qualified answers and proposed changes, it's still a destestable non-open-source license agreement.  And that's not going to change for this bit of commercial software due to it's historical baggage.  On the other hand, it doesn't have to change how you view it (the proprietary version), because I'm still interested (and have been for quite a while now) in releasing an open source as-free-as-it-gets version.

Before you respond to this bit though, know this: there's no need to lecture me any further about the virtues of open source - because I get it, I *really* do.  It's just that I'm more than a bit allergic to pretty much any and all kinds of "One True Way(tm)" thinking about problems and solutions (that includes religion, government, religion, software licenses, religion, oh, and politics too).  So while I generally consider open source to be a GoodThing(tm), no, make that GreatThing(tm), it doesn't solve all of my nor the world's software or security problems.  More specifically, it doesn't solve a set of problems particular to AutonomyCentral.

> Getting into the actual tech - I find it rather concerning that many of
> the VaultletSoft web services load a java applet to do the heavy lifting:

They *don't* do the majority of the heavy lifting.  The applets, which I'm not too much a fan of by the way, actually make it easier for people to have (more) secure communications w/ someone who can't or won't be bothered to actually install the application binary w/ a runtime that's known to work w/ the client.

Think of the applets and TLS pieces as lying on the convenience end of the security spectrum, in which you are definitely going to have to give up something (less security) in exchange for convenience.  In fact, I used to characterize this dichotomy as "Convenience vs. Security" until too many marketing people (and users too!) balked at "getting less than the absolute, more-superlative-laden security" just because they wanted convenience.  Sucked to be me explaining Truth to people who don't want to hear it...  And it still does!

If you use VaultletMail to VaultletMail for your email, there are no applets involved (praise Zeus!)  It's pure purpose-built to purpose-built client-to-client communication.

> In a sense, I see two major problems. The first is a lack of open
> standards in the crypto beyond the buzzwords of RSA and AES. 

They're not buzz words, they're Bouncy Castle's implementation w/ my open source object wrappers.

> is that the security of the entire thing boils down to the security of
> the SSL/TLS trust model. 

...Bzzzzzzz!  ¡Equivocado!   Nope, Nope, Nope!

Jacob, you are definitely a brilliant guy who does great work and also has his heart in the right place (yeah, I'm a bit of a fanboy).  But on this one, I gotta throw the yellow card on this one: you're guilty of hasty induction ;-)

Here's the scoop: Back when I designed the client-server communication layer (CSCL), I realized that SSL was but one of the many weak links in securing communcation between client and server (the biggest being the end user's shite laden, virus infected computer and crazy Typhoid Mary computing habits).  So I decided not to count on it for anything other than encrypting the metadata of the CSCL.  Every request/transaction uses RFC standard digest authentication + a replay detection timestamp.  Plus, the payload (the message itself) is encrypted on the client (and applets too) using the recipient's public key.

So even if we stripped away the SSL, we'd not lose much, except protection from lower-level traffic analysis.

But wait, it get's better: I figured that someone could try to redirect and/or poison the DNS or offer up a faux SSL cert, so I have the AutonomyCentral application perform its own version of certificate validity checking (instead of relying on the JVM to do the right thing via HTTPS).  On top of that, once that test is passed, the app server itself authenticates itself to the client (something it also does to all of the applets) - if the client doesn't like the credentials presented by the server, then everything comes to a screeching halt.

> If every time you use the web forms you load
> the java applets over TLS, a successful MITM wins the entire game. This
> is not unlike the problems with Hushmail or in their case, I believe one
> story was that they delivered a special java applet for a targeted user.
> It's technically possible that the same thing could happen here, what
> steps do they take to ensure that this doesn't happen?

...See above.

> As far as the client side software goes, I think that they solve
> problems that need to be solved - I'm not sure that they solve them in a
> way that makes sense. As an example I looked at the Vaultlet filer page
> and noticed something quite strange:

You got me on that one... That's my crappiest piece of software, and I'm glad to see it EOL'd - while it did work, it was clunky and only mildly useful to anybody other than myself.  It's been superceded by AutonomyCentral's VaultletFiler DnD (Drag and Drop) app that does file-based encryption, as opposed to whole partition encryption as done (so well too!) by TrueCrypt.
> Does it really disclose file names, contents, file sizes, and other
> things *before* you provide an encryption key? That seems... uh, less
> than ideal, if so.

Nope, it doesn't do that.  Well, at least, not anymore.

> As I absolutely refuse to audit something with a gag, I did not request
> the source. I did however look at the portable linux installer and found
> that it ships with a huge javakeystore. It appears that if each of these
> CA certs is trusted that basically the TLS layer is vulnerable to attack
> from each listed CA (Comodo is included in the list; DigiNotar isn't).
> Though I won't make this claim, I've decided to CC the author and let
> him reply here with a yes or no - if it's possible, I guess we'll call
> that a pretty serious issue.

As a minimalist, I used to build installers w/ only the certs necessary to validate and connect to my servers.  Even though the design that I explained above negates the largest part of the problem that a certificate laden keystore represents, I probably should go back to doing that.  Thanks for pointing that out.  I'll try to incorporate that into the next build.
> I've done a disassembly on the software as well but I don't have time to
> look through it right now. I'll put it on the TODO list as it looks like
> it might be an interesting target. 

It would indeed be interesting to see what you come up w/ and I'd appreciate it if you let me (and the world) know if you find any boo boos or malfeasance.  

> The NDA/gag doesn't lend to the right
> incentives thought and that really encourages me to audit some Free
> Software projects when I do find the spare time.

Gods, I hate that word "Gag".  Makes me sound like just another over-lawyered shark in a suit ;-)  Coming from you, though, I *do* understand what that shorthand means.
> All the best,
> Jacob

And to you the same.   I also *really* appreciate your expression of interest in reviewing the open source version of AutonomyCentral.  I will definitely contact you when that happens.

p.s.: And many thanks to all for not pointing out that it was Madeline Kahn in Young Frankenstein (not Bride o' Frankenstein) when I mentioned being tired last week.

Send me a secure VaultletMail DropBox message anytime, anywhere!:

More information about the liberationtech mailing list