[mod_gnutls-devel] Certificates not always exported to environment

[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

> 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.

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.

> 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.

> 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

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