Re: [openssl-users] Authentication over ECDHE
You really have no idea how to code. You look like one of those junior engineers that think they know it all. I won't be replying again, so don't need to get your hopes up. Na(o) sábado, 29 de dez de 2018, 17:19, C.Wehrmeyer escreveu: > On 29.12.18 16:53, Jakob Bohm via openssl-users wrote: > > The session caching in the SSL and TLS protocols is to skip the > > expensive key exchange when reconnecting within a few seconds, > > as is extremely common with web browsers opening up to 8 parallel > > connections to each server. > > My outburst was somewhat out of line. SSL_clear() is not *completely* > superfluous, you're right, but it's incredibly limited. > > > There is hopefully a configuration option to tell the OpenSSL server > > end SSL_CTX to not do this, just as there should (for multi-process > > web servers) be an option to hand the state storage over to the web > > server application for inter-process sharing in whatever the web > > server application (and its configuration) deems secure. > > Then why doesn't the documentation page of SSL_clear() mention this > directly? "If you want to reuse an SSL object, use this function to set > some option on the SSL_CTX object". > > On 29.12.18 17:08, Richard Levitte wrote: > > ... I'm not sure about you, but I have a hard time seeing how one > > would trim off fat from *public* structures that everyone and their > > stray cat might be tinkering in. Trimming off fat usually means > > restructuring the structures, and unless they're opaque, the freedom > > to do so is severily limited. > > You're implying that people can't do that anymore. Let me assure you > that they still can, you just made it a little harder for people who're > really determined to walk outside of the API bounds. > > On the other hand you've made the normal applications programmers job - > which is to know where and when to allocate and free memory - a lot > harder. Here I am, having a bunch of objects all sitting in a designated > memory area of mine - which I can initialise, reset, and reuse just how > I seem fit (not that I want to horribly break SSL objects, I just want > to determine where they are stored) - and I can't use them because the > OpenSSL devs are working on taking a little bit of power from me that I > need in order to help the library do smart things. > > Like, imagine that I know I'll need: > > - a context object > - a connection object > - a BIO object > - some X.509 cert object/memory/whatever > - and so forth and so on > > And that not just once, but for a thousand connections. As an > application programmer who knows a thing or two about scalable > programming I'd be like: OK, that's fantastic. I can mmap the necessary > memory, use hugepages, reduce the TLB, and just have all that stuff > written on the same chunk without metadata or padding inbetween, which > doesn't bloat our D$. Sweet money! > > And now I can't do that because the devs want me to use their > single-object-only creation functions who return already allocated > memory to me. I don't get to decide anymore where my objects are > written, I don't get to decide what caching objects are used (maybe I > don't WANT an X.509 cert object, so I could pass NULL to the function > that creates it, or maybe I already HAVE a couple hundred of those lying > here, so you can have them ... no? You prefer your structures to be > opaque? Oh well). > > But, you know, it could still be argued that this is safer somehow. > *Somehow*. If not ... for the fact that I don't even seem to be able to > KEEP the objects OpenSSL created for me quite elaborately. > > > You do know that your string insert NUL bytes, right? If you have a > > look at how they're used, you might see why those stray NUL bytes > > aren't a good thing. > > Yes, I do. See below, I wrote the last part first. > > (Also, what? Please have a look again, those stray NUL bytes wouldn't > have ANY effect, at least not that I see it. One memcpy(), two > EVP_DigestUpdate(), and it's always a separately calculated length). > > > P.S. as a side note, your message triggered profanity filters. I > > don't really care, it's not our filters, but this is just to inform > > you that your rant didn't quite reach everyone (those with profanity > > filters in place) > > /postmaster > > It's just that this is so stupid to me. I'm no crypto master, I know > that. But I constantly hear about timing attacks and side channels and > all that, so I tried to avoid stepping into the pitfalls that other > people would do - and then I'm being told it's SUPPOSED to be like that. > Come on, please! It's almost as if the devs aren't even trying. > > On 29.12.18 17:21, J. J. Farrell wrote:> So instead of correct portable > code which derives obviously and > > straightforwardly from the specification, you'd write arrays of a > > different length from the original, the first 48 bytes of which would > > only be correct in some compilation environments, and
Re: [openssl-users] Multiple client connection to Nginx server
Hi, Socket file descriptor is unique during the entire connection time. You could save the data using the fd as key to a hashtable entry. Regards Na(o) quinta, 13 de dez de 2018, 05:16, ASHIQUE CK escreveu: > 4. f-stack nginx server 1.11.10 > > On Thu, Dec 13, 2018 at 9:00 AM ASHIQUE CK wrote: > >> Hi, >> 1. The engine that we wrote is by the reference of qat, is just an >> interface which receives the openssl parameters of AES and RSA and offload >> them to an FPGA hardware accelerator. >> 2. >> 3. Openssl 1.1.0 h >> 4. Uses f-stack nginx 1.10.1 >> 5. We ran nginx server which have a 1 Gb file in its root directory. Then >> connected 3 clients to this server. These clients waits after handshake is >> done. After I run 3rd client, I gave a Get request through 1 st client to >> download that 1 gb file. But it showed error message, "decryption failed or >> bad record mac". When I debugged using gdb, I understood that Tag >> verification is getting failed. But the matter is, I am storing the Key and >> IV at the time of handshake itself, to a buffer in my engine. When an >> SSLRead or SSLWrite occur, I will copy the saved Key and Iv to fill the >> respective descriptors. >> But, in this case what happens is, if there is 3rd client handshake >> occurred, its key and iv stored in a buffer. And when I give a Sslwrite in >> the 1st client, it used the last saved key and iv, but it is actually key >> and iv of 3 rd client. But I can download the file if I give get request >> through the last handshaked client. >> So what I can do is, save the key and iv of different clients in >> different buffers. If the SSLread/write from any client comes, then just >> offload the key and iv from the respective buffer. But for that, i need a >> unique id for each client, which must be the same for a client in the >> entire connection. >> How can i get the unique id. Beyond the parameters *in, *out, inl (in >> the case of plaintext/ cipher text offloading) and *ptr, *type, *arg (in >> the case of header/aad offload) only what I have is ctx. With this ctx, can >> i get a unique id or is there any way to solve this problem. >> 6. Didn't tried with Apache server. >> >> Thanks >> >> On Thu 13 Dec, 2018, 1:30 AM Michael Richardson > >>> >>> ASHIQUE CK wrote: >>> > We are using a Crypto Accelerator Engine to offload AESGCM and RSA >>> > parameters. Trying to connect multiple clients simultaneously with a >>> > single Nginx server, which is using this accelerator. The Key and IV >>> >>> You probably need to tell us: >>> >>> 1) which engine? did you write this engine? >>> 2) whose driver? >>> 3) what version of openssl? >>> 4) what version of nginx? >>> 5) how did you observe the problem you described? >>> 6) is it different for, for instance, apache? or some other server >>> software? >>> >>> > is passing only at handshake, and after handshake this set of key and >>> > IV is using for all encryption and decryption. So at Engine side, we >>> > are storing this Key and IV to a buffer and while >>> > encrypting/decrypting , this Key and IV is used from this buffer. But, >>> > while multiple client connects, the last saved Key/IV is getting for >>> > all clients. >>> > So, is there any way to get a unique ID foer each client connection ? >>> > >>> -- >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >> -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL - Session Resumption on an On-going Connection
> I thought you wanted renegotiation, not resumption, servers can't > do "resumption", because resumption is what you do to avoid a full > handshake on a *new* connection, and only the client can reconnect. Ok. Agreed. > You seem to be confused, and have not explained your requirements > clearly. What is your *goal*? My goal is to have the Openssl to "perform the TLS Resumption (initiated by the Hello Request message from the server or the Client Hello message from the client), in an ongoing TLS Session." (it's specifically stated on the spec, like this). > What does "always on" mean to you? Always on, means that the socket connection is up for as long as it is possible, meaning that the socket is not closed and it keeps exchanging information all the time (server<->client) > Only clients can resume previous > sessions, when reconnecting to a server. Is that what you're trying > to do? (Implement a server with a session cache for client resumption? I'm developing the server side with OpenSSL 1.0.2. And it supports cache (I've activated it on the method SSL_CTX_set_session_cache_mode). > Support session tickets? Is there just one server or a server "farm"? > Do the clients support resumption?) There's only 1 server, not a farm. How can I tell if the client supports resumption? > Or are you trying to periodically rekey a long-running connection? Maybe this is it. For me, Renegotiation is request "everything" (new pubkey, certificates, etc) Resumption, is just to refresh the keys? I'm a little confused here. > > Or something else? I think this is it :) On Wed, 21 Nov 2018 at 23:12, Viktor Dukhovni wrote: > On Wed, Nov 21, 2018 at 05:45:19PM +, Filipe Fernandes wrote: > > > I've followed your example, and it looks like the server is doing what > it's > > supposed to, however, I'm getting a disconnect from the server when the > > session expires. Which should not happen, and I can't seem to find a > reason > > for this to be happening. > > > > As previously said, I'm developing a server that handles always-on TLS > > connections, and I'm trying to perform a session resumption. > > I thought you wanted renegotiation, not resumption, servers can't > do "resumption", because resumption is what you do to avoid a full > handshake on a *new* connection, and only the client can reconnect. > > You seem to be confused, and have not explained your requirements > clearly. What is your *goal*? > > What does "always on" mean to you? Only clients can resume previous > sessions, when reconnecting to a server. Is that what you're trying > to do? (Implement a server with a session cache for client resumption? > Support session tickets? Is there just one server or a server "farm"? > Do the clients support resumption?) > > Or are you trying to periodically rekey a long-running connection? > > Or something else? > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL - Session Resumption on an On-going Connection
I've misjudged. The socket is closed even if the session has not ended
(I've set the session timeout to 10 times the resumption cycle).
You can check the tcpdump here:
https://imgfly.me/i/66LJY
I'm doing exactly what is on the s_server example, without avail.
if (SSL_renegotiate(GetSSL()) <= 0) {
CSyException Ex("SocketSSL", "SSL_renegotiate() failed.
Stopping communication.");
Ex.PrintError();
SetShouldClose(TRUE);
GetSSLConfig()->uiLastTLSRenegotiation = time1sVal;
return FALSE;
}
if (SSL_do_handshake(GetSSL()) <= 0) {
CSyException Ex("SocketSSL", "SSL_do_handshake() has failed.
Stopping communication.");
Ex.PrintError();
SetShouldClose(TRUE);
GetSSLConfig()->uiLastTLSRenegotiation = time1sVal;
return FALSE;
}
Thanks!
On Wed, 21 Nov 2018 at 17:45, Filipe Fernandes <
filipe.mfgfernan...@gmail.com> wrote:
> Hi Viktor,
>
> I've followed your example, and it looks like the server is doing what
> it's supposed to, however, I'm getting a disconnect from the server when
> the session expires. Which should not happen, and I can't seem to find a
> reason for this to be happening.
>
> As previously said, I'm developing a server that handles always-on TLS
> connections, and I'm trying to perform a session resumption.
>
>
> Thanks!
>
>
>
> On Mon, 19 Nov 2018 at 21:02, Viktor Dukhovni
> wrote:
>
>> On Mon, Nov 19, 2018 at 04:01:35PM +, Filipe Fernandes wrote:
>>
>> > I'm developing a specific SSL Server, in which it's supposed to have an
>> > always-on socket connection. So, to be on the safe side, there's
>> specific
>> > needs that need to be filled on this implementation. One of the needs is
>> > that the server must send a resumption request (ServerHello) to the
>> client
>> > on a cyclic manner. I've tried everything I could, but it seems that the
>> > server does not send the ServerHello to the Client.
>>
>> This is only possible with TLS <= 1.2, TLS 1.3 eliminated renegotiation.
>>
>> > My question: How can I make LibOpenSSL-1.0.2g to send a ServerHello to
>> the
>> > Client *on demand*? The socket should not close, nor perform a
>> > renegotiation.
>>
>> The relevant code in apps/s_server.c is:
>>
>> SSL_renegotiate(con);
>> i = SSL_do_handshake(con);
>>
>> this implements the handling of the 'r' magic character, see s_server(1):
>>
>> CONNECTED COMMANDS
>>
>>If a connection request is established with an SSL client and
>> neither
>>the -www nor the -WWW option has been used then normally any data
>>received from the client is displayed and any key presses will be
>> sent
>>to the client.
>>
>>Certain commands are also recognized which perform special
>> operations.
>>These commands are a letter which must appear at the start of a
>> line.
>>They are listed below.
>>
>>[...]
>>
>>r Renegotiate the SSL session (TLSv1.2 and below only).
>>
>>R Renegotiate the SSL session and request a client certificate
>>(TLSv1.2 and below only).
>>
>> --
>> Viktor.
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL - Session Resumption on an On-going Connection
Hi Viktor, I've followed your example, and it looks like the server is doing what it's supposed to, however, I'm getting a disconnect from the server when the session expires. Which should not happen, and I can't seem to find a reason for this to be happening. As previously said, I'm developing a server that handles always-on TLS connections, and I'm trying to perform a session resumption. Thanks! On Mon, 19 Nov 2018 at 21:02, Viktor Dukhovni wrote: > On Mon, Nov 19, 2018 at 04:01:35PM +0000, Filipe Fernandes wrote: > > > I'm developing a specific SSL Server, in which it's supposed to have an > > always-on socket connection. So, to be on the safe side, there's specific > > needs that need to be filled on this implementation. One of the needs is > > that the server must send a resumption request (ServerHello) to the > client > > on a cyclic manner. I've tried everything I could, but it seems that the > > server does not send the ServerHello to the Client. > > This is only possible with TLS <= 1.2, TLS 1.3 eliminated renegotiation. > > > My question: How can I make LibOpenSSL-1.0.2g to send a ServerHello to > the > > Client *on demand*? The socket should not close, nor perform a > > renegotiation. > > The relevant code in apps/s_server.c is: > > SSL_renegotiate(con); > i = SSL_do_handshake(con); > > this implements the handling of the 'r' magic character, see s_server(1): > > CONNECTED COMMANDS > >If a connection request is established with an SSL client and > neither >the -www nor the -WWW option has been used then normally any data >received from the client is displayed and any key presses will be > sent >to the client. > >Certain commands are also recognized which perform special > operations. >These commands are a letter which must appear at the start of a > line. >They are listed below. > >[...] > >r Renegotiate the SSL session (TLSv1.2 and below only). > >R Renegotiate the SSL session and request a client certificate >(TLSv1.2 and below only). > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL - Session Resumption on an On-going Connection
I'm developing a specific SSL Server, in which it's supposed to have an always-on socket connection. So, to be on the safe side, there's specific needs that need to be filled on this implementation. One of the needs is that the server must send a resumption request (ServerHello) to the client on a cyclic manner. I've tried everything I could, but it seems that the server does not send the ServerHello to the Client. My question: How can I make LibOpenSSL-1.0.2g to send a ServerHello to the Client *on demand*? The socket should not close, nor perform a renegotiation. Thanks! -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
