Hello Developers,
I am working on an embedded project. My target is Arm Cortex m3 microcontroller
(32-bit).
I need cryptography(encryption/decryption) support for my application.
Thus, I want to add part of openssl 1.1.1f source code to support AES
algorithms (modes cbc-mac, ctr128) in my exist
>Speaking of which, I've recently discovered (a documented interface
landmine) that:
status = SSL_read(ssl, ...);
err = SSL_get_error(ssl, status);
>is an anti-pattern, because the "correct" usage is:
It's not unlike checking errno without knowing if the syscall actua
On 20/05/2020 21:46, Viktor Dukhovni wrote:
> Glad to hear that at least handshakes are less prone to unexpected
> issues of that sort. I'd be interested to hear your thoughts (perhaps a
> separate thread) on what to do about SSL_read() and SSL_write().
Perhaps open a github issue for this?
>
On Wed, May 20, 2020 at 09:40:35PM +0100, Matt Caswell wrote:
> On 20/05/2020 21:36, Viktor Dukhovni wrote:
> > My take is that this is a sufficiently nasty problem to warrant some
> > changes in SSL_read(), SSL_write, SSL_accept(), ... to internally
> > memoize the error status before returning,
On 20/05/2020 21:36, Viktor Dukhovni wrote:
> My take is that this is a sufficiently nasty problem to warrant some
> changes in SSL_read(), SSL_write, SSL_accept(), ... to internally
> memoize the error status before returning, in a manner that does not
> depend on the prior state of the error s
On Wed, May 20, 2020 at 09:21:25PM +0100, Matt Caswell wrote:
> > Explanation:
> > want_write = BIO_ctrl_pending(network_bio)
> > want_read = BIO_ctrl_get_read_request(network_bio)
> >
> > I didn't instrument the write part, only the read part.
> > want_read>0 -> invoke read, check result: read=
On 20/05/2020 17:52, Claus Assmann wrote:
> On Wed, May 20, 2020, Matt Caswell wrote:
>
> [Thanks for still helping me with this!]
>
>> Can you test the underlying socket to see if it has been closed down in
>> an orderly way (i.e. recv() should return 0 on the socket if so)? That
>
> Yes, th
On Wed, May 20, 2020, Matt Caswell wrote:
[Thanks for still helping me with this!]
> Can you test the underlying socket to see if it has been closed down in
> an orderly way (i.e. recv() should return 0 on the socket if so)? That
Yes, that what happens.
So I added some debugging to the client a
On 20/05/2020 14:24, Claus Assmann wrote:
> On Wed, May 20, 2020, Matt Caswell wrote:
>
>> I wonder if there could be some middlebox in between these two peers
>> that is interfering with the connection in some way and arbitrarily
>> closing it down?
>
> No, it's being tested on localhost. An
On Wed, May 20, 2020, Matt Caswell wrote:
> I wonder if there could be some middlebox in between these two peers
> that is interfering with the connection in some way and arbitrarily
> closing it down?
No, it's being tested on localhost. And it works fine if I use a
different server (e.g., opens
On 20/05/2020 13:44, Claus Assmann wrote:
> On Wed, May 20, 2020, Matt Caswell wrote:
>
>> SSL_accept:TLSv1.3 early data
>
>> What happens in the application code? What was the function being called
>> (SSL_accept?) and what return value do you get? What does
>> SSL_get_error() return at this
On Wed, May 20, 2020, Matt Caswell wrote:
> SSL_accept:TLSv1.3 early data
> What happens in the application code? What was the function being called
> (SSL_accept?) and what return value do you get? What does
> SSL_get_error() return at this point?
It's:
r = SSL_accept(srv_ssl);
On 19/05/2020 15:56, Claus Assmann wrote:
> That's basically already in the code:
> while ((l = ERR_get_error_line_data((const char **) &file, &line,
> (const char **) &data, &flags)) != 0)
> log it ...
> but that does not generate any output. Even if I add
> the line you sug
13 matches
Mail list logo
