Kyle Hamilton wrote:
On Wed, Dec 24, 2008 at 1:27 PM, Edward Diener <el...@tropicsoft.com> wrote:
Kyle Hamilton wrote:
If you're on Windows, it does make sense to include the PEMs for the
CA (and chain) in the application directory. (See, for example, the
software distribution of Second Life, which has its own CA for TLS
authentication of its own grid servers.)
For client certificates, though, it depends. If it's a per-user
certificate, the certificate (and key) should go in the user's home
directory (in a folder not unlike, but also not, ~/.ssh) -- and should
have permissions which only allow the user access. If it's a
per-machine certificate, the certificate (and key) should go under
either /etc/ or /var/ (on *nix) or the application directory (on
Windows).
It is a per-machine cert in my case under Windows. But it is solely for the
use of a single application. I certainly can distribute the certs in the
common application directory under Windows but that complicates the issue
under Windows Vista protected mode, where certain directories are off-limits
to a running application unless the application runs with Administrator
rights, which is something not being required of the end user once the
application has been installed. Nonetheless it is a good idea to consider.
At least the certs are more hidden there than in the application directory.
If it's under Windows, you can place the certificate (and key) in your
app's registry. You could also use the so-called "native" API to
embed a NUL character ('\0') in the name of the key you place it in.
See http://technet.microsoft.com/en-us/sysinternals/bb897446.aspx for
information on this (look for "Hidden Registry Keys" on the page);
however, be aware that many rootkit scanners will find and delete
these WinSDK-inaccessible entries.
My interpretation of using the Windows registry is that a very long
string should not be placed there, even if I could obfuscate the actual
key using the NUL character technique you mention above.
This is a red flag to most security-conscious hackers, though, and
many will do anything they can to figure out what's in there.
I fully agree.
Also, the host/port must be considered public information. They can
be easily derived with netstat.
You are right.
If I encrypt the cert files pre-installation I would use the the Windows
Crypto API library to do so, and then use the same library at run-time to
decrypt it and put it someplace temporarily in order to user the cert files.
I have already used the Crypto API successfully so I know it can be done
fairly easily.
If you're using CryptoAPI, why are you not using it for key storage as well?
According to the MySQL client documentation using the C/C++ API, I must
pass file names to the API where my CA, client certificate, and client
key reside.
Furthermore the CryptoAPI is not a storage mechanism, only an
encrypt/decrypt mechanism AFAIK.
I do not think I really need to scramble anything once the data is encrypted
as the "strings" are just totally encrypted sequences of byte information
once Crypto API encrypts them.
The openssl library (libeay) can do everything that cryptoAPI can do,
as well. It doesn't use the same API convention, though.
I am not using OpenSSL directly in my application, although I suppose I
could do so. I find the CryptoAPI pretty adequate and the doc for the
CryptoAPI which Microsoft supplies is quite good.
This is potentially a very good idea. At least I could keep everyone except
my application from easily viewing the certs.
No, since your application runs with the user's rights, the user must
be able to read the certs and key.
The user meaning my application. You are correct.
It is my employer who has been told that
distributing the certs so that an end user can easily view them is a
security risk.
This is absolute garbage. The idea behind certificates is that they
uniquely identify the consumer's public key (and thus the private key
they use with it), and they're signed by someone you trust. You can
also embed a critical extension in the certificate so that no other
X.509 application would or could use it. You don't have to put any
kind of private or confidential data in the certificate itself. (It
is the PRIVATE KEY which must be kept protected.)
I totally agree with you.
I'd like to know the name of the rep at Sun who told your employer
this, so I can go to Sun and say "you need to train your developer
liaisons better about X.509 and asymmetric cryptography."
I would gladly give it to you if my employer agreed to do it. I did not
think the Sun representative was right.
My own viewpoint is that the certs are useless without
host-name/username/password/database knowledge of the server database anyway
so there is little point really in inventing elaborate measures to hide the
certs from the end users eyes.
MySQL uses the certificate itself to identify the user to the
database, avoiding the use of a password entirely -- but only if the
certificate is issued by a trusted authority. The hostname/port is
public information (remember, netstat). The username which is used to
authenticate to the application is tested against the database, and
the password is as well. (You are remembering not to store the users'
passwords in clear-text, right?)
None of the information is stored as clear-text.
But he has asked me to investigate the ways it can be done nonetheless.
You should instead be focusing on mitigating what happens WHEN (not
IF, because it WILL HAPPEN) someone manages to break the security of
your application and server. That's where you should be focusing your
development time/effort, not on some "makes the manager feel warm and
fuzzy" security theater. (You have my authorization to print out this
message and share it with him, if you think it would do any good.)
I will do so. My employer is not my "manager" but rather a private
individual who runs a company and who employs me as a consultant to work
on the software he needs. He is a very decent person, and I did try to
convince him that distributing the certs as part of the application is
not a security risk about which he should worry. He has focused on other
issues, particularly the server side database and server security which
would prevent a disruptive hacker from gaining access to the server data.
I am not try to make him feel "fuzzy and warm" but just trying to
answers his concerns in a rational way by asking others who know about
certs and security about the issue of distributing the certs.
Depending on
how important it is that the data be secure, you may need to ensure
that a given client key is only used from a specific IP address or IP
range...
It is an application to be sold to end users, so the 'from' IP address can
not be pre-established. We do have ways from within the application to make
sure that the client is a registered user which takes into account the
client's machine. But of course a destructive hacker who could use the
client certs along with the host-name/username/password/database knowledge
to access the database is not running from within the application.
This is what needs to be mitigated, not "the access to read the certificate".
Then again, if your boss is really THAT paranoid, you should be
creating the keypair on the client machine, sending the public key in
for signing by your own CA, and using the certificate that's been
returned. This could be done during installation, or upon realization
that an anti-rootkit software erased the private key and certificate.
A server side MySQL consultant was entrusted to setup the server side
database, generate the certs, and pass the client side certs to me. My
job in this regard is to write the client side code which uses the certs
to communicate to the MySQL server database using SSL. I have been
successful in doing so. Now the issue is distributing those certs as
part of the application.
and you may also need to be on the lookout for inappropriate
access patterns (any 'select *', for example, if your application
doesn't use that means of getting data out of the tables) -- and if
you do see it, boot the connection from the server and invalidate the
client authentication credentials.
I do not know how I can 'see' such patterns from within the application
itself. I do not think a destructive hacker can easily change the
application, even knowing the client certs, but maybe there are ways and I
am willing to be educated about them.
http://www.acm.uiuc.edu/sigmil/RevEng/ has an (incomplete) book on the
matter. There's also a whole slough of books on reverse engineering.
Remember, once the application leaves your machine, it is running in a
hostile world. You cannot trust the application. You cannot trust
that just because that the other end of the connection knows the
secret key (and provides the certificate) you can assume that it's an
unmodified application. You should not try to detect this from your
application -- the only thing that you have control over is the
database, and the point where the application interacts with the
database is the "demarcation" -- you get to choose what information
comes over that link that you want to act upon.
This may require modifications to the MySQL server itself, to detect
these issues -- but, the server is the only place that you can place
your control.
What are the ways that the MySQL server can detect a client-side hacking
attack, as you suggest could happen ?
One of the maxims of security-conscious programming is: "always assume
that the client is hostile." Don't ever provide any more services
than the blessed client will use.
Also, be aware that many hotels block connections to port 3306 (and,
in fact, to anything other than SMTP and HTTP/HTTPS). If this is
designed to be for the end-user on-the-go, you really shouldn't try
using a raw MySQL connection. Instead, make a web service (xml-rpc)
and perform all of your access- and bounds-checking there.
I think that is extreme. If a client is blocking the port by which the
application needs to communicate with a server, then the appplication
needs to be largely rewritten to handle this scenario. I will take that
possibility into account when I communicate to my employer, but I do not
think it is reasonable to re-engineer the application because of the
possibility. We are also not targeting hotels although the purposes of
the software is broad enough that a hotel might buy it.
Thanks for your suggestions, especially about the ACLs, which can fairly
easily be manipulated by the installation program.
With this new information about what you're doing, I'd like to know
what the name of your software is so that I can avoid it. What you're
doing is security theater, not true security.
That is an unduly harsh remark and not necessary. There is no attempt on
my part to create "security theatre". I am sincerely trying to deal with
security issues and, if the issues raised by my employer seem wrong to
you, I also did not think they were valid but I wanted to check with
others to see what they think.
I am a good enough programmer to do most anything programatically to
help solve security problems, if there is really a security problem
which others see when the certs are distributed as files in the
application's directory. If worrying about such an issue is truly
"security theatre" from your knowledge, I have no reason to hesitate in
telling my employer so and will do so, no matter what he has been told
otherwise.
Thanks for your help !
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
