Re: Can no longer receive short ASN1 messages

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
> > > > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%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
> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs
> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3KIVU5bgk6rsaB8ZpGKFShtsdKpjW
> mOkSmpO3kjnFws%3D&reserved=0

-- 
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/SA9PR09MB530934CE05CAF0B556F710FDDB44A%40SA9PR09MB5309.namprd09.prod.outlook.com.