Re: Can no longer receive short ASN1 messages

Okay, I just submitted a pull request referencing issue 22704.  Please kick it around and offer any critique.

> -----Original Message-----
> From: 'Tomas Mraz' via openssl-users <[email protected]>
> Sent: Thursday, March 12, 2026 4:17 AM
> To: Sands, Daniel N. <[email protected]>; [email protected]
> Subject: [EXTERNAL] 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%2
> > > > > > F%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%7Cc16ca75c
> 03d
> > > > > >
> > >
> 3496346dc08de7e8a1d52%7C7ccb5a20a303498cb0c129007381b574%7C
> 1%7C0
> > > %7
> > > > > >
> > >
> C639087328848814562%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG
> kiOnR
> > > 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%2Fop
> > >
> enssl%2F&data=05%7C02%7Cdnsands%40sandia.gov%7C35f6f425b425465
> ef1b80
> > >
> 8de80208c0c%7C7ccb5a20a303498cb0c129007381b574%7C1%7C0%7C63
> 908907445
> > >
> 1441685%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi
> OiIwLjAu
> > >
> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C
> %7C%7
> > >
> C&sdata=bPbzXbSEWWSgYgX%2BXYBSCN5wsor2MQFBaQwKS7hrNfE%3D&r
> eserved=0
> > > -
> > >
> foundation.org%2Fdonate%2F&data=05%7C02%7Cdnsands%40sandia.gov%
> 7Cc1
> > >
> 6ca75c03d3496346dc08de7e8a1d52%7C7ccb5a20a303498cb0c12900738
> 1b574
> > >
> %7C1%7C0%7C639087328848838859%7CUnknown%7CTWFpbGZsb3d8ey
> JFbXB
> > >
> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp
> bC
> > > Is
> > >
> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3KIVU5bgk6rsaB8ZpGKFShtsd
> KpjW
> > > mOkSmpO3kjnFws%3D&reserved=0
> 
> --
> Tomáš Mráz, Chief Technology Officer, OpenSSL Foundation We need your
> support! Help us protect digital privacy… everywhere.
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopen
> ssl.foundation%2Fdonate%2Fways-to-
> give&data=05%7C02%7Cdnsands%40sandia.gov%7C35f6f425b425465ef1b
> 808de80208c0c%7C7ccb5a20a303498cb0c129007381b574%7C1%7C0%7C
> 639089074451463248%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=VqwfnPxgymoCiS%2FvnWV7fLvnq
> dT9EizIPslB5L2MmQk%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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroup
> s.google.com%2Fa%2Fopenssl.org%2Fd%2Fmsgid%2Fopenssl-
> users%2F757ff5c2184c34b04d1c1bc6227b3b4b66382cb0.camel%2540ope
> nssl.foundation&data=05%7C02%7Cdnsands%40sandia.gov%7C35f6f425b4
> 25465ef1b808de80208c0c%7C7ccb5a20a303498cb0c129007381b574%7C
> 1%7C0%7C639089074451480506%7CUnknown%7CTWFpbGZsb3d8eyJFbX
> B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF
> pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Q7asFFY6EvRMM6Jowv
> EnCM128SvuuVBo0UKOWoO7bu4%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/SA9PR09MB53090373295528C65E94BC3FDB44A%40SA9PR09MB5309.namprd09.prod.outlook.com.