Ben, I'm pretty new to TLS, so please bear with me. I was thinking through what you said and I had a few questions. Couldn't you pull off the same DOS attack using the existing 16K message size today. The scale of the DOS attack would have to be larger as the packet size is smaller, but the vector of attack still exists today correct? On Mon, Dec 7, 2015 at 2:46 PM, Benjamin Kaduk <bkaduk at akamai.com> wrote: > On 12/07/2015 02:43 PM, Software Engineer 979 wrote: > > Hello, > > I'm currently developing an data transfer application using OpenSSL. The > application is required to securely transfer large amounts of data over a > low latency/high bandwidth network. The data being transferred lives in a > 3rd part application that uses 1 MB buffer to transfer data to my > application. When I hook OpenSSL into my application I notice an > appreciable decline in network throughput. I've traced the issue the > default TLS record size of 16K. The smaller record size causes the 3rd > party application's buffer to be segmented into 4 16K buffers per write and > the resulting overhead considerably slows things down. I've since modified > the version of OpenSSL that I'm using to support an arbitrary TLS record > size allowing OpenSSL to scale up to 1MB or larger TLS record size. Since > this change, my network throughput has dramatically increased (187% > degradation down to 33%). > > I subsequently checked the TLS RFC to determine why a 16K record size was > being used, and all could find was the following: > > length > The length (in bytes) of the following TLSCompressed.fragment. > > The length MUST NOT exceed 2^14 + 1024. > > The language here is pretty explicit stating that the length must not > exceed 16K (+ some change).Does anyone know the reason for this? Is there a > cryptographic reason why we shouldn't exceed this message size? Based on my > limited experiment, it would appear that a larger record size would benefit > low latency/high bandwidth networks. > > > The peer is required to buffer the entire record before processing it, at > at that point the data could be from an untrusted party/attacker. So the > limit is for protection against denial-of-service via resource exhaustion. > > -Ben > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151208/a5c7e3a3/attachment.html>
