Hello list,
this is to inform you that the Usenet kabal & I have decided to modify
deeply the Nessus transport layer.
Why? Because libpeks is buggy, as any piece of code in fact, and
strongly "newbie unfriendly", as most pieces of cryptographic
software. There are many messages on the Nessus mailing list on
related topics; and the load of support is heavy.
More, a cryptographic layer is a fragile clockwork, and as far as
security is concerned, we cannot beat the huge research and
cross-examination on standard layers
Starting from this, I came to the conclusion that it would be great
if, at least, we got rid of the software maintenance load.
We had several possibilities:
1. Remove libpeks, or disable it by default.
This means that the passwords and the reports may be sniffed.
Definitely not great (we could at the same time remove this odd SSH
software and switch back to clear text telnet :)
2. Work hard on it to make it failsafe and fool proof... forever.
Unfortunately, "you can make it fool proof, but you cannot make it
damned fool proof".
There is _always_ a way for a newbie to shoot himself in the foot with
some dangerous asymetric key. Where I wrote "work hard", read "really
hard", as a cryptographic layer may be very complicated (look at SSL).
3. Use some external layer.
Point (1) could not be chosen, point (3) is cheaper than point (2),
although it will probably not solve the "shoot the newbie's foot"
problem.
I looked around (very quickly, I have to admit) and saw two potential
solutions: libmcrypt and SSL.
The big plus for SSL is that it is standard, based upon the famous
X509 norm. Yeah, great! The famous f* brain damaged awfully complex
BAD (Broken As Designed) X509 norm <grin>.
(Note: X509 caliber is designed so that you shoot you in the foot only
once. After that, you have no foot any more)
Anyway, a bad standard is often better than an excellent specific
software.
We have OpenSSL that works and is supported (that solves the software
maintenance problem) and we have kazillons of RFCs, norms, FAQs,
HOWTOs, tutorials, white papers, etc., on the topic, so we may dream
that the "customer support" load is reduced.
Last but not least, X509 is fashionable and could be inserted in the
expensive company PKI, and that is definitely *great* :-]
I added a small SSL support in Nessus 1.1.x (e.g. it can test SSL
based services) and may imagine that I understood the big gizmo, or
at least would spend less time deciphering the documentation than
learning to use mcrypt from scratch.
So... I chose SSL, because it is based upon RFCs that are based
upon ISO standards (got the message? :)
And among the numerous SSL software, the free one, OpenSSL, as Nessus
is already linked to it.
Now... Why do I bother you with all this? Because it is not too late
to stop me from shooting _you_ in the foot :)
Currently, I have something "that works". i.e., nessus can connect to
nessusd through SSL, and then launch a basic username/password
authentication in the enciphered pipe.
Any communication afterwards goes into the SSL pipe. So far so good,
although I suspect that there are some nasty bugs just waiting for my
holidays to pop up (especially in the ugly timeout management)
What _should_ be done:
- the client software should validate the server certificate, or at
least show it to the use before he enters his password for the first
time (we can remember the certificate fingerprint afterwards)
- offer a procedure to build your own CA and certificates, or at
least install some standard certificate, signed by Snake Oil Inc. or
Nessus.org
(note that this "backup plan" allow anyone to steal your password if
he can hijack your connection. dsniff rulez)
- implement some kind of strong user authentication, based upon the
certificates.
(what _might_ be done)
It is very easy to make the client certificate compulsary (and of
course, it has to be signed by a trusted CA). Identifying the user
with the content of the certificate is a little more complex:
should I use the full subject name, or just the "CN" or the e-mail
address?
What _should not__ be done:
- keep SSL *and* PEKS in the code
One is enough, two will make the maintainers crazy. If you want to
keep SSL (for any reason, good, bad, technical, sentimental,
whatever...), I'll drop SSL. rm -rf is quick and painless.
Comments welcome.
--
mailto:arboi@bigfoot.com http://www.bigfoot.com/~arboi/
GPG Public keys: http://www.bigfoot.com/~arboi/pubkey.txt
FAQNOPI de fr.comp.securite : http://www.bigfoot.com/~arboi/secu/FAQNOPI/
this is to inform you that the Usenet kabal & I have decided to modify
deeply the Nessus transport layer.
Why? Because libpeks is buggy, as any piece of code in fact, and
strongly "newbie unfriendly", as most pieces of cryptographic
software. There are many messages on the Nessus mailing list on
related topics; and the load of support is heavy.
More, a cryptographic layer is a fragile clockwork, and as far as
security is concerned, we cannot beat the huge research and
cross-examination on standard layers
Starting from this, I came to the conclusion that it would be great
if, at least, we got rid of the software maintenance load.
We had several possibilities:
1. Remove libpeks, or disable it by default.
This means that the passwords and the reports may be sniffed.
Definitely not great (we could at the same time remove this odd SSH
software and switch back to clear text telnet :)
2. Work hard on it to make it failsafe and fool proof... forever.
Unfortunately, "you can make it fool proof, but you cannot make it
damned fool proof".
There is _always_ a way for a newbie to shoot himself in the foot with
some dangerous asymetric key. Where I wrote "work hard", read "really
hard", as a cryptographic layer may be very complicated (look at SSL).
3. Use some external layer.
Point (1) could not be chosen, point (3) is cheaper than point (2),
although it will probably not solve the "shoot the newbie's foot"
problem.
I looked around (very quickly, I have to admit) and saw two potential
solutions: libmcrypt and SSL.
The big plus for SSL is that it is standard, based upon the famous
X509 norm. Yeah, great! The famous f* brain damaged awfully complex
BAD (Broken As Designed) X509 norm <grin>.
(Note: X509 caliber is designed so that you shoot you in the foot only
once. After that, you have no foot any more)
Anyway, a bad standard is often better than an excellent specific
software.
We have OpenSSL that works and is supported (that solves the software
maintenance problem) and we have kazillons of RFCs, norms, FAQs,
HOWTOs, tutorials, white papers, etc., on the topic, so we may dream
that the "customer support" load is reduced.
Last but not least, X509 is fashionable and could be inserted in the
expensive company PKI, and that is definitely *great* :-]
I added a small SSL support in Nessus 1.1.x (e.g. it can test SSL
based services) and may imagine that I understood the big gizmo, or
at least would spend less time deciphering the documentation than
learning to use mcrypt from scratch.
So... I chose SSL, because it is based upon RFCs that are based
upon ISO standards (got the message? :)
And among the numerous SSL software, the free one, OpenSSL, as Nessus
is already linked to it.
Now... Why do I bother you with all this? Because it is not too late
to stop me from shooting _you_ in the foot :)
Currently, I have something "that works". i.e., nessus can connect to
nessusd through SSL, and then launch a basic username/password
authentication in the enciphered pipe.
Any communication afterwards goes into the SSL pipe. So far so good,
although I suspect that there are some nasty bugs just waiting for my
holidays to pop up (especially in the ugly timeout management)
What _should_ be done:
- the client software should validate the server certificate, or at
least show it to the use before he enters his password for the first
time (we can remember the certificate fingerprint afterwards)
- offer a procedure to build your own CA and certificates, or at
least install some standard certificate, signed by Snake Oil Inc. or
Nessus.org
(note that this "backup plan" allow anyone to steal your password if
he can hijack your connection. dsniff rulez)
- implement some kind of strong user authentication, based upon the
certificates.
(what _might_ be done)
It is very easy to make the client certificate compulsary (and of
course, it has to be signed by a trusted CA). Identifying the user
with the content of the certificate is a little more complex:
should I use the full subject name, or just the "CN" or the e-mail
address?
What _should not__ be done:
- keep SSL *and* PEKS in the code
One is enough, two will make the maintainers crazy. If you want to
keep SSL (for any reason, good, bad, technical, sentimental,
whatever...), I'll drop SSL. rm -rf is quick and painless.
Comments welcome.
--
mailto:arboi@bigfoot.com http://www.bigfoot.com/~arboi/
GPG Public keys: http://www.bigfoot.com/~arboi/pubkey.txt
FAQNOPI de fr.comp.securite : http://www.bigfoot.com/~arboi/secu/FAQNOPI/