Can no longer receive short ASN1 messages
Sands, Daniel N.
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?
Neil Horman
#include <stdio.h>
#include <openssl/bio.h>
#include <openssl/buffer.h>
#include "internal/asn1.h"
unsigned char msgbuf[] = { 1, 2, 0, 1 };
int main(int argc, char **argv)
{
BIO *in = BIO_new_mem_buf(msgbuf, 4);
BUF_MEM *membuf = NULL;
asn1_d2i_read_bio(in, &membuf);
}
--
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-user...@openssl.org.
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/SA9PR09MB5309355179862CB0C56F6C35DB79A%40SA9PR09MB5309.namprd09.prod.outlook.com.
Sands, Daniel N.
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
Sands, Daniel N.
Small correction: Use fwrite instead of fprintf since there’s an embedded NULL.
Neil Horman
Tomas Mraz
> 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
read further if the header is not complete yet before calling
ASN1_get_object().
Tomas
> > > https://groups.google.com/a/openssl.org/d/msgid/openssl-users/SA9PR09MB5309355179862CB0C56F6C35DB79A%40SA9PR09MB5309.namprd09.prod.outlook.com
> > > .
--
Join the Code Protectors or support us on Github Sponsors
https://openssl-foundation.org/donate/
Sands, Daniel N.
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?
> > > > 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
> 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
Tomas Mraz
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:
https://openssl.foundation/donate/ways-to-give
Sands, Daniel N.
> 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
> > > mOkSmpO3kjnFws%3D&reserved=0
>
> --
> Tomáš Mráz, Chief Technology Officer, OpenSSL Foundation We need your
> support! Help us protect digital privacy… everywhere.
> 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
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroup
> s.google.com%2Fa%2Fopenssl.org%2Fd%2Fmsgid%2Fopenssl-
> 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.