Re: Schanner secu
Hi, The latest Windows update that corrected the WinShock SChannel vulnerability brought many changes to the way TLS is performed and among the changes is the fact that the Supported Point Formats Extension is not sent anymore in the ServerHello during the TLS handshake. In version of OpenSSL prior to 1.0.0c, the Supported Point Formats Extension was expected to be present all the time which ofcourse is not correct. I have sent a patch for that in 2010 (https://rt.openssl.org/Ticket/Display.html?id=2240user=guestpass=guest#txn-26841) and the correction was subsequently included in 1.0.0c. This explains why you are starting to receive TLS handshake errors with curl client linked with OpenSSL 1.0.0a and 1.0.0b after the SChannel update from Microsoft. If you are not able to upgrade your clients, then the only solution is to ask Microsoft how to force the inclusion of the Supported Point Formats Extension in the TLS handshake as it was the case before. Their SChannel update brought new issues anyway and most certainly Microsoft will publish another update to SChannel in order to solve them, so there is a possibility for them to restore the old TLS handshake behavior unless it causes security issues for them (but I can't imagine how). Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 11/14/2014 10:02 PM, Gilles Vollant wrote: Microsoft just published a patch on their SChannel component (KB 2992611 ) https://technet.microsoft.com/library/security/MS14-066 But with this fix, Web server IIS 7.5/8.0 on Windows server 2008R2 or Windows server 2012 did not accept download from curl + OpenSSL 1.0.0a / 1.0.0b ! If you compile curl with OpenSSL 1.0.0a or 1.0.0b, curl cannot download anything from IIS 7.5/8.0 webserver using https after patching ! OpenSSL 1.0.0c has no problem. But somes clients cannot be updated magically! Curl says: curl: (35) error:1411809D:SSL routines:SSL_CHECK_SERVERHELLO_TLSEXT:tls invalid ecpointformat list I made a report here: http://www.winimage.com/demo_report_openssl_windows/ I hope Microsoft can (and will) update their fix to allow curl + openssl1.0.0(a or b) connect ! regards Gilles Vollant __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Differences between openssl-fips-2.0.7 and 2.0.8
Hello, I am currently using openssl-fips-2.0.7 and I noticed that 2.0.8 is available on the website. Neither distribution contain a changelog, so I was wondering what changes were made to 2.0.8. Thanks, Phil Phil Bellino Principal Software Engineer | MRV Communications Inc. 300 Apollo Drive | Chelmsford, MA 01824 Phone: 978-674-6870 | Fax: 978-674-6799 www.mrv.com [MRV-email] [E-Banner]http://www.mrv.com/landing/mrvs-software-defined-networking-sdn-and-network-function-virtualization-nfv-products-and-architecture The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited.
Digital Certificates
Hello, Actually I have developed one algorithm like RSA so how can I use my algorithm with OPENSSL to secure Tcp/ip connections. Sorry if you don't understand my questions, I am totally new to the these topics. -Niraj On 19-Nov-2014 1:08 PM, Amir Reda amirale...@gmail.com wrote: sorry sir what do you mean by your question On Wed, Nov 19, 2014 at 9:02 AM, Niraj Sorathiya nirajsorathiya...@gmail.com wrote: Hello Everyone, Where we are executing these client.cc,server.cc,client.h,server.h,certificate.cpp files ? As i want to make my own Digital Certificate using my own algorithm i was not understanding where to execute these files. Thankyou. Regards, Niraj. On Wed, Nov 19, 2014 at 12:12 AM, Scott Neugroschl scot...@xypro.com wrote: That looks like a debugger message, not an actual error from the code. *From:* owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] *On Behalf Of *Amir Reda *Sent:* Tuesday, November 18, 2014 10:29 AM *To:* openssl-users@openssl.org *Subject:* sign problem dear all i made an application a client server the client send a certificate request and server reply with the certificate and it creates a encrypted shared key and some data and sign the digest of the shared key and data my problem is 1- in SignDigest() in EVP_DigestSignFinal(mdctx, NULL, signlen); function return an error No source available for EVP_PKEY_sign() at 0xb7ede098 i don't know the reason for this error it should return the length of the sign only then i reserve a location in memory with this size please help me -- Warmest regards and best wishes for a good health,*urs sincerely * *mero* -- Warmest regards and best wishes for a good health,*urs sincerely * *mero*
RE: Digital Certificates
I have developed one algorithm like RSA so how can I use my algorithm with OPENSSL to secure Tcp/ip connections. Adding new algorithms to openssl is not trivial. It's also not really documented. Good luck! For what it's worth, developing your own crypto algorithms is generally a bad idea, unless it is a learning exercise. A free opinion, worth what you paid for it :)
X509_verify_cert: How to retrieve the actual CRLs used to verifiy a certificate?
Hi, via X509_LOOKUP_load_file() resp. X509_LOOKUP_add_dir() I'm adding a PEM file containing multiple CRLs and/or a directory containing hashed CRL files to a X509_STORE. Then I'm using the X509_verify_cert() function to verify a certificate. After verification is successful, I would like to get the actual CRL object that was used to verify the certificate. How can that be done? Do I have to plug into the get_crl() callback function of the X509_STORE structure? Thanks Stephan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openSSL equivalent of RSA/ECB/PKCS1Padding
I am trying to emulate in OpenSSL java encryption algorithm. When using RSA_public_encrypt are there parameters to emulate any of these combinations of parameters in Java? RSA/ECB/OAEPWITHMD5ANDMGF1PADDING or RSA/ECB/PKCS1Padding? I tried using RSA_PKCS1_PADDING as a padding parameter but when I decrypt the encrypted text in Java I get a BadPadding exception. Thanks, Dan
SSL alert number 51
Good day - Can anyone offer some clues on 10280:error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error:.\ssl\s3_pkt.c:1275:SSL alert number 51 OpenSSL 1.01h is the server, running on Windows 7 Pro 64 bit. Thanks, Charles
Re: Schanner secu
Microsoft published today a new version of the KB 2992611 on the first patch, they modified the registry entry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CryptographyBeforce\Configuration\Local\SSL\00010002 , entry Functions original list, before 11 november, and after 19 november TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_MD5 SSL_CK_RC4_128_WITH_MD5 SSL_CK_DES_192_EDE3_CBC_WITH_MD5 TLS_RSA_WITH_NULL_SHA256 TLS_RSA_WITH_NULL_SHA The list between 11 november and 18 november TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521 TLS_RSA_WITH_NULL_MD5 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_NULL_SHA256 TLS_RSA_WITH_NULL_SHA SSL_CK_RC4_128_WITH_MD5 SSL_CK_DES_192_EDE3_CBC_WITH_MD5 and openssl 1.0.0b run well. The week whene TLS_ECDHE_* were in top of lists, OpenSSL 1.0.0b select it and we had the compatibility problem. Now, openssl 1.0.0b select again a TLS_RSA_WITH_AES_* cipher without problem 2014-11-14 22:02 GMT+01:00 Gilles Vollant vollant.gil...@gmail.com: Microsoft just published a patch on their SChannel component (KB 2992611 ) https://technet.microsoft.com/library/security/MS14-066 But with this fix, Web server IIS 7.5/8.0 on Windows server 2008R2 or Windows server 2012 did not accept download from curl + OpenSSL 1.0.0a / 1.0.0b ! If you compile curl with OpenSSL 1.0.0a or 1.0.0b, curl cannot download anything from IIS 7.5/8.0 webserver using https after patching ! OpenSSL 1.0.0c has no problem. But somes clients cannot be updated magically! Curl says: curl: (35) error:1411809D:SSL routines:SSL_CHECK_SERVERHELLO_TLSEXT:tls invalid ecpointformat list I made a report here: http://www.winimage.com/demo_report_openssl_windows/ I hope Microsoft can (and will) update their fix to allow curl + openssl1.0.0(a or b) connect ! regards Gilles Vollant
Re: Schanner secu
On https://support.microsoft.com/kb/2992611 we can read Some customers have reported an issue that is related to the changes in this release. These changes added the following new cipher suites to Windows Server 2008 R2 and Windows Server 2012. In order to give customers more control over whether these cipher suites are used in the short term, we are removing them from the default cipher suite priority list in the registry. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256
RE: SSL alert number 51
From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Wednesday, November 19, 2014 14:08 10280:error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error:.\ssl\s3_pkt.c:1275:SSL alert number 51 http://tools.ietf.org/html/rfc5246.html#section-7.2 decrypt_error A handshake cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message. This message is always fatal. Either there's a bug somewhere or you are being attacked (MitM'ed). OpenSSL 1.01h is the server, running on Windows 7 Pro 64 bit. Do you mean the server, running 1.0.1h on Win7, produced this error message, or some client talking *to* such a server produced the error? In either case, what is in the error output or log of the opposite peer? If you try to connect s_client to the server, or the client to s_server, respectively, does it work or what error info does it give you? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: openSSL equivalent of RSA/ECB/PKCS1Padding
From: owner-openssl-us...@openssl.org On Behalf Of Dan Si Atat Sent: Wednesday, November 19, 2014 14:32 I am trying to emulate in OpenSSL java encryption algorithm. When using RSA_public_encrypt are there parameters to emulate any of these combinations of parameters in Java? RSA/ECB/OAEPWITHMD5ANDMGF1PADDING or RSA/ECB/PKCS1Padding? I tried using RSA_PKCS1_PADDING as a padding parameter but when I decrypt the encrypted text in Java I get a BadPadding exception. Then you're doing something wrong. I can encrypt in openssl with PKCS1_PADDING or OAEP_PADDING and decrypt in Java with RSA/ECB/PKCS1PADDING (or just RSA, because Java defaults to PKCS1 padding) or RSA/ECB/OAEPWITHSHA1ANDMGF1PADDING (SHA1 not MD5; openssl doesn't do OEAP-MD5, nor the SHA-2s) and vice versa. Tested with openssl 0.9.8za 1.0.0j,m 1.0.1c,h versus Java 7u15 7u72 8u05 8u25 which are the versions I currently have on my throwaway test environment. (FWIW I do have unlimited crypto policy in all Javas, although I don't think that makes a difference for RSA.) Are you sure you're using (halves of) the same keypair on both sides? Key mismatch will definitely manifest as bad padding. Are you treating the data as binary (C/C++ b, Java Stream bytes not Reader/Writer chars) or encoding/decoding to a form that exactly preserves bits (usually base64 or hex)? (Although if not I would usually expect length errors rather than padding.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL alert number 51
Dave - Thanks much. Either there's a bug somewhere or you are being attacked (MitM'ed). Unlikely I am being MitM'ed -- the connection is over a VPN. (Why TLS when there is already a VPN in place? I am testing TLS software and the VPN is a fact of life and my only client to server link. Do you mean the server, running 1.0.1h on Win7, produced this error message, or some client talking *to* such a server produced the error? Statement was kind of ambiguous, wasn't it? The server, which is OpenSSL 1.0.1h 5 Jun 2014, produced this message, when the client attempted to connect. The client is application software that uses the IBM GSK crypto library on z/OS. The error message at the client end is Error code 9 returned from GSK function gsk_secure_socket_init(): Cryptographic processing error. It is my code that produces that exact message, but the 9 comes back from the indicated method and the text comes from a system function, gsk_strerror(9). The documentation says 9 Cryptographic processing error. Explanation: An error is detected by a cryptographic function. This error may also occur if key sizes that are non-FIPS are used during an SSL handshake while operating in FIPS mode. User response: If the error occurred while executing in FIPS mode, check that only FIPS key sizes are used. Collect a System SSL trace containing the error and then contact your service representative. I can connect between the client and the server using the set of parameters under test. They negotiate TLSV1.1 and what you call DHE-RSA-AES256-SHA and GSK calls Cipher Suite 39 - SSL V3.0 AES SHA-1(ephemeral Diffie-Hellman) RSA. It works provided I do not turn on FIPS 140-2 mode. If I turn on FIPS 140-2 mode with rc = gsk_fips_state_set(GSK_FIPS_STATE_ON); and use otherwise identical parameters then this error occurs. (Cipher Suite 39 is a valid FIPS 140-2 cipher suite, according to the IBM GSK documentation.) I don't think that an s_client test would be terribly informative, seeing as I can connect with the actual client software. Back to you ... Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Wednesday, November 19, 2014 2:20 PM To: openssl-users@openssl.org Subject: RE: SSL alert number 51 From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Wednesday, November 19, 2014 14:08 10280:error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error:.\ssl\s3_pkt.c:1275:SSL alert number 51 http://tools.ietf.org/html/rfc5246.html#section-7.2 decrypt_error A handshake cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message. This message is always fatal. Either there's a bug somewhere or you are being attacked (MitM'ed). OpenSSL 1.01h is the server, running on Windows 7 Pro 64 bit. Do you mean the server, running 1.0.1h on Win7, produced this error message, or some client talking *to* such a server produced the error? In either case, what is in the error output or log of the opposite peer? If you try to connect s_client to the server, or the client to s_server, respectively, does it work or what error info does it give you? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL alert number 51
On 19/11/14 22:57, Charles Mills wrote: Dave - Thanks much. Either there's a bug somewhere or you are being attacked (MitM'ed). Unlikely I am being MitM'ed -- the connection is over a VPN. (Why TLS when there is already a VPN in place? I am testing TLS software and the VPN is a fact of life and my only client to server link. Do you mean the server, running 1.0.1h on Win7, produced this error message, or some client talking *to* such a server produced the error? Statement was kind of ambiguous, wasn't it? The server, which is OpenSSL 1.0.1h 5 Jun 2014, produced this message, when the client attempted to connect. The client is application software that uses the IBM GSK crypto library on z/OS. The error message at the client end is Error code 9 returned from GSK function gsk_secure_socket_init(): Cryptographic processing error. It is my code that produces that exact message, but the 9 comes back from the indicated method and the text comes from a system function, gsk_strerror(9). The documentation says 9 Cryptographic processing error. Explanation: An error is detected by a cryptographic function. This error may also occur if key sizes that are non-FIPS are used during an SSL handshake while operating in FIPS mode. My guess is that this last sentence is the cause of your problem. User response: If the error occurred while executing in FIPS mode, check that only FIPS key sizes are used. Collect a System SSL trace containing the error and then contact your service representative. I can connect between the client and the server using the set of parameters under test. They negotiate TLSV1.1 and what you call DHE-RSA-AES256-SHA and FIPS 140-2 places restrictions on the size of the RSA key that you can use. I'm not a FIPS 140-2 expert but I believe you have to be compliant with the various other FIPS standards including FIPS 186-4(?): This Standard specifies three choices for the length of the modulus (i.e.,nlen): 1024, 2048 and 3072 bits. Federal Government entities shall generate digital signatures using one or more of these choices. So how big is your RSA key on the server? Are you able to post the certificate? Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL alert number 51
On Wed, Nov 19, 2014, Matt Caswell wrote: On 19/11/14 22:57, Charles Mills wrote: User response: If the error occurred while executing in FIPS mode, check that only FIPS key sizes are used. Collect a System SSL trace containing the error and then contact your service representative. I can connect between the client and the server using the set of parameters under test. They negotiate TLSV1.1 and what you call DHE-RSA-AES256-SHA and FIPS 140-2 places restrictions on the size of the RSA key that you can use. I'm not a FIPS 140-2 expert but I believe you have to be compliant with the various other FIPS standards including FIPS 186-4(?): This Standard specifies three choices for the length of the modulus (i.e.,nlen): 1024, 2048 and 3072 bits. Federal Government entities shall generate digital signatures using one or more of these choices. So how big is your RSA key on the server? Are you able to post the certificate? Also the DH parameter size should be at least 1024 bits. 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: SSL alert number 51
- DHE is 1024 - RSA is 2048 Server certificate: Certificate: Data: Version: 3 (0x2) Serial Number: 13 (0xd) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=Charles Mills Consulting, LLC, ST=California, C=US/emailAddress=charles m...@mcn.org, O=Charles Mills Consulting, LLC Validity Not Before: Nov 19 17:06:26 2014 GMT Not After : Nov 19 17:06:26 2015 GMT Subject: CN=Charles Mills Consulting, LLC, ST=California, C=US/emailAddress=charle s...@mcn.org, O=X201NOTEBOOK_Server Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c2:31:37:47:60:74:b9:b7:f1:3e:31:40:d4:5b: 76:0b:a6:fb:d7:0d:75:87:3e:70:9b:1b:93:d2:a1: 0c:94:68:ba:ee:75:eb:28:28:de:16:25:32:d3:7a: 8c:4a:3f:39:1e:82:b6:5a:8a:89:75:cc:cc:77:87: af:8f:9c:c6:dc:b2:40:5c:8a:0a:74:3e:f1:f5:9f: da:23:b7:4d:a5:b7:48:7b:44:aa:58:8f:42:34:41: a2:51:22:50:50:74:28:99:5f:56:b5:f8:77:26:8e: a1:96:f3:28:10:7c:bf:75:37:a6:45:e7:3a:a2:63: 4f:ec:39:b0:12:51:90:18:7e:e2:a1:9e:76:c7:77: bd:ab:cf:0c:d2:d0:e8:cb:a8:fc:c3:85:94:41:ed: 53:82:f5:0c:32:dc:0d:80:e5:2d:34:f1:9c:e4:98: 2d:93:20:6b:57:78:87:3e:5e:c5:50:45:5a:ac:af: dc:bd:38:c1:3d:31:2c:18:bc:4f:f2:7e:cf:f0:ba: 94:57:54:3e:89:2a:af:37:73:08:4d:b7:e3:e1:bb: 9a:86:6d:f6:73:a3:22:d8:d9:c7:8d:2a:32:8a:be: fa:36:66:54:c1:3a:7a:bd:e6:b8:2b:72:65:1f:c3: 5c:91:ca:bc:44:7b:0b:d2:8f:1c:73:75:ff:5d:ce: cf:31 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Alternative Name: DNS:X201NOTEBOOK_Server, DNS:10.17.40.*, DNS:10.17.40.* X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 7B:A3:68:D6:1D:26:59:91:5D:21:1B:45:99:C4:B2:92:BF:46:1D:29 Signature Algorithm: sha1WithRSAEncryption 61:2e:16:1c:b5:90:72:e8:b6:1c:00:82:5f:7f:70:69:14:e3: 6b:fc:4c:3d:7f:24:f1:85:73:16:21:58:7e:46:4f:b5:97:d3: 5e:92:f0:4e:70:be:28:41:12:65:1e:fd:12:f3:43:d5:96:44: 60:96:3e:52:d8:1f:ae:8b:52:a1:bc:4f:1b:1a:59:2b:8f:5a: 49:1e:21:4b:14:f1:d1:84:b3:fb:58:48:04:27:5f:ac:28:73: 3b:81:c3:39:72:0a:6b:3e:c4:58:a9:a9:75:78:a1:f0:4e:6d: e7:4e:a2:71:22:9d:11:1a:a8:38:03:8c:ff:5c:9d:e0:a2:3a: 39:39:0b:fb:c2:7a:ec:42:4e:fb:fe:53:c1:63:b1:c6:2d:59: 14:82:4f:07:05:9d:91:96:e9:bd:15:c0:ba:f4:da:54:81:2e: 11:f8:b9:86:00:a2:09:fc:7a:f5:c5:2d:44:06:c8:cc:2a:ad: b8:d7:12:90:43:7a:74:81:64:6b:19:db:00:d1:f6:cf:da:b9: c7:49:5e:4d:18:65:6d:ef:c0:0d:b9:9c:d1:27:27:b6:64:0c: 11:5c:0d:a9:54:90:38:aa:61:63:f1:88:ae:d4:1b:40:98:96: 3c:13:e9:97:8e:9f:a4:01:f5:a4:ff:4d:4a:c7:2e:a6:56:63: 82:c0:57:7b -BEGIN CERTIFICATE- MIIETDCCAzSgAwIBAgIBDTANBgkqhkiG9w0BAQUFADCBkzEmMCQGA1UEAwwdQ2hh cmxlcyBNaWxscyBDb25zdWx0aW5nLCBMTEMxEzARBgNVBAgMCkNhbGlmb3JuaWEx CzAJBgNVBAYTAlVTMR8wHQYJKoZIhvcNAQkBFhBjaGFybGVzbUBtY24ub3JnMSYw JAYDVQQKDB1DaGFybGVzIE1pbGxzIENvbnN1bHRpbmcsIExMQzAeFw0xNDExMTkx NzA2MjZaFw0xNTExMTkxNzA2MjZaMIGJMSYwJAYDVQQDDB1DaGFybGVzIE1pbGxz IENvbnN1bHRpbmcsIExMQzETMBEGA1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMC VVMxHzAdBgkqhkiG9w0BCQEWEGNoYXJsZXNtQG1jbi5vcmcxHDAaBgNVBAoME1gy MDFOT1RFQk9PS19TZXJ2ZXIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDCMTdHYHS5t/E+MUDUW3YLpvvXDXWHPnCbG5PSoQyUaLrudesoKN4WJTLTeoxK PzkegrZaiol1zMx3h6+PnMbcskBcigp0PvH1n9ojt02lt0h7RKpYj0I0QaJRIlBQ dCiZX1a1+HcmjqGW8ygQfL91N6ZF5zqiY0/sObASUZAYfuKhnnbHd72rzwzS0OjL qPzDhZRB7VOC9Qwy3A2A5S008ZzkmC2TIGtXeIc+XsVQRVqsr9y9OME9MSwYvE/y fs/wupRXVD6JKq83cwhNt+Phu5qGbfZzoyLY2ceNKjKKvvo2ZlTBOnq95rgrcmUf w1yRyrxEewvSjxxzdf9dzs8xAgMBAAGjgbIwga8wCQYDVR0TBAIwADA2BgNVHREE LzAtghNYMjAxTk9URUJPT0tfU2VydmVyggoxMC4xNy40MC4qggoxMC4xNy40MC4q MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAsBglghkgBhvhCAQ0EHxYd T3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHujaNYdJlmR XSEbRZnEspK/Rh0pMA0GCSqGSIb3DQEBBQUAA4IBAQBhLhYctZBy6LYcAIJff3Bp FONr/Ew9fyTxhXMWIVh+Rk+1l9NekvBOcL4oQRJlHv0S80PVlkRglj5S2B+ui1Kh vE8bGlkrj1pJHiFLFPHRhLP7WEgEJ1+sKHM7gcM5cgprPsRYqal1eKHwTm3nTqJx Ip0RGqg4A4z/XJ3gojo5OQv7wnrsQk77/lPBY7HGLVkUgk8HBZ2Rlum9FcC69NpU gS4R+LmGAKIJ/Hr1xS1EBsjMKq241xKQQ3p0gWRrGdsA0fbP2rnHSV5NGGVt78AN uZzRJye2ZAwRXA2pVJA4qmFj8Yiu1BtAmJY8E+mXjp+kAfWk/01Kxy6mVmOCwFd7 -END CERTIFICATE- Underlying root: Certificate: Data: Version: 3 (0x2)
Possible bug in GCM/GMAC with (just) AAD of size unequal to block size
Hi all, I would be very grateful if somebody could explain why the following problem occurs: a test vector with an AAD of 20 bytes created an authentication tag that is not correct, this could for instance be a padding bug in OpenSSL's GCM implementation. Ref: http://stackoverflow.com/q/27023287/589259 The Bouncy Castle implementation does seem to generate the correct value for the same test vector. I'll try and execute the code, but currently my openssl development environment is not up. Regards, Maarten
Re: Possible bug in GCM/GMAC with (just) AAD of size unequal to block size
On Nov 19, 2014, at 5:03 PM, Maarten Bodewes maarten.bode...@gmail.com wrote: Hi all, I would be very grateful if somebody could explain why the following problem occurs: a test vector with an AAD of 20 bytes created an authentication tag that is not correct, this could for instance be a padding bug in OpenSSL's GCM implementation. Ref: http://stackoverflow.com/q/27023287/589259 http://stackoverflow.com/q/27023287/589259 The Bouncy Castle implementation does seem to generate the correct value for the same test vector. I'll try and execute the code, but currently my openssl development environment is not up. Regards, Maarten I built your code against 1.0.1j and got the expected result for the authtag on your test vector: should be: c75b7832b2a2d9bd827412b6ef5769db result is: c75b7832b2a2d9bd827412b6ef5769db $ openssl version OpenSSL 1.0.1j 15 Oct 2014
Re: Possible bug in GCM/GMAC with (just) AAD of size unequal to block size
On Nov 19, 2014, at 6:09 PM, William McGovern w...@thaiglish.com wrote: On Nov 19, 2014, at 5:03 PM, Maarten Bodewes maarten.bode...@gmail.com mailto:maarten.bode...@gmail.com wrote: Hi all, I would be very grateful if somebody could explain why the following problem occurs: a test vector with an AAD of 20 bytes created an authentication tag that is not correct, this could for instance be a padding bug in OpenSSL's GCM implementation. Ref: http://stackoverflow.com/q/27023287/589259 http://stackoverflow.com/q/27023287/589259 The Bouncy Castle implementation does seem to generate the correct value for the same test vector. I'll try and execute the code, but currently my openssl development environment is not up. Regards, Maarten I built your code against 1.0.1j and got the expected result for the authtag on your test vector: should be: c75b7832b2a2d9bd827412b6ef5769db result is: c75b7832b2a2d9bd827412b6ef5769db $ openssl version OpenSSL 1.0.1j 15 Oct 2014 If I build against the native OpenSSL library in Ubuntu 12.04 that matches your version I get the same failure you are seeing: should be: c75b7832b2a2d9bd827412b6ef5769db result is: e5fb99cb5b9658aa5d2caa3308e0ce6c $ /usr/bin/openssl version OpenSSL 1.0.1 14 Mar 2012 It does seem to work correctly and give expected output when built on Ubuntu 14.04.
RE: SSL alert number 51
To be perfectly clear, the server is not OpenSSL itself but application code that calls OpenSSL. The code is stable and in production and, as I said, works if I do *not* turn on FIPS on the client. I could trace through the calls if necessary. Also, I will be out of the office all day Thursday so this is probably my last reply for ~36 hours. Thanks for your help. I really appreciate what you folks do. Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Charles Mills Sent: Wednesday, November 19, 2014 4:53 PM To: openssl-users@openssl.org Subject: RE: SSL alert number 51 - DHE is 1024 - RSA is 2048 Server certificate: Certificate: Data: Version: 3 (0x2) Serial Number: 13 (0xd) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=Charles Mills Consulting, LLC, ST=California, C=US/emailAddress=charles m...@mcn.org, O=Charles Mills Consulting, LLC Validity Not Before: Nov 19 17:06:26 2014 GMT Not After : Nov 19 17:06:26 2015 GMT Subject: CN=Charles Mills Consulting, LLC, ST=California, C=US/emailAddress=charle s...@mcn.org, O=X201NOTEBOOK_Server Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c2:31:37:47:60:74:b9:b7:f1:3e:31:40:d4:5b: 76:0b:a6:fb:d7:0d:75:87:3e:70:9b:1b:93:d2:a1: 0c:94:68:ba:ee:75:eb:28:28:de:16:25:32:d3:7a: 8c:4a:3f:39:1e:82:b6:5a:8a:89:75:cc:cc:77:87: af:8f:9c:c6:dc:b2:40:5c:8a:0a:74:3e:f1:f5:9f: da:23:b7:4d:a5:b7:48:7b:44:aa:58:8f:42:34:41: a2:51:22:50:50:74:28:99:5f:56:b5:f8:77:26:8e: a1:96:f3:28:10:7c:bf:75:37:a6:45:e7:3a:a2:63: 4f:ec:39:b0:12:51:90:18:7e:e2:a1:9e:76:c7:77: bd:ab:cf:0c:d2:d0:e8:cb:a8:fc:c3:85:94:41:ed: 53:82:f5:0c:32:dc:0d:80:e5:2d:34:f1:9c:e4:98: 2d:93:20:6b:57:78:87:3e:5e:c5:50:45:5a:ac:af: dc:bd:38:c1:3d:31:2c:18:bc:4f:f2:7e:cf:f0:ba: 94:57:54:3e:89:2a:af:37:73:08:4d:b7:e3:e1:bb: 9a:86:6d:f6:73:a3:22:d8:d9:c7:8d:2a:32:8a:be: fa:36:66:54:c1:3a:7a:bd:e6:b8:2b:72:65:1f:c3: 5c:91:ca:bc:44:7b:0b:d2:8f:1c:73:75:ff:5d:ce: cf:31 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Alternative Name: DNS:X201NOTEBOOK_Server, DNS:10.17.40.*, DNS:10.17.40.* X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 7B:A3:68:D6:1D:26:59:91:5D:21:1B:45:99:C4:B2:92:BF:46:1D:29 Signature Algorithm: sha1WithRSAEncryption 61:2e:16:1c:b5:90:72:e8:b6:1c:00:82:5f:7f:70:69:14:e3: 6b:fc:4c:3d:7f:24:f1:85:73:16:21:58:7e:46:4f:b5:97:d3: 5e:92:f0:4e:70:be:28:41:12:65:1e:fd:12:f3:43:d5:96:44: 60:96:3e:52:d8:1f:ae:8b:52:a1:bc:4f:1b:1a:59:2b:8f:5a: 49:1e:21:4b:14:f1:d1:84:b3:fb:58:48:04:27:5f:ac:28:73: 3b:81:c3:39:72:0a:6b:3e:c4:58:a9:a9:75:78:a1:f0:4e:6d: e7:4e:a2:71:22:9d:11:1a:a8:38:03:8c:ff:5c:9d:e0:a2:3a: 39:39:0b:fb:c2:7a:ec:42:4e:fb:fe:53:c1:63:b1:c6:2d:59: 14:82:4f:07:05:9d:91:96:e9:bd:15:c0:ba:f4:da:54:81:2e: 11:f8:b9:86:00:a2:09:fc:7a:f5:c5:2d:44:06:c8:cc:2a:ad: b8:d7:12:90:43:7a:74:81:64:6b:19:db:00:d1:f6:cf:da:b9: c7:49:5e:4d:18:65:6d:ef:c0:0d:b9:9c:d1:27:27:b6:64:0c: 11:5c:0d:a9:54:90:38:aa:61:63:f1:88:ae:d4:1b:40:98:96: 3c:13:e9:97:8e:9f:a4:01:f5:a4:ff:4d:4a:c7:2e:a6:56:63: 82:c0:57:7b -BEGIN CERTIFICATE- MIIETDCCAzSgAwIBAgIBDTANBgkqhkiG9w0BAQUFADCBkzEmMCQGA1UEAwwdQ2hh cmxlcyBNaWxscyBDb25zdWx0aW5nLCBMTEMxEzARBgNVBAgMCkNhbGlmb3JuaWEx CzAJBgNVBAYTAlVTMR8wHQYJKoZIhvcNAQkBFhBjaGFybGVzbUBtY24ub3JnMSYw JAYDVQQKDB1DaGFybGVzIE1pbGxzIENvbnN1bHRpbmcsIExMQzAeFw0xNDExMTkx NzA2MjZaFw0xNTExMTkxNzA2MjZaMIGJMSYwJAYDVQQDDB1DaGFybGVzIE1pbGxz IENvbnN1bHRpbmcsIExMQzETMBEGA1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMC VVMxHzAdBgkqhkiG9w0BCQEWEGNoYXJsZXNtQG1jbi5vcmcxHDAaBgNVBAoME1gy MDFOT1RFQk9PS19TZXJ2ZXIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDCMTdHYHS5t/E+MUDUW3YLpvvXDXWHPnCbG5PSoQyUaLrudesoKN4WJTLTeoxK PzkegrZaiol1zMx3h6+PnMbcskBcigp0PvH1n9ojt02lt0h7RKpYj0I0QaJRIlBQ dCiZX1a1+HcmjqGW8ygQfL91N6ZF5zqiY0/sObASUZAYfuKhnnbHd72rzwzS0OjL qPzDhZRB7VOC9Qwy3A2A5S008ZzkmC2TIGtXeIc+XsVQRVqsr9y9OME9MSwYvE/y fs/wupRXVD6JKq83cwhNt+Phu5qGbfZzoyLY2ceNKjKKvvo2ZlTBOnq95rgrcmUf w1yRyrxEewvSjxxzdf9dzs8xAgMBAAGjgbIwga8wCQYDVR0TBAIwADA2BgNVHREE
Re: Possible bug in GCM/GMAC with (just) AAD of size unequal to block size
On Nov 19, 2014, at 6:26 PM, William McGovern w...@thaiglish.com wrote: On Nov 19, 2014, at 6:09 PM, William McGovern w...@thaiglish.com mailto:w...@thaiglish.com wrote: On Nov 19, 2014, at 5:03 PM, Maarten Bodewes maarten.bode...@gmail.com mailto:maarten.bode...@gmail.com wrote: Hi all, I would be very grateful if somebody could explain why the following problem occurs: a test vector with an AAD of 20 bytes created an authentication tag that is not correct, this could for instance be a padding bug in OpenSSL's GCM implementation. Ref: http://stackoverflow.com/q/27023287/589259 http://stackoverflow.com/q/27023287/589259 The Bouncy Castle implementation does seem to generate the correct value for the same test vector. I'll try and execute the code, but currently my openssl development environment is not up. Regards, Maarten I built your code against 1.0.1j and got the expected result for the authtag on your test vector: should be: c75b7832b2a2d9bd827412b6ef5769db result is: c75b7832b2a2d9bd827412b6ef5769db $ openssl version OpenSSL 1.0.1j 15 Oct 2014 If I build against the native OpenSSL library in Ubuntu 12.04 that matches your version I get the same failure you are seeing: should be: c75b7832b2a2d9bd827412b6ef5769db result is: e5fb99cb5b9658aa5d2caa3308e0ce6c $ /usr/bin/openssl version OpenSSL 1.0.1 14 Mar 2012 It does seem to work correctly and give expected output when built on Ubuntu 14.04. Looks like the version that is failing still has this bug: http://rt.openssl.org/Ticket/Display.html?id=2859 http://rt.openssl.org/Ticket/Display.html?id=2859 There is also a workaround detailed in the ticket that you might be able to utilize if you don’t want to build a newer library version.
Re: Possible bug in GCM/GMAC with (just) AAD of size unequal to block size
On Nov 19, 2014, at 6:26 PM, William McGovern w...@thaiglish.com wrote:
On Nov 19, 2014, at 6:09 PM, William McGovern w...@thaiglish.com
mailto:w...@thaiglish.com wrote:
On Nov 19, 2014, at 5:03 PM, Maarten Bodewes maarten.bode...@gmail.com
mailto:maarten.bode...@gmail.com wrote:
Hi all,
I would be very grateful if somebody could explain why the following
problem occurs:
a test vector with an AAD of 20 bytes created an authentication tag that is
not correct,
this could for instance be a padding bug in OpenSSL's GCM implementation.
Ref: http://stackoverflow.com/q/27023287/589259
http://stackoverflow.com/q/27023287/589259
The Bouncy Castle implementation does seem to generate the correct value
for the same test vector.
I'll try and execute the code, but currently my openssl development
environment is not up.
Regards,
Maarten
I built your code against 1.0.1j and got the expected result for the authtag
on your test vector:
should be: c75b7832b2a2d9bd827412b6ef5769db
result is: c75b7832b2a2d9bd827412b6ef5769db
$ openssl version
OpenSSL 1.0.1j 15 Oct 2014
If I build against the native OpenSSL library in Ubuntu 12.04 that matches
your version I get the same failure you are seeing:
should be: c75b7832b2a2d9bd827412b6ef5769db
result is: e5fb99cb5b9658aa5d2caa3308e0ce6c
$ /usr/bin/openssl version
OpenSSL 1.0.1 14 Mar 2012
It does seem to work correctly and give expected output when built on Ubuntu
14.04.
And one last reply… I implemented the workaround in your code and verified that
it now working as expected.
Add this to load zero length data after you load the AAD with EVP_EncryptUpdate
and before EVP_Encrypt_Final_ex:
rc = EVP_EncryptUpdate(ctx, empty, unused, empty, 0);
assert(rc == 1);
The “empty” reference is just a dummy array (i.e. not a NULL pointer):
u_char empty[] = {};
With this change you get the correct result for the authtag for your test
vector:
should be: c75b7832b2a2d9bd827412b6ef5769db
result is: c75b7832b2a2d9bd827412b6ef5769db
$ /usr/bin/openssl version
OpenSSL 1.0.1 14 Mar 2012
