GnuTLS (libgrypt really) and Postfix

[leichter_jerrold at emc.com]

| >> I disagree strongly here.  Any code which detects an impossible state
| >> or an error clearly due to a programming error by the caller should
| >> die as soon as possible.  
| >
| >That is a remarkably unprofessional suggestion.  I hope the people
| >who write software for autopilots, pacemakers, antilock brakes,
| >etc. do not follow this suggestion.
| 
| This just shows the dangers of over-generalization.
And *this* shows the danger of false dichotomies.

| Of course, we have to decide which is more important: integrity,
| or availability.  I suspect that in the overwhelming majority (perhaps
| all) of the cases where libgcrypt is used, integrity is more important
| than availability.  If that is true, well, if in doubt, it's better to
| fail closed than to fail open.
| 
| You rightly points out that there are important applications where
| availability is more important than integrity.  However, I suspect
| those cases are not too common when building Internet-connected desktop
| applications.
A library can't possibly know what kind of applications it will be part of!

| I think the attitude that it's better to die than to risk letting an
| attacker take control of the crypto library is defensible, in many cases.
| Of course, it would be better for a crypto library to document this
| assumption explicitly than to leave it up to users to discover it the
| hard way, but I would not agree with the suggestion that this "exit before
| failing open" stance is always inappropriate.
No, the "library thinks it can call exit()" is *always* inappropriate.

There are reasonable ways to deal with this kind of thing that are just as
safe, but allow general-purpose use.  For example:

	1.  On an error like this, put the encrypted connection (or whatever
		it is) into a permanent error state.  Any further calls act
as
		if the connection had been closed.  Any incoming or outgoing
		data is erased and discarded.  Any keying material is
		immediately erased and discarded.  Of course, return error
		statuses to the caller appropriately.  (You don't return
		error statuses?  Then you're already talking about a poor
		design.  Note that there's a world of difference between
		returning an error status *locally* and sending it over the
		wire.  The latter can turn your code into an oracle.  The
		former ... well, unless you're writing a closed-source
		library for a secret protocol and you assume your code and
		protocol can't be reverse-engineered, the local user can
		*always* get this information somehow.)

	2.  When such an error occurs, "throw an exception".  In a language
		that supports exceptions as such (C++, Java), use the native
		mechanism.  For languages that don't support exceptions, you
		can call a function through a pointer.  By default, the
		function can call, or simply be, exit(); but the user can
		specify his own function.  The function *must* be allowed
		to do something other than call exit()!

		In general, this technique has to be combined with technique
		1.

Granted, a user *could* write code that leaked important information upon
being informed of an error.  But he would have to try.  And, frankly,
there's
not a damn thing you can do to *prevent* that.  Most Unix systems these days
allow you to interpolate functions over standard library functions.  You
think you're calling exit(), or invoking kill()?  Hah, I've replaced them
with
my own functions.  So there.  (No interpolation?  Patching compiled code to
change where a function call goes is pretty easy.)

Of course, all this is nonsensical for an open-source library anyway!

You're kidding yourself if you think *any* programming practice will protect
you against a programmer who needs his program to do something that you
consider a bad idea.  But the whole approach is fundamentally wrong-headed.
The user of your library is *not* your enemy.  You should be cooperating
with
him, not trying to box him in.  If you treat him as your enemy, he'll either
choose another library - or find a way to work around your obstinacy.

							-- Jerry


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com