Re: Question: why doesn't my wildcard matching work with OpenSSL?
> On Jun 10, 2019, at 4:41 PM, Paul Smith wrote: > >> As a safety measure, OpenSSL does not support "*.tld" wildcards. >> The non-wildcard portion of the domain name needs to have at >> least two labels. It seems I've neglected to document this... :-( >> >> You can have "*.domain.example", but not "*.domain". > > Is this something controlled by an option for X509_check_host() or is > it just hardcoded and can't be modified? I didn't see any options in > the docs that seem to manage that, unless it's a side-effect. This is not presently configurable. I see some references to similar policies in at least some of the major browsers, not just OpenSSL, so it is probably best to avoid *.tld wildcards. -- Viktor.
Re: Question: why doesn't my wildcard matching work with OpenSSL?
On Mon, 2019-06-10 at 15:14 -0400, Viktor Dukhovni wrote: > As a safety measure, OpenSSL does not support "*.tld" wildcards. > The non-wildcard portion of the domain name needs to have at > least two labels. It seems I've neglected to document this... :-( > > You can have "*.domain.example", but not "*.domain". I see, thanks, that's good info. We will try to figure out how to modify our Docker-based test configuration to use a multi-label domain name for its private network. I'm not sure how or if that will impact users, outside of our test environment. Is this something controlled by an option for X509_check_host() or is it just hardcoded and can't be modified? I didn't see any options in the docs that seem to manage that, unless it's a side-effect.
Re: Question: why doesn't my wildcard matching work with OpenSSL?
On Mon, 2019-06-10 at 20:12 +, Michael Wojcik wrote: > > What I cut out was only the base64-encoded certificate. > > Yes. That was what we needed to see. The certificate. Yep, that's my bad. Thanks for the reminder. > As it turns out, you're hitting the OpenSSL restriction on wildcards > with fewer than two domain components, as Viktor explained. I'd > forgotten about that restriction. > > However, I still recommend using a proper X.509v3 server certificate > with one or more SANs. If you're running your own CA using the > openssl utiltity, there are various online tutorials showing how to > generate modern certificates. Just to be clear, this is being seen in our docker-based test environment using a virtual network and the docker resolvers, where we're creating our own certificates so we can easily do both positive and negative testing with things like good/bad hostnames, expired certificates, incorrect chains, testing key rotation, etc. etc. Our Java and Python clients work fine, but the C/C++ clients were failing. These certificates aren't being used "for real". I'll look into enhancing our test environment to address this. Cheers!
RE: Question: why doesn't my wildcard matching work with OpenSSL?
I don't know why you sent this to me directly rather than to the list. > From: Paul Smith [mailto:p...@mad-scientist.net] > Sent: Monday, June 10, 2019 12:54 > To: Michael Wojcik > > On Mon, 2019-06-10 at 18:49 +, Michael Wojcik wrote: > > Argh. You cut out the actual relevant information. We need to see the > > server certificate. > > > > In particulary, does it contain any Subject Alternative Name > > extensions? > > What I cut out was only the base64-encoded certificate. Yes. That was what we needed to see. The certificate. > There weren't any settings shown there. I didn't mention "settings". I discussed Subject Alternative Name extensions, which are part of the certificate. > > I have a vague memory that wildcard matching only works with SANs. As it turns out, you're hitting the OpenSSL restriction on wildcards with fewer than two domain components, as Viktor explained. I'd forgotten about that restriction. However, I still recommend using a proper X.509v3 server certificate with one or more SANs. If you're running your own CA using the openssl utiltity, there are various online tutorials showing how to generate modern certificates. -- Michael Wojcik Distinguished Engineer, Micro Focus
Re: Question: why doesn't my wildcard matching work with OpenSSL?
> On Jun 10, 2019, at 2:39 PM, Paul Smith wrote: > > On Mon, 2019-06-10 at 14:23 -0400, Viktor Dukhovni wrote: >>> $ openssl s_client -connect admin0.domain:8004 \ >>> -CAfile ca.cert -verify_hostname admin0.domain >>> >>> --- >>> Verify return code: 62 (Hostname mismatch) >> >> It seems that you've elided too much information. Is the hostname >> really "admin0.domain", or is there some underlying domain name >> that you've obfuscated? > > I tried not to elide anything other than a lot of keys and stuff. > Maybe that info isn't output? > > That is actually the hostname (I have this running in a Docker > container to get the hostname set up without a lot of hassle). As a safety measure, OpenSSL does not support "*.tld" wildcards. The non-wildcard portion of the domain name needs to have at least two labels. It seems I've neglected to document this... :-( You can have "*.domain.example", but not "*.domain". -- Viktor.
Re: Question: why doesn't my wildcard matching work with OpenSSL?
On Mon, 2019-06-10 at 14:23 -0400, Viktor Dukhovni wrote: > > $ openssl s_client -connect admin0.domain:8004 \ > > -CAfile ca.cert -verify_hostname admin0.domain > > > > --- > > Verify return code: 62 (Hostname mismatch) > > It seems that you've elided too much information. Is the hostname > really "admin0.domain", or is there some underlying domain name > that you've obfuscated? I tried not to elide anything other than a lot of keys and stuff. Maybe that info isn't output? That is actually the hostname (I have this running in a Docker container to get the hostname set up without a lot of hassle). But maybe that's my confusion. What "hostname" is OpenSSL looking at? I told it the name I wanted it to use for the verify on the command line: "-verify_hostname admin0.domain", which matches the wildcard the certificate provides. That appears to be what the docs say; from verify(1ssl): -verify_hostname hostname Verify if the hostname matches DNS name in Subject Alternative Name or Common Name in the subject certificate. I thought that's all it used: this value plus the wildcard in the certificate. Am I misunderstanding this? Where else will openssl go looking for hostnames to match? Note that if I don't use wildcards but instead have a full hostname in the certificate, then verify hostname does work. It's only using a wildcard that doesn't match the way I thought it would. Thanks for the reply!
Re: Question: why doesn't my wildcard matching work with OpenSSL?
On Mon, Jun 10, 2019 at 01:52:06PM -0400, Paul Smith wrote: > Note for my C client I have not set any special flags for matching, I'm > just using the default and using SSL_set1_host() to add the hostname. > But, I can't even get it to work with openssl itself. > > For example, here's a connection attempt using the CLI... note if I > remove the -verify_hostname option the connection works fine: > > $ openssl s_client -connect admin0.domain:8004 \ > -CAfile ca.cert -verify_hostname admin0.domain > > CONNECTED(0003) > depth=1 C = US, ST = MA, L = Boston, O = Mycorp, OU = Eng, CN = ca.mycorp.com > verify return:1 > depth=0 CN = *.domain > verify return:1 > --- > Certificate chain > 0 s:/CN=*.domain >i:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com > 1 s:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com >i:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com > --- > Server certificate > -BEGIN CERTIFICATE- > ... > -END CERTIFICATE- > subject=/CN=*.domain > issuer=/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com > --- > Verify return code: 62 (Hostname mismatch) It seems that you've elided too much information. Is the hostname really "admin0.domain", or is there some underlying domain name that you've obfuscated? -- Viktor.
Question: why doesn't my wildcard matching work with OpenSSL?
I'm having problems trying to get wildcard matching working with OpenSSL. Full hostname matching is working fine, but when my certification uses a wildcard I always get an error. That includes both with OpenSSL 1.1.1b linked into my normal client, AND with the openssl CLI with a system default version. However, trying to use this same certificate and hostname matching works fine with Java and Python clients. Note for my C client I have not set any special flags for matching, I'm just using the default and using SSL_set1_host() to add the hostname. But, I can't even get it to work with openssl itself. I feel like I must be missing something dumb. Any pointers appreciated! For example, here's a connection attempt using the CLI... note if I remove the -verify_hostname option the connection works fine: $ openssl s_client -connect admin0.domain:8004 \ -CAfile ca.cert -verify_hostname admin0.domain CONNECTED(0003) depth=1 C = US, ST = MA, L = Boston, O = Mycorp, OU = Eng, CN = ca.mycorp.com verify return:1 depth=0 CN = *.domain verify return:1 --- Certificate chain 0 s:/CN=*.domain i:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com 1 s:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com i:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com --- Server certificate -BEGIN CERTIFICATE- ... -END CERTIFICATE- subject=/CN=*.domain issuer=/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com --- Acceptable client certificate CA names /C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=nuocmd.mycorp.com /C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com Client Certificate Types: RSA sign, DSA sign, ECDSA sign Requested Signature Algorithms: ... Shared Requested Signature Algorithms: ... Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits ... --- SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 Session-ID: ... Session-ID-ctx: Master-Key: ... Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1560181877 Timeout : 300 (sec) Verify return code: 62 (Hostname mismatch)
Re: CMS and GCM
Hi, On Mon, May 13, 2019 at 12:50 AM Dr. Pala wrote: > Hi All, > > I am having issues using AES GCM in EnvelopedData - in particular if I use > AES CBC, that is ok, but when I try to use the GCM mode, I simply cannot > finalize the data. > > If you want to use AES GCM, then you need AuthEnvelopedData. > Are there any specific operations that need to happen in order to use AES > in GCM mode (as per RFC5084) ? > > I have created a PR for this: https://github.com/openssl/openssl/pull/8024 . It just needs a review from OpenSSL committers. I also need to rebase it once anyone is interested in reviewing it. :) Cheers
Re: New to the list and one question ;-)
On Mon, Jun 10, 2019 at 03:21:16PM +, Patrick Regnouf via openssl-users wrote: > All is well and good when the program works on the linux PC and the > handshake is succesful using the 0xc02f cipher. and that is linked to > version 3.0.0 of openssl. on the embedded version, (linked with version > 1.0.2s) firefox fails the handshake with ssl_no_shared_cipher whereas > chrome and safari do successfully handshake chrome client hello contains > 12 ciphers and the server hello seems to choose 0xc02f cipher firefox > client hello contains only 10 ciphers (including the above mentioned 0xc02f > cipher) and fails. any suggestion as to what could causes that failure > would be appreciated. In addition to the cipher algorithm, the two parties must also agree on the signature algorithms, supported EC groups, ... You've not provided much detail about the configuration of the embedded (1.0.2s) server. The cipher that works with the other browsers is: 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD this requires a shared ECDHE curve, are you using "auto", or an explicit curve? What are the signature algorithms on your certificate chain? It would also be useful to post PCAP files of a working handshake with Chrome, and a failing handshake with Firefox. -- Viktor.
Re: Query related to SSL_CTX_set_msg_callback_arg
> On Jun 10, 2019, at 10:54 AM, Jeremy Harris wrote: > >> |void SSL_CTX_sess_set_new_cb(SSL_CTX *ctx, int (*new_session_cb)(SSL *, >> SSL_SESSION *));| >> >> >> How do we specify a user-defined callback data pointer in that call? > > You don't; you additionally use > SSL_CTX_set_msg_callback_arg() > which the OP said he was already using. That was a different callback (upthread), the OP is now asking about the new session callback, which has no explicit application argument. Perhaps there should be a new "_ex" version that supports an argument, but in the meantime applications that want an application context with the new session callback have been using ex_data for the last decade or two. -- Viktor.
stunnel 5.55 released
Dear Users, I have released version 5.55 of stunnel. This release addresses a number of important Windows issues, including security vulnerabilities. Version 5.55, 2019.06.10, urgency: HIGH * Security bugfixes - Fixed a Windows local privilege escalation vulnerability caused insecure OpenSSL cross-compilation defaults. Successful exploitation requires stunnel to be deployed as a Windows service, and user-writable C:\ folder. This vulnerability was discovered and reported by Rich Mirch. - OpenSSL DLLs updated to version 1.1.1c. * Bugfixes - Implemented a workaround for Windows hangs caused by its inability to the monitor the same socket descriptor from multiple threads. - Windows configuration (including cryptographic keys) is now completely removed at uninstall. - A number of testing framework fixes and improvements. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 90de69f41c58342549e74c82503555a6426961b29af3ed92f878192727074c62 stunnel-5.55.tar.gz e586b68da9e4faedf41cbcc8378402d7b188bb25b1f0f3cd1f2ce68620ef9e29 stunnel-5.55-win64-installer.exe 7af80d424986149629aad7d75710400f58ba259042c58557adf743627b5c8e3c stunnel-5.55-android.zip Best regards, Mike signature.asc Description: OpenPGP digital signature
New to the list and one question ;-)
Hello all, Hello all, Presently writing a server/relay dealing with an h264 stream. one of the threads' job is to establish a handshake with the browser requesting the stream in order to feed the libsrtp2 with keys and salts and start encrypting the h264 stream towards the browser. all is well and good when the program works on the linux PC and the handshake is succesful using the 0xc02f cipher. and that is linked to version 3.0.0 of openssl. on the embedded version, (linked with version 1.0.2s) firefox fails the handshake with ssl_no_shared_cipher whereas chrome and safari do successfully handshake chrome client hello contains 12 ciphers and the server hello seems to choose 0xc02f cipher firefox client hello contains only 10 ciphers (including the above mentioned 0xc02f cipher) and fails. any suggestion as to what could causes that failure would be appreciated. Thanks
Re: Query related to SSL_CTX_set_msg_callback_arg
On 10/06/2019 15:21, J. J. Farrell wrote: > |void SSL_CTX_sess_set_new_cb(SSL_CTX *ctx, int (*new_session_cb)(SSL *, > SSL_SESSION *));| > > > How do we specify a user-defined callback data pointer in that call? You don't; you additionally use SSL_CTX_set_msg_callback_arg() which the OP said he was already using. -- Cheers, Jeremy
Re: Query related to SSL_CTX_set_msg_callback_arg
On 10/06/2019 11:05, Jeremy Harris wrote: On 10/06/2019 09:32, Viktor Dukhovni wrote: On Mon, Jun 10, 2019 at 07:16:26AM +, shalu dhamija via openssl-users wrote: Actually while setting the callback, we can not pass the user-defined/application data. You can however attach it to the SSL connection handle as "ex_data": I fail to see the point. You don't need to pass the data, only a pointer to the data. Well ... obviously ... Any time you set the callback, you can set the callback-arg. How? As Shalu quoted, the prototype of the call to set the callback is |void SSL_CTX_sess_set_new_cb(SSL_CTX *ctx, int (*new_session_cb)(SSL *, SSL_SESSION *));| How do we specify a user-defined callback data pointer in that call? When the callback is called it is given the arg; Where? According to the prototype which Shalu quoted the callback gets just a pointer to an SSL and a pointer to an SSL_SESSION; neither of those is a user-defined data pointer. if the arg was a pointer you can deref to get the data... which could have been manipulated as needed in the interim. Using the ex_data facility is not needed. I may be missing something, but I can't see any other way to do it. -- J. J. Farrell Not speaking for Oracle
Re: failing in reproducing .so files
In the unmodified directory:
$ make clean
$ make 2>&1 | tee /tmp/openssl-working-build.log
In the modified directory:
$ make clean
$ make 2>&1 | tee /tmp/openssl-broken-build.log
$ diff /tmp/openssl-working-build.log /tmp/openssl-broken-build.log |
${PAGER:more}
Take note of the differences in output, and use that to determine what
broke. (the '2>&1' syntax redirects stderr to stdout, which is very useful
when you need to capture why something is failing.)
Good luck.
-Kyle H
On Mon, Jun 10, 2019, 03:34 Giovanni Fontana
wrote:
> The unmodified version works. As I said, it's sure the issue is on what I
> added, but info from the building logs is not sufficient to figure out what
> is the issue there. So as result of the building I have just:
>
>- libcrypto.a
>- libssl.a
>- libcrypto.map
>
>
> so what is missing are the following files:
>
>- libssl.map
>- libcrypto.so
>- libssl.so
>
>
> Il giorno dom 9 giu 2019 alle ore 19:30 Kyle Hamilton
> ha scritto:
>
>> Can you try building an unmodified version of the tarball, and see if it
>> has a problem?
>>
>> -Kyle
>>
>> On Sun, Jun 9, 2019, 07:31 Giovanni Fontana
>> wrote:
>>
>>> Hello Kurt,
>>>
>>>
>>>- it's perl 5, version 26, subversion 1 (v5.26.1) built for
>>>x86_64-linux-gnu-thread-multi
>>>- ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>>>
>>>
>>> I guess is something from what I added since the original OPENSSL I'm
>>> able to build, as well as other intermediate modifications. My issue is
>>> it looks like the log doesn't give so much info and also the *make
>>> update* doesn't complete his task.
>>>
>>> BR
>>> Giovanni
>>>
>>> Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx ha
>>> scritto:
>>>
On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
> */usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2:
There seems to be a problem generating the libcrypto.map file for
you. What does the file look like? Which perl version are you
using? Which libc do you use?
Kurt
Issue with EVP_sha256 and Tspi_Context_CreateObject
Hi, Earlier with openssl 1.0.2n version, I was using EVP_sha256 for creating Certificate Signing Request and "TSS_HASH_OTHER" flag in Tspi_Context_CreateObject. Recently I upgraded openssl to 1.1.0g version and now am getting "Signature Verify Failure" in my CSR. I have attached the screenshot here If I use EVP_sha1 and TSS_HASH_SHA1, then I am able to generate certificate but if it fails in TLS Handshake with my HTTPS Server. Are there any changes in openssl engine structure with respect to Signing and private key encryption in openssl 1.1.0?
Re: Query related to SSL_CTX_set_msg_callback_arg
On 10/06/2019 09:32, Viktor Dukhovni wrote: > On Mon, Jun 10, 2019 at 07:16:26AM +, shalu dhamija via openssl-users > wrote: > >> Actually while setting the callback, we can not pass the >> user-defined/application data. > > You can however attach it to the SSL connection handle as "ex_data": I fail to see the point. You don't need to pass the data, only a pointer to the data. Any time you set the callback, you can set the callback-arg. When the callback is called it is given the arg; if the arg was a pointer you can deref to get the data... which could have been manipulated as needed in the interim. Using the ex_data facility is not needed. -- Cheers, Jeremy
Re: failing in reproducing .so files
The unmodified version works. As I said, it's sure the issue is on what I added, but info from the building logs is not sufficient to figure out what is the issue there. So as result of the building I have just: - libcrypto.a - libssl.a - libcrypto.map so what is missing are the following files: - libssl.map - libcrypto.so - libssl.so Il giorno dom 9 giu 2019 alle ore 19:30 Kyle Hamilton ha scritto: > Can you try building an unmodified version of the tarball, and see if it > has a problem? > > -Kyle > > On Sun, Jun 9, 2019, 07:31 Giovanni Fontana > wrote: > >> Hello Kurt, >> >> >>- it's perl 5, version 26, subversion 1 (v5.26.1) built for >>x86_64-linux-gnu-thread-multi >>- ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27 >> >> >> I guess is something from what I added since the original OPENSSL I'm >> able to build, as well as other intermediate modifications. My issue is >> it looks like the log doesn't give so much info and also the *make >> update* doesn't complete his task. >> >> BR >> Giovanni >> >> Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx ha >> scritto: >> >>> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote: >>> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2: >>> >>> There seems to be a problem generating the libcrypto.map file for >>> you. What does the file look like? Which perl version are you >>> using? Which libc do you use? >>> >>> >>> Kurt >>> >>>
Re: Query related to SSL_CTX_set_msg_callback_arg
On Mon, Jun 10, 2019 at 07:16:26AM +, shalu dhamija via openssl-users wrote: > Actually while setting the callback, we can not pass the > user-defined/application data. You can however attach it to the SSL connection handle as "ex_data": https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_misc.c#L300-L304 https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_server.c#L395-L406 https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_server.c#L812-L817 and retrieve it from the SSL handle as needed: https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_server.c#L265 -- Viktor.
Re: Query related to SSL_CTX_set_msg_callback_arg
Actually while setting the callback, we can not pass the user-defined/application data. For example: void SSL_CTX_sess_set_new_cb(SSL_CTX *ctx, int (*new_session_cb)(SSL *, SSL_SESSION *)); When the callback arrives, I have SSL* and SSL_SESSION*. Earlier I was getting it from the 'msg_callback_arg' of SSL pointer but in the openssl1.1.1, SSL structure is no longer accessible. On Sunday, 9 June, 2019, 8:27:46 pm IST, Jeremy Harris wrote: On 09/06/2019 11:31, shalu dhamija wrote: > Hi All,In openssl 1.0.2, I was using SSL_CTX_set_msg_callback_arg() API to > set the application specific argument. And in the callback, I was retrieving > that argument from SSL pointer received in the callback e.g. > "ssl->msg_callback_arg"But in openssl1.1.1, the SSL structure members are no > more accessible. And I did not find any API to get the msg_callback_arg back. > Can someone please comment on this if there is any way to get the > msg_callback_arg back in the callbacks from ssl pointer. When the callback is called, the arg you set is given to the callback function, as a function argument. It's not intended as a general- purpose data stash. -- Cheers, Jeremy
Crash in x86_64-mont5.s when running speed for RSA on openssl-1.1.1a
Hello, Starting from the rsa choice "rsa2048", there is crash due to segment fault when running speed. RSA512 and rsa1024 doesn't have this issue. Following is the call stacks, registers info when crash happened. It shows that the register %rbp is zero at that point. The value of %rbp is set by instruction "movq%xmm2,$nptr " in label .L8x_no_tail. I don't understand how the algorithm in the x86_64-mont5.s works. So i have no idea why a zero value of %xmm2 was moved to %rbp at that point. Please help have a look. (wrdbg) bt #0 0x00242d23 at __bn_sqrx8x_reduction+0x6c #1 0x0023f96b at bn_sqr8x_mont+0xcb #2 0x0023b014 at bn_mul_mont_fixed_top+0x64 #3 0x002b61f5 at BN_mod_exp_mont+0x445 #4 0x00281b1f at rsa_ossl_public_decrypt+0x28f #5 0x00285c0a at int_rsa_verify+0x8a #6 0x00285f92 at RSA_verify+0x32 #7 0x00217963 at RSA_verify_loop+0x53 #8 0x002176d8 at run_benchmark+0x108 #9 0x00212e80 at speed_main+0x1400 #10 0x00201411 in main (argc=1, argv=0x68ff20) at rtp.c:33 #11 0x00201073 at _start+0x72 (wrdbg) info registers rax 0x 0 rdx 0x68f8f88932a43dc0 7564068842312580544 rcx 0xfff8 18446744073709551608 rbx 0x123959978a8b3640 1313179273754523200 rsi 0x 0 rdi 0x00688430 6849584 rbp 0x 0 rsp 0x006883b8 6849464 r8 0x123959978a8b3640 1313179273754523200 r9 0xf7a5b45905344009 17844867392957857801 r10 0x73dbc32a132b324b 8348480919738987083 r11 0x37cda4961a791379 4021051006907913081 r12 0x701103ae9d18bf8a 8075239655346847626 r13 0xbfbd1a5d2ab85477 13816228219293553783 r14 0x3f3610a53ecd4756 4554846375041124182 r15 0xea5e26bc1a343a39 16887978242021276217 rip 0x00242d23 2370851 PC eflags 0x0246 582[ pf zf if ] fpu None xmm None __bn_sqrx8x_reduction: 00242cb7: xor eax, eax 00242cb9: mov rbx, qword ptr [rsp+0x28] 00242cbe: mov rdx, qword ptr [rsp+0x38] 00242cc3: lea rcx, ptr [rbp+r9*1-0x40] 00242cc8: mov qword ptr [rsp+0x8], rcx 00242ccd: mov qword ptr [rsp+0x10], rdi 00242cd2: lea rdi, ptr [rsp+0x38] 00242cd7: jmp 0x242ce0 <__bn_sqrx8x_reduction+41> 00242cd9: nop dword ptr [rax], eax 00242ce0: mov r9, qword ptr [rdi+0x8] 00242ce4: mov r10, qword ptr [rdi+0x10] 00242ce8: mov r11, qword ptr [rdi+0x18] 00242cec: mov r12, qword ptr [rdi+0x20] 00242cf0: mov r8, rdx 00242cf3: imulrdx, rbx 00242cf7: mov r13, qword ptr [rdi+0x28] 00242cfb: mov r14, qword ptr [rdi+0x30] 00242cff: mov r15, qword ptr [rdi+0x38] 00242d03: mov qword ptr [rsp+0x20], rax 00242d08: lea rdi, ptr [rdi+0x40] 00242d0c: xor rsi, rsi 00242d0f: mov rcx, -8 00242d16: jmp 0x242d20 <__bn_sqrx8x_reduction+105> 00242d18: nop dword ptr [rax+rax*1], eax 00242d20: mov rbx, r8 00242d23: mulxr8, rax, qword ptr [rbp] 00242d29: adcxrax, rbx 00242d2f: adoxr8, r9 L8x_no_tail: adc 8*0($tptr),%r8 adc 8*1($tptr),%r9 adc 8*2($tptr),%r10 adc 8*3($tptr),%r11 adc 8*4($tptr),%r12 adc 8*5($tptr),%r13 adc 8*6($tptr),%r14 adc 8*7($tptr),%r15 adc \$0,%rax# top-most carry mov-8($nptr),%rcx # np[num-1] xor$carry,$carry movq%xmm2,$nptr # restore $nptr mov %r8,8*0($tptr) # store top 512 bits mov %r9,8*1($tptr) movq %xmm3,$num # $num is %r9, can't be moved upwards configdata.pm --dump: Command line (with current working directory = .): /usr/bin/perl ../Configure vxworks-x86-64 no-weak-ssl-ciphers no-aria no-blake2 no-camellia no-chacha no-cmac no-md2 no-md4 no-mdc2 no-ocb no-poly1305 no-rc2 no-rc5 no-scrypt no-seed no-siphash no-sm2 no-sm3 no-sm4 no-whirlpool no-autoerrinit no-comp no-sctp no-srtp --with-rand-seed=none -DOPENSSL_SYS_VXWORKS_SUPPORT
