RE: problems with too many ssl_read and ssl_write errors
> From: Kamala Ayyar > Sent: Monday, 23 August, 2021 09:22 > We get the SSL_ERROR_SYSCALL from SSL_Read and SSL_Write quite often. You'll get SSL_ERROR_SYSCALL any time OpenSSL makes a system call (including, on Windows, a Winsock call) and gets an error. > It seems the handshake is done correctly and over a period of time (few hours > to 2-3 days random) the SSL_Read /SSL_Write fails. We do not get the > WSAEWOULDBLOCK error code What is the underlying error, then? Are you logging the result of WSAGetLastError immediately after you get SSL_ERROR_SYSCALL? What about the SSL error stack (with ERR_print_errors_fp or similar)? > nor the OpenSSL's version of SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE > error. SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE are not related to WSAEWOULDBLOCK, so I'm not sure why you're mentioning them here. > We get WSAETIMEDOUT on Receive more often and a few times on the Send. That's typically the case; generally speaking, a timeout is more likely when receiving (where you are at the mercy of the peer sending data) than when sending (where you simply need the peer to open the receive window and then ACK the sent data, both of which are often possible even if the application is not behaving, depending on the amount of data and other variables). > We are not using SO_KEEPALIVE but using application specific heartbeat TO to > keep the socket alive. That could certainly cause send or receive timeouts on the socket if the peer becomes unresponsive. The same is true of any application-data transmission, of course. > Based on blogs and googling we have seen that OpenSSL quite often issues a > SSL_ERROR_SYSCALL when a Timeout is encountered Yes, that's what it should do, if "when a timeout is encountered" means "a socket-API function returns an error due to a timeout". SSL_ERROR_SYSCALL means exactly that: a system call returned an error. I suspect one of the following: - A client application is hanging (or blocking for some other reason), and consequently: - Not sending data, so the server's not receiving data until it times out, or - Not receiving data that the server is sending; that will cause its receive window to fill, and eventually the server's send will time out. - Network issues are transiently preventing data and/or ACK reception by one side or the other. That will also eventually lead to timeouts. -- Michael Wojcik
HMAC verification with EVP Interface
Hello,
I am trying to verify an HMAC signature with the code below and the
EVP_DigestVerifyInit()
routine is failing with "error:0608F096:digital envelope
routines:EVP_PKEY_verify_init:operation not supported for this
keytype". Eventually it gets to EVP_PKEY_verify_init() and since the
ctx->pmeth->verify pointer is null, it sets this error. It's unclear
to me why this function pointer is NULL, can someone elaborate the
right way to do this via EVP interfaces?
Openssl Version: OpenSSL 1.1.1f 31 Mar 2020
Thanks,
Bill
/* This is just a testing key */
unsigned char hmac_key[] = {
0x30, 0x33, 0x33, 0x36, 0x61, 0x61, 0x37, 0x39,
0x34, 0x35, 0x61, 0x33, 0x63, 0x61, 0x64, 0x65,
0x63, 0x33, 0x63, 0x62, 0x64, 0x63, 0x36, 0x65,
0x37, 0x39, 0x30, 0x34, 0x33, 0x62, 0x35, 0x62
};
EVP_PKEY *ekey = EVP_PKEY_new_mac_key(EVP_PKEY_HMAC, NULL, hmac_key,
sizeof(hmac_key));
assert_non_null(ekey);
EVP_MD_CTX *mdctx = EVP_MD_CTX_new();
assert_non_null(mdctx);
int rc = EVP_DigestVerifyInit(mdctx, NULL, EVP_sha256(), NULL, ekey);
unsigned long x = ERR_get_error();
printf("EVP_DigestSignInit failed, error 0x%lx: %s\n", x,
ERR_error_string(x, NULL));
assert_int_equal(rc, 1);
rc = EVP_DigestVerifyUpdate(mdctx, msg, msg_len);
assert_int_equal(rc, 1);
rc = EVP_DigestVerifyFinal(mdctx, sig, sig_len);
assert_int_equal(rc, 1);
EVP_MD_CTX_free(mdctx);
EVP_PKEY_free(ekey);
OpenSSL version 1.1.1l for NonStop TNS/E and TNS/X Binary Builds Published
Hello OpenSSL Community, Binary builds of OpenSSL version 1.1.1l for the HPE NonStop TNS/E (ia64) and TNS/X (x86) platforms have been published on the ITUGLIB website in its usual place at https://ituglib.connect-community.org/apps/Ituglib/SrchOpenSrcLib.xhtml. The builds consist of: . Unthreaded 32-bit . POSIX User Thread Model (PUT) 32-bit . Standard POSIX Thread (SPT) Model 32-bit . IEEE Float Unthreaded 32-bit build for x86 Please consult the OpenSSL Security Advisory for 1.1.1l for more details on this release. -- Randall S. Becker ITUGLIB Process Designer, Repository Manager, Occasional Porting Dude +1.416.984.9826 NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
Re: Testing
Please remove my email from this group. Thank you On Wed, Aug 25, 2021 at 4:10 PM Turritopsis Dohrnii Teo En Ming < ceo.teo.en.m...@gmail.com> wrote: > Testing >
Testing
Testing
I have successfully configured SSL/TLS for Postfix SMTP outgoing mail server for a customer in Singapore on 25 Aug 2021 Wed
Subject: I have successfully configured SSL/TLS for Postfix SMTP outgoing mail server for a customer in Singapore on 25 Aug 2021 Wed Good day from Singapore, I have successfully configured SSL/TLS for Postfix SMTP outgoing mail server for a customer in Singapore on 25 Aug 2021 Wed. It took me 7-8 hours to solve this problem. I think my boss can probably solve this problem in 10 minutes. I have prepared this extremely short and concise guide to remind myself and everyone how to configure SSL/TLS for Postfix SMTP outgoing Linux mail server. Author: Mr. Turritopsis Dohrnii Teo En Ming (TARGETED INDIVIDUAL) Country: Singapore Date: 25 August 2021 Wed Singapore Time Type of Publication: Plain Text Document version: 20210825.01 ===BEGINNING OF GUIDE=== Add the following lines to /etc/postfix/main.cf: smtpd_tls_cert_file = /etc/postfix/teo-en-ming-corp.crt smtpd_tls_key_file = /etc/postfix/teo-en-ming-corp.key smtp_tls_security_level = may smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache Add the following lines to /etc/postfix/master.cf: submission inetn - n - - smtpd smtps inetn - n - - smtpd Restart Postfix for changes to take effect. # service postfix restart Submission port is 587. SMTPS port is 465. Normal SMTP port is 25. Add the following firewall rules to /etc/sysconfig/iptables. This is to open ports for services/daemons listening on TCP ports 25, 465, and 587. -A INPUT ! -i lo -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT -A OUTPUT ! -o lo -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT -A INPUT ! -i lo -p tcp -m state --state NEW -m tcp --dport 465 -j ACCEPT -A OUTPUT ! -o lo -p tcp -m state --state NEW -m tcp --dport 465 -j ACCEPT -A INPUT ! -i lo -p tcp -m state --state NEW -m tcp --dport 587 -j ACCEPT -A OUTPUT ! -o lo -p tcp -m state --state NEW -m tcp --dport 587 -j ACCEPT Reload firewall rules. # service iptables restart Linux troubleshooting commands: # openssl s_client -connect mail.teo-en-ming-corp.com:25 -servername mail.teo-en-ming-corp.com -starttls smtp # openssl s_client -connect mail.teo-en-ming-corp.com:465 -servername mail.teo-en-ming-corp.com -starttls smtp # openssl s_client -connect mail.teo-en-ming-corp.com:587 -servername mail.teo-en-ming-corp.com -starttls smtp # openssl s_client -connect example.com:[port] -servername example.com # telnet mail.teo-en-ming-corp.com 25 # telnet mail.teo-en-ming-corp.com 465 # telnet mail.teo-en-ming-corp.com 587 ===END OF GUIDE=== You will be able to see STARTTLS in the SMTP banner for Postfix for TCP ports 25, 465 and 587 if you do a Telnet to your mail server. If there are corrections and/or additions to this guide, I will post back here. Mr. Turritopsis Dohrnii Teo En Ming, 43 years old as of 25 August 2021, is a TARGETED INDIVIDUAL living in Singapore. He is an IT Consultant with a System Integrator (SI)/computer firm in Singapore. He is an IT enthusiast. -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE-
