Re: OpenSSL 1.0.0 beta5 release (Build Broblem)
perl Configure VC-WIN32 -DOPENSSL_SSL_CLIENT_ENGINE_AUTO=capi -DOPENSSL_CAPIENG_DIALOG ms\do_ms nmake -f ms\ntdll.mak .\engines\e_capi.c(466) : error C2220: warning treated as error - no object fil generated .\engines\e_capi.c(466) : warning C4013: 'OPENSSL_isservice' undefined; assumin extern returning int NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. 2010/1/21 OpenSSL open...@openssl.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.0 Beta 5 OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL is currently in a release cycle. The fifth beta is now released. This is expected be the final beta depending on the number of bugs reported. The beta release is available for download via HTTP and FTP from the following master locations (the various FTP mirrors you can find under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The file names of the beta are: o openssl-1.0.0-beta5.tar.gz Size: 4006467 MD5 checksum: f869b6b044296f31cee710f178605ef2 SHA1 checksum: a16377c02625f803a5dcfaa9c11aeadcfd3703b6 The checksums were calculated using the following command: openssl md5 openssl-1.0.0-beta5.tar.gz openssl sha1 openssl-1.0.0-beta5.tar.gz Please download and test them as soon as possible. This new OpenSSL version incorporates 122 documented changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES). Also check the latest snapshots at ftp://ftp.openssl.org/snapshot/ or CVS (see http://www.openssl.org/source/repos.html) to avoid reporting previously fixed bugs. Since the fourth beta, the following has happened: - Provisional TLS session renegotiation fix - Option to output hash using older algorithm in x509 utility - Compression session handling bug fix - Build system fixes. - Other bug fixes. Reports and patches should be sent to openssl-b...@openssl.org. Discussions around the development of OpenSSL should be sent to openssl-...@openssl.org. Anything else should go to openssl-us...@openssl.org. The best way, at least on Unix, to create a report is to do the following after configuration: make report That will do a few basic checks of the compiler and bc, then build and run the tests. The result will appear on screen and in the file testlog. Please read the report before sending it to us. There may be problems that we can't solve for you, like missing programs. Yours, The OpenSSL Project Team... Mark J. Cox Ben Laurie Andy Polyakov Ralf S. Engelschall Richard Levitte Geoff Thorpe Dr. Stephen Henson Bodo Möller Ulf Möller Lutz JänickeNils Larsch -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBS1cho6LSm3vylcdZAQJiQAf+MFwN93YBcJI6sQIjAr5RSql7gdP9H+NV zNBf6nkLCJcuwu9tXeheuLRfvye5wF+FpWE6qS5a8mgm3Z6S8aOnacBvyfyo57U7 mTs4eNG9YBwS/wK7cavxzKLsVX0zgOMurqLmONUlNBSrW9m2R7uupfLn+SzQYrov gZl48yqB5AVtM4MiwEWmK9EnXH4SCtOWG4TEi2G30hP/5ssKoM4Y+GrQMueZnTEW RXR+N+1uvmqzDfekoTE3bfXd0BNPMUNh7JmSxT/WlhPxDk7Tx5yMxqnZChPgsSFN a9V38M/yDzbL8Gz3zToOC+GsVmf560+7b6aC1LvUPLXZZWOXn/vLsA== =A39y -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 0.9.8m-beta1 release (Build Broblem)
On Tue, Jan 26, 2010, So Gerald wrote: I built it with VC-Win32 and got a problem: perl Configure VC-WIN32 no-hw enable-capieng -DOPENSSL_ SSL_CLIENT_ENGINE_AUTO=capi -DOPENSSL_CAPIENG_DIALOG ms\do_masm nmake -f ms\ntdll.mak .\ssl\d1_both.c(992) : warning C4761: integral size mismatch in argument; conversion supplied .\ssl\d1_both.c(992) : error C2220: warning treated as error - no object file ge nerated NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. 2010/1/21 Thor Lancelot Simon t...@panix.com Should be fixed in the next snapshot. In future please report bugs to the request tracker. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 beta5 release (Build Broblem)
On Tue, Jan 26, 2010, So Gerald wrote: perl Configure VC-WIN32 -DOPENSSL_SSL_CLIENT_ENGINE_AUTO=capi -DOPENSSL_CAPIENG_DIALOG ms\do_ms nmake -f ms\ntdll.mak .\engines\e_capi.c(466) : error C2220: warning treated as error - no object fil generated .\engines\e_capi.c(466) : warning C4013: 'OPENSSL_isservice' undefined; assumin extern returning int NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. 2010/1/21 OpenSSL open...@openssl.org Should be fixed in the next snapshot. In future please report bugs to the request tracker. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: can TLS be used securely or it is flawed by design not allowing to use it securely
* Kyle Hamilton wrote on Tue, Jan 19, 2010 at 16:00 -0800: On Tue, Jan 19, 2010 at 6:19 AM, Steffen wrote: * Kyle Hamilton wrote on Thu, Jan 14, 2010 at 15:50 -0800: (assuming, that a peers identity should not change within a session - but as discussed later in this mail this could be wrong?): If there's a certificate DN or Issuer change (even from null to something non-null), I agree that in many/most circumstances it's reasonable to abort the connection. It doesn't necessarily follow, though, that because it's the reasonable thing in most circumstances that it's the correct thing to do in all circumstances. mmm... I do a bit hard understanding this... the tunnel is to ensure to talk with an authentic identity. Like in real life someone my tell some things only to his girl but not to the postman. I do not expect that the identity I'm connected to changes during the conversation (i.e. I would consider designs where girls pass the cell phone to the postmen as bad :-)). (Imagine an ATM with a TLS-encrypted serial line or other link back to the central processing house. It has its own certificate -- the processing house doesn't want to accept connections that it can't authenticate -- so it builds that TLS channel with mutual authentication... but the ATM doesn't have any accounts, so its key and certificate can't be used alone to compromise any accounts. Then, Imagine USB ATM cards that could be plugged in, with an attendant please enter your PIN message on the screen of the ATM that would unlock your private key, so that the ATM could then initiate a renegotiation as you... and the server initiates renegotiations every 6 seconds to ensure that you're still there. Then, when you remove your USB stick, the machine reauthenticates as itself. mmm... I would guess that in such a situation the remote side would want to know that: maybe only the USB tokens are allowed/autorized to communicate here or whatever. But I see that there might be cases where it could be used, ok. So the perfect browser might need a configuration option to accept `Identity Changes' after accepting a certificate, maybe even URL-based to avoid that banks change while performing transactions. OT: I personally would wish to be able to put a browser tab or better even a browser instance into some `secured' mode (for online banking HTTPS but not for myspace HTTPS). In this mode, flash would not work, no plug-ins installed and I would be Note: My bank's multi-factor authentication mechanism uses Flash, so it would be necessary for each site to provide a manifest of what it makes use of and what the maximum privileges each should have on the user's system. However, this is a very good idea. I don't know of any rendering engine or browser that would or could operate in this manner (other than possibly Chrome), but at that point we're still dealing with operating systems that can be compromised by viruses. (Flash was intended as a placeholder for any plug-in or color advertising multimedia extension) Why not keeping the pages simple and stupid. On the highly secured pages used with browser in secured mode the banking frontend could use simple HTML only, no flash and no embedded video. Wouldn't life be so much easier? Maybe someone could run a simple stable browser (not needing almost-daily-updates-with-only-2-year-support), maybe on a mobile phone which does not support any software upgrading except JTAG flashing. For the truely paranoid the adavantage here isn't that it works everywhere but that it securely works in the private basement (to make eavesdropping harder) :-) warned when the DN of a certificate of a web page changes (now, I'm warned only if CN does not match DNS name, but I would like to be informed: www.xyz.com now is DN=XYZ Ltd. UK but last time it was DN=XYZ Inc. US or so). Probably there are many This already exists and is called Petnames, you might wish to look for it on addons.mozilla.org. thanks, in case I'd update to Firefox 3 I might give it a try (althrough it might not be exactly what I meant). more nice security features that could be turned on. This would not prevent the twitter attack but maybe could make online banking attacks more expensive. In my case, my bank's multifactor authentication includes sending a numeric code to my phone that I then enter into their Flash applet. Online banking attacks are regrettably cheap and relatively easy at this point... MITB is the watchword nowadays. yes, MITbrowser, MITplug-in, MITtodaysUpdate... I think for many a `SSL secured' label on a webpage means that the running application (lets say a online banking web app) is secured. That's what the intrusion-detection/resistance-certification services are for. All the lock icon means is that nobody can listen in between you and the other end. (I guess many assume security even if this `SSL secured' label /
RE: Re-negotiation handshake failed: Not accepted by clientwithOpenSSL 0.98m-beta1
Hi Steve, I double checked that swapping BIO_CTRL_PENDING and BIO_CTRL_WPENDING in modules/ssl/ssl_engine_io.c does NOT fix this. It results in a fatal alert, without it the s_client hangs. My test is a little unusual in that I copy/paste an HTTP GET request into the s_client session in a terminal window and sometimes press enter for an extra linefeed, which probably results in smaller than normally found packets of data on the wire. -fred -Original Message- From: Dr. Stephen Henson [mailto:st...@openssl.org] Sent: Monday, January 25, 2010 5:51 PM To: openssl-users@openssl.org Subject: Re: Re-negotiation handshake failed: Not accepted by clientwithOpenSSL 0.98m-beta1 On Mon, Jan 25, 2010, Shotton, Fred wrote: Hi Steve, Adding a third case in s3_srvr.c did work, yeah! Applying the Apache fix did not work. Let me know if you need anything else. I can't reproduce your issue but it does depend critically on the amount of data transferred to reproduce it (which was why PR 1949 was do tricky to trace). Can you double check that swapping BIO_CTRL_PENDING and BIO_CTRL_WPENDING in modules/ssl/ssl_engine_io.c does NOT fix this? I'm confused because adding the third case should have the same effect because one of those always returns zero. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Re-negotiation handshake failed: Not accepted by clientwithOpenSSL 0.98m-beta1
On Tue, Jan 26, 2010, Shotton, Fred wrote: I double checked that swapping BIO_CTRL_PENDING and BIO_CTRL_WPENDING in modules/ssl/ssl_engine_io.c does NOT fix this. It results in a fatal alert, without it the s_client hangs. My test is a little unusual in that I copy/paste an HTTP GET request into the s_client session in a terminal window and sometimes press enter for an extra linefeed, which probably results in smaller than normally found packets of data on the wire. OK, I've simplified the OpenSSL code to unconditionally flush the data instead. The change is here: http://cvs.openssl.org/chngview?cn=19183 Please let me know if that solves the problem. If you can't apply that diff or pull the source from CVS you can try tomorrow's snapshot. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Re-negotiation handshake failed: Not accepted byclientwithOpenSSL 0.98m-beta1
Hi Steve, I have verified the new change solves the problem. Thank you, fred -Original Message- From: Dr. Stephen Henson [mailto:st...@openssl.org] Sent: Tuesday, January 26, 2010 11:56 AM To: openssl-users@openssl.org Subject: Re: Re-negotiation handshake failed: Not accepted byclientwithOpenSSL 0.98m-beta1 On Tue, Jan 26, 2010, Shotton, Fred wrote: I double checked that swapping BIO_CTRL_PENDING and BIO_CTRL_WPENDING in modules/ssl/ssl_engine_io.c does NOT fix this. It results in a fatal alert, without it the s_client hangs. My test is a little unusual in that I copy/paste an HTTP GET request into the s_client session in a terminal window and sometimes press enter for an extra linefeed, which probably results in smaller than normally found packets of data on the wire. OK, I've simplified the OpenSSL code to unconditionally flush the data instead. The change is here: http://cvs.openssl.org/chngview?cn=19183 Please let me know if that solves the problem. If you can't apply that diff or pull the source from CVS you can try tomorrow's snapshot. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Re-negotiation handshake failed: Not accepted byclientwithOpenSSL 0.98m-beta1
On Tue, Jan 26, 2010, Shotton, Fred wrote: Hi Steve, I have verified the new change solves the problem. Excellent, thanks for running the tests. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: utf8string vs printablestring mismatch in certificate checking
1.0.0 uses a different algorithm for computing hashes which relies on a form of canonical encoding. Does that mean we need to recompute the hashes for existing CA certs and CRLs if we are to work with 1.0.0 since it seems to generate a different hash value for the same cert? -Sandeep On Tue, Jan 19, 2010 at 1:55 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Tue, Jan 19, 2010, Colin Phipps wrote: We are having trouble using openssl's certificate checking to validate certain certificates where certificates in the chain are inconsistent in their choice of string encoding. Using e.g. openssl-0.9.8e-12.el5, the connection in the accompanying certificate chain (intermediate cert and final cert only attached) will never be made by openssl. I think that this is because the intermediate cert has issuer Government of Korea (utf8, type 12) but the root cert is subject Government of Korea (printable, type 19), so it doesn't see this intermediate cert as signed by this issuing cert due to the names not matching (although they do match semantically, as it were); openssl looks for the wrong hash value in the CAdir and, even if I fake up a symlink in the CAdir to the right root cert, it doesn't use it. Internet Explorer accepts the same certificate chain, and presumably that is how it is in use in the field (Korea is known for being quite IE-centric, or at least it used to be). I have seen this problem on another private/governmental CA before but the problem was fixed before I got around to looking for solutions. Have I diagnosed the problem correctly? Is this behaviour by openssl correct or incorrect, likely to change, or is it possible to make it work at the application level? Changing the encoding does violate a few standards including RFC3280 and RFC5280 but a few errant CAs exist which do it. Your analysis of that case is correct. If you use the command: openssl x509 -in mogaha.pem -subject -issuer -nameopt multiline,show_type -noout -subject_hash -issuer_hash You can clearly see the result: subject= countryName = PRINTABLESTRING:KR organizationName = PRINTABLESTRING:Government of Korea organizationalUnitName= PRINTABLESTRING:GPKI commonName= PRINTABLESTRING:GPKIRootCA issuer= countryName = PRINTABLESTRING:KR organizationName = PRINTABLESTRING:Government of Korea organizationalUnitName= PRINTABLESTRING:GPKI commonName= PRINTABLESTRING:GPKIRootCA 20e6f02d 20e6f02d Note the two hash values are the same. Whereas for mogaha_int.pem you get: subject= countryName = PRINTABLESTRING:KR organizationName = UTF8STRING:Government of Korea organizationalUnitName= UTF8STRING:GPKI commonName= UTF8STRING:CA134040001 issuer= countryName = PRINTABLESTRING:KR organizationName = UTF8STRING:Government of Korea organizationalUnitName= UTF8STRING:GPKI commonName= UTF8STRING:GPKIRootCA 610e5e7b 449b326d You can see here that the string types differ and the second hash value (issuer) doesn't match those for mogaha.pem. If you tried getting those hash values with with OpenSSL 1.0.0 or later using: openssl x509 -in mogaha.pem -subject_hash -issuer_hash -noout you get this: mogaha.pem: 11e07c09 11e07c09 mogaga_int.pem aac725e5 11e07c09 Here you'll see that now the issuer hash matches because 1.0.0 uses a different algorithm for computing hashes which relies on a form of canonical encoding. So the best I can suggest is using 1.0.0 which is currently in beta. For compatibility reasons we can't backport the modified algorithm to 0.9.8. I think MSIE uses SKID/AKID to build chains if the extensions are present avoiding DN matching altogether though that can introduce its own problems. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
Hi,
Thanks for all the help. I modified the code based on your comments.
Basically, I am trying to verify a CMS data signed by a C# program. So I have
the base 64 decoded CSM data stored as nBytes a BYTE array.
I have to verify the data(nBytes) using the DSA params and public key which is
hard coded in the code as const char arrays(uLicenseCheckG,
uLicenseCheckP, uLicenseCheckQ and uLicenseCheckY).
I tried to verify even using the CMS_NO_CONTENT_VERIFY flag. CMS_verify() fails
with error signer certificate not found.
I digged in to the code and found that CMS_Verify() tries to copy the st(stack
of x509 certs) to cms and fails? I am copying the skid value from the
cms and creating the x509Cert using that so they match. I have notices that the
x509Cert-skid is becoming NULL after the call to CMS_verify().
Is there anything wrong with the above x509 cert created above with the public
key and DSA params and skid. Am I missing something?
What else do I need to verify correctly?
Please find the modified code below.
-Ujwal
//COPY the DSA params and public keys from const char arrays into DSA structure
DSA *dsaParams= DSA_new();
dsaParams-g = BN_new();
dsaParams-p = BN_new();
dsaParams-q = BN_new();
dsaParams-pub_key = BN_new();
BN_bin2bn((const unsigned char *)uLicenseCheckG, sizeof(uLicenseCheckG),
dsaParams-g);
BN_bin2bn((const unsigned char *)uLicenseCheckP, sizeof(uLicenseCheckP),
dsaParams-p);
BN_bin2bn((const unsigned char *)uLicenseCheckQ, sizeof(uLicenseCheckQ),
dsaParams-q);
BN_bin2bn((const unsigned char *)uLicenseCheckY, sizeof(uLicenseCheckY),
dsaParams-pub_key);
//Create a EVP_PKEY to use in creating a certificate
EVP_PKEY *evpTemp = EVP_PKEY_new();
EVP_PKEY_assign_DSA(evpTemp, dsaParams);
//Create a CMS content info structure out of the license key
CMS_ContentInfo *cms = NULL;
BIO *bioBuff = BIO_new_mem_buf((char *)nBytes, nCountOfBytes);
BIO_set_mem_eof_return(bioBuff,0);
cms = d2i_CMS_bio(bioBuff, NULL);// i believe this finds the end of ASN1
data
STACK_OF(CMS_SignerInfo) *sinfos;
CMS_SignerInfo *si;
sinfos = CMS_get0_SignerInfos(cms);
si = sk_CMS_SignerInfo_value(sinfos, 0);
ASN1_OCTET_STRING* keyid;
X509_NAME* issuer;
ASN1_INTEGER* sno;
int rc = CMS_SignerInfo_get0_signer_id(si, keyid, issuer, sno);
//USE THIS KEYID TO SET THE x509Cert-skid VALUE
printf (si: %d %p %p %p\n, rc, keyid, issuer, sno);
//create a x509 cert with above DSA params and public key and skid
X509 *x509Cert = X509_new();
X509_set_version(x509Cert, 2);
ASN1_INTEGER_set(X509_get_serialNumber(x509Cert), 0);
x509Cert-skid = ASN1_OCTET_STRING_dup(keyid);
X509_gmtime_adj(X509_get_notBefore(x509Cert),0);
X509_gmtime_adj(X509_get_notAfter(x509Cert), (long) 60*60*24*365);
int error = X509_set_pubkey(x509Cert, evpTemp);
if (error) {
printf(set public key error: %s,
ERR_error_string(ERR_get_error(), NULL));
}
X509_print_fp(stdout, x509Cert);
//create a stack of x509 cert to use it in CMS_verify
STACK_OF(X509) *st=sk_X509_new_null();
sk_X509_push(st, x509Cert);
//x509Cert-skid is valid here
printf (skid: %p\n, x509Cert-skid);
//It fails here with signer certificate not found error
//Also tried using the CMS_NO_CONTENT_VERIFY
int cmsVerify = CMS_verify(cms, st, NULL, NULL, NULL,
CMS_NOINTERN|CMS_NO_SIGNER_CERT_VERIFY);
errortemp = ERR_get_error();
ERR_error_string(errortemp, errorbuff);
printf(countofbytes = %d, error num = %d, and error =
%s\n,nCountOfBytes,errortemp, errorbuff);
//x509Cert-skid is in-valid here
printf (skid: %p\n, x509Cert-skid);
