Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[stunnel-users] Confusion regarding part of stunnel.conf

1,071 views
Skip to first unread message

Dave

unread,
Feb 9, 2011, 7:13:30 PM2/9/11
to
I've set up a test of stunnel with the latest stunnel and latest
openssl, and if I set "verify=0" or "verify=1" I can get it to work (I'm
tunneling a pop3 session), but if I set it any higher (to 2 or 3) it
won't work for me.

Now, I'm not sure which level is "necessary" because in stunnel.conf I read:
-------------------------
; authentication stuff needs to be configured to prevent MITM attacks
; it is not enabled by default!
;verify = 2
-------------------------
... which sounds like verify defaults to 0. But is a verify level of 1
enough to solve the man-in-the-middle problem? It seems like it would
not be (since level 1 will allow absence of a certificate), but I am not
sure. I guess my questions boil down to:

1) What are the necessary settings for "authentication stuff" to prevent
the MITM attack vector mentioned in stunnel.conf?
2) What is the proper way to set up (self-signed) certs to prevent such
an attack? Can a self-signed cert be used at a verify level of 2 or 3?

Dave

_______________________________________________
stunnel-users mailing list
stunne...@stunnel.org
http://stunnel.mirt.net/mailman/listinfo/stunnel-users

Ludolf Holzheid

unread,
Feb 10, 2011, 3:37:21 AM2/10/11
to
On Wed, 2011-02-09 18:13:30 -0600, Dave wrote:
> [..]

>
> 1) What are the necessary settings for "authentication stuff" to prevent
> the MITM attack vector mentioned in stunnel.conf?

As far as I understood the whole thing, you need level two or three to
force the peer to use a certificate at all.

> 2) What is the proper way to set up (self-signed) certs to prevent such
> an attack? Can a self-signed cert be used at a verify level of 2 or 3?

Self-signed certificates can't be checked against a certificate
authority (and can't be revoked). For self-signed certificates to be
handled sensibly, you need level three.

BTW, level three is not 'higher' than level two, just 'different':
Level two checks the certificate against a CA, while level three
checks it for being locally installed.

HTH,

Ludolf

--

---------------------------------------------------------------
Ludolf Holzheid Tel: +49 621 339960
Bihl+Wiedemann GmbH Fax: +49 621 3392239
Floßwörthstraße 41 e-mail: lhol...@bihl-wiedemann.de
D-68199 Mannheim, Germany
---------------------------------------------------------------

Dave

unread,
Feb 10, 2011, 11:28:42 AM2/10/11
to
> BTW, level three is not 'higher' than level two, just 'different':
> Level two checks the certificate against a CA, while level three
> checks it for being locally installed.

OK, I see the difference there. I am still confused as to how I need to set
things up on the machine on which stunnel resides using my locally-generated
private key and self-signed cert. If I set the verify level to 3 and try to
start stunnel, it won't start and says:

"Either CApath or CAfile has to be used for authentication"

If I have a self-signed cert, what needs to be in this file for things to
work? I guess perhaps I am unsure how to locally install my cert? I thought
it was already, as it's defined elsewhere in the config (cert = ....)?

Dave

Ludolf Holzheid

unread,
Feb 10, 2011, 12:29:08 PM2/10/11
to
On Thu, 2011-02-10 10:28:42 -0600, Dave wrote:
>
> [..]

>
> If I set the verify level to 3 and try to start stunnel, it won't
> start and says:
>
> "Either CApath or CAfile has to be used for authentication"
>
> If I have a self-signed cert, what needs to be in this file for things to
> work? I guess perhaps I am unsure how to locally install my cert? I thought
> it was already, as it's defined elsewhere in the config (cert = ....)?

Dave,

o cert= defines the certificate (and public key) to be presented to
the other end of the tunnel.

o key= defines the private key to be used for decryption (and thus
has to match the public key given in cert=)

o CApath= and CAfile= define the location of certificates of CAs
and/or valid peers.

That is, the location of _your_ keys and certificate is given by cert=
and key=. The location of the _CA_ certificate (verify level=2) or the
certificates of the _peers_ (verify level=3) is given by CApath= or
CAfile=.

You install a certificate of a valid peer by copying it to the
directory given by CApath= and run c_rehash on this directory, or by
appending it to the file given by CAfile=.


HTH,

Ludolf

--

---------------------------------------------------------------
Ludolf Holzheid Tel: +49 621 339960
Bihl+Wiedemann GmbH Fax: +49 621 3392239
Floßwörthstraße 41 e-mail: lhol...@bihl-wiedemann.de
D-68199 Mannheim, Germany
---------------------------------------------------------------

_______________________________________________

Dave

unread,
Feb 10, 2011, 1:43:15 PM2/10/11
to
> That is, the location of _your_ keys and certificate is given by cert=
> and key=. The location of the _CA_ certificate (verify level=2)

Ludolf,

Thanks for the explanation! I am slowly starting to understand (I think).

So, what exactly will be looked for in the CAfile when verify is set to 2? While I've been pondering this and testing things, I went ahead and set myself up as a CA so that I could sign my own cert, to test that angle. I've gotten that done, signed the cert, and this new signed cert and key work just fine at verify=1 or lower. So what should be in CAfile when verify=2? What is being looked for in that file when a connection attempt is made?

You mentioned above that CAfile would contain the location of the CA certificate, but I've tried the new CA's public pem, its private key, the server's public certs, and various combinations of those in the file referenced in CAfile (since I am not sure what exactly to put there) :), and while most of these changes would actually allow stunnel to start, connecting with a client would fail and I'd get this in the logs:

SSL alert (read): warning: no certificate
SSL alert (write): fatal: handshake failure
SSL_accept: 140890C7: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate
Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket

So I guess I've put the wrong thing in the file referenced by CAfile, but I'm still not sure I understand what it's looking for...?
Dave

Ludolf Holzheid

unread,
Feb 10, 2011, 2:56:58 PM2/10/11
to
On Thu, 2011-02-10 12:43:15 -0600, Dave wrote:
>
> [..]

>
> So, what exactly will be looked for in the CAfile when verify is set
> to 2?

Dave,

I use verify level three, so I didn't test yet. I expect the CAfile
to be a file with one ore more certificates in PEM format concatenated
together. 'openssl verify -CAfile <ca file> <peer certificate>' should
give 'OK'.

If a connection with the peer is made, the two instances of stunnel
(one at either end of the tunnel) present their certificates to each
other. With verify level two, each instance checks the certificate
received from the peer against the CA certificate in CAfile (or
CApath, respectively) just as "openssl verify" does.

> [..]


> and while most of these changes would actually allow
> stunnel to start, connecting with a client would fail and I'd get
> this in the logs:
>
> SSL alert (read): warning: no certificate
> SSL alert (write): fatal: handshake failure
> SSL_accept: 140890C7: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate
> Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket

I'm not sure about the first two lines, but the third one says the
peer did not present a valid certificate, i.e. it possibly presented a
certificate which could not be successfully verified.

HTH,

Ludolf

--

---------------------------------------------------------------
Ludolf Holzheid Tel: +49 621 339960
Bihl+Wiedemann GmbH Fax: +49 621 3392239
Floßwörthstraße 41 e-mail: lhol...@bihl-wiedemann.de
D-68199 Mannheim, Germany
---------------------------------------------------------------

_______________________________________________

Dave

unread,
Feb 10, 2011, 4:08:11 PM2/10/11
to
> If a connection with the peer is made, the two instances of stunnel
> (one at either end of the tunnel) present their certificates to each
> other. With verify level two, each instance checks.......

Wait, so in my case, there is not an instance of stunnel on each end. It is like this:

<offsite-connecting-client> connects to --->
<mainserver:995> (port 995 created by stunnel in server mode on mainserver) forwards to --->
<mainserver:110> (standard pop3 running on same machine as stunnel server)

So is verify 2 or 3 only necessary when there is an stunnel instance on each end? If I'm just connecting to stunnel from an offsite mail client, with stunnel running on the same machine as and solely to provide a secure connection to the pop3 service, is this all a moot point?

Dave

Ludolf Holzheid

unread,
Feb 11, 2011, 3:37:01 AM2/11/11
to
On Thu, 2011-02-10 15:08:11 -0600, Dave wrote:
>
> [..]

>
> So is verify 2 or 3 only necessary when there is an stunnel instance
> on each end? If I'm just connecting to stunnel from an offsite mail
> client, with stunnel running on the same machine as and solely to
> provide a secure connection to the pop3 service, is this all a moot
> point?

No, there is no need for stunnel on both sides. Let's call it 'SSL
encryption engine' instead, which could be built-in into the mail
client or be a separate process such as stunnel.

However, for verify level two or three, the client-side encryption
engine needs to present a client certificate to the server. Some years
ago, as I started to use stunnel, this was not the case for Outlook's
encryption engine. (I don't know why one would like to authenticate
the server, but not the client -- there is a German proverb saying
'nearly hit is missed too' ;-) ).

In order to test the server-side stunnel setup, I would propose to run
a client-side stunnel first, possibly on the same machine as the
server-side stunnel.

You may use "telnet localhost <port>" then to open a connection to the
POP3 server (in clear-text or encrypted if <port> is 110 or the port
the client-side stunnel listens on, respectively).

A POP3 server welcomes new clients with '+OK', and the clean way for a
client to close a connection is to say 'quit'.

Ludolf

--

---------------------------------------------------------------
Ludolf Holzheid Tel: +49 621 339960
Bihl+Wiedemann GmbH Fax: +49 621 3392239
Floßwörthstraße 41 e-mail: lhol...@bihl-wiedemann.de
D-68199 Mannheim, Germany
---------------------------------------------------------------

_______________________________________________

Dave

unread,
Feb 11, 2011, 2:23:32 PM2/11/11
to
> However, for verify level two or three, the client-side encryption
> engine needs to present a client certificate to the server.

Is this client certificate you mention one of the certs of the server being connected to (is it from "mainserver"? or the CA I created?)? Like, will I have to pass out this cert to any clients I know will be connecting, so that they all have it, before they can connect at level 2 or 3? Or is it just something built into the software a connecting person is using?

I apologize for my ignorance and appreciate your patience, I just haven't had to worry about something like this in setting up any SSL-secured services before. For example, with https, as long as the web server is configured to serve that protocol, it "just works" and you don't have to worry about providing certs to everyone connecting to your web site. (Or perhaps I'm making a leap there, and you don't mean above that each client has to have a copy of some cert from the server.) I guess I'm trying to figure out the difference between that and this issue with stunnel.

Dave

Ludolf Holzheid

unread,
Feb 11, 2011, 3:48:12 PM2/11/11
to
On Fri, 2011-02-11 13:23:32 -0600, Dave wrote:
>
> Is this client certificate you mention one of the certs of the
> server being connected to (is it from "mainserver"? or the CA I
> created?)? Like, will I have to pass out this cert to any clients I
> know will be connecting, so that they all have it, before they can
> connect at level 2 or 3? Or is it just something built into the
> software a connecting person is using?

You should create one certificate for each client. In this way you
will be able to revoke certificates for single clients.

It does not matter whether these are self-signed or signed by a CA as
long as stunnel is able to check them against a white list (in case of
self-singed ones) or a black list (in case of the certificates signed
by a CA).

The clients have to configure their mail programs to use this
certificate while connecting to your server.

> I apologize for my ignorance and appreciate your patience, I just
> haven't had to worry about something like this in setting up any
> SSL-secured services before. For example, with https, as long as
> the web server is configured to serve that protocol, it "just works"
> and you don't have to worry about providing certs to everyone
> connecting to your web site. (Or perhaps I'm making a leap there,
> and you don't mean above that each client has to have a copy of some
> cert from the server.) I guess I'm trying to figure out the
> difference between that and this issue with stunnel.

The goal of SSL-securing an HTTP server is to encrypt the conversation
(in order to hide e.g. bank details of the customer on the way to the
server) and to provide a way to authenticate the server (i.e. the
customer shall be given a possibility to ensure the server he
connected to is run by the company he wants to order from).

Thus, HTTP servers usually don't verify client certificates. (The
fact, HTTP users usually don't check the owner of the server
certificate, is an other issue.)

If one would SSL-secure an HTTP server with stunnel, it would usually
run with verify level one or zero (at least for web stores and sites
like that).


In the other hand, if you want to run an SSL-secured POP3 server, it
is essential to authenticate the client. As it is much easier to send
forged e-mails than to set up a forged POP3 server, it is not that
interesting to authenticate the server.

So if you SSL-secure a POP3 server with stunnel, it should run with
verify level two or three to force the clients to authenticate
themselves.

HTH,

Ludolf

--

---------------------------------------------------------------
Ludolf Holzheid Tel: +49 621 339960
Bihl+Wiedemann GmbH Fax: +49 621 3392239
Floßwörthstraße 41 e-mail: lhol...@bihl-wiedemann.de
D-68199 Mannheim, Germany
---------------------------------------------------------------

_______________________________________________

Dave

unread,
Feb 11, 2011, 6:00:58 PM2/11/11
to
> You should create one certificate for each client. In this way you
> will be able to revoke certificates for single clients.

OK, I'm starting to get a grasp on the bigger picture here. I re-read through some of the stunnel docs with some of your information in mind, and also through some of the docs here:

http://wiki.dovecot.org/SSL, and particularly:
http://wiki.dovecot.org/SSL/CertificateCreation

From dovecot, I know, not stunnel, but had some good info about what goes in the different various files and was some good additional info.

I think I'm going to have to start from the ground up, I've got so many certs and concatenated pems and copies of crls that it's getting confusing. But I think I understand more what needs to be in each file, and more importantly WHY those things need to be there, so I will do some re-creation and test things out.

Out of curiosity, how do large corporations handle the installation of one of their certs on all of the client machines? Because it seems like that would be a pain! Like, for example, if one were to set up their mail client to handle their gmail account, how does Google make the connection to your mail client safe from a MITM attack if you've not pre-installed one of their certs? I guess perhaps because they'd have a cert built into the mail client by default?

Dave

Ludolf Holzheid

unread,
Feb 12, 2011, 8:23:29 AM2/12/11
to
On Fri, 2011-02-11 17:00:58 -0600, Dave wrote:
>
> [..]

>
> Out of curiosity, how do large corporations handle the installation
> of one of their certs on all of the client machines? Because it
> seems like that would be a pain! Like, for example, if one were to
> set up their mail client to handle their gmail account, how does
> Google make the connection to your mail client safe from a MITM
> attack if you've not pre-installed one of their certs? I guess
> perhaps because they'd have a cert built into the mail client by
> default?

I think those sites use SSL for encryption only. Client authentication
is done by the good old user name/password pair. At least this is the
case for my mail account at GMX.

Ludolf

--

---------------------------------------------------------------
Ludolf Holzheid Tel: +49 621 339960
Bihl+Wiedemann GmbH Fax: +49 621 3392239
Floßwörthstraße 41 e-mail: lhol...@bihl-wiedemann.de
D-68199 Mannheim, Germany
---------------------------------------------------------------

_______________________________________________

0 new messages