Re: [openssl-users] X509_verify_cert cannot be called twice

2016-03-24 Thread DEXTER
? 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

[openssl-users] X509_verify_cert cannot be called twice

2016-03-24 Thread DEXTER
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

Re: issue with set_tlsext_ticket_key_cb and set_verify

2014-09-26 Thread DEXTER
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

issue with set_tlsext_ticket_key_cb and set_verify

2014-09-25 Thread DEXTER
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

Re: issue with set_tlsext_ticket_key_cb and set_verify

2014-09-25 Thread DEXTER
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

Re: client side session cache with SNI, and tlsext_ticket_key_cb

2014-08-12 Thread DEXTER
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

client side session cache with SNI, and tlsext_ticket_key_cb

2014-08-11 Thread DEXTER
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

Re: client side session cache with SNI, and tlsext_ticket_key_cb

2014-08-11 Thread DEXTER
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

Re: suspending and continuing handshake

2014-06-05 Thread DEXTER
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... --

Re: suspending and continuing handshake

2014-06-05 Thread DEXTER
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

Re: suspending and continuing handshake

2014-06-04 Thread DEXTER
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

Re: suspending and continuing handshake

2014-05-27 Thread DEXTER
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

Re: suspending and continuing handshake

2014-05-27 Thread DEXTER
/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

Re: suspending and continuing handshake

2014-05-27 Thread DEXTER
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

Re: suspending and continuing handshake

2014-05-27 Thread DEXTER
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

suspending and continuing handshake

2014-05-26 Thread DEXTER
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

Problem compiling OpenSSL

1999-09-16 Thread Scott Dexter
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