Re: [openssl-users] X509_verify_cert cannot be called twice
So let me get this straight. If someone had a software where they called X509_verify_cert from SSL_CTX_set_cert_verify_callback callback twice (to verify first with crls, and maybe verify again without crls) and it worked as expected, after this patch their software is broken. Am I right? And there is no solution to this after the patch for 1.0.[12] Am I right? On 2016.03.24. 16:17, Viktor Dukhovni wrote: > >> On Mar 24, 2016, at 4:21 AM, DEXTER <mydexte...@gmail.com> wrote: >> >> So this patch: >> https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=b3b1eb5735c5b3d566a9fc3bf745bf716a29afa0 >> >> magically made itself into ubuntu trusty's version of openssl in a >> security update. >> >> My question is: >> >> What is the recommended way now to call X509_verify_cert twice or >> unlimited times from SSL_CTX_set_cert_verify_callback callback. >> (This is where the ctx is already initialized by openssl and not by the user) > > I'm afraid multiple calls are not supported. > I'll consider updating the 1.1.0 code to make that possible, > but that won't help you with 1.0.[12]... > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] X509_verify_cert cannot be called twice
Hi! So this patch: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=b3b1eb5735c5b3d566a9fc3bf745bf716a29afa0 magically made itself into ubuntu trusty's version of openssl in a security update. My question is: What is the recommended way now to call X509_verify_cert twice or unlimited times from SSL_CTX_set_cert_verify_callback callback. (This is where the ctx is already initialized by openssl and not by the user) Thanks. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: issue with set_tlsext_ticket_key_cb and set_verify
It's OK that I have to use this function, but what I don't understand is why do I have to use it? Why do I have to set an arbitrary string? Why doesn't openssl do this internally so that I don't have to know about an obscure thing to set to make it work. On Sep 26, 2014 3:18 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Thu, Sep 25, 2014 at 02:51:16PM +0200, DEXTER wrote: Also checking openssl source (apps/s_server.c) to find out why it works with plain s_client, s_server, I see this: static int s_server_session_id_context = 1; /* anything will do */ SSL_CTX_set_session_id_context(ctx,(void*)s_server_session_id_context, sizeof s_server_session_id_context); Can anybody tell me what the hell is this hack? anything will do? int converted to void*, when the function itself should get a const unsigned char*? What? While RTFS is a fine strategy, generally RTFM first: https://www.openssl.org/docs/ssl/SSL_CTX_set_session_id_context.html Postfix uses: static const char server_session_id_context[] = Postfix/TLS; SSL_CTX_set_session_id_context(ctx, (void *) server_session_id_context, sizeof(server_session_id_context)); You should use something that identifies your application. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
issue with set_tlsext_ticket_key_cb and set_verify
Hi! I have an openssl server, and I'm using the SSL_CTX_set_tlsext_ticket_key_cb to set a callback to be able to use tls tickets. When the SSL_CTX_set_verify callback is not set, then it works as it should. But as soon as I set a verify callback (to verify the client cert) I this error when the client tries to connect: error:140D9115:SSL routines:lib(20):SSL_GET_PREV_SESSION:func(217):session id context uninitialized:reason(277) Anyone has any idea why this happens? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: issue with set_tlsext_ticket_key_cb and set_verify
Also checking openssl source (apps/s_server.c) to find out why it works with plain s_client, s_server, I see this: static int s_server_session_id_context = 1; /* anything will do */ SSL_CTX_set_session_id_context(ctx,(void*)s_server_session_id_context, sizeof s_server_session_id_context); Can anybody tell me what the hell is this hack? anything will do? int converted to void*, when the function itself should get a const unsigned char*? What? On Thu, Sep 25, 2014 at 1:56 PM, DEXTER mydexte...@gmail.com wrote: Hi! I have an openssl server, and I'm using the SSL_CTX_set_tlsext_ticket_key_cb to set a callback to be able to use tls tickets. When the SSL_CTX_set_verify callback is not set, then it works as it should. But as soon as I set a verify callback (to verify the client cert) I this error when the client tries to connect: error:140D9115:SSL routines:lib(20):SSL_GET_PREV_SESSION:func(217):session id context uninitialized:reason(277) Anyone has any idea why this happens? 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 6:00 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: 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. I see, thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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
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: suspending and continuing handshake
On Wed, Jun 4, 2014 at 4:49 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: Sounds like the requested feature is already implemented. That's some fast work. :-) Indeed, it is some fast work. That's all that about the itching feature, low priority, and many years... -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: suspending and continuing handshake
Hi Steve, That is exactly what I needed. I've just tried it out with OpenSSL-1.0.2-beta1 and it works perfectly. Do you have any ETA on when the 1.0.2 will be released? Thank you! On Wed, Jun 4, 2014 at 4:29 PM, Dr. Stephen Henson st...@openssl.org wrote: On Wed, Jun 04, 2014, DEXTER wrote: Well, that's not how it works. Normally when OpenSSL returns with something like WANT_READ or WANT_WRITE, it is possible to later determine whether the preconditions for moving forward are satisfied. In this case you're asking OpenSSL to just wait for nothing in particular. That feature does not exist. That's the problem. I'm asking kindly the devs of openssl to make this feature exist. Now that Openssl has two full time developers, is there an official way to request such a feature? (The request is about supporting a way for mitm proxies to be able to get the servername from the client, suspend the handshake with it, and continue later when you have the proper certificate.) I'm not sure if this will do precisely what you want but OpenSSL 1.0.2+ supports certificate callbacks for both client and server certificates. In the server case the callback is called when the server certificate is required. It has a feature where the callback can return -1 and this then sets a special state SSL_ERROR_WANT_X509_LOOKUP and you can retry in the same way as other SSL_ERROR_WANT_* conditions. See: http://www.openssl.org/docs/ssl/SSL_CTX_set_cert_cb.html 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: suspending and continuing handshake
Well, that's not how it works. Normally when OpenSSL returns with something like WANT_READ or WANT_WRITE, it is possible to later determine whether the preconditions for moving forward are satisfied. In this case you're asking OpenSSL to just wait for nothing in particular. That feature does not exist. That's the problem. I'm asking kindly the devs of openssl to make this feature exist. Now that Openssl has two full time developers, is there an official way to request such a feature? (The request is about supporting a way for mitm proxies to be able to get the servername from the client, suspend the handshake with it, and continue later when you have the proper certificate.)
Re: suspending and continuing handshake
That is exactly what I thought first, to control it with BIOs. Unfortunately even if I give openssl the exact amount of bytes (not more) to be able to call the SNI callback, right after I return from the callback, openssl's own state machine goes into a state where it'll immediately say the: No shared cipher error. (so I don't have time to set the certificate later). That is why I think an internal code change is needed in openssl itself, to support this case. On Mon, May 26, 2014 at 11:40 PM, Kyle Hamilton aerow...@gmail.com wrote: I would think that this could be done by handling BIO communications yourself via memory BIOs, then sending the content of those BIOs over the network as appropriate. But, this does appear to be something that needs attention (given the reactive nature of SNI's specification long after the original API was developed). Ironically, this issue appears to make it much easier to write an MITM proxy than an opaque CONNECT-method proxy. -Kyle H On Mon, May 26, 2014 at 2:03 AM, DEXTER mydexte...@gmail.com wrote: Hi! In a proxying environment when the client connects to the proxy and it sends the SNI, you have to suspend the handshake with the client side, start the handshake on the serverside, get the certificate from the server, and send that certificate back to the client. This is only possible, if I can suspend the handshake procedure with the client, and continue when I have the certificate from the server. Right now openssl has some callbacks like the info and msg callbacks but you cannot return from it with let's say: SSL_HANDSHAKE_SUSPEND, or SSL_HANDSHAKE_INTERRUPT or something like that to be able to continue it later. So right now when you return from these and you don't have the certificate set you'll get the: No shared cipher error. The question is that will there'be some kind of way to suspend and continue the handshake? Or is there any other way to do this now? Thank you.
Re: suspending and continuing handshake
What do you mean by I have to register default certificates? There are no default certificates. Before I know what certificate should I show to the client, I have to connect to the server to get the certificate from it (and then copy it, sign it, etc.). But before connecting to the server I need the SNI from the client to be able to connect to the server with SNI, so the server will show the proper cert. I can only set the certificate on the client side _after_ I got the sni, connected to the server(with the servername got from the client), got the certificate from the server, copied/signed/whatever and _then_ I can show this to the client. Do we misunderstand each other? Or am I only misunderstanding you? On Tue, May 27, 2014 at 2:46 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, May 27, 2014 at 12:03:05PM +0200, DEXTER wrote: That is exactly what I thought first, to control it with BIOs. Unfortunately even if I give openssl the exact amount of bytes (not more) to be able to call the SNI callback, right after I return from the callback, openssl's own state machine goes into a state where it'll immediately say the: No shared cipher error. (so I don't have time to set the certificate later). That is why I think an internal code change is needed in openssl itself, to support this case. You need to register default certificates of each type (RSA, DSA, ECDSA). Your SNI callback can switch to a fresh SSL_CTX with the appropriate MITM chain. If you're not doing MITM, you can't splice-in the server's chain anyway, since you don't have the private keys. For non-MITM proxies you should not an SSL API, as you're not terminating the SSL connection, just copying bytes back and forth. You'll just need some custom code to parse the client SSL HELLO and forward the connection accordingly. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: suspending and continuing handshake
On Tue, May 27, 2014 at 4:34 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, May 27, 2014 at 03:20:22PM +0200, DEXTER wrote: So you are writing an MiTM proxy? Exactly. When you sign the server certificate, do you replace the public key with a new public key whose private key you know? Yep. Do you instantiate the keypair in question in a new SSL_CTX that you associate with the SSL connection before returning from the SNI callback? Not now. Right now I'm sort of hacking the connection. I mean, I store the client's data in a temp buffer, and when I got back to the client to continue the handshake with it, I threw away the original ssl connection, create a new one, and feed it from the temp buffer. But it is really a hacking and my state machine becomes very complicated because of this. You should also not forget to verify the upstream server's certificate and if verification fails, avoid signing it with a key that is trusted by the downstream client. Of course. But before connecting to the server I need the SNI from the client to be able to connect to the server with SNI, so the server will show the proper cert. That's fine, this just increases the latency of your SNI callback. You mean I should connect to the server from the SNI callback itself? That doesn't seem to be a very good idea. Openssl itself should have a mechanism built in it, so I could return from the SNI callback with something like SSL_TLSEXT_ERR_SUSPEND and later after I've set the appropriate certs (or changed the context) and called the SSL_do_handshake() again, it should continue where it left off. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: suspending and continuing handshake
On Tue, May 27, 2014 at 5:09 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, May 27, 2014 at 04:57:39PM +0200, DEXTER wrote: Not now. Right now I'm sort of hacking the connection. I mean, I store the client's data in a temp buffer, and when I got back to the client to continue the handshake with it, I threw away the original ssl connection, create a new one, and feed it from the temp buffer. But it is really a hacking and my state machine becomes very complicated because of this. You're doing it wrong. Since there's no other way right now, it is the only way. Perhaps using OpenSSL to implement an MiTM proxy is not the right approach, but if you're using OpenSSL, then you must not return from the SNI callback before instantiating the appropriate connection-specific key-pair. That is exactly my problem, that you cannot return from the SNI callback before instantiating the appropriate connection-specific key-pair. Well, that's not how it works. Normally when OpenSSL returns with something like WANT_READ or WANT_WRITE, it is possible to later determine whether the preconditions for moving forward are satisfied. In this case you're asking OpenSSL to just wait for nothing in particular. That feature does not exist. That's the problem. I'm asking kindly the devs of openssl to make this feature exist. With the current API, you need something like threads or co-routines to suspend execution in the middle of the SNI callback and resume at that point once you have the required data. I want to avoid using threads/co-routines. Perhaps the OpenSSL state-machine is not sufficiently fine-grained (in terms of possible suspend/resume entry points) to make it easy to write an event-based MiTM proxy. That is why I'm saying that openssl should have a mechanism to support this case. Perhaps this is not the appropriate mailing list to discuss this, though noone answered my post on the openssl-devel list yet. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
suspending and continuing handshake
Hi! In a proxying environment when the client connects to the proxy and it sends the SNI, you have to suspend the handshake with the client side, start the handshake on the serverside, get the certificate from the server, and send that certificate back to the client. This is only possible, if I can suspend the handshake procedure with the client, and continue when I have the certificate from the server. Right now openssl has some callbacks like the info and msg callbacks but you cannot return from it with let's say: SSL_HANDSHAKE_SUSPEND, or SSL_HANDSHAKE_INTERRUPT or something like that to be able to continue it later. So right now when you return from these and you don't have the certificate set you'll get the: No shared cipher error. The question is that will there'be some kind of way to suspend and continue the handshake? Or is there any other way to do this now? Thank you.
Problem compiling OpenSSL
I am compiling OpenSSL 0.9.4 on a Linux Mandrake machine, and when I do the make command I get the following error: gcc -I.. -I../../include -DTHREADS -D_REENTRANT -fpic -DL_ENDIAN -DTERMIO -O 3 -fomit-frame-pointer -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -c sha_dgst.c -o sha_dgst.o /tmp/ccyX9lOs.s: Assembler messages: /tmp/ccyX9lOs.s:305: Error: suffix or operands invalid for `bswap' /tmp/ccyX9lOs.s:312: Error: suffix or operands invalid for `bswap' /tmp/ccyX9lOs.s:317: Error: suffix or operands invalid for `bswap' /tmp/ccyX9lOs.s:322: Error: suffix or operands invalid for `bswap' /tmp/ccyX9lOs.s:522: Error: suffix or operands invalid for `bswap' /tmp/ccyX9lOs.s:527: Error: suffix or operands invalid for `bswap' /tmp/ccyX9lOs.s:532: Error: suffix or operands invalid for `bswap' /tmp/ccyX9lOs.s:537: Error: suffix or operands invalid for `bswap' make[2]: *** [sha_dgst.o] Error 1 make[2]: Leaving directory `/home/scottder/SSL/openssl-0.9.4/crypto/sha' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/scottder/SSL/openssl-0.9.4/crypto' make: *** [all] Error 1 If anyone could help me with this, I would greatly appreciate it. -Scott __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
