Use certificates from Keychain

[Daniel Bertolo]

Hi

I thought a bit about what Tunnelblick could do better. One thing I
always struggle with is the deployment of configurations. I really do
like all the options that have been developed in the past years. But a
major issue still remains: I need to deploy configurations without
certificates. Our users use their real user certificates that were
generated within the OS X Keychain. Up to now, the user itself always
needed to export the certificate from the keychain which is a bit of a
hassle. Even more if the users don't really get the point of PKI.
Afterwards, the users need to put their PKCS#12 file into either the
deploy folder or the .tblk configuration file. This isn't really the
way it could be.

The first idea that came to my mind was what I suggested in issue 176:
Let Tunnelblick check the config file with a .tblk package upon
installation for missing files. In my case, I could deploy config
files without certificate and Tunnelblick would ask the user which
file to import.

But The Real Thing (r) that Tunnelblick could do is to use the
certificate from the Keychain itself. Just the way browsers such as
Safari or Google Chrome do it. Probably the easier way to implement
would be to check for missing certificates upon install of a config
file. Then let the user select its certificate from the Keychain and
export it into the configuration file (don't forget the CA chain ;)).
The more secure way would probably be to use the certificate upon
connection. I don't really know if the Keychain actually serves a copy
or if there is an API you can use. But the latter probably should be
supported by the OpenVPN binary and not by Tunnelblick.

In conclusion, Tunnelblick should separate the deployable
configuration (config, CA certificates, TLS authentication keys) from
the personal credentials.

Any other ideas or comments?

Regards,
Daniel

[jkbull...gmail.com]

Thanks for your thoughtful comments.

There is a patch to OpenVPN that provides an option that (without Tunnelblick being involved) pulls certificates from the user's Keychain. I don't know the status of it (whether or not it has been accepted and included into the official OpenVPN releases, although I think it hasn't, because of a lack of testers). I know of one other Tunnelblick user who tried it and it worked except that it would not work on "when computer starts" configurations because it only checks the "Login" Keychain, and thus requires a logged-in user. I will forwarded my copy of the original email thread that discusses this patch you privately. I know there have been subsequent mentions of the patch by the OpenVPN developers in their IRC meetings, but don't remember what happened with it.

I think an OpenVPN solution such as this patch would be the best way to get this done -- especially since it is done upon connection and doesn't involve Tunnelblick at all.

An alternative that I am vaguely aware of is to use "certificate requests" -- .csr files. I don't know how they work, but I think the idea is the same as yours -- that the user generates their own credentials instead of having them be generated and maintained centrally. But they may not be implemented on OS X -- I really know very little about it.

Importing Keychain certificates into a .tblk upon install of the .tblk is another possibility. However, I don't like the idea of the user having to use Keychain Assistant to "export" to a file and then specify the file to Tunnelblick -- I would rather not involve the user in the process at all. I don't recall that there is an API for Tunnelblick to ask the Keychain for a list of Keychain items (which would be needed for the user to "pick" which Keychain item to use), so perhaps Tunnelblick could use a standard name for the Keychain items it wants, based on the name in the config file. In other words, if the config file had "cert ABCDE.p12", then Tunnelblick would look first for file ABCDE.p12 and put that in the .tblk if it exists, then look in the Keychain for an item called ABCDE.p12 and, if found, create an ABCDE.p12 file with its contents and put that in the .tblk.

I don't see this as being useful except for a small set of users like your organization, though, so it would not be a high priority for me.

[Mohammad A. Haque]

I also wouldn't consider this to be something for Tunnelblick as it's openvpn that requires the certificates.

I attempted to test the patch many months ago and could not get it to work. Don't know if I was doing something wrong of the patch is broken.

-- 

You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.

To post to this group, send email to tunnelbli...@googlegroups.com.

To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en.

[Friedrich Romstedt]

2011/5/19 jkbull...gmail.com <jkbu...@gmail.com>:

> An alternative that I am vaguely aware of is to use "certificate requests"
> -- .csr files. I don't know how they work, but I think the idea is the same
> as yours -- that the user generates their own credentials instead of having
> them be generated and maintained centrally.

Just to clarify this and for the entertainment of the list subscribers
- I think Daniel might get bored :-) - the use of csr (certificate
signing requests) is to keep the key of the user private.

CSRs work the following way:

1. The user (client) generates a key & and a csr on his machine. The
key should be stored in a safe place, and there will be no necessity
anymore to transfer the key between machines. This is the ideal
configuration one can reach.
2. The user sends the csr via any channel, even my email, to the
authority (ca or similar).
3. The CA signs the csr, this means, it creates a certificate out of
it using its private key.
4. The CA cert will have to be transmitted somewhen now. This can
happen, as for all certs, via insecure channels.
5. The CA sends back also the Cert newly created for the client (user).
6. Now the client has a key and a cert (for use with the asymmetric
en/decryption) and noone came in contact with its key.

The same procedure usually happens for the server (which is distinct
from a CA); ideally the CA is a non-networked machine to prevent any
attacks except physical ones.

So now:
- The server has a key, generated by random, and can publish a cert,
wich is generated out of the server's csr using the CA's key. The
server also has access (as anybody has) to the CA's cert.
- The client has a key, generated by random, and can publish a cert,
... and so on (same as for the server).

Now, for the following, I'm not completely sure, I'm just using
logical reasoning.

Any instance can check if any cert is signed by the CA. For this only
the CA's cert is necessary (otherwise it wouldn't make sense).

When the client connects to the server, it's transmitting its cert,
and the server will check if this is signed by CA or not. If it is
so, it'll accept the connection, and I guess he's sending back the
server's cert. Note that certs are always public, so it might send
the cert back also without restriction, I guess it wouldn't matter
much.

Guess the client is checking the same regarding the server's cert
using his own copy of the CA's cert.

Now as the server trusts the client, it'll start sending encrypted
data and will start to decrypt data from the client. Now it's merely
a matter of choice IMO if one uses the cert for crypting and the key
for decrypting or vice versa, but I strongly guess, it's more
important to not be able to listen to the communication, so the key
will be used for deciphering and the cert for enciphering. Thus
anybody might send data into the channel, using the certs exchanged,
but the intruder doesn't possess the key, so he can't decrypt
anything. That's the reason why the key is of such prime importance
and should not be even transmitted between different machines.

Same happens of course for the client. He'll use the server's cert to
send data to the server, data which he cannot even encrypt himself
:-), and will use its key to decrypt the data sent by the server.

I will not go into details of my understanding of establishing trust,
that's a matter of CA, and who's reading the technical explanation on
MS Windows 7 Updates, will have noticed, that recently (according to
the message), there was an update to the cert db in Windows because
some CA-delegate has signed some certificates which better would not
have been signed ...

So now, this was a nice exercise to think it through once more. Hope
you enjoyed (or: could enjoy it :-)

Correct me if there is any wrong in the section lead in by "For the
following I'm not completely sure". For the section how the procedure
is I am sure, because I did it several times. But I'm not an expert
on the algorithms used to implement PKIs (public key infrastructures).

> But they may not be implemented
> on OS X -- I really know very little about it.

openssl, afaict, came bundled with my OS X 10.6. At least when I
needed it, let it be before or after installing Tunnelblick, $openssl
opened a nice and shiny ``OpenSSL> `` prompt. openssl (or any
equivalent) is anything needed for doing the csr/crt/key stuff. There
goes some work into designing the openssl.cnf, though. There is some
"easyrsa" around coming with openvpn, but I regard this not as useful
as it seems. It prevents the user from understanding what he's doing.

cul,
Friedrich

[Gian Uberto Lauri]

On Saturday, May 21, 2011 12:02:36 PM UTC+2, Friedrich Romstedt wrote:

2011/5/19 jkbull...gmail.com <jkbu...@gmail.com>: 

openssl, afaict, came bundled with my OS X 10.6.  At least when I
needed it, let it be before or after installing Tunnelblick, $openssl
opened a nice and shiny ``OpenSSL> `` prompt.  openssl (or any
equivalent) is anything needed for doing the csr/crt/key stuff

Does this mean that I can give Mac OS X users the same instructions I supply to GNU/Linux|Unix users, possibly the same helper script ?

I am setting up a VPN with OpenVPN for remote users outside my organization (they are partner in research project) and I want to support GNU/Linux|Unix, Windows and Mac OS X (that should be an Unix, at least according to Apple demo). 

Since we have remote users, we need them to generate their own private key and a csr that I will sign with the server private key. While I found that Windows GUI has an utility to generate key and csr, i did not find any in Tunnelbrick, so I am looking for infos about the private key/csr generation on Mac OS X.

[jkbull...gmail.com]

I think you can use the same instructions.

Tunnelblick doesn't help with keys/certificates, but OS X does include OpenSSL. Usually the OpenSSL included in OS X is not the most recent version available. Tunnelblick includes the most recent version of the OpenSSL library (but not the command line utility itself) so it can support the latest ciphers and digests, even on older versions of OS X, which may have older versions of OpenSSL..

The OpenVPN source includes some command line utilities in the "easy-rsa" directory that make certificate/key generation easier.

[Gian Uberto Lauri]

But easy-rsa requires the CA certificate, so it is unsuitable for our purpose.

[Friedrich Romstedt]

2011/10/1 Gian Uberto Lauri <gianuber...@gmail.com>:

> But easy-rsa requires the CA certificate, so it is unsuitable for our purpose.

No, AISI, certs are always meant to be public. You can transmit them
via any channel, including insecure ones like email. AFAIK, there's
no more use to a cert alone than verifying another cert if that other
cert has been signed by the first cert we're checking against (aside
of using it for communication). For signing of course you need the
key (this follows for me because of pure logic, since otherwise
anybody could sign). I don't see from the openssl commands how the ca
key goes in, since it's not mentioned on e.g. this line:

> ca -days 3650 -out "VPN-Server.crt" -in "VPN-Server.csr" -extensions server -config openssl.cnf

But from my local openssl.cnf I see that the CA section refers to the
private_key. So that's the point where the ca key goes in. You see,
you have to dive a bit to understand what's going on.

In fact, if you're going to build up a PKI, you'll have to transmit
the ca's cert to your clients (by some means), so that they're able to
verify the cert promoted by the server of the vpn they're connecting
to. Since communication can only happen when the server has the key
too, the communication channel is called secured by this. (The
verification happens mutually.) Otherwise, without verification, the
server could be any internet host. In fact, anybody could use the
cert of your server to promote it on connection, but he'll be unable
to take fully part in the communication (AFAIR, the certs are used for
enciphering and the keys for deciphering). A signed cert just say's
"the owner of this cert has a key we allow to take part in
communication". "The owner" is defined by the fact that this thing or
person has the key. Since you never publish keys (that's the purpose
of creating them on the machines where we need them), we can secure
the channel by verification of certs, although anybody can propose the
certs. But only the owners have the key too.

So far to that, I hope I'm not boring you all.

So in summary, just publish the ca's key to your clients. But the
transmission is a crucial thing, since if it is modified, it could be
exchanged by a cert of another company. To my needs, I've been using
phone-verified instantaeous emails, or physical tranmission by an
administration (which is me). But my network is really tiny. Just
keep in mind that the clients will establish trust to your VPN
server's cert through the ca cert *only*. At some point we have to
establish trust without a secured channel active, so we have to use
some other definition of "secure" before the vpn is up. Using two
channels simultaneously (email and phone, email & skype, etc.) in
general secures the transmission better.

One more note, just for completeness: It's of course self-understood
that the CA and the VPN server are distinct entities. If you want to
be very secure, the CA is (as you probably are doing) a non-networked
machine.

And finally, unless you want to establish sub-CAs, make sure the
cert/key pairs you create by signing the csr are not suitable for
sub-signing other certs. I've never worked with sub-CAs so far, but
AISI, the certs signed by the sub-CA will be automatically signed by
you too (since you shared the power). I.e., users can enable other
machines to connect to your vpn server. But here, I'm close to the
border of my solid ground, and maybe already beyond. It's to be
understood as a pure warning.

One of the things I don't like about easy-rsa is that it's, to my
understanding, way to easy to just issue the commands and not
understanding what's happening and why it's working. (And why it's
done this way.)

For the OS X thingy, you might want to use .tblk directories, they're
easier to handle from the user's perspective.

Correct me if I'm wrong.

So far, hth,
Friedrich

[Gian Uberto Lauri]

On 10/02/11 17:12, Friedrich Romstedt wrote:
> 2011/10/1 Gian Uberto Lauri<gianuber...@gmail.com>:
>
>> But easy-rsa requires the CA certificate, so it is unsuitable for our purpose.
>>

I meant key but wrote certificate, sorry. And it is required by the
scripts in easy_rsa.

> understanding, way to easy to just issue the commands and not
> understanding what's happening and why it's working.  (And why it's
> done this way.)
>

I needed something easy for the remote users for building their own
private key. I solved it reading
the openssl manual. I will prepare a script good for users of all Unix
flavors and they may pick it or read openssl manual if they want :)

--
ing. Gian Uberto Lauri
Ricercatore / Reasearcher
Laboratorio Ricerca e Sviluppo / Research & Development Lab.
Area Calcolo Distribuito / Distributed Computation Area

GianUber...@eng.it

Engineering Ingegneria Informatica spa
Corso Stati Uniti 23/C, 35127 Padova (PD)

Tel. +39-049.8283.571         | main(){printf(&unix["\021%six\012\0"],
Fax  +39-049.8283.569          |    (unix)["have"]+"fun"-0x60);}  
Skype: gian.uberto.lauri      |          David Korn, AT&T Bell Labs            
http://www.eng.it               |          ioccc best One Liner, 1987            

[jkbull...gmail.com]

 I will prepare a script good for users of all Unix
flavors and they may pick it or read openssl manual if they want :)

Great! Please post a link for it here or submit it for the Tunnelblick user-contributed downloads section of the Downloads page.

 

[jkbull...gmail.com]

You shoujld also look into Certificate signing requests

[Daniel Bertolo]

Hi all

Long time no update.

Actually, I just stumbled upon this: <https://community.openvpn.net/openvpn/ticket/8>. The keychain patch for OpenVPN is ready to be tested since ages. They actually planned to introduce it in OpenVPN 2.2. But as nobody tested the patch, they didn't.

Couldn't you add an OpenVPN binary that contains this patch?

Regards,

Daniel

[jkbull...gmail.com]

I could -- especially now that Tunnelblick includes multiple versions of OpenVPN and has a user interface to choose which one to use -- but this is a very low priority for me, given

• There doesn't seem to be a lot of interest, and
• The problem with the patch from Tunnelblick's perspective (it only works with the "Login" keychain).