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 [email protected] Sender: [email protected] Date: Tue, 14 Feb 2012 10:05:15 To: [email protected] Subject: [stunnel-users] server does not send its cert?
_______________________________________________ stunnel-users mailing list [email protected] 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, [email protected] 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 [email protected] Sender: [email protected] Date: Tue, 14 Feb 2012 10:05:15 To: [email protected] Subject: [stunnel-users] server does not send its cert?
stunnel-users mailing list [email protected] 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 [email protected]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, [email protected] 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 [email protected] Sender: [email protected] Date: Tue, 14 Feb 2012 10:05:15 To: [email protected] Subject: [stunnel-users] server does not send its cert?
stunnel-users mailing list [email protected] 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 [email protected]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.htmlhttp://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 [email protected] http://stunnel.mirt.net/**mailman/listinfo/stunnel-usershttp://stunnel.mirt.net/mailman/listinfo/stunnel-users
-
josealf＠rocketmail.com -
Keresztfalvi Laszlo -
Michal Trojnara