Re: Can no longer receive short ASN1 messages

Yeah, I think you have it right. In the current code (where we read at
least 8 bytes) it does not matter much, but the condition should be
`max < i`.

Tomas Mraz, OpenSSL Foundation


On Thu, 2026-03-12 at 03:38 +0000, 'Sands, Daniel N.' via openssl-users
wrote:
> I'm looking into this to suggest a patch, but I also noticed what I
> believe to be an off-by-one error in asn1_get_length.
> 
> 131	        if (*p++ & 0x80) {
> 132	            if (max < i + 1)
> 133	                return 0;
> 
> At this point, 'max' is the number of octets left in the buffer so
> far.  'i' is the number of additional octets to gather into a length
> word.  If we have read only enough octets to form a full header at
> this point, 'max' will equal 'i'.  So I don't think it should be
> comparing to 'i+1'.  Certainly, in my test change that only makes
> sure it has read enough for a complete header, this test always fails
> for multi-byte lengths.  Is there an error in my thinking here?
> 
> > -----Original Message-----
> > From: Tomas Mraz <[email protected]>
> > Sent: Tuesday, March 10, 2026 3:48 AM
> > To: Neil Horman <[email protected]>; Sands, Daniel N.
> > <[email protected]>
> > Cc: [email protected]
> > Subject: Re: [EXTERNAL] Re: Can no longer receive short ASN1
> > messages
> > 
> > On Mon, 2026-03-09 at 20:28 -0400, Neil Horman wrote:
> > > Ok, that did it, If I stream in data from a process that never
> > > closes
> > > stdout, to stdin of the above program, I see the hang
> > > 
> > > It appears (at least in this case, but I presume in the socket
> > > case as
> > > well, since TCP generally uses blocking sockets), we get stuck in
> > > the
> > > read syscall, waiting for more bytes that never appear.
> > > 
> > > Unsure what to do about it.  Possibly just reduce the HEADER_SIZE
> > > to
> > > be two bytes, which is the minimal size IIRC for an ASN1 object
> > 
> > No, that won't work (alone). We would have to examine the two bytes
> > and read
> > further if the header is not complete yet before calling
> > ASN1_get_object().
> > 
> > Tomas
> > 
> > > On Mon, Mar 9, 2026 at 7:49 PM Sands, Daniel N.
> > > <[email protected]>
> > > wrote:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Small correction:  Use fwrite instead of fprintf since there’s
> > > > an
> > > > embedded NULL.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > From: 'Sands, Daniel N.' via openssl-users
> > > > <[email protected]>
> > > > Sent: Monday, March 9, 2026 5:47 PM
> > > > To: Neil Horman <[email protected]>
> > > > Cc: [email protected]
> > > > Subject: RE: [EXTERNAL] Re: Can no longer receive short ASN1
> > > > messages
> > > > 
> > > > Do you have a reproducer available?
> > > > 
> > > > I tried this quickly with the following code (need to link it
> > > > statically since I'm hacking into internal interfaces)
> > > > 
> > > > The problem with your reproducer is that you are not reading a
> > > > socket.  So when you hit end of file, you get a definite end of
> > > > file
> > > > condition.  The same works for my case:  When the sender is
> > > > killed
> > > > after sending the message, it shuts down the socket, which
> > > > allows
> > > > the receiver to go ahead and try to use what it got.  Let’s
> > > > have it
> > > > receive through stdin or something like that, and then run the
> > > > program with a separate program that writes those bytes to
> > > > stdout
> > > > and then does not exit.  Pipe this into the receiver program.
> > > > 
> > > > Sender:  Something like,
> > > > 
> > > > #include <stdio.h>
> > > > 
> > > > int main() {
> > > >     fprintf(stdout, “\001\002\000\001”);
> > > >     sleep(1000);
> > > > }
> > > > 
> > > > Receiver:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > #include <stdlib.h>
> > > > #include <stdio.h>
> > > > #include <openssl/bio.h>
> > > > #include <openssl/buffer.h>
> > > > #include "internal/asn1.h"
> > > > 
> > > > 
> > > > 
> > > > int main(int argc, char **argv)
> > > > {
> > > >     BIO *in = BIO_new_fd(stdin, 0);
> > > >     BUF_MEM *membuf = NULL;
> > > > 
> > > >     asn1_d2i_read_bio(in, &membuf);
> > > > }
> > > > 
> > > > Run as:  sender | receiver
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > On Mon, Mar 9, 2026 at 4:49 PM 'Sands, Daniel N.' via openssl-
> > > > users
> > > > <[email protected]> wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > As of 3.5.x, after an issue having something to do with
> > > > > headers, I
> > > > > can no longer receive messages of less than 8 bytes.  As an
> > > > > example, if I only need to send a status code as a response,
> > > > > I
> > > > > will send 1 tag byte, 1 length byte, and possibly 1 byte
> > > > > indicating an integer status code.  Since this is a TCP
> > > > > socket, I
> > > > > keep the socket open for further communication.  The
> > > > > receiving
> > > > > side now insists on receiving at least HEADER_SIZE bytes (8)
> > > > > before it will do anything, so now both sides are at a
> > > > > stalemate—the receiver still waiting for its message, and the
> > > > > sender waiting for further communication from the sender.
> > > > > 
> > > > > I saw in issue 21777 why this was done, but the strategy is
> > > > > not
> > > > > working for short messages.  I suggest an alternate strategy
> > > > > where
> > > > > you add a “need” variable, which is the very least amount of
> > > > > bytes
> > > > > necessary to decode the next part, and want will be some
> > > > > value
> > > > > higher than that.  If “want” bytes can be read, awesome.
> > > > > If it’s stalled between “want” and “need” then just go ahead
> > > > > and
> > > > > process it.  If it’s less than “need”, then, and only then,
> > > > > do you
> > > > > continue the loop.  Obviously, “need” would only start at 2,
> > > > > since
> > > > > the smallest legal DER encoding is 2 bytes (the NULL type). 
> > > > > It
> > > > > would expand if the tag or length turn out to be multiple
> > > > > bytes.
> > > > > 
> > > > > Anyway, is there a workaround for this, other than reducing
> > > > > HEADER_SIZE and recompiling, or attaching non-sequitur data
> > > > > just
> > > > > to reach the 8-byte minimum?
> > > > > --
> > > > > You received this message because you are subscribed to the
> > > > > Google
> > > > > Groups "openssl-users" group.
> > > > > To unsubscribe from this group and stop receiving emails from
> > > > > it,
> > > > > send an email toopenssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
> > > > > To view this discussion visit
> > > > > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > > groups.google.com%2Fa%2Fopenssl.org%2Fd%2Fmsgid%2Fopenssl-
> > users%2F
> > > > > 
> > SA9PR09MB5309355179862CB0C56F6C35DB79A%2540SA9PR09MB5309.nampr
> > d09.
> > > > > 
> > prod.outlook.com&data=05%7C02%7Cdnsands%40sandia.gov%7Cc16ca75c03d
> > > > > 
> > 3496346dc08de7e8a1d52%7C7ccb5a20a303498cb0c129007381b574%7C1%7C0
> > %7
> > > > > 
> > C639087328848814562%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> > ydW
> > > > > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo
> > > > > yfQ%3
> > > > > 
> > D%3D%7C0%7C%7C%7C&sdata=P25Bgjl%2FWW%2Fb5LTa%2Bd9yrPNQ6AC%2F
> > 2Tg%2F
> > > > > 6MfgKek7HVU%3D&reserved=0
> > > > > .
> > 
> > --
> > Tomáš Mráz, Chief Technology Officer, OpenSSL Foundation Join the
> > Code
> > Protectors or support us on Github Sponsors
> > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenssl
> > -
> > foundation.org%2Fdonate%2F&data=05%7C02%7Cdnsands%40sandia.gov%7Cc1
> > 6ca75c03d3496346dc08de7e8a1d52%7C7ccb5a20a303498cb0c129007381b574
> > %7C1%7C0%7C639087328848838859%7CUnknown%7CTWFpbGZsb3d8eyJFbXB
> > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC
> > Is
> > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3KIVU5bgk6rsaB8ZpGKFShtsdKpjW
> > mOkSmpO3kjnFws%3D&reserved=0

-- 
Tomáš Mráz, Chief Technology Officer, OpenSSL Foundation
We need your support! Help us protect digital privacy… everywhere.
https://openssl.foundation/donate/ways-to-give

-- 
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/757ff5c2184c34b04d1c1bc6227b3b4b66382cb0.camel%40openssl.foundation.