Hi stunnel-users,
There is example configuration:
<!-- client = yes foreground = yes ciphers = DES-CBC3-SHA verify = 2 CAfile = ThawteServerCA.txt
[asd] accept = 127.0.0.1:60465 connect = smtp.gmail.com:465 #connect = 64.233.185.109:465 -->
I don't know how to enforce stunnel to verify CN field from server provided certificate. Even if i change "connect" field to next one stunnel will not complain.
So, am I wrong that when someone hijack (mitm) this connection and provide any server cert signed by ThawteServerCA then I loose? Please add this verification to stunnel when verify is set to 2 or better as an separate option "verify_cn?" which could be used in service-level context.
Usting this option with that described below I can drop 'verify' and 'CAfile' at all and feel much better. :)
There is another verification method that could be added - not related to verify option. In most cases I know public cert of remote server. So I also know sha1/md5 fingerprint of that cert.
Security could improve v.much by just adding these lines to my example configuration: fingerprint_md5=F5:BD:C3:C8:D5:4B:03:EA:57:BB:81:72:46:6B:26:54 fingerprint_sha1=CE:3A:0D:3E:DA:4B:77:A3:53:C0:9E:A8:65:B7:F8:C2:09:71:43:41
Another good service-level option?
There are some other good options that could be ported from openssl/s_client: "-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1"
Regards.
Dear Anonymous,
(where is the traditional Polish politeness...)
On Saturday 14 of May 2005 22:50, [email protected] wrote:
client = yes verify = 2 CAfile = ThawteServerCA.txt [asd] accept = 127.0.0.1:60465 connect = smtp.gmail.com:465
I don't think it's a good idea. You probably don't really *trust* all companies that have a certificate signed by Thawte.
It's much better to have verify=3 and the exact certificate used by the server as the CAfile parameter.
I don't know how to enforce stunnel to verify CN field from server provided certificate.
What you need is cryptographic authentication. CN verification is vulnerable to DNS poisoning.
So, am I wrong that when someone hijack (mitm) this connection and provide any server cert signed by ThawteServerCA then I loose? Please add this verification to stunnel when verify is set to 2 or better as an separate option "verify_cn?" which could be used in service-level context.
No. I'm not going to give users a false sense of security.
Usting this option with that described below I can drop 'verify' and 'CAfile' at all and feel much better. :)
No. You should download the peer certificate and verify it with verify=3.
Best regards, Mike
CAfile = ThawteServerCA.txt
In my example I'm not using "CApath" option. Is there any difference between: - CAfile which contains ThawteServerCA and peer cert - CApatch with ddc328ff.0 (ThawteServerCA) and 313fe585.0 (smtp.gmail.com peer cert) files
Both ways work fine.
No. You should download the peer certificate and verify it with verify=3.
Instead of downloading can I obtain this peer cert this way? $ openssl s_client -connect smtp.gmail.com:465
It's much better to have verify=3 and the exact certificate used by the server as the CAfile parameter.
That's the solution. Thank You.
[email protected] wrote:
Is there any difference between:
- CAfile which contains ThawteServerCA and peer cert
- CApatch with ddc328ff.0 (ThawteServerCA) and 313fe585.0 (smtp.gmail.com
peer cert) files
There's no difference other than CAfile is a bit easier to setup while CApath allows to add certificates without restarting stunnel.
No. You should download the peer certificate and verify it with verify=3.
Instead of downloading can I obtain this peer cert this way? $ openssl s_client -connect smtp.gmail.com:465
Yes. That's the recommended way to download a certificate from an SSL server.
Best regards, Mike
-
Michal Trojnara -
Michal Trojnara -
spambox＠poczta.onet.pl