I'm also a bit confused at how this became the limiting factor for the application in question. https://datatracker.ietf.org/doc/html/draft-ietf-emu-eaptlscert-08 has some discussion of how large certificates can cause issues for EAP (as well as some guidance to EAP deployments as to how to reduce the scale of the issues), which suggests that most of the time there is already some buffering going on at a 1-2k chunk size just based on the limits of the EAP exchange's MTU. (The parties in the exchange have to transmit one chunk at a time and get an ACK back before transmitting the next chunk, and once that handshake flight is finished the process is reversed with the other party sending a chunk at a time.) A BIO-layer buffer would be between that and the libssl handshake buffering, and as you describe, it should still get the data through, just maybe with a slight inefficiency. -Ben On Wed, Oct 20, 2021 at 02:30:19PM +0100, Matt Caswell wrote: > Your scenario is still not quite clear to me. > > It sounds like you are using a BIO_f_buffer() BIO to buffer data. This is on > the server side right? Are you encountering this problem for server writes? > Since you are talking about the certificate chain, I assume you are > referring to the server writing that chain. > > libssl itself also uses a BIO_f_buffer() internally for writes during the > handshake. It's not clear to me whether you are referring to the internal > libssl buffering BIO, or one that you have created? > > Either way, the effect of the buffering BIO during writes is that a 4k > buffer is used by default. If data is written that is less than 4k in length > then it is held in the buffer until either the BIO is "flushed" or the > buffer is filled. In the event the buffer gets filled then it is > automatically flushed, and any remaining data gets buffered. > > The only effect of changing the buffer size should be to decrease the > frequency that the buffer gets filled and automatic flushes occur. It sounds > like by trying to increase the buffer size you are seeking to avoid "parial" > writes where only part of the data is flushed and the remainder is held back > for sending later when the buffer is next filled or flushed. This should not > normally make any difference to the correct operation of the protocol > (except for efficiency) although it does depend on what happens "downstream" > of the buffering bio and how partial writes get sent to the peer. > > It sounds like things are not quite working correctly for you when "partial" > writes occur. This sounds like a potential problem in the BIO chain > downstream of libssl (i.e. in your application). > > Matt > > On 20/10/2021 12:34, Vishal Sinha wrote: > > Hi Matt > > > > The certificate is not large as such. But since it's a chain, the > > overall size crosses 4k. We used BIO_set_write_buffer_size() API to > > increase the size from 4k to 8k of the BIO buffer in SSL context. > > > > Regards > > Vishal > > > > > > On Wed, Oct 20, 2021 at 3:26 PM Vishal Sinha <vishals1991@xxxxxxxxx > > <mailto:vishals1991@xxxxxxxxx>> wrote: > > > > Hi > > > > We are using openssl 1.1.1c version on our client and server. Client > > and Server are doing EAP-TLS authentication using certificates which > > are more than 4k in size (using 1 root CA and 2 intermediate CAs). > > We noticed that the server is not able to handle it gracefully due > > to insufficient buffer size during SSL handshake and hence > > authentication fails. To solve this issue, we increased the buffer > > size to 8k programmatically and authentication passed. Is there any > > other way to solve this problem? > > > > Regards > > Vishal > >
