[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the "crime" attack on TLS
From: |
Nikos Mavrogiannopoulos |
Subject: |
Re: the "crime" attack on TLS |
Date: |
Sat, 15 Sep 2012 12:11:16 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 |
On 09/15/2012 02:30 AM, Phil Pennock wrote:
> But yes, OpenSSL has the BIO abstraction, GnuTLS just provides
> gnutls_record_send() and friends. I know what you mean here, but where
> in OpenSSL you can use BIO_flush(), in GnuTLS, you could have a similar
> flush call; or a call which sets a flag in gnutls_session_t which will
> be cleared with the next send, to coerce the change: on next send,
> Z_FINISH the current compression block and start a new one. It's that,
> or add gnutls_record_send_flagged() which takes a 4th parameter.
Is any advantage in having such a fine-tuning? I think a simpler
approach of allowing either stateless compression with FULL_FLUSH, and
another option that allows SYNC_FLUSH would be sufficient for most uses.
>> It's operation is
>> comparable to unix sockets. You provide data for sending in each
>> record. That data is then compressed. I'm thinking whether it makes
>> sense to use Z_FULL_FLUSH on each record boundary, or drop compression
>> altogether.
>
> Given the size of a record, a full flush on every send would probably
> work out larger than no compression for most workloads, surely? You
> still need to send the Huffman tree as overhead.
A preliminary test with the Z_FULL_FLUSH option doesn't show a much
larger overhead (packets are typically few bytes larger).
regards,
Nikos