Hello,
Thanks for writing stunnel, it looks like a great tool!
I have, however, a really hard time understanding the difference between verify=2,3 and 4. In the manpage, I found
verify = level verify peer certificate
level 0 - request and ignore peer certificate level 1 - verify peer certificate if present level 2 - verify peer certificate level 3 - verify peer with locally installed certificate level 4 - ignore CA chain and only verify peer certificate default - no verify
Levels 0-2 seem pretty clear cut, but then it becomes confusing for me.
First, I do not understand how level 3 differs from level2. What does "against a locally installed certificate" mean? It seems to me that I certainly need to have a local copy of the trusted CAs even in level 2 -- at least I hope that they aren't somehow build in to stunnel. But there is also just one CApath option, so will that be used for level 2 or level 3?
For level 4, the "ignore the CA chain" path is fine -- but where do I put the peer certificates that I'm willing to accept? CApath seems wrong, but cert is already used for the server's own certificate...
Best,
-Nikolaus
On Fri, 13 Sep 2013 22:55:14 -0700 Nikolaus Rath [email protected] wrote:
Hello,
Thanks for writing stunnel, it looks like a great tool!
I have, however, a really hard time understanding the difference between verify=2,3 and 4. In the manpage, I found
verify = level verify peer certificate level 0 - request and ignore peer certificate level 1 - verify peer certificate if present level 2 - verify peer certificate level 3 - verify peer with locally installed certificate level 4 - ignore CA chain and only verify peer certificate default - no verifyLevels 0-2 seem pretty clear cut, but then it becomes confusing for me.
First, I do not understand how level 3 differs from level2. What does "against a locally installed certificate" mean? It seems to me that I certainly need to have a local copy of the trusted CAs even in level 2 -- at least I hope that they aren't somehow build in to stunnel. But there is also just one CApath option, so will that be used for level 2 or level 3?
Hi,
They differ in how you manage certificates to validate them.
The level 2 verify the peer certificate against CA (CAfile).
The level 3 verify the peer certificate against CA and also with a local copy of that certificate in the CAfile. In other words, in addition to the CAs certificates you'll have the incoming peer certificates in that file. And you verify that not only is valid against the CA, but against the certificate itself, in that file.
It's a way of a double check to ensure it's not a fake certificate.
For level 4, the "ignore the CA chain" path is fine -- but where do I put the peer certificates that I'm willing to accept? CApath seems wrong, but cert is already used for the server's own certificate...
In the CAfile.
I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate but just the top CA, without the full CAs chain (all CAs part of the certificate).
If no one corrects me, L4 is as I told. But the best way is to test it.
Regards.
On 2013-09-17 01:17, Javier wrote:
I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate but just the top CA, without the full CAs chain (all CAs part of the certificate).
If no one corrects me, L4 is as I told. But the best way is to test it.
It looks like I'll be the one to correct you. It is the opposite: "verify = 4" *only* checks your peer certificate, ignoring all the other certs in the chain. The rationale behind this mode is to be able to use: 1. Specific certificates issued by CAs you don't trust for any other certificates. This can also be achieved by "verify = 3". 2. Specific certificates issued by CAs for which you don't *have* the root certificate. This may happen, as SSL does only requires servers to send the remaining part of the chain. Sending the root certificate itself is optional.
IMHO most stunnel deployments *should* use "verify = 4".
Mike
On Thu, 19 Sep 2013 21:05:44 +0200 Michal Trojnara [email protected] wrote:
On 2013-09-17 01:17, Javier wrote:
I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate but just the top CA, without the full CAs chain (all CAs part of the certificate).
If no one corrects me, L4 is as I told. But the best way is to test it.
It looks like I'll be the one to correct you.
Hi.
Better you, as the developer, than anyone else haha. So, glad you did :)
It is the opposite: "verify = 4" *only* checks your peer certificate, ignoring all the other certs in the chain. The rationale behind this mode is to be able to use:
- Specific certificates issued by CAs you don't trust for any other
certificates. This can also be achieved by "verify = 3". 2. Specific certificates issued by CAs for which you don't *have* the root certificate. This may happen, as SSL does only requires servers to send the remaining part of the chain. Sending the root certificate itself is optional.
IMHO most stunnel deployments *should* use "verify = 4".
I think I understand now.
But a bit contradictory to accept a certificate that has been issued by a CA you don't trust, just for the main purpose of establish an SSL connection.
It depends in the service you are offering, I guess.
I the other hand, I mainly use Stunnel in client mode.
Thanks for the explanation, Michal :)
On 2013-09-20 04:30, Javier wrote:
But a bit contradictory to accept a certificate that has been issued by a CA you don't trust, just for the main purpose of establish an SSL connection.
It seems to be contradictory, but it is not. You often cannot control the certificate of your peer server. In case its certificate is issued by a large CA, you really want to make sure you're connecting to this specific server, and not any other server with certificate issued by the same CA. Web browsers use CNAME/SubjectAltName verification to solve the same problem in a different way.
Mike
On 20.09.2013 04:30, Javier wrote:
But a bit contradictory to accept a certificate that has been issued by a CA you don't trust, just for the main purpose of establish an SSL connection.
Why? I can easily see a provider (say, e-mail) buying a server cert from an ultra-el-cheapo CA that *I* wouldn't trust to hold the door open for me. As long as that CA only gets the CSR from the provider (and never sees the private key), there's no reason why I shouldn't trust *the keypair*, though. And the server cert effectively is the embodiment of that keypair / the pubkey in the SSL exchange.
(And "I don't care about the CA, just gimme encryption to prevent eavesdropping" *is* how web browsers used HTTPS for quite some time. Which then got supplanted by "everyone works along the list of CAs that come preinstalled in browsers today" ... :-S )
On 20.09.2013 05:27, Nikolaus Rath wrote:
So in which case would I ever use 3? Somehow I can't think of such a situation. If I already explicitly trust a specific certificate, why would I be interested in checking the CA chain?
Imagine the CA (or one of the intermediate CAs) getting compromised and corresponding revocations becoming available to your machine (by OS updates, OCSP, whatever) before you hear of the incident.
Regards, J. Bern
Jochen Bern [email protected] writes:
On 20.09.2013 05:27, Nikolaus Rath wrote:
So in which case would I ever use 3? Somehow I can't think of such a situation. If I already explicitly trust a specific certificate, why would I be interested in checking the CA chain?
Imagine the CA (or one of the intermediate CAs) getting compromised and corresponding revocations becoming available to your machine (by OS updates, OCSP, whatever) before you hear of the incident.
FWIW, I still don't see why I'd use verify=3 in that case.
Best, Nikolaus
On Fri, 2013-09-20 09:25:24 -0700, Nikolaus Rath wrote:
Jochen Bern [email protected] writes:
On 20.09.2013 05:27, Nikolaus Rath wrote:
So in which case would I ever use 3? Somehow I can't think of such a situation. If I already explicitly trust a specific certificate, why would I be interested in checking the CA chain?
Imagine the CA (or one of the intermediate CAs) getting compromised and corresponding revocations becoming available to your machine (by OS updates, OCSP, whatever) before you hear of the incident.
FWIW, I still don't see why I'd use verify=3 in that case.
Nikolaus,
With verify=3, you don't explicitly trust the peer certificate, but you restrict the use of /valid/ certificates issued by a certain CA to the ones locally installed.
Revoking the server certificate or one of the intermediate certificates renders the peer certificate as invalid and stunnel will reject it (if the CRLs are available to stunnel), even though it still is locally installed.
Ludolf
On 20.09.2013 18:25, Nikolaus Rath wrote:
Jochen Bern [email protected] writes:
On 20.09.2013 05:27, Nikolaus Rath wrote:
So in which case would I ever use 3? Somehow I can't think of such a situation. If I already explicitly trust a specific certificate, why would I be interested in checking the CA chain?
Imagine the CA (or one of the intermediate CAs) getting compromised and corresponding revocations becoming available to your machine (by OS updates, OCSP, whatever) before you hear of the incident.
FWIW, I still don't see why I'd use verify=3 in that case.
Because verify=4 doesn't know the CA chain (barring the oddity reported by Thomas) and thus would not consider the server cert invalid because of the CA cert revocation.
Whether you *want* that to happen is a somewhat different question. Under normal circumstances, one would expect such a situation to result in the server operators installing a new server cert from another CA, at which point your stunnel setup will stop working, anyway. (Unless the attacker was able to snarf the server's privkey from the CA's archives and has already set up a MitM attack against *your* connections.) In other words, using 4 instead of 3 where possible gains you maybe a couple days of continued operation, at the expense of probably not learning that fast *how* the CA was compromised and what that means for the trustworthiness of the server cert.
(I currently have another case at hand where the difference would be much more pronounced, though. IMHO the CA blundered there - as in, the server cert is valid until late 2015, but one intermediate CA's cert expires early in 2014. Ho hum ... !)
Regards, J. Bern
Michal Trojnara [email protected] writes:
On 2013-09-17 01:17, Javier wrote:
I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate but just the top CA, without the full CAs chain (all CAs part of the certificate).
If no one corrects me, L4 is as I told. But the best way is to test it.
It looks like I'll be the one to correct you. It is the opposite: "verify = 4" *only* checks your peer certificate, ignoring all the other certs in the chain. The rationale behind this mode is to be able to use:
- Specific certificates issued by CAs you don't trust for any other
certificates. This can also be achieved by "verify = 3". 2. Specific certificates issued by CAs for which you don't *have* the root certificate. This may happen, as SSL does only requires servers to send the remaining part of the chain. Sending the root certificate itself is optional.
IMHO most stunnel deployments *should* use "verify = 4".
Thanks for explanations. So in which case would I ever use 3? Somehow I can't think of such a situation. If I already explicitly trust a specific certificate, why would I be interested in checking the CA chain?
Best,
-Nikolaus
On 2013-09-20 05:27, Nikolaus Rath wrote:
IMHO most stunnel deployments *should* use "verify = 4".
Thanks for explanations. So in which case would I ever use 3? Somehow I can't think of such a situation. If I already explicitly trust a specific certificate, why would I be interested in checking the CA chain?
Good point. The reason is historical: "verify = 4" was added just 2 years ago. As stunnel is 15 years old I decided to keep "verify = 3" for backward compatibility. Alternatively I could have replaced the existing functionality of "verify = 3", but most people expect modifications of the already defined functionality on software updates to be as small as possible.
Mike
On 9/16/2013 6:17 PM, Javier wrote:
I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate but just the top CA, without the full CAs chain (all CAs part of the certificate). If no one corrects me, L4 is as I told. But the best way is to test it.
Testing is the best way, for sure. In theory, L4 checks for the peer certificate only. Yet, I'm currently using at least one peer certificate that requires the top CA to be present in the .pem file. If I remove it, L4 fails. Go figure.
Best regards,
Thomas
On 09/20/2013 10:10 AM, Thomas Eifert wrote:
Testing is the best way, for sure. In theory, L4 checks for the peer certificate only. Yet, I'm currently using at least one peer certificate that requires the top CA to be present in the .pem file. If I remove it, L4 fails. Go figure.
I wasn't able to reproduce this issue. Could you send some more details. A step-by-step procedure to would be great.
Mike
Mike,
Okay, here's the simple way to test it. This is repeatable in Stunnel 4.56 and 5.00:
Start with a simple stunnel.conf:
debug = 6 fips = no delay = yes output = stunnel.log
[nntps.3] client = yes accept = 127.0.0.1:119 connect = news.eternal-september.org:563
Point your favorite newsreader to 127.0.0.1/119, then connect to the server.
Having done that, open the stunnel log window. From the menu bar, choose "save peer certificate".
Save the certificate, which will now be "peer-nntps.3.pem" in the stunnel directory.
Add certificate verification to stunnel conf:
[nntps.3] client = yes cafile = peer-nntps.3.pem verify = 4 accept = 127.0.0.1:119 connect = news.eternal-september.org:563
Reload the configuration file.
Attempt to reconnect to the server. The certificate verify will fail:
2013.09.20 11:12:35 LOG4[3964]: CERT: Verification error: unable to get local issuer certificate 2013.09.20 11:12:35 LOG4[3964]: Certificate check failed: depth=0, /description=z8x2a0S5FjpJGCa7/C=DE/CN=news.eternal-september.org/[email protected] 2013.09.20 11:12:35 LOG3[3964]: SSL_connect: 14090086: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
If you paste the certificate for the root CA into the peer-nntps.3.pem file, then it will verify okay.
I have a feeling you'll find something wrong with the certificate that's causing this to happen. The guy that runs the server likes to "roll his own".
Best regards,
Thomas
On 9/20/2013 5:16 AM, Michal Trojnara wrote:
On 09/20/2013 10:10 AM, Thomas Eifert wrote:
Testing is the best way, for sure. In theory, L4 checks for the peer certificate only. Yet, I'm currently using at least one peer certificate that requires the top CA to be present in the .pem file. If I remove it, L4 fails. Go figure.
I wasn't able to reproduce this issue. Could you send some more details. A step-by-step procedure to would be great.
Mike _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
-
Javier -
Jochen Bern -
Ludolf Holzheid -
Michal Trojnara -
Nikolaus Rath -
Thomas Eifert