RE: Problems with DSA 2048-bit keys
> 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 > 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
Re: Openssl tarball SHA1 checksum
* 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: Strange SSL_shutdown() error return (SSL_ERROR_SYSCALL but errno == 0)
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
