RE: Tls1.2 Problem with client certificate and RSA_verify
> From: owner-openssl-us...@openssl.org On Behalf Of Albers, Thorsten > Sent: Monday, 30 July, 2012 03:43 > I also debugged the openssl-server when receiving the message > above. The server recognized the correct hash and signature > algorithms, but while following the functions to the point > where the signature shall be verified, I will come to a point > where for some reason a wrong function is called. The code > says it wants to call RSA_verify(), but > CMS_RecipientInfo_type() is called instead and returns a > value that (of course) does not correspond with the function > that should have been called. It would really help me a lot > if I could debug the server correctly so that I could compare > my hash/signature better with the one computed by the openssl > server. Did anyone see that behavior before? > Is it really calling CMS_blah, or is your debugger just displaying the location as CMS_blah + x? Most symbolic debuggers, if you have some code with symbols and some without, and you're 'running' (i.e. your PC is in) code without symbols, will just take some symbol it considers 'handy' and use that plus an offset. If you are at the direct call to RSA_verify from ssl3_get_cert_verify which is at s3_srvr.c line 3057 in 1.0.1c, and your libssl has symbols but your libcrypto doesn't, I would expect debugger display like that. But, you shouldn't be executing that call. For TLS1.2, you should be taking the branch at line 3023 et seq which instead uses EVP_Verify*, and if you step through EVP_VerifyFinal it should reach a point where it calls through a function pointer to RSA_verify, so you wouldn't see that name in your source. And EVP_* should be in the same libcrypto as RSA_*, unless you did partial rebuild(s) or some kind of linking that mixed pieces from different sources. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Tls1.2 Problem with client certificate and RSA_verify
On Mon, Jul 30, 2012, Albers, Thorsten wrote: > Thanks Steve! Unfortunately your hint couldn't help me. I know that in TLS > 1.2 the hash and signature algorithms can be chosen during the handshake. I > chose to use Sha256 with RSA for the signature, and therefore adding the > corresponding algorithm ids in front of the signature. In Wireshark my > Client Certificate Verify message (including the record layer header) looks > like following: > 16 03 03 00 88 0f 00 00 84 04 01 00 80 b4 ee c0 > 0010 8a 35 79 0d 97 7d f0 82 e6 69 3d 7d 66 a7 58 11 > 0020 e5 9c 86 c1 9e 18 0c a0 94 37 2e 2b d2 08 9a 69 > 0030 0f 14 22 42 5c 66 b8 cb 8f dd 85 6d 85 82 f7 5e > 0040 48 84 05 b5 ca e1 7b 67 d2 08 da 8c ec 55 a2 49 > 0050 5e e6 eb f4 c2 ae b9 6e 0c 9b 43 2a 78 92 16 97 > 0060 8a ee 1e 19 57 10 7c dc d3 f5 74 21 7c cc b8 e4 > 0070 cb f2 c0 2d fe 4f c7 5f 33 cb 1a 55 da 6c 6a 76 > 0080 6a 94 ad 64 f5 b0 d1 d2 0e 9b 15 8d b7 > > The first 5 bytes are the record layer header (handshake message, protocol > version TLS 1.2, length 0x88 byte). Next comes 0x0F as handshake message > type (certificate verify), then 0x84 as the length, then 0x0401 for > SHA256 hash signed with RSA, followed by the length of the signature and the > signature itself. From this point of view to me it looks exactly like the > message I observed on a conversation between an openssl client and server > (both TLS1.2). So where else can the problem be? > The problem you mentioned indicates that there is a bug in the RSA signature format itself and not the TLS message structure. Without the corresponding public key it is impossible to analyse that signature though. > I also debugged the openssl-server when receiving the message above. The > server recognized the correct hash and signature algorithms, but while > following the functions to the point where the signature shall be verified, > I will come to a point where for some reason a wrong function is called. The > code says it wants to call RSA_verify(), but CMS_RecipientInfo_type() is > called instead and returns a value that (of course) does not correspond with > the function that should have been called. It would really help me a lot if > I could debug the server correctly so that I could compare my hash/signature > better with the one computed by the openssl server. Did anyone see that > behavior before? > This sounds like the debugger is getting confused. Try adding a debugging printf in the RSA_verify function to check it is being called. 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: Tls1.2 Problem with client certificate and RSA_verify
Thanks Steve! Unfortunately your hint couldn't help me. I know that in TLS 1.2 the hash and signature algorithms can be chosen during the handshake. I chose to use Sha256 with RSA for the signature, and therefore adding the corresponding algorithm ids in front of the signature. In Wireshark my Client Certificate Verify message (including the record layer header) looks like following: 16 03 03 00 88 0f 00 00 84 04 01 00 80 b4 ee c0 0010 8a 35 79 0d 97 7d f0 82 e6 69 3d 7d 66 a7 58 11 0020 e5 9c 86 c1 9e 18 0c a0 94 37 2e 2b d2 08 9a 69 0030 0f 14 22 42 5c 66 b8 cb 8f dd 85 6d 85 82 f7 5e 0040 48 84 05 b5 ca e1 7b 67 d2 08 da 8c ec 55 a2 49 0050 5e e6 eb f4 c2 ae b9 6e 0c 9b 43 2a 78 92 16 97 0060 8a ee 1e 19 57 10 7c dc d3 f5 74 21 7c cc b8 e4 0070 cb f2 c0 2d fe 4f c7 5f 33 cb 1a 55 da 6c 6a 76 0080 6a 94 ad 64 f5 b0 d1 d2 0e 9b 15 8d b7 The first 5 bytes are the record layer header (handshake message, protocol version TLS 1.2, length 0x88 byte). Next comes 0x0F as handshake message type (certificate verify), then 0x84 as the length, then 0x0401 for SHA256 hash signed with RSA, followed by the length of the signature and the signature itself. From this point of view to me it looks exactly like the message I observed on a conversation between an openssl client and server (both TLS1.2). So where else can the problem be? I also debugged the openssl-server when receiving the message above. The server recognized the correct hash and signature algorithms, but while following the functions to the point where the signature shall be verified, I will come to a point where for some reason a wrong function is called. The code says it wants to call RSA_verify(), but CMS_RecipientInfo_type() is called instead and returns a value that (of course) does not correspond with the function that should have been called. It would really help me a lot if I could debug the server correctly so that I could compare my hash/signature better with the one computed by the openssl server. Did anyone see that behavior before? Regards, Thorsten >-Original Message- >From: owner-openssl-us...@openssl.org [mailto:owner-openssl- >us...@openssl.org] On Behalf Of Dr. Stephen Henson >Sent: Friday, July 27, 2012 6:47 PM >To: openssl-users@openssl.org >Subject: Re: Tls1.2 Problem with client certificate and RSA_verify > >On Fri, Jul 27, 2012, Albers, Thorsten wrote: > >> Hi, >> I have a problem with the openssl s_server (v1.0.1c) when requesting a >client certificate. I'm developing my own TLS 1.2 implementation (for >embedded platforms), and I'm stuck with a problem with using the client >certificate. I already implemented TLS 1.0 earlier, so it's not completely new >for me, and it worked fine even with client certificates. >> My current implementation can handle TLS 1.2 handshakes without client >authentication, as well as TLS 1.0 with or without client authentication. When >I >try to connect to the openssl server, the handshake goes as far as the client >having sent its messages up to (including) 'change cipher spec'. But then the >server sends an alarm (decrypt error). The openssl server console tells me >some strange error: >> >> ACCEPT >> bad gethostbyaddr >> depth=1 CN = TestAndDevRootAuthority >> verify return:1 >> depth=0 CN = MyClient >> verify return:1 >> 1696:error:0D07209B:asn1 encoding routines:ASN1_get_object:too >long:.\crypto\asn1\asn1_lib.c:142: >> 1696:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object >header:.\crypto\asn1\tasn_dec.c:1306: >> 1696:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested >asn1 error:.\crypto\asn1\tasn_dec.c:381:Type=X509_SIG >> >> 1696:error:1408807B:SSL routines:SSL3_GET_CERT_VERIFY:bad >signature:.\ssl\s3_srvr.c:3049: >> 1696:error:140780E5:SSL routines:SSL23_READ:ssl handshake >failure:.\ssl\s23_lib.c:131: >> ACCEPT >> > >For previous versions of TLS the signature for RSA is a raw MD5+SHA1 >concatenation. For TLS 1.2 it is the DigestInfo structure instead using >whatever digest is appropriate. That error looks like OpenSSL is trying to >interpret an MD5+SHA1 signature as a DigestInfo and choking on it. > >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: Tls1.2 Problem with client certificate and RSA_verify
On Fri, Jul 27, 2012, Albers, Thorsten wrote: > Hi, > I have a problem with the openssl s_server (v1.0.1c) when requesting a client > certificate. I'm developing my own TLS 1.2 implementation (for embedded > platforms), and I'm stuck with a problem with using the client certificate. I > already implemented TLS 1.0 earlier, so it's not completely new for me, and > it worked fine even with client certificates. > My current implementation can handle TLS 1.2 handshakes without client > authentication, as well as TLS 1.0 with or without client authentication. > When I try to connect to the openssl server, the handshake goes as far as the > client having sent its messages up to (including) 'change cipher spec'. But > then the server sends an alarm (decrypt error). The openssl server console > tells me some strange error: > > ACCEPT > bad gethostbyaddr > depth=1 CN = TestAndDevRootAuthority > verify return:1 > depth=0 CN = MyClient > verify return:1 > 1696:error:0D07209B:asn1 encoding routines:ASN1_get_object:too > long:.\crypto\asn1\asn1_lib.c:142: > 1696:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object > header:.\crypto\asn1\tasn_dec.c:1306: > 1696:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 > error:.\crypto\asn1\tasn_dec.c:381:Type=X509_SIG > > 1696:error:1408807B:SSL routines:SSL3_GET_CERT_VERIFY:bad > signature:.\ssl\s3_srvr.c:3049: > 1696:error:140780E5:SSL routines:SSL23_READ:ssl handshake > failure:.\ssl\s23_lib.c:131: > ACCEPT > For previous versions of TLS the signature for RSA is a raw MD5+SHA1 concatenation. For TLS 1.2 it is the DigestInfo structure instead using whatever digest is appropriate. That error looks like OpenSSL is trying to interpret an MD5+SHA1 signature as a DigestInfo and choking on it. 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: Tls1.2 Problem with client certificate and RSA_verify
Hi, An idea out of nowhere : did you investigate the "bad gethostbyaddr" issue ? There is reverse DNS done. how is your reverse dns set ? can you enter you host in hosts and see if does help ? Regards, From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of Albers, Thorsten [thorsten.alb...@vector.com] Sent: Friday, July 27, 2012 1:11 PM To: openssl-users@openssl.org Subject: Tls1.2 Problem with client certificate and RSA_verify Hi, I have a problem with the openssl s_server (v1.0.1c) when requesting a client certificate. I’m developing my own TLS 1.2 implementation (for embedded platforms), and I’m stuck with a problem with using the client certificate. I already implemented TLS 1.0 earlier, so it’s not completely new for me, and it worked fine even with client certificates. My current implementation can handle TLS 1.2 handshakes without client authentication, as well as TLS 1.0 with or without client authentication. When I try to connect to the openssl server, the handshake goes as far as the client having sent its messages up to (including) ‘change cipher spec’. But then the server sends an alarm (decrypt error). The openssl server console tells me some strange error: ACCEPT bad gethostbyaddr depth=1 CN = TestAndDevRootAuthority verify return:1 depth=0 CN = MyClient verify return:1 1696:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:.\crypto\asn1\asn1_lib.c:142: 1696:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header:.\crypto\asn1\tasn_dec.c:1306: 1696:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:.\crypto\asn1\tasn_dec.c:381:Type=X509_SIG 1696:error:1408807B:SSL routines:SSL3_GET_CERT_VERIFY:bad signature:.\ssl\s3_srvr.c:3049: 1696:error:140780E5:SSL routines:SSL23_READ:ssl handshake failure:.\ssl\s23_lib.c:131: ACCEPT I’m most confused by the ASN1 errors. I debugged the openssl server beginning at the function ssl3_get_cert_verify() and through some functions to pkey_rsa_verify(). Here I found a call of RSA_verify() that never called this function but always called CMS_RecipientInfo_type(). That seems to be so wrong, and I don’t understand why this function call is misguided. Why does is call the wrong function? Any ideas? I build the openssl.exe using the batch file to build openssl with Visual Studio 2010. I’d be pleased for any hint. Regards, Thorsten Albers
Tls1.2 Problem with client certificate and RSA_verify
Hi, I have a problem with the openssl s_server (v1.0.1c) when requesting a client certificate. I'm developing my own TLS 1.2 implementation (for embedded platforms), and I'm stuck with a problem with using the client certificate. I already implemented TLS 1.0 earlier, so it's not completely new for me, and it worked fine even with client certificates. My current implementation can handle TLS 1.2 handshakes without client authentication, as well as TLS 1.0 with or without client authentication. When I try to connect to the openssl server, the handshake goes as far as the client having sent its messages up to (including) 'change cipher spec'. But then the server sends an alarm (decrypt error). The openssl server console tells me some strange error: ACCEPT bad gethostbyaddr depth=1 CN = TestAndDevRootAuthority verify return:1 depth=0 CN = MyClient verify return:1 1696:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:.\crypto\asn1\asn1_lib.c:142: 1696:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header:.\crypto\asn1\tasn_dec.c:1306: 1696:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:.\crypto\asn1\tasn_dec.c:381:Type=X509_SIG 1696:error:1408807B:SSL routines:SSL3_GET_CERT_VERIFY:bad signature:.\ssl\s3_srvr.c:3049: 1696:error:140780E5:SSL routines:SSL23_READ:ssl handshake failure:.\ssl\s23_lib.c:131: ACCEPT I'm most confused by the ASN1 errors. I debugged the openssl server beginning at the function ssl3_get_cert_verify() and through some functions to pkey_rsa_verify(). Here I found a call of RSA_verify() that never called this function but always called CMS_RecipientInfo_type(). That seems to be so wrong, and I don't understand why this function call is misguided. Why does is call the wrong function? Any ideas? I build the openssl.exe using the batch file to build openssl with Visual Studio 2010. I'd be pleased for any hint. Regards, Thorsten Albers
