Re: [openssl-dev] [openssl.org #2021] sni bug

[Peter Sylvester via RT]

On 06/02/2016 15:50, Rich Salz via RT wrote:
> Is this still a bug?
> --
> Rich Salz, OpenSSL dev team; rs...@openssl.org
>
>
I don't know, there have been many changes to the extension treatment.
I have not followed the stuff since 5 years.

The extension handling is not what I had in the original design and seems to be 
broken.

There was no split into two functions two functions that communicate through 
the session.;

Some callbacks are done in the check loop (as far as I remember) .
Unfortunately this split occured almost in parallel to our contribution in 2006
when some EC stuff was added.

A correct logic is one single function(the code of check and parse combined) 
that collects the 
values of extensions
and then treat them calls callbacks in a defined order.

Actually it seems that you could influence the server behavoiur if you change 
the order of 
extensions in the clienthello.
sni first or last for example.
That makes server application code difficult.

best



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2021
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Matt Caswell]

On 06/02/16 04:24, Fedor Indutny via RT wrote:
> On Fri, Feb 5, 2016 at 7:14 PM, Matt Caswell  wrote:
> 
>>
>>
>> On 05/02/16 22:42, Fedor Indutny wrote:
>>> Matt,
>>>
>>> I have looked through the APIs. Will have to experiment with them
>>> somewhen later to see how well they will perform, but from theoretical
>>> point of view I am a bit scared of having 2 fds (and one ucontext) for
>>> every job in a pool. It seems like this could be a bit of burden in
>>> event-loop based model. For example, it is not hard to imagine a
>>> situation in node.js application with 1 handshakes that are trying
>>> to complete in parallel. Is there any need in creating this fds
>>> unconditionally?
>>
>> Well of course the number of jobs in the pool is not the same as the
>> number of handshakes. We create a pool of jobs that are shared between
>> the handshakes as required in order to conserve resources. With regards
>> to the fds, I mentioned that I was working on some tweaks to the API. It
>> is in this area where there are tweaks being made. Specifically I am
>> moving the creation of the fds to be a responsibility of the called code
>> (i.e. most likely an engine) and not the async framework itself.
>>
> 
> I understand what the pool means ;) The imaginary situation that I was
> talking about had lots of handshakes happening in parallel. To make it a
> bit real: a server that decrypts premaster secrets remotely with 2000ms
> latency, that receives 1000 requests per second. In such situation pool
> size needs to be at least 2000 to accommodate this amount of requests.
> 
> While 2000ms is a bit far-fetched, it is very easy to imagine that that
> remote decrypting server will go absolutely down and won't respond at
> all. Meaning that for some period of time (maybe 5-10 seconds) all this
> load is going to attempt to take new job from the pool. While I'm sure that
> SSL structures itself will take a huge stake in resources usage, having
> extra fd for each of these jobs doesn't sound right to me.

Right, but you can set a maximum size limit on the pool if that is
something you are worried about. I would expect you would size it to the
amount of jobs that your "remote decrypting server" (as you call it...I
think of it as an engine) can handle, plus possibly a bit more if you
are willing to have some kind of queue in the engine itself.

You are of course right that there will be a limit where you attempt to
throw so much load at something that it's not going to be able to take
any more. Handshakes will start failing at that point. That's no
different to the situation today of course. If you throw enough load at
OpenSSL today, sooner or later you will hit the limits of the hardware.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4293] cmds help cleanup

[Rich Salz via RT]

fixed in commit 6755ff1
The github PR was done before the RT moderator :)
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4293
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3359] Expired certificates bug.

[Rich Salz via RT]

It's been a couple of years :) We think this is fixed.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3359
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4269] Extend ECDH tests to more curves. Add more ECDH KATs.

[Rich Salz via RT]

done in commit b438f0e on master. thanks!
--
Rich Salz, OpenSSL dev team; rs...@openssl.org


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4269
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Matt Caswell via RT]

On 06/02/16 04:24, Fedor Indutny via RT wrote:
> On Fri, Feb 5, 2016 at 7:14 PM, Matt Caswell  wrote:
> 
>>
>>
>> On 05/02/16 22:42, Fedor Indutny wrote:
>>> Matt,
>>>
>>> I have looked through the APIs. Will have to experiment with them
>>> somewhen later to see how well they will perform, but from theoretical
>>> point of view I am a bit scared of having 2 fds (and one ucontext) for
>>> every job in a pool. It seems like this could be a bit of burden in
>>> event-loop based model. For example, it is not hard to imagine a
>>> situation in node.js application with 1 handshakes that are trying
>>> to complete in parallel. Is there any need in creating this fds
>>> unconditionally?
>>
>> Well of course the number of jobs in the pool is not the same as the
>> number of handshakes. We create a pool of jobs that are shared between
>> the handshakes as required in order to conserve resources. With regards
>> to the fds, I mentioned that I was working on some tweaks to the API. It
>> is in this area where there are tweaks being made. Specifically I am
>> moving the creation of the fds to be a responsibility of the called code
>> (i.e. most likely an engine) and not the async framework itself.
>>
> 
> I understand what the pool means ;) The imaginary situation that I was
> talking about had lots of handshakes happening in parallel. To make it a
> bit real: a server that decrypts premaster secrets remotely with 2000ms
> latency, that receives 1000 requests per second. In such situation pool
> size needs to be at least 2000 to accommodate this amount of requests.
> 
> While 2000ms is a bit far-fetched, it is very easy to imagine that that
> remote decrypting server will go absolutely down and won't respond at
> all. Meaning that for some period of time (maybe 5-10 seconds) all this
> load is going to attempt to take new job from the pool. While I'm sure that
> SSL structures itself will take a huge stake in resources usage, having
> extra fd for each of these jobs doesn't sound right to me.

Right, but you can set a maximum size limit on the pool if that is
something you are worried about. I would expect you would size it to the
amount of jobs that your "remote decrypting server" (as you call it...I
think of it as an engine) can handle, plus possibly a bit more if you
are willing to have some kind of queue in the engine itself.

You are of course right that there will be a limit where you attempt to
throw so much load at something that it's not going to be able to take
any more. Handshakes will start failing at that point. That's no
different to the situation today of course. If you throw enough load at
OpenSSL today, sooner or later you will hit the limits of the hardware.

Matt



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3528
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3344] PATCH: don't crash or fail in ASN1_print from t_pkey.c

[Rich Salz via RT]

Can't reproduce it. Maybe the machine that had the problem got infected by
aliens or something :)

Please open a new ticket if needed.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3344
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4293] cmds help cleanup

[J Mohan Rao Arisankala via RT]

Hi,

In commands help, option valtype, 0 is to be treated same as '-', but in
apps/opt.c: valtype2param(),
case 0 was missing. Because of this, *openssl asn1parse -help* was printing
options without args wrongly.

Few cleanups are also done in asn1parse/ca/ciphers.

I have created the following pull request with these changes. Please have a
look

https://github.com/openssl/openssl/pull/635

Thanks,
Mohan

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4293
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4214] [GitHub PR] RFC 7714 DTLS-SRTP profiles

[Matt Caswell via RT]

Patch applied to master. Closing ticket.

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4214
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2021] sni bug

[Rich Salz via RT]

Is this still a bug?
--
Rich Salz, OpenSSL dev team; rs...@openssl.org


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2021
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4194] engine command regression in 1.1

[Rich Salz via RT]

There's now a manpage that explains where and when engines can be named. :)
Not changing the behavior back to what it was, sorry.
Closing the ticket.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4194
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev