Re: [Burp-users] Large file problems?

[Brendon H. <br...@qu...>]

Oh, one more thing I forgot to mention: Apparently Debian needs the 
libcap-dev package installed to compile burp, now, otherwise sys/
compatibility.h is missing, otherwise. I suspect something must have 
changed, recently. I didn't see that one mentioned in the README.

Best,
Brendon

On Sunday, February 15, 2026 9:57:53 p.m. Eastern Standard Time 
Brendon Higgins wrote:
> Hi Graham,
> 
> Thanks so much for investigating this. I tried testing it out: I had kept an
> archive of the backup that was failing for me, so I restored that 
(changing
> "current" symlink and adding "working" symlink by hand) and confirmed 
that
> my previous build of burp still gets stuck partway into this chromium file
> as before (it does). Next I applied your change to ssl.c in my working
> copy, rebuilt it, and tried again.
> 
> Sorry to bear bad news, but this also gets stuck when it gets to that file.
> I tried it a second time after double-checking the build was fresh, just to
> be certain. But it does seem like this isn't the cause.
> 
> Let me know if it would be helpful to send you the logs, which also have 
all
> the debug statements I added (the patch I sent previously).
> 
> The workaround at present is to simply remove the failing backup and 
let
> burp restart it from scratch. For me, the problem is reproducible when
> resuming, but only intermittent on restart.
> 
> Best,
> Brendon
> 
> On Sunday, February 15, 2026 6:14:56 a.m. Eastern Standard Time 
Graham
> 
> Keeling wrote:
> > Hello,
> > 
> > This weekend, I have spent a long time trying to reproduce the issue.
> > Bad news: I haven't managed to do so
> > Good news: I have found some suspicious parts of code on the server
> 
> side
> 
> > In src/ssl.c::ssl_load_dh_params() - the ssl v3 section from line 61:
> > if(OSSL_DECODER_from_bio(dctx, bio))
> > {
> > 
> > 	...error handling...
> > 
> > }
> > 
> > But the man page for OSSL_DECODER_from_bio() says this should:
> >        "return 1 on success, or 0 on failure."
> > 
> > It appears then, that this function is always going to the 'success' part
> > of the code, and carrying on. It should always be failing instead. 
Indeed,
> > when I fix the 'if()' to be 'if(!)', the burp server immediately exits
> > with
> > this error every time, indicating that this code has always been broken:
> > "No supported data to decode. Input type: PEM"
> > 
> > I suspect that the ssl library works for the initial handshake for basic
> > ciphers. But on trying to transfer large data in phase2, it tries to
> > renegotiate DH cipers and hangs on it's ephemeral key generation.
> > 
> > I have rewritten the section of code (lines 61-103), like so:
> > 
> > #else
> > #include <openssl/decoder.h>
> > int ssl_load_dh_params(SSL_CTX *ctx, struct conf **confs)
> > {
> > 
> > 	BIO *bio=NULL;
> > 	EVP_PKEY *pkey=NULL;
> > 	const char *ssl_dhfile=get_string(confs[OPT_SSL_DHFILE]);
> > 	
> > 	if(!(bio=BIO_new_file(ssl_dhfile, "r")))
> > 	{
> > 	
> > 		logp_ssl_err("Couldn't open ssl_dhfile: %s\n",
> 
> ssl_dhfile);
> 
> > 		return -1;
> > 	
> > 	}
> > 	
> > 	// Modern way - read as EVP_PKEY directly (preferred in 3.x).
> > 	pkey=PEM_read_bio_Parameters(bio, NULL);
> > 	BIO_free(bio);
> > 	if(!pkey)
> > 	{
> > 	
> > 		logp_ssl_err("Couldn't read DH parameters from
> 
> %s\n", ssl_dhfile);
> 
> > 		return -1;
> > 	
> > 	}
> > 	
> > 	// Transfer ownership to OpenSSL.
> > 	if(SSL_CTX_set0_tmp_dh_pkey(ctx, pkey)<=0)
> > 	{
> > 	
> > 		logp_ssl_err("Couldn't set DH parameters from
> 
> %s\n", ssl_dhfile);
> 
> > 		EVP_PKEY_free(pkey);
> > 		return -1;
> > 	
> > 	}
> > 	
> > 	// Success, openssl now owns pkey, do not free it here.
> > 	return 0;
> > 
> > }
> > #endif
> > 
> > I hope that this would prevent the hangs by loading the DH 
parameters
> 
> up
> 
> > front instead of leaving it to re-negotiation.
> > 
> > This is working for me in all my tests so far, but as I said, I am not
> > able
> > to get anything to hang as described by yourself.
> > 
> > I wonder whether somebody experiencing the issue is able to try this
> 
> code
> 
> > change on the server side and see if it fixes the issue?
> > 
> > Thank you for your patience with this annoying issue.
> > 
> > 
> > _______________________________________________
> > Burp-users mailing list
> > Bur...@li...
> > https://lists.sourceforge.net/lists/listinfo/burp-users