[mod_gnutls-devel] Certificates not always exported to environment

Benny Baumann BenBE at geshi.org
Sat Feb 22 15:55:40 CET 2014


Hi,

Am 21.02.2014 20:09, schrieb Daniel Kahn Gillmor:
> On 02/21/2014 11:58 AM, Benny Baumann wrote:
>> I'm currently using 8K RSA keys which equals a handshake footprint of
>> about 7.5 KiB without and 9.5KiB with OCSP stapling (server to client).
>> The client in both cases gives another 0.5 to 1KiB - although here the
>> number of packets is more interesting.
> yep, that's a lot of data to push back and forth.  You'll get into more
> significant delays as the number of packets exceeds the TCP congestion
> window since it incurs more round-trips.  latency is probably more of an
> issue than bandwidth in many cases, since bandwidth is getting larger,
> but the speed of light has stayed pretty much the same, :P
That's too unfortunate. Couldn't we just invent faster light?
>> What about allowing the admin to choose but defaulting to 64KiB on the
>> server if not set.
> I think this is reasonable.  My proposal is to change the config
> directive GnuTLSExportCertificates.
>
> currently this directive takes either "off" or "on".  I propose to add a
> third option, which would be a number of kibibytes (or just bytes?  not
> sure which would be preferable, but i tend to think that kibibyte
> granularity is roughly the right scale to be thinking of this).
>
> So "off" would mean "no certificates exported", "on" would mean
> certificates exported to a maximum of 16 KiB each, and N would mean
> certificates exported to a maximum of N KiB each.  I think 64KiB is
> unreasonably high for a default because of the cost in terms of
> round-trips for such a series of connections, but i'm willing to support
> it for admins who require it and want to change the setting.
What's the default unit for Apache settings to specify sizes in? IIRC
most settings are given in bytes. If this isn't too hard to implement
I'd go for this. But given the maximum amount as a number and treating
on using a default sounds fine to me. 16KiB looks fine too.
>
> In the event that a certificate is not exported, we can also expose that
> to the CGI process explicitly (by setting the environment variable to a
> fixed string like "GNUTLS_CERTIFICATE_SIZE_LIMIT_EXCEEDED"), in addition
> to logging the error as we currently do.
Seems fine to me.
>> Furthermore you should be aware that by the time you ask to export the
>> certificate you already have it loaded by GnuTLS in memory. Therefore
>> resulting in a "memory usage amplification attack" with factor ~2.4
>> which requires the client to send you megabytes of data beforehand. I'm
>> not sure of the record structure of TLS regarding the Client and Server
>> Hello frames, but IIRC they might be limited in size - and thus probably
>> mitigating the attack forreally big certificates.
> right, there does need to be mitigation earlier in general; but we
> shouldn't allow the memory amplification by default anyway.
Ack.
>> Suggestion: Ask for required size for export, check against (per-vhost)
>> setting for the maximum exportable size, allocate a buffer large enough
>> to hold the exported value and export a value indicating size
>> restriction violation otherwise. That way all the initially raised
>> concerns should be properly addressed.
> I think what i've proposed above aligns with your suggestion.  Does it
> meet your concerns?  i'll try to get the test suite fleshed out to cover
> these cases too.
>
> 	--dkg
>
Regards,
BenBE.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140222/f158ddbd/attachment.sig>


More information about the mod_gnutls-devel mailing list