Print SSL errors
Hello, at startup after SSL_library_init I correctly call SSL_load_error_strings and every time I have an SSL error I try to log useful data using ERR_error_string_n. The problem is that the output never contains error messages but only numeric code like: error:0001:lib(0):func(0):reason(1) Please note that if I use the function ERR_print_errors_fp (stdout); than it correctly loads and print useful debug messages like: 4349079552:error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned:/SourceCache/OpenSSL098/OpenSSL098-50/src/ssl/s3_srvr.c:2631: Any idea? -- Marco Bambini http://www.sqlabs.com http://twitter.com/sqlabs http://instagram.com/sqlabs __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL Library Error: error:2D06D075:FIPS routines:fips_pkey_signature_test:test failure (Type=RSA SHA1 X931)
Hello All, I have a set up which runs Apache http-2.4.10 and Openssl-1.0.1i, when I try to start the http server with FIPS mode i get the following error. [Mon Aug 11 14:39:24.407781 2014] [suexec:notice] [pid 380] AH01232: suEXEC mechanism enabled (wrapper: /apps/apache/2.4.10/bin/suexec) [Mon Aug 11 14:39:24.428616 2014] [ssl:emerg] [pid 380] AH01885: FIPS mode failed [Mon Aug 11 14:39:24.428656 2014] [ssl:emerg] [pid 380] SSL Library Error: error:2D06D075:FIPS routines:fips_pkey_signature_test:test failure (Type=RSA SHA1 X931) [Mon Aug 11 14:39:24.428663 2014] [ssl:emerg] [pid 380] AH02312: Fatal error initialising mod_ssl, exiting. AH00016: Configuration Failed Could somebody help me out with this issue ? Thanks in advance. -- Regards, Abdul --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
PR#3400 and CVE-2014-0224
Hi All, We are using OpenSSL version 0.9.8h. We take the security vulnerability fixes from latest release of OpenSSL 0.9.8 series and patch our internally used 0.9.8h. From the OpenSSL release 0.9.8za, we took CVE-2014-0224 and merged it our OpenSSL code. But in latest release 0.9.8za, I see that there is a change which seems to be leftover piece of 0224 fix. The doubt is regarding PR#3400. It seems to be the leftover piece of CVE-2014-0224 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0224. Please see the links below. PR#3400 http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=70d923fb0359ed68e59b8c59d1687ebff6f8d952 CVE-2014-0224 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0224 http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=410a49a4fa1d2a1a9775ee29f9e40cbbda79c149 Can someone from OpenSSL team confirm if PR#3400 is part of CVE-2014-0224 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0224 and we should merge this fix as well? Thanks for your support. Regards, Aditya
client side session cache with SNI, and tlsext_ticket_key_cb
Hi, I have two questions about how openssl handles session caching. 1. If I want session caching on the client side, I have to store the session manually, to be able to retrieve it when the client connects to a server and use SSL_set_session() with the stored session. The question is, how should I store the session when the client also uses SNI. Without SNI I could just use ip:port. But when SNI is in use, it can happen that although the client connects to the same ip:port, it will be a completely different ssl connection (because a load balancer rerouted the connection, or it was an apache vhost). So should I always use ip:port-sni to store the session, or what is recommended here? 2. When you use SSL_CTX_set_tlsext_ticket_key_cb (on the server side) to set a callback to use session tickets, and you store those tickets in your own cache, how do you make sure the cache will be emptied regularly (to erase expired tickets)? Does openssl call this cb when its flusing its own cache, or the user must take care to empty its own cache regularly? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
about EVP_DigestInit_ex
Hello,
I'm a bit confused about the behavior of EVP_DigestInit_ex :
int EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl)
{
if (type)
{
else
if(!ctx-digest)
{
EVPerr(EVP_F_EVP_DIGESTINIT_EX,EVP_R_NO_DIGEST_SET);
return 0;
}
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: client side session cache with SNI, and tlsext_ticket_key_cb
On Mon, Aug 11, 2014 at 01:48:34PM +0200, DEXTER wrote: 1. If I want session caching on the client side, I have to store the session manually, to be able to retrieve it when the client connects to a server and use SSL_set_session() with the stored session. Correct so far. The question is, how should I store the session when the client also uses SNI. Without SNI I could just use ip:port. But when SNI is in use, it can happen that although the client connects to the same ip:port, it will be a completely different ssl connection (because a load balancer rerouted the connection, or it was an apache vhost). So should I always use ip:port-sni to store the session, or what is recommended here? Salt the session lookup key with all destination-specific and security-relevant parameters. The Postfix SMTP client uses: ip, port, destination domain, mx hostname, server helo name, protocol mask (SSL_OP_NO_SSLv2 | ...), cipherlist and, if present, the DANE TLSA RRset. In Postfix sessions are shared between multiple processes, and cached by default for an hour, so any of the above can change during that time (newly started processes might be configured differently, ...). You need to figure in your case what information is sufficient in the lookup key to avoid using a cached session that does not meet the security properties you'd want from a new session. 2. When you use SSL_CTX_set_tlsext_ticket_key_cb (on the server side) to set a callback to use session tickets, and you store those tickets in your own cache, how do you make sure the cache will be emptied regularly (to erase expired tickets)? Does openssl call this cb when its flusing its own cache, or the user must take care to empty its own cache regularly? Sesssion tickets should NOT be stored on the server side, only the encryption keys are stored, these should be rotated from time to time. Postfix rotates the encryption keys once an hour, but stores two sets of keys, the previous and the current, so it can validate any unexpired sessions across key rotation. As for the client side cache, yes in a long-lived client cache you also need to keep track of the session's age, and discard sufficiently old sessions. Postfix runs a cache scan periodically, removing stale entries, the cache scan is asynchronous in the event loop to avoid garbage collection stall when the cache is large. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
about EVP_DigestInit_ex
Hello,
sorry for the first incomplete message :-/
I'm a bit confused about the behavior of EVP_DigestInit_ex when no md is given :
int EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl)
{
#ifndef OPENSSL_NO_ENGINE
(...)
if (type)
{
(...)
}
else
if(!ctx-digest)
{
EVPerr(EVP_F_EVP_DIGESTINIT_EX,EVP_R_NO_DIGEST_SET);
return 0;
}
// so we want to keep the old digest if type is NULL
#endif
if (ctx-digest != type)
{
(...)
ctx-digest=type;
(...)
}
// but if a digest is already set, and type is NULL, digest will be set to
NULL...
// Wouldn't it make more sense to keep existing old digest if type is NULL?
// and should the the if statements look more like this :
#ifndef OPENSSL_NO_ENGINE
(...)
if (type)
{
(...)
}
#endif
if(!type !ctx-digest)
{
EVPerr(EVP_F_EVP_DIGESTINIT_EX,EVP_R_NO_DIGEST_SET);
return 0;
}
if (type (ctx-digest != type))
{
(...)
ctx-digest=type;
(...)
}
Thanks for your answer
Nicolas
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Print SSL errors
err = SSL_get_error(client-ssl, r2);
if (err != 0) {
char str[2048];
ERR_error_string_n(err, str, sizeof(str));
printf(%s, str);
ERR_print_errors_fp (stdout);
}
The first function produces:
error:0001:lib(0):func(0):reason(1)
while ERR_print_errors_fp prints:
4349079552:error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no
certificate
returned:/SourceCache/OpenSSL098/OpenSSL098-50/src/ssl/s3_srvr.c:2631:
--
Marco Bambini
http://www.sqlabs.com
http://twitter.com/sqlabs
http://instagram.com/sqlabs
On 11 Aug 2014, at 15:36, Salz, Rich rs...@akamai.com wrote:
every time I have an SSL error I try to log useful data using
ERR_error_string_n.
Can you post the code with the call?
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Print SSL errors
What's the value of err (%ul)? -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz
Re: Print SSL errors
It is 1. -- Marco Bambini http://www.sqlabs.com http://twitter.com/sqlabs http://instagram.com/sqlabs On 11 Aug 2014, at 16:24, Salz, Rich rs...@akamai.com wrote: What’s the value of err (“%ul”)? -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz
RE: Print SSL errors
Try printing r2 in your original code. SSL_get_error isn't doing what you think it does; see the docs. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz
empty certificate-messag
How to send empty certificate-message in response to certificate request from server ?
[OpenSSL] [SSL_READ and SSL_WRITE] [Edge Trigged EPOLL]
I have a TLS Server and TLS Client which is running on the top of *Edge Triggered EPOLL* and *Non Blocking Sockets.* Client and server is doing following operations 1. Client - Connect to TLS Server. (SSL_CTX_new - SSL_new - SSL_set_fd) 2. Client - Set modes (SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER, SSL_MODE_AUTO_RETRY) 3. Server - Sends streaming data to the connected clients. 4. Client - Read data whenever EPOLLIN occurs. 5. Server - When it fails to send data (Client is slow to read), stores data into local buffer and waits for EPOLLOUT to occur. 6. Server - When EPOLLOUT occurs for particular socket it sends the same data which was failed previously. Problem that I am seeing is even after the client is successfully reading all the data from Kernel Buffer, Event EPOLLOUT is not invoked in Server Side (In Server Buffered data is ready for writing to clients). EPOLLOUT is invoked only one time in Server side, when the SSL_WRITE fails for first time. Is there any specific way to handle SSL_READ and SSL_WRITE over Edge Triggered EPOLL ? I am very new to openssl. Please help. -- Harikrishnan R -- Connect with Market Simplified on Linked-in http://www.linkedin.com/company/market-simplified-inc | Facebook https://www.facebook.com/MarketSimplified | Twitter https://twitter.com/MarketGoMobile | Google Plus https://plus.google.com/114913942441116940871/ | Pinterest http://pinterest.com/marketGoMobile/mobility-in-bfsi Confidentiality Statement: This message is intended only for the use of the Addressee and may contain information that is PRIVILEDGED and CONFIDENTIAL: If you are not the intended recipient, dissemination of this communication is prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately
[OpenSSL] [SSL_READ and SSL_WRITE] [Edge Trigged EPOLL]
I have a TLS Server and TLS Client which is running on the top of *Edge Triggered EPOLL* and *Non Blocking Sockets.* Client and server is doing following operations 1. Client - Connect to TLS Server. (SSL_CTX_new - SSL_new - SSL_set_fd) 2. Client - Set modes (SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER, SSL_MODE_AUTO_RETRY) 3. Server - Sends streaming data to the connected clients. 4. Client - Read data whenever EPOLLIN occurs. 5. Server - When it fails to send data (Client is slow to read), stores data into local buffer and waits for EPOLLOUT to occur. 6. Server - When EPOLLOUT occurs for particular socket it sends the same data which was failed previously. Problem that I am seeing is even after the client is successfully reading all the data from Kernel Buffer, Event EPOLLOUT is not invoked in Server Side (In Server Buffered data is ready for writing to clients). EPOLLOUT is invoked only one time in Server side, when the SSL_WRITE fails for first time. Is there any specific way to handle SSL_READ and SSL_WRITE over Edge Triggered EPOLL ? I am very new to openssl. Please help. -- Harikrishan R http://harikrishnanr.wordpress.com/
Re: client side session cache with SNI, and tlsext_ticket_key_cb
On Mon, Aug 11, 2014 at 4:09 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: Salt the session lookup key with all destination-specific and security-relevant parameters. The Postfix SMTP client uses: ip, port, destination domain, mx hostname, server helo name, protocol mask (SSL_OP_NO_SSLv2 | ...), cipherlist and, if present, the DANE TLSA RRset. In Postfix sessions are shared between multiple processes, and cached by default for an hour, so any of the above can change during that time (newly started processes might be configured differently, ...). You need to figure in your case what information is sufficient in the lookup key to avoid using a cached session that does not meet the security properties you'd want from a new session. I see. Sesssion tickets should NOT be stored on the server side, only the encryption keys are stored, these should be rotated from time to time. Postfix rotates the encryption keys once an hour, but stores two sets of keys, the previous and the current, so it can validate any unexpired sessions across key rotation. Hmm.. maybe I worded this poorly, I meant to say you store the key (key-aes_key, key-hmac_key, key-expire_time) with the key_name, so later when it is called with enc=0 you can retreive those and can call EVP_DecryptInit_ex. And every new session (enc=1) gets a new key (aes_key, hmac_key) and key_name. Isn't this the case? As for the client side cache, yes in a long-lived client cache you also need to keep track of the session's age, and discard sufficiently old sessions. Postfix runs a cache scan periodically, removing stale entries, the cache scan is asynchronous in the event loop to avoid garbage collection stall when the cache is large. I see. Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: client side session cache with SNI, and tlsext_ticket_key_cb
On Mon, Aug 11, 2014 at 05:13:00PM +0200, DEXTER wrote: Sesssion tickets should NOT be stored on the server side, only the encryption keys are stored, these should be rotated from time to time. Postfix rotates the encryption keys once an hour, but stores two sets of keys, the previous and the current, so it can validate any unexpired sessions across key rotation. Hmm.. maybe I worded this poorly, I meant to say you store the key (key-aes_key, key-hmac_key, key-expire_time) with the key_name, so later when it is called with enc=0 you can retreive those and can call EVP_DecryptInit_ex. Correct, however one set of keys encrypts and decrypts many sessions. And every new session (enc=1) gets a new key (aes_key, hmac_key) and key_name. Isn't this the case? No, generally you re-use previously generated keys, otherwise you lose much of the advantage of stateless resumption. However, along with each keyset you associated some suitable TTL, and you stop signing new sessions with a keyset that is expiring, while keeping it in memory long enough to decrypt any previously signed sessions. So each keyset lives in memory for 2 * encryption-TTL, where the encryption-TTL is also the maximum session lifetime, but is only used to encrypt new sessions for 1 * encryption-TTL. This means you only have 2 keysets in memory, the current and previous. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: RST after close_notify
The server end appears to be GlobalScape EFT running on a windows server. I will summarize the IBM response: When SSL is not involved, TCP will normally go through a graceful connection teardown sequence where one side initiates the connection closure by sending out a FIN. The other side acks that FIN and sends out their own FIN... When SSL is involved or when an application is implemented to end the connection with a Reset (using SOLINGER), one side can send out a FIN then the application immediately closes down its socket. Then anything with data comes in after that results in a Reset coming out. When the other side receives the Reset, their TCP immediately cleans up that connection. Using this SSL session as an example, the remote side sends out the FIN. At this point, the application on the remote side seems to have already closed down its socket. When we receive the FIN, SSL layer still needs to send out the SSL alert. Therefore, we are not sending out our FIN just yet because we're still waiting for the ack for the FIN. The remote side then sends back the ack along with the Reset. When we receive the Reset, we clean up the connection without any further communication. -- Donald J. dona...@4email.net On Sat, Aug 9, 2014, at 09:44 AM, Michael Wojcik wrote: Well, it sounds like someone needs to modify the client, then, if you want to use SSL/TLS. should return a FIN before RST is an oversimplification, and possibly incorrect, depending on what should means in this context. There is no simple explanation of this. ... -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Configure Error with no-ec?
When trying to configure 1.0.1h with no-ec, I am getting an error out of Configure. When it's configuring the engines subdirectory: make[1]: Leaving directory `/users/scottn/testssl/openssl-1.0.1h/ssl' making links in engines... make[1]: Entering directory `/users/scottn/testssl/openssl-1.0.1h/engines' /bin/sh: syntax error at line 1 : `;' unexpected make[1]: *** [links] Error 2 make[1]: Leaving directory `/users/scottn/testssl/openssl-1.0.1h/engines' make: *** [links] Error 1 It looks like for some reason ENGDIRS is not set or passed properly. Even though the test for -z is being passed, the for loop in RECURSIVE_MAKE is generating a syntax error. Has anyone else run into something like this? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: empty certificate-messag
If you did not use, SSL_CTX_use_certificate(), SSL_use_certificate() and set the certificate SSL client responds with no_cert if cert request comes from the server. -Jayadev. On Mon, Aug 11, 2014 at 6:24 PM, Sanju Gurung sanju.gur...@gmail.com wrote: How to send empty certificate-message in response to certificate request from server ?
RE: RST after close_notify
The IBM response is still significantly oversimplified, where it isn't simply wrong. I've made some comments in-line below, but to get the full picture you'd really need to study a text like Stevens' /TCP/IP Illustrated/, paying particular attention to the TCP state diagram and the empirical results Stevens sees in his experiments (and maybe do some experiments of your own to ferret out the quirks of the implementations you're using). You have to consider all the permutations of: - What the applications do (in terms of calling the API and responding to the returned values) - What the stacks do in response to the applications' actions, and what the state of the conversation is at the moment each action is processed - When various packets are sent and received That's a lot of combinatorial explosion. Vague, handwaving descriptions of what TCP will normally do aren't going to explain all the possible cases. And OpenSSL (like pretty much any middle layer) complicates the situation by hiding some information from you in its abstraction of the conversation, and doing things (like sending close_notify) that aren't apparent from the application level. If you control both sides of the conversation, you can ensure that close_notify exchanges never cause an RST flow, by sending the close_notify manually, performing a half-close, and then draining data until you receive the peer's half-close. But if you don't control both sides, then as Rescorla says, you have to be prepared to deal with a conversation abort. It's a bad iteraction between the SSL/TLS application-level handshaking and TCP's conversation-level handshaking, caused by people writing to the socket API without learning how to avoid abortive close. You have no choice in the matter but to follow Postel's interoperability principle and be liberal in what you accept. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Donald J. Sent: Monday, 11 August, 2014 13:14 To: openssl-users@openssl.org Subject: Re: RST after close_notify The server end appears to be GlobalScape EFT running on a windows server. I will summarize the IBM response: When SSL is not involved, TCP will normally go through a graceful connection teardown sequence where one side initiates the connection closure by sending out a FIN. The other side acks that FIN and sends out their own FIN... This is what happens regardless of whether SSL is involved, in the normal case (that is, the common case where one side does an active close, and the other side responds with a passive close, and all application data has been received by the applications, and the conversation is otherwise idle, and no intermediate nodes interfere, etc). The TLS close_notify flow is application data that is sent normally, as far as the TCP layer is concerned. It does not alter TCP close negotiation in the slightest. When SSL is involved or when an application is implemented to end the connection with a Reset (using SOLINGER), one side can send out a FIN then the application immediately closes down its socket. Then anything with data comes in after that results in a Reset coming out. When the other side receives the Reset, their TCP immediately cleans up that connection. Sigh. SSL has nothing to do with this; when SSL is involved is simply wrong. Using the SO_LINGER option to tell the stack to do an abortive close is only one way of generating an RST. Regardless of whether SSL is in use, or whether the peer has used SO_LINGER to tell the stack that it wants an abortive close when it closes its end, a FIN may (but doesn't necessarily) indicate that the application has closed its socket. And that's the order it usually happens in: the application closes its socket (which is a call to the sockets API, not an operation on the TCP conversation), and the stack responds by sending a FIN (and changing the state of the local conversation endpoint internally). Using this SSL session as an example, the remote side sends out the FIN. At this point, the application on the remote side seems to have already closed down its socket. Yes, that's usually the case. When we receive the FIN, SSL layer still needs to send out the SSL alert. Therefore, we are not sending out our FIN just yet because we're still waiting for the ack for the FIN. That's wrong. There are various possibilities for the local side in this situation, but none of them are waiting for the ack for the FIN, because the local side *received* the FIN. It will send an ACK for it, but nothing on the local side waits for that to happen. The remote side then sends back the ack along with the Reset. When we receive the Reset, we clean up the connection without any further communication. -- Donald J. dona...@4email.net On Sat, Aug 9, 2014, at 09:44 AM, Michael Wojcik
Handshake finish msg
hi all, I did a little comparison between microsoft's handshake process to openssl one. At the end of Msft handshake process i can see a finish, which i dont see when using openssl . Can i have that finish msg using openssl too? Thanks Idan Idan Freiberg
