Re: Strange SSL_shutdown() error return (SSL_ERROR_SYSCALL but errno == 0)

2010-04-11 Thread Darryl Miles

Antoine Pitrou wrote:

Well, in our case, and unless I'm mistaken,
ret == -1, ERR_get_error() == 0 and then errno (the Unix errno) == 0.


SSL_shutdown() by virtue of its unique mechanic you will not see ret == 
0 (in the way the SSL_get_error man page describes) since that has a 
different and special meaning.  It means the first point that 
((SSL_get_shutdown()  SSL_SENT_SHUTDOWN) == SSL_SENT_SHUTDOWN) would be 
true.



Unlike for example SSL_read() which can return 0, which does mean EOF. 
For which you can then do ((SSL_get_shutdown()  SSL_RECEIVED_SHUTDOWN) 
== SSL_RECEIVED_SHUTDOWN) to find out if it was a secure EOF.




=== RANT MODE 
If the OpenSSL SSL_shutdown() API could have been made better this is 
certainly one area that could be better.  i.e. make SSL_shutdown() 
return the current state like SSL_get_shutdown() does (which means 
non-zero states).  Then reuse the return of 0 state to mean EOF on 
transport and keep -1/WANT_READ/WANT_WRITE/ERROR_SYSCALL as-is.


This would mean (simplified understanding) :
 * old version returned 0, new version returns 1 (SSL_SENT_SHUTDOWN).
 * old version returned 1, new version returns 3 
(SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN).



Unfortunately this would have broken historical compatibility; it took 
quite a while to get the minimum breakage patch in to achieve my goals 
by the end of that time thinking about improving OpenSSL (rather than 
bug fixing it) was long out of my mind.


I'm all for breaking APIs to make things better, providing its done in a 
responsible way.  A poorly thought out API call can't hog a popular API 
symbol forever, otherwise the whole product starts to weaken.

=== RANT MODE 



Perhaps errno gets cleared by another operation... I may try to
investigate if I get some time.


Well now I've looked at the Python Module/_ssl.c to understand the 
context of your usage, you are using standard stuff for BIO.


I know that errno==0 is getting set by OpenSSL before it makes the 
read() system call (openssl-1.0.0/crypto/bio/bss_fd.c:150 function 
fd_read() calls clear_sys_error() which does errno=0; from 
openssl-1.0.0/e_os.h).


Then (I presume) it gets a read()==0 from kernel (bss_fd.c:151).  Of 
course a read()==0 does not modify errno in libc.


So in openssl-1.0.0/ssl/s3_lib.c:3191 inside the SSL_shutdown() 
implementation you can see the error return is ignored.  Since returning 
0 from here has a different documented meaning.


I think this is the sequence of events you observe.


Unfortunately I can't confirm it to be so since I can't get the test 
cases to run from Python's SVN.




Darryl
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: Openssl tarball SHA1 checksum

2010-04-11 Thread Steffen DETTMER
* Kenneth Goldman wrote on Fri, Apr 09, 2010 at 08:12 -0400:
I notice that the tarballs also include a SHA1 digest. What's the
point?

To have a check whether the FTP download was successful to avoid
accidently using corrupt files, a file integrity check with a
checksum is quite common.

oki,

Steffen


 
About Ingenico: Ingenico is a leading provider of payment solutions, with over 
15 million terminals deployed in more than 125 countries. Its 2,850 employees 
worldwide support retailers, banks and service providers to optimize and secure 
their electronic payments solutions, develop their offer of services and 
increase their point of sales revenue. More information on 
http://www.ingenico.com/.
 This message may contain confidential and/or privileged information. If you 
are not the addressee or authorized to receive this for the addressee, you must 
not use, copy, disclose or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.
 P Please consider the environment before printing this e-mail
 
 
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


RE: Problems with DSA 2048-bit keys

2010-04-11 Thread Dave Thompson
 From: owner-openssl-us...@openssl.org On Behalf Of Sad Clouds
 Sent: Saturday, 10 April, 2010 10:56

 I'm testing a very simple SSL web server. Everything seems to work OK
 with RSA and DSA 1024-bit keys.
 
 I tried using DSA 2048-bit key and snip
 Then when I use Firefox to connect to the server I get:
 
 Thread starting
 keylength = 1024
 SSL_accept() error
 error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error
 
 Any ideas why I'm getting decrypt error with OpenSSL? Is this related
 to the fact that the tmp_dh_callback() is passed 1024-bit key length,
 even though the certificate was set up with a 2048-bit key? Why does
 this happen?

This is an alert received by openssl in your server, *from* Firefox.
Either openssl is encrypting something improperly so Firefox can't 
decrypt it, which seems unlikely since you say later s_client works;
or FF is decrypting something wrong or perhaps just disliking it, 
in which case you probably need help from FF support/development.

There's no protocol reason the ephDH group has to be the same size 
as the DSA key/group that authenticates it, although for security 
good sense you probably want it to. The actual call to the callback 
is s3_srvr.c uses some macros to enforce 'export' restrictions 
on strength, which I don't understand in detail but it appears 
to me can limit your pubkey size to 1024 in at least some cases.
Maybe someone else is more familiar with this area.

Aside: do you really need this? FIPS 186-3 extended DSA to 2k and 3k, 
but SP 800-57 no longer approves classic DSA for USgovt use at all, 
even in the new sizes, it switches to ECDSA instead.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org