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
On Wed, 2011-02-09 18:13:30 -0600, Dave wrote:
[..]
- 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.
- 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
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
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
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
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
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
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
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
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
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
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
-
Dave -
Ludolf Holzheid