[Zope] - Cryptography... and the absurdity of things

[Andreas Kostyrka]

On Wed, 30 Dec 1998, Christopher G. Petrilli wrote:

> On Thu, Dec 31, 1998 at 12:09:06AM +0100, Andreas Kostyrka wrote:
> > [ Flame bait deleted ]
> > Nope that's not the way it's done with free software ;)
> > (Actually I mean technical sound software in comparision to software where
> > marketodroids have the saying *g*, which happens to apply often to free
> > software.)
> 
> If you want it, write it, and then I'll be happy to put my
Ok. Let's take my asbesto pants, and start to play a bit fire dep. ;)

Ok, this whole threat started, with someone noticing that:
-) He likes his editor,
-) He likes to use his standard project management tools,
-) Basically, he doesn't like BoboPOS.

Ok, I responded that it's not to difficult to achieve very many benefits
of a Zopesque development without BoboPOS ;)

The crypto stuff came into play when someone tried to sell the planned FTP
interface as a replacement, and I mentioned that I do not like to send
plaintext passwords over the Internet. Especially not if the password
``means'' something like the ability to edit a website. (A password to
access some paysite may be ok to send in cleartext. That depends upon your
goals ;) )

Now to summerize my only ``difference'' with the Z Zen ;). Z uses BoboPOS
to activate/deactivate objects. IMHO, this is one of the shortcut hacks,
that make Python what it is. *g*
I strongly prefer to have an explicit activation/deactivation. Why?
Because this much stronger spells out what is stored/done/etc. in the
object, compared to some implicit activation/deactivation.

Additionally, I prefer to use more ``traditional'' storage forms (kind of
HTML documents usually belong onto a filesystem, or into a document
managment system, ``data'' belongs into a SQL system.), I know this is
pain in the beginning, but in the long run it's got the best
maintainibility.

> cryptographer's hat on (didn't you wonder what I did for money?) and rip
> it to shreds... the reality is that at this point, in this poltical
> climate, with the current available resources, it's just not an
> intellegent move.  
I've never suggested that I want seriously implement such a beast. I'm
quite happy with BoboHTTPServer running on internal loopback alias,
protected by some additional levels of paranoia ;), being served to the
world by Apache/SSL ;)

Before I found the ``solution'' (hack is probably the better naming) with
Apache/mod_rewrite/mod_proxy/BHS, I've considered (not too seriously) to
use SSLeay to enhance BHS. Knowing that I'm not a crypto guru *g* (they
teach here around not to much crypto to CS majors :( ), I'd considered
much more strongly to patch pcgi to work better to my liking ;)

> Security (of which cryptography may or may not be a component of) is a
Correctly. I'd just rather say, that with an unsecure communication
channel, cryptography is rather a good idea (I know S/key, etc., but it's
all in some way poor substitute to secure channel, isn't it?)

> highly complex topic often bantered around by marketing people, and
> almost never understood by anyone who uses the word.  THe only thing
> worse than no security is the false sense of SOME security (ney, Windows
Actually, NT3.51 in a patched version was C2, without floppy, CDs,
network, etc. Actually, some people suggest that after the some
architectural changes in NT4, it isn't possible for NT4 to achieve
the C2 even with the funny restrictation 3.51 had, ...
But MS has some trolls on the NTSEC mailing list, that keeps singing the
mantra: NT is safe. NT is safe. No matter what other people tell them *g*

> NT and it's "C2" certification---without a floppy or network, or many
> other things).
Exactly my point. I'm not sleeping to well, as I'm responsible for some
servers on the Internet. To put it bluntly. I consider myself relativly
capable to provide for security on my ``own'' (administered by myself)
boxes and LANs, but I'd never go advertising myself as a security
consultant. Especially as I know at least one guy that has his ads run in
some national publications as security consultant, and we know that the
only achievment of this guy in this field are:
-) configuring his companies firewall in a funny way, so that transmitting
   files from the internal network to servers outside the firewall is only
   possible by sending email :( (Not by intend, but by gross
   missunderstanding of TCP/IP).
-) Being hacked at least once a month on his web server. Actually I'd
   rather say, that he notices it once a month, there are just no
   statistics about the unnoticed breakins ;) )

So I'm quite wary of security experts, being it individuals or companies.
But I managed to manage (or co-manage) Linux (and for a short time HP/UX,
but that were unexposed boxes) boxes on the Internet for 6 years, without
being hacked to often. Actually it happened once on my home box with modem
dialup, and since then I've learned that even Modem dialup boxes that come
in contact with the Internet have to be secured properly.

> You need to define WHAT you're trying to accomplish before you reach
That's quite easy. (Actually you are right, it's not that easy.)

-) Running websites without exposing the server to hacking, even
   considering that it is located in a highrisk area of the net (colocated
   at a ISP on one huge ethernet segment, and the ISP seems not to have a
   policy against turning one's ethernet device into promiscious mode,
   ...)

-) Asorted other typical tasks. Again without being compromised.

At the moment my biggest headache is POP, as it insists on cleartext
passwords, and requiring clients to use ssh tunnels doesn't work to well,
as I don't like the idea of shell access for untrusted people to much.

So is the mission goal clear enough.

> into the toolbox and pick a tool, rather than swing about your
> hammer-de'jour looking for anything that might stick out, and calling it
> a nail.  Cryptography is a grand thing, a mathematical tour-de-force if
> done correctly, BUT it's rarely the issue.  If all you ahve to worry
Not really. As outlined, using an unsecure communication channel,
``security'' becomes VERY HARD to achieve without cryptography.
And the Internet is an insecure channel. Admittingly it comes in different
shades, ranging from threat area to insanely high threat area.
(Actually, I've got one private box I manage on the internet in a segment
 where the main admin has a laissez-faire mentality. Actually he likes to
 collect all the nice tools the hackers leave on his servers, he only gets
 sometimes upset, because the hackers leave some CPU intensive processes
 running, etc. Still my box hasn't been hacked. Admittingly the box
 doesn't run much except apache and sshd *g*)

> about is whether someone can break your 40-bit key by brute force,
Actually, I'm quite happy with 40-bit keys for website editing. The point
is to get rid of sniffers. What I like less are 40-bit keys when
authenticating for a root shell, but then it'd probably do the trick too.
The point is that if there is enough crypted traffic, the real bad guy
have much more to decrypt ;)
> you've done a handy job, but don't delude yourself into thinking that
> even relevant to most discussions.
> 
> The concept of "role based" authentication in ZOPE is wonderful as a
> first step, there are many more that need to be made... all in good
> time, as technology and time permit.  I would love ot see a fully
> trusted, multi-level secure object publishing system, but given we can't
What do you mean exactly by trusted, multi-level?
> even get a secure WEB SERVER, I'm not holding MY breath for another
When you mean by trusted, multi-level, secure WEB SERVER something that
supports UP-write, DOWN-read policies and level separation, I'd rather say
you are on lost ground, as http as such doesn't support that to well.

> minute.  One must ask the question, "what are you protecting" and "what
> is it worht".... so long as the aggregate of what you protect and it's
> value is less than the effort required to counter your protections, you
> have succeeded in building a reasonably secure system.
*nod* But now let's consider virtual website hosting.
These sites quite possibly could contain:
-) personal data. We've got stupid laws about protecting personal data
                  here arounds. Beside all the hassle, not complying with
                  these stupid (actually, personally I consider this law
                  much to mild, but that's the theoretical point) law is
                  punished by around USD20000 per incident, ...
                  Now explain to someone that you did not sell the data,
                  that it was stolen. (Every data processing facility have
                  to be able to explain how it got the personal data and
                  how it acquired it legally, but I personally tend to
                  provide my personal data often with spelling mistakes
                  and have a list which mistake was provided where *g*)
-) credit card numbers. I don't know what the credit card companies would
                  do to us, but I'm pretty sure, I would not like it much.
                  And one thing is sure. They have more money for lawyers.
                  While we have more fair and sane judicary process here
                  around than in the land of freedom, it tends still to be
                  a deciding factor. (Ok, if someone wants to discuss this
                  claim, explain to me how one can be a murderer, and not
                  be one at the same time? It's probably my
                  shallow training in logic as a CS major which makes me
                  having problems to accept a calcule that defines  
                  (A and not A) as true ;)

-) medical personal information. I'm about to lauch some sites for clients
                  where doctors will be publishing but also counceling
                  patients. Don't think that having your data base of
                  medical inquiries (x@isp.at: Hi, my brother does have
                  AIDS and I'd like to ask, ...) stolen is a ``good
                  thing''.

> 
> The world is about risk-mitigation, not about absolute security, the
> latter does not, can not, will not exist, ever, even the NSA understands
> this concept.
Absolutly. In my case I just observe:
-) https (even the bastardized NSA approved key length version) greatly
         improves the security. (against the threat of sniffing, which in
         my experience (of six years working with the Internet) is quite
         often the first breach of usage policies.
-) https is extremely cheapily to implement. It basically costs:
         a bit of CPU usage. (With my current hardware, I'll have enough
                              possibilities to upgrade horsepowers. Coming
                              from a P100 ANYTHING today is really fast.)
         If there is a need of a separate certificate, it's about 125USD
         or so. For editing websites it's obviously not mandatory to do it
         under the same URL. It's probably ok to edit http://www.xyz.com
         as https://www.isp.com/xyz/ :)

The situation may be different in the states, where RSA is patented, but
here around it's quite cheap :)

Andreas
-- 
Win95: n., A huge annoying boot virus that causes random spontaneous system
     crashes, usually just before saving a massive project.  Easily cured by
     UNIX.  See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.