On Jan 26, 2009, at 4:23 PM, Philipp Gühring wrote:
Hello Douglas,
I'm wanting to use openssl to provide a psk-like authentication and
encryption. While I see that openssl cvs has some TLS-PSK
functionality,
this does not seem to exist in any of the released tarballs. I run
gentoo and I don't see any psk related options when I run openssl
s_client --help either. In my quest to develop and distribute an
application that relies on psk-like functionality without requiring
people to build and install cvs revisions of openssl, I have decided
that this functionality isn't a reasonable route.
Yes, PSK isn't in a released tarball yet. It looks like it will be in
0.99 (whenever that will be released, I have no idea)
So I've tried to think of ways to have a psk-like functionality with
openssl. My project does not require high enough security to need
both
client and server to be able to trace certs up the CA chain to a
common
root CA, so I am relying on the server side having a self-created CA
that every cert is signed with.
Could you please explain what your project actually is, and why you
think that you don't need high security? (Or do you only require high
security regarding that the client knows that it talks to the right
server, but the server doesn't care who the client is?)
I am asking, because there are severa
My project is a MythTV client for the iPhone. There are two sticky
points in implementing a client accessing the server across an
untrusted network:
1. MythTV relies on being able to easily access all master and slave
backend server comprising the backend system.
2. MythTV's protocol has absolutely zero security outside of a 4 digit
pin for authentication only.
The simplest way for me to implement these without requiring people to
compile MythTV with special patches that very well may never get
integrated into the official sources, and certainly not anytime soon,
is to create a proxy server that a client connects to as though it
were the master backend. From there, all the requests are routed to
the correct backend for the content desired.
Of course, the protocol has read and write usage, so at the very least
authentication and signing of the protocol (but not video data)
messages is a must. I have decided that it makes the most sense to
fully encrypt the protocol connections and leave the read-only video
data connections unencrypted, at least for my iPhone client. The proxy
could, and may in the future, be modified to encrypt the video data as
well.
From there, here is the process:
- A server private key and server cert signed with self-created CA
cert
are created
Why not use an existing CA like e.g. CAcert.org ?
Thank you for the suggestion. I am new to security (hence this post)
and was not aware of a free alternative to verisign and the like. My
question concerning this is how do I know that when my client receives
a cert from the server, it can look at the data in the cert like
common name and location info, but how do I know that it isn't someone
else pretending to be my server by using the same data? In essence,
how do I know that cacert.org has sufficiently identified the identity
of those it grants certificates to? Are all granted certificates
unique in some way that can be easily tracked other than through a
different signature, i.e. something the client can use to know that it
is connecting to the server it is intending to?
If not, this still doesn't easily solve the issue of the client
verifying the first connection to the server, but again that isn't a
huge issue as long as one can compare something like a hash of the
certs to the certs created when setting up the proxy server.
- A client private key protected by a passphrase and a client cert
signed with the self-created CA cert are created
- When the client first connects to the server, the client
downloads the
client private key and client cert along with the CA cert it was
signed
with.
- The client then attempts to create an ssl connection to the server.
The client can only do this if the client public key can be decrypted
with the correct passphrase used when the private key was created.
Both
the client and server certs are verified by the self-created CA cert
that both sides now have.
How do you distribute the client software and the server software?
Server through source code download and compiling at first. This is
all open source (both proxy server and client).
What are the interests of the users, the server operators, the
attackers?
Users: Easy access to their recorded and live tv shows
Server admins: Same people as users
Attackers: Probably none, but we must be prepared :)
Why did you think that PSK would help you? You do not seem to have a
secure key-negotiation infrastructure, which is needed for PSK.
PSK without a secure key-negotiation is actually very insecure.
Perhaps you thought that PSK would give you some kind of zero-
knowledge
password authentication mechanism, where 2 parties could get a secure
connection if both knew the same key?
I may be confusing PSK with something else. I just want a password
that the user sets up on the server and enters when prompted on the
client. This system is only intended to be used and administered on
both ends by the same party. No one in their right mind would be
opening up their mythtv server to an anonymous or untrusted third party.
The one weakness in all this is the initial connection where the
client
downloads the client key and cert and shared CA cert. If the server
isn't the intended server, the client won't know. I plan on providing
for the user to confirm or reject the server based on whether the CA
cert matches what the user thinks it should (would it be safe
enough to
just MD5sum hash the CA cert and present that sum to the user?).
MD5 just got broken enough that you should use SHA1 instead.
Thanks for the info.
From
then on, the client stores the CA cert and if a subsequent man in the
middle attack is attempted, the server cert won't match the CA cert
the
client possesses.
Does this design work as I am intending, with only one set of
server and
client certs needed per server implementation?
Take a look at TLS-SRP instead of TLS-PSK.
I don't see this implemented in openssl either, aside from a patch
that one can apply. For the same reasons as TLS-PSK, I'd prefer to
rely on such a solution.
And please explain what you want to achieve.
I hope I have provided enough information, but I would be happy to
provide more if it helps.
Thanks______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
