Hello, after a day of trying.. - 2 box of *Win7 Pro x64* - fresh install of *stunnel 4.52* - keys generated with C:\Program Files (x86)\stunnel>* **.\openssl.exe req -new -x509 -days 365 -nodes -config stunnel.cnf -out stunnel.pem -keyout stunnel.pem* - *certs.pem* on both box contains certificate part of stunnel.pem from both machine server stunnel.conf (192.168.0.52): debug = 7 cert = stunnel.pem verify = 2 CAfile = certs.pem options = NO_SSLv2 [unison] accept = 10001 connect = 127.0.0.1:10000 client stunnel.conf (192.168.0.216): client = yes debug = 7 cert = stunnel.pem verify = 2 CAfile = certs.pem options = NO_SSLv2 [unison] client = yes accept = 127.0.0.1:10000 connect = 192.168.0.52:10001 Test #1: *OK* C:\Program Files (x86)\stunnel>* .\openssl verify -CAfile certs.pem stunnel.pem* *stunnel.pem: OK* C:\Program Files (x86)\stunnel>* .\openssl verify -CAfile certs.pem certs.pem* *certs.pem: OK* Test #2: *OK* C:\Program Files (x86)\stunnel> *.\openssl s_server -accept 10001 -cert stunnel.pem -verify 2 -CAfile certs.pem -no_ssl2* vs C:\Program Files (x86)\stunnel> *.\openssl s_client -connect 192.168.0.52:10001 -cert stunnel.pem -verify 2 -CAfile certs.pem -no_ssl2* Test #3: *OK - "certificate accepted" * C:\Program Files (x86)\stunnel> *.\openssl s_server -accept 10001 -cert stunnel.pem -verify 2 -CAfile certs.pem -no_ssl2* vs *stunnel client** * Test #4: *OK - "certificate accepted" * *stunnel server* vs C:\Program Files (x86)\stunnel> *.\openssl s_client -connect 192.168.0.52:10001 -cert stunnel.pem -verify 2 -CAfile certs.pem -no_ssl2* Test #5: *FAILED* *stunnel server* Service unison accepted connection from 192.168.0.216:23134 2012.02.14 09:02:39 LOG3[134028:132792]: SSL_accept: 140943F2: error:140943F2:SSL routines:*SSL3_READ_BYTES:sslv3 alert unexpected message* 2012.02.14 09:02:39 LOG5[134028:132792]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket* * vs *stunnel client * 2012.02.14 09:02:33 LOG5[2500:5876]: Service unison connected remote server from 192.168.0.216:23134 2012.02.14 09:02:33 LOG7[2500:5876]: Remote FD=372 initialized 2012.02.14 09:02:33 LOG3[2500:5876]: SSL_connect: 140870E8: error:140870E8:SSL routines:*SSL3_GET_CERTIFICATE_**REQUEST:tls client cert req with anon cipher* 2012.02.14 09:02:33 LOG5[2500:5876]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket After a *stunnel.conf **reload* on both box (yes, only a reload) then the following details and differences appear: *stunnel server* vs *openssl s_client : OK - "certificate accepted" * 2012.02.14 09:42:02 LOG5[134236:132440]: Service unison accepted connection from 192.168.0.216:23698 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): before/accept initialization 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): SSLv3 read client hello B 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): *SSLv3 write server hello A* 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): *SSLv3 write certificate A* 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): *SSLv3 write key exchange A* 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): SSLv3 write certificate request A 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): SSLv3 flush data 2012.02.14 09:42:02 LOG7[134236:132440]: Starting certificate verification: depth=0, /C=HU/ST=Mazovia Province/L=Budapest/O=-/OU=client/CN=x-pc 2012.02.14 09:42:02 LOG5[134236:132440]: Certificate accepted: depth=0, /C=HU/ST=Mazovia Province/L=Budapest/O=-/OU=client/CN=x-pc 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): SSLv3 read client certificate A 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): SSLv3 read client key exchange A 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): SSLv3 read certificate verify A 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): SSLv3 read finished A 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): SSLv3 write session ticket A 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): SSLv3 write change cipher spec A 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): SSLv3 write finished A 2012.02.14 09:42:02 LOG7[134236:132440]: SSL state (accept): SSLv3 flush data *stunnel server* vs *stunnel client : FAILED * *server:* 2012.02.14 09:45:24 LOG5[134236:134552]: Service unison accepted connection from 192.168.0.216:23752 2012.02.14 09:45:24 LOG7[134236:134552]: SSL state (accept): before/accept initialization 2012.02.14 09:45:24 LOG7[134236:134552]: SSL state (accept): SSLv3 read client hello B 2012.02.14 09:45:24 LOG7[134236:134552]: SSL state (accept): *SSLv3 write server hello A* 2012.02.14 09:45:24 LOG7[134236:134552]: SSL state (accept): *SSLv3 write key exchange A* 2012.02.14 09:45:24 LOG7[134236:134552]: SSL state (accept): SSLv3 write certificate request A 2012.02.14 09:45:24 LOG7[134236:134552]: SSL state (accept): SSLv3 flush data 2012.02.14 09:45:24 LOG7[134236:134552]: SSL alert (read): fatal: unexpected_message 2012.02.14 09:45:24 LOG3[134236:134552]: SSL_accept: 140943F2: error:140943F2:SSL routines:*SSL3_READ_BYTES:sslv3 alert unexpected message* 2012.02.14 09:45:24 LOG5[134236:134552]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2012.02.14 09:45:24 LOG7[134236:134552]: Service unison finished (0 left) *client:* 2012.02.14 09:45:18 LOG5[1100:7176]: Service unison connected remote server from 192.168.0.216:23752 2012.02.14 09:45:18 LOG7[1100:7176]: Remote FD=452 initialized 2012.02.14 09:45:18 LOG7[1100:7176]: SSL state (connect): before/connect initialization 2012.02.14 09:45:18 LOG7[1100:7176]: SSL state (connect): SSLv3 write client hello A 2012.02.14 09:45:18 LOG7[1100:7176]: SSL state (connect): *SSLv3 read server hello A* 2012.02.14 09:45:18 LOG7[1100:7176]: SSL state (connect): *SSLv3 read server key exchange A* 2012.02.14 09:45:18 LOG7[1100:7176]: SSL alert (write): *fatal: unexpected_message* 2012.02.14 09:45:18 LOG3[1100:7176]: SSL_connect: 140870E8: error:140870E8:SSL routines:*SSL3_GET_CERTIFICATE_**REQUEST:tls client cert req with anon cipher* 2012.02.14 09:45:18 LOG5[1100:7176]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket Please, give me some clues. Thank you, Laszlo **
Laszlo, Please add key=stunnel.pem fips=no to your config files. Make sure stunnel.pem contains the certifcate and private key for each computer. Try again and let us know the results. Regards Jose -----Original Message----- From: Keresztfalvi Laszlo <lkereszt@gmail.com> Sender: stunnel-users-bounces@stunnel.org Date: Tue, 14 Feb 2012 10:05:15 To: <stunnel-users@stunnel.org> Subject: [stunnel-users] server does not send its cert? _______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org http://stunnel.mirt.net/mailman/listinfo/stunnel-users
Jose, Oh, yeah! This solved the problem! Actually, *fips = no* alone was enough to let the certs meet. Previously, I just didn't bothered the FIPS setting since I couldn't imagine that non-approved protocols would be used or any crypto/algo deviances would show up.. in such a simple case :) It was very frustrating that the OpenSSL test commands (s_server, s_client) worked. You may leave this solution visible for Google or extend the documentation / FAQ to help others.. No relevant document showed up for the next search strings: SSL3_GET_CERTIFICATE_REQUEST:tls client cert req with anon cipher SSL3_READ_BYTES:sslv3 alert unexpected message Thank you very very much! Laszlo On Tue, Feb 14, 2012 at 12:06, <josealf@rocketmail.com> wrote:
Laszlo,
Please add
key=stunnel.pem fips=no
to your config files. Make sure stunnel.pem contains the certifcate and private key for each computer. Try again and let us know the results.
Regards Jose
-----Original Message----- From: Keresztfalvi Laszlo <lkereszt@gmail.com> Sender: stunnel-users-bounces@stunnel.org Date: Tue, 14 Feb 2012 10:05:15 To: <stunnel-users@stunnel.org> Subject: [stunnel-users] server does not send its cert?
_______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org http://stunnel.mirt.net/mailman/listinfo/stunnel-users
One more thing.. 2012.02.14 13:13:32 LOG6[87260:136504]: Negotiated ciphers: RC4-SHA SSLv3 Kx=RSA Au=RSA *Enc=RC4(128)* Mac=SHA1 RC4 128-bit is not something that considered secure. I don't know why this was choosen but probably this caused that FIPS mode rejected the connection? Best Regards, Laszlo On Tue, Feb 14, 2012 at 13:29, Keresztfalvi Laszlo <lkereszt@gmail.com>wrote:
Jose,
Oh, yeah! This solved the problem!
Actually, *fips = no* alone was enough to let the certs meet.
Previously, I just didn't bothered the FIPS setting since I couldn't imagine that non-approved protocols would be used or any crypto/algo deviances would show up.. in such a simple case :) It was very frustrating that the OpenSSL test commands (s_server, s_client) worked.
You may leave this solution visible for Google or extend the documentation / FAQ to help others.. No relevant document showed up for the next search strings:
SSL3_GET_CERTIFICATE_REQUEST:tls client cert req with anon cipher SSL3_READ_BYTES:sslv3 alert unexpected message
Thank you very very much! Laszlo
On Tue, Feb 14, 2012 at 12:06, <josealf@rocketmail.com> wrote:
Laszlo,
Please add
key=stunnel.pem fips=no
to your config files. Make sure stunnel.pem contains the certifcate and private key for each computer. Try again and let us know the results.
Regards Jose
-----Original Message----- From: Keresztfalvi Laszlo <lkereszt@gmail.com> Sender: stunnel-users-bounces@stunnel.org Date: Tue, 14 Feb 2012 10:05:15 To: <stunnel-users@stunnel.org> Subject: [stunnel-users] server does not send its cert?
_______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org http://stunnel.mirt.net/mailman/listinfo/stunnel-users
Keresztfalvi Laszlo wrote:
2012.02.14 13:13:32 LOG6[87260:136504]: Negotiated ciphers: RC4-SHA SSLv3 Kx=RSA Au=RSA ENC=RC4(128) Mac=SHA1
RC4 128-bit is not something that considered secure. I don't know why this was choosen but probably this caused that FIPS mode rejected the connection?
Contrary to popular belief, RC4-SHA is probably the most secure ciphersuite available in SSL/TLS. In fact RC4 is the only SSL algorithm not vulnerable to the BEAST attack: http://blog.zoller.lu/2011/09/beast-summary-tls-cbc-countermeasures.html On the other hand it is easy to use RC4 in an insecure way. Many products and protocols were broken because RC4 was used incorrectly. This is *not* the case for SSL/TLS. No practical attacks are currently known against RC4-based SSL/TLS. Mike
Right after I clicked the send button I've got the feeling that this is a too-old-to-be-true story. Thanks for the clarification! Laszlo On Tue, Feb 14, 2012 at 14:55, Michal Trojnara <Michal.Trojnara@mirt.net>wrote:
Keresztfalvi Laszlo wrote:
2012.02.14 13:13:32 LOG6[87260:136504]: Negotiated ciphers: RC4-SHA SSLv3 Kx=RSA Au=RSA ENC=RC4(128) Mac=SHA1
RC4 128-bit is not something that considered secure. I don't know why this was choosen but probably this caused that FIPS mode rejected the connection?
Contrary to popular belief, RC4-SHA is probably the most secure ciphersuite available in SSL/TLS. In fact RC4 is the only SSL algorithm not vulnerable to the BEAST attack: http://blog.zoller.lu/2011/09/**beast-summary-tls-cbc-** countermeasures.html<http://blog.zoller.lu/2011/09/beast-summary-tls-cbc-countermeasures.html>
On the other hand it is easy to use RC4 in an insecure way. Many products and protocols were broken because RC4 was used incorrectly. This is *not* the case for SSL/TLS. No practical attacks are currently known against RC4-based SSL/TLS.
Mike
______________________________**_________________ stunnel-users mailing list stunnel-users@stunnel.org http://stunnel.mirt.net/**mailman/listinfo/stunnel-users<http://stunnel.mirt.net/mailman/listinfo/stunnel-users>
participants (3)
-
josealf＠rocketmail.com -
Keresztfalvi Laszlo -
Michal Trojnara